Exclusive switch -- only one switch of a group on at a time

[busman]

I have 20 switches that each run a water value (irrigation stations). I plan on using the Irrigation Unlimited integration, but want to add some basic safeguards.

First, I only want to run one value at a time. Any suggestions how to implement? Anything more clever than an automation for each one that turns all the others off – so 20 automations each listing the other 19 as turn-off actions?

Second, I want to prevent any single switch remaining on more than X minutes. I tried to create a group and test for time:

platform: state
entity_id:
  - switch.all_water_valves
to: "on"
for:
  hours: 1
  minutes: 0
  seconds: 0

but of course that would only work if every switch is off before turning one on because the group time is the total time “on”, and group is “on” is when any switch is on.

Any options other than an automation for each switch?

Thanks,

[123 (Taras)]

This might meet your needs. It’s a 5-zone irrigation controller but can be modified to support more zones.

Complex Automations - State Machine

Entities Here’s a summary of all the entities required for this 5-zone controller: One timer to countdown a zone’s duration. One counter to keep track of which zone to process. One input_select to control overall operation (on/off/pause). One group containing all the zone switches. Five input_booleans, one per zone to indicate its enabled/disabled status. Five input_datetimes, one per zone to indicate its duration (in hours and minutes). Five more input_booleans, one per zone representing eac…

[parautenbach (Pieter Rautenbach)]

To further aid your search, this is called an interlock (more specifically, it would be called a software interlock).

On my phone, but in this case you could make an automation that triggers when any switch is turned on, and as the action turn all the others off. Note that there will be a small bit of overlap which could cause things such as water hammer. I’ve seen many great solutions from Taras. Perhaps they have something like this already at hand.

The best option for interlocks are to use hardware interlocks, since you can then easier prevent another switch from turning on before the other has turned off. I used e.g. a Sonoff CH4 Pro for irrigation which has a hardware interlock to control 4 valves, running ESPHome’s sprinkler component. This also has the benefit of making it a standalone device, but with control from HA.

[busman]

Yes, the overlap is part of the issue. Essentially, I want to override the switch method and when it is called first turn off all the valves, then turn on the requested sprinkler valve.

I did try a “kludge” where I created input_boolean helpers to indirectly call the valve switches. That way I could run the code to turn off all valves before turning on the requested valve.

Here switch.sprinkler_valve_group is a group helper with all the valves, and the automation below first turns that off (therefore turning all valves off), then turns on the requested sprinkler valve (by string replacing the input_boolean name).

This is just a test with three valves:

alias: "Test: trigger on any switch"
description: ""
trigger:
  - platform: state
    entity_id:
      - input_boolean.toggle_1
      - input_boolean.toggle_2
      - input_boolean.toggle_3
    to: "on"
condition: []
action:
  - service: switch.turn_off
    target:
      entity_id: switch.sprinkler_valve_group
    data: {}
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: input_boolean.turn_on
    target:
      entity_id: |
        {{ trigger.entity_id }}
  - service: switch.turn_on
    target:
      entity_id: >
        {{ trigger.entity_id|replace('input_boolean.toggle','switch.sprinkler_valve') }}
mode: single

So, input_boolean.toggle_2 turns on switch.sprinkler_valve_2.

That delay and turning on the input_boolean (which is what triggered the automation) is in case the valve is already on (see next automation).

Now, to keep the input_boolean helpers in sync, need to turn those off when a valve is turned off:

alias: "Test: turn off helper"
description: ""
trigger:
  - platform: state
    entity_id:
      - switch.sprinkler_valve_1
      - switch.sprinkler_valve_2
      - switch.sprinkler_valve_2
    to: "off"
condition: []
action:
  - service: input_boolean.turn_off
    target:
      entity_id: >
        {{ trigger.entity_id|replace('switch.sprinkler_valve','input_boolean.toggle') }}
    data: {}
mode: queued

In other words, when the first automation calls the group helper switch.sprinkler_valve_group and turns off all the valves, each one then triggers this second automation and turns off the associated input_boolean helper.

All this feels very hackish and fragile and not worth actually using.

One disappointing thing is that it would be nice to trigger on the group helper, but then trigger.entity_id is the group’s ID, not the actual member of the group. It would be handy to abstract away the collection of valves.

Also, it doesn’t appear I can create a group helper for a collection of input_boolean helpers.

Have to rethink the approach or give up.

[parautenbach (Pieter Rautenbach)]

The principle of input booleans as indirect switches is probably the only way to go about this. I only glanced over it now, but I think Taras’ link solves this as elegant as one can.

(Amazing job, Taras, and a great write-up.)

[rgc99]

Started down this path a few years back and things get messy very quickly especially as the system grows. I ended up creating the Irrigation Unlimited component.

You can setup a Sequence to run the valves (zones) one-at-a-time. There can be a delay between zones which can be negative, turn the next one on before stopping the current to prevent hammering. There are safety constraints on the valves for min and max run time. Schedule by time of day, sun events, cron if you so wish. Handy companion card that works on mobile devices.

[busman]

Yes, I’m planning on using your integration. I was trying to do some lower-level protections, but maybe it’s silly to duplicate. With Irrigation Unlimited if I turn on a valve in HA directly will those safety constraints catch that situation?

Is this thread the best place to ask general questions?

Thanks

[rgc99]

No as there are many ways to turn on the valve. There is a check back facility which checks that the zone turned on or off in HA as expected. Probably best not to directly manipulate the valve and let the component take care of it. Schedule the run or use a manual run which will handle all the higher level logic. A thought - you could create a script that monitors the valve entity and compares it to that of the Irrigation Unlimited entity, they should be in sync.

The main concern is much lower. What happens if the valve is turned on and then there is a catastrophic failure; Power, internet/cloud, communications, the raspberry PI driving it all melts down. For me, I have a dead man switch on the valve. Basically a run-on timer that cuts the power after 1 hour.

Yes, Thats a good place to ask away.

Regards