Direction check: cycle/soak scheduling, queueing, well gate, and Hydrawise adapter

[fpytloun]

Hi, first of all: I like this project. It looks clean, test-heavy, and much more maintainable than the YAML-based smart irrigation controller I currently run in Home Assistant.

I am considering replacing my current setup with NeverDry, but I am missing a few capabilities. I would be happy to contribute them if they fit the direction of the project. Before starting a larger PR, I wanted to check whether these ideas make sense upstream.

1. Cycle / soak scheduling

My current controller does not run one long irrigation pass. It splits watering into cycles and lets water soak in between runs.

Example:

• lawn: 5 cycles × 6 min per zone
• terrace bed: 3 cycles × 1 min
• minimum soak time per zone, e.g. 15 min

The important part is that soak time should be smart: time spent watering other zones, waiting for a pump/well to recover, or waiting in the queue should all count toward soak time.

This helps avoid runoff and local puddles, especially on clay soil or sloped/uneven areas.

2. Queue / scheduler behavior

It would be useful to have a real queue/scheduler rather than treating an irrigation run as one blocking operation.

What I would need:

• scheduled/manual/reactive jobs can queue behind each other
• the scheduler picks the next eligible zone segment
• a zone is eligible only if its soak time has elapsed
• overlapping schedules should queue, not overwrite or disappear

This would also make cycle/soak behavior much easier to reason about.

3. Pump / well recovery gate

My irrigation is limited by a well. I currently pause irrigation below one threshold and resume above another, for example:

• pause below 55%
• resume above 90%

Waiting for the well should not reset the irrigation job. It should simply pause the scheduler, and the elapsed time should count as soak time.

I think this could be generic: any HA sensor + pause/resume thresholds, not specifically a well integration.

4. Actuator abstraction / Hydrawise adapter

Another thing I would like to explore is a direct Hydrawise adapter.

Instead of relying only on Home Assistant's Hydrawise integration, NeverDry could have a cleaner actuator abstraction, for example:

• HA switch actuator
• MQTT actuator
• Hydrawise API actuator

For Hydrawise, the adapter could start a zone, poll state, and fetch actual runtime/water metrics if available. That would make delivery accounting much more reliable than relying only on estimated runtime.

Question

Would these fit the intended direction of NeverDry?

If yes, I can start with a smaller architectural PR first, probably one of:

1. actuator abstraction while keeping current switch behavior unchanged
2. queue/scheduler model
3. pump/well gate
4. cycle/soak scheduling

I would prefer to contribute this properly upstream and share with others rather than continue growing a private YAML controller or making my own integration if the direction makes sense here.

[drake69]

Hi @fpytloun, thanks for the detailed write-up — you've clearly thought this through, and several of these ideas align with where I want to take NeverDry.

Abstractions in general — fully agree, this is the right direction.

Intelligent retries + valve close certainty — this is the part I'm most protective of. NeverDry already has three safety layers (delivery timeout → ValveOperator watchdog → hardware
interlock). Any refactor must keep this contract intact: if a valve can't be confirmed closed, the user gets an alert. Non-negotiable.

Cycle & soak — I like this more than I initially thought. It can be done per zone with just two optional fields: max segment duration and soak time. If not set, the current behaviour is unchanged. With both sets, the controller splits the calculated run automatically. Keeps the UI light, covers the main use case (clay soils, slopes). I'll add this.

Binary sensor gate (well pump, etc.) — good idea. I'd add two things to make it production-ready: (1) notify the user when a run is postponed, not just skip silently; (2) a maximum wait
window — if the sensor doesn't come back within N hours, skip and notify rather than block indefinitely. Worth noting: if the sensor drops mid-run, the existing valve safety layers
already handle closure and alerting.

One thing worth saying explicitly: the deficit model is event-driven on temperature and rain, not on irrigation runs. Postponing or splitting a run doesn't affect how the deficit
accumulates — the math stays correct regardless.

Queue/scheduler (your point 2) — I understand the appeal, and the cycle/soak efficiency gain is real (soak time of one zone covered by irrigating another). That said, for the target
user (hobbyist, 2–5 zones), I think it's more complex than it earns right now — both to implement and to reason about ("why isn't my zone running yet?"). My plan: ship the simple cycle
& soak first; if the queue model gets traction from more users, I'd revisit it as a proper scheduler rewrite.

What's your take — does the simpler cycle & soak cover your actual use case, or is the queue model load-bearing for something specific you have in mind?

[fpytloun]

Thanks, that makes sense.

For my setup, I think the deciding point is whether NeverDry wants to grow into a slightly more general irrigation controller, or stay intentionally simple for small hobby installations.

Simple cycle/soak is useful, but for me it is probably not enough on its own. The load-bearing parts are:

• a pause/resume gate for a well or pump capacity sensor
• a path toward actuator abstraction, ideally so Hydrawise API support can be added cleanly
• not blocking a future scheduler/queue design, even if it is not implemented first

I do not want to push complexity into the project if that is not your goal. But if this direction fits, I would rather contribute properly here than keep growing my private YAML controller.

So the real question is: would you be open to NeverDry becoming that kind of controller over time, or would you prefer to keep it deliberately simpler?

[drake69]

Yes, I think NeverDry can grow into a general controller along the lines you describe. The guiding principle would be: a new user sets up a zone in three fields and never sees a pump gate or actuator backend option unless they go looking. Advanced features are there for experienced users, but never in the critical path.

Your three points — pause/resume gate, actuator abstraction, and a non-blocking path toward a proper scheduler — align well with where I'd want to take this. Actuator abstraction feels like the right first step, since it's foundational and invisible to basic users.

If you'd like to contribute, the abstraction layer would be a good place to start. Are you thinking of a PR for that, or would you prefer to start with a design discussion first?

have a good afternoon

[fpytloun]

Thanks, that sounds like a good direction.

I think I need to take a bit more time before committing to it. My current YAML-based controller is already working reasonably well, so I want to avoid pushing NeverDry too far toward my specific setup unless I am sure this is the right long-term move.

If I do move forward, I would probably not start with a tiny change — I would want to implement the abstraction properly and make sure it does not weaken the existing valve safety model.

For now I’ll keep following the project and may come back to this when I have enough time to do it properly.

Thanks again for the thoughtful response.

[drake69]

I like the scheduler Idea, one well as one pipe is the same concept, a unique shared resource, could be nice to limit the scheduler within sunset and sunrise. And probably the well or sensor availability could be per zone, as the scheduler. Just an idea.