Allow parallel irrigation (Sprinkler integration)

[soeffi]

Describe the problem you have/What new integration you would like I'd like to be able to start zones in parallel with auto-advance. Note: This is not the same as #1982, as I'd like to have different durations for the zones, so I can't make it a group as suggested there.

Please describe your use case for this integration and alternatives you've tried:

• I have a drip line, which has very low flow but needs to stay on for quite some time. I'd like to activate that while the different lawn irrigation zones are active (with auto-advance) in order to minimize pump run time, saving on energy cost.
• I have two zones with lower flow requirements. Want to run them in parallel to save irrigation time and again energy cost of pump runtime.

Additional context A possible way of implementation (inspired by MS Powerpoint's "start with previous" setting in animation timing editor): Add boolean parameter "is_parallel" to a valve configuration. If set to true, the auto-advance feature will activate the next valve in sequence immediately when the current one becomes active.

In other words, "is_parallel" determines, whether auto-advance should proceed in the sequence when then irrigation of the given zone ends (is_parallel = false, default) or start (is_parallel = true).

In my use case I'd then be able to configure the drip line as follows:

sprinkler:
  ...
    valves:
      - valve_switch: "Drip line"
        is_parallel: true
      - valve_switch: "Lawn 1"
      - valve_switch: "Lawn 2"
      - valve_switch: "Lawn 3"

"Drip line" is activated first in sequence, as usual. With auto-advance on and "is_parallel" is set, "Lawn 1" shall be activated immediately as well. When "Lawn 1" is done, auto-advance will activate "Lawn 2", and so on. Drip line has a much longer duration an will keep running along with Lawn 1, 2 and 3. When "Drip line" is done, nothing happens.

[mill1000]

What about configuring 2 controllers? IIRC, the controllers will share the pump (see the Note section under this example)

[soeffi]

Well, yes, in fact that's a workaround, and in particular for the drip line vs lawn it will work, with the overhead of having to synchronize the two controller's start times manually (probably could use a user defined switch that enables both simultaneously.

Nevertheless, my second use case is more advanced in that respect, as stated I'd like to run "Lawn 3" and "Lawn 4" valves in parallel (but with different duration). I want them to run in parallel to minimize pump run time, and they should run after the first two valves (they are low priority and I'll skip those when I run low on water after Lawn 1&2).

Doing so with my suggested extension above would be:

  ...
    valves:
      - valve_switch: "Lawn 1"
      - valve_switch: "Lawn 2"
      - valve_switch: "Lawn 3"
        is_parallel: true
      - valve_switch: "Lawn 4"

With a separate controller for lawn 4, I'd have to use some (probably fragile) magic, to activate that separate controller when Lawn 3 is started. Plus, it just feels wrong to not have all lawn circuits in one controller.

[kbx81]

First, please see this comment and this comment.

The in_parallel flag is a good idea, although implementing this will still require a significant re-working of how its internal scheduling/state machine works. There are requests for a couple of other features which will likely also require re-working these bits; it'll likely make more sense to work this in whenever that work is done.

with the overhead of having to synchronize the two controller's start times manually

This is a really trivial task. 😉

it just feels wrong to not have all lawn circuits in one controller

Hard disagree. 😇 The purpose of the component was to handle all of the logic and complexity of ensuring that any given valve/zone/circuit:

• operates exclusively at any given time, and
• is always switched off after some duration.

In general, if you want different types of systems (drip vs. spray, for example) to run in parallel, there should be different controllers for each type of system since they're used/operated somewhat differently from each other. In fact, this was the primary motivation for supporting common pumps/main valves across controller instances. Even so, your request makes sense and I do indeed think it's a good idea. Stay tuned. 🙂

[soeffi]

Hard disagree. The purpose of the component was to handle all of the logic and complexity of ensuring that any given valve/zone/circuit:

• operates exclusively at any given time, and
• is always switched off after some duration.

Well, the first one is actually already "broken" with the overlap setting ;-) And in fact, I still want this, unless it's told explicitly not to do so. But I see the point, that it's currently not covered by the state machines' architecture

In general, if you want different types of systems (drip vs. spray, for example) to run in parallel, there should be different controllers for each type of system

Understood, and it makes sense in my drip line vs lawn spray case. Not so much for the lawn circuits, though, they are same technologies, but I still want slightly different durations (less evaporation on one strip, slightly different spacing of nozzles, etc.).

Even so, your request makes sense and I do indeed think it's a good idea.

Great to hear :-) In fact, I read the two comments that you referenced and tried to answer all those questions with my initial post (expexcted behavior, YAML config example, etc.) as much as possible. I guess I left out a few details, so let me add:

How does a full cycle of the system behave?

Parallel activation as described above. Depending on how you implemented the transitions of the controller's state machine, the end of the cycle cannot rely on the last valve in the list completing, since there could still be another valve active (which had been started previously with in_parallel set). Need to check all the valves' state machines to be completed.

Queues: Could either be left fully sequential in a first step. Or implement a similar mechanism. allowing parallel start.

How would features such as the queue and cycle repeating integrate with this behavior?

With above logic to detect the full cycle being complete: Wait for cycle completion, then restart if repeat is set.

This is a really trivial task

That's my lack of knowledge of manually configuring / scripting ESPhome and home assistant. If I may ask - how do you activate your irrigation on schedule? I was thinking about the scheduler component & card, as it allows scheduling in the front-end (in contrast to manually configured automations).

If I do want both controllers activate in parallel, I'd add a switch that basically activates/deactivates both controllers using the on_turn_on / on_turn_off action - or is there a better way of doing it?

Anyway, thanks a lot for that great piece of code :-)

[mill1000]

That's my lack of knowledge of manually configuring / scripting ESPhome and home assistant. If I may ask - how do you activate your irrigation on schedule? I was thinking about the scheduler component & card, as it allows scheduling in the front-end (in contrast to manually configured automations).

It could be as simple as an on_time trigger with the following actions (I think)

on_...:
  then:
    - sprinkler.start_full_cycle: sprinkler_ctrlr_1
    - sprinkler.start_full_cycle: sprinkler_ctrlr_2

Or more complex with an input_datetime in HA imported as a sensor to compare against the current time in a lambda (I could post an example in a few days).

Or if/when #2267 is implemented, ESPHome can export a datetime entity to HA and again lambdas could make comparisons.

[kbx81]

That's my lack of knowledge of manually configuring / scripting ESPhome and home assistant. If I may ask - how do you activate your irrigation on schedule? I was thinking about the scheduler component & card, as it allows scheduling in the front-end (in contrast to manually configured automations).

I have an automation in Node-Red that uses a schedex node to turn on the sprinkler controller's main switch -- nothing crazy complex. But, I know..."what if HA is down?!?" I just make sure that doesn't happen here. 😉

If I do want both controllers activate in parallel, I'd add a switch that basically activates/deactivates both controllers using the on_turn_on / on_turn_off action - or is there a better way of doing it?

That's certainly one option (as is similar to that suggested above). If you build an automation on the HA side as I did, you'd just have it switch on both controllers together.

Anyway, thanks a lot for that great piece of code :-)

You're very welcome, I'm happy that you are using it!

[soeffi]

It could be as simple as an on_time trigger with the following actions

If I understand correctly, there is currently no way to have the on_time schedule configurable via entities, right? All examples I found so far were using custom lambdas for comparison. #2267 would be a nice basis to make schedules editable at run-time...

Edit: Just found #2100, requesting exactly that.

But, I know..."what if HA is down?!?" I just make sure that doesn't happen here.

Exactly :-)