Break before Make Struggle

Folks, I am trying to set “Break before Make” logic with two relays. They should be idiot (me) proof , meaning that they must never be turned on simultaneously (otherwise I may blow my fuses up).

Tried different methods with configuration.yaml and automations, but nothing worked for me. My best effort was that the second relay will try to be energized and will immediately turn off, which is wrong.

Appreciate ideas and comments.

Are these relays that can only be turned on via Home Assistant, or do they also have a manual switch to turn them on. For the latter, the best you’ll ever do is to quickly turn one off it you sense the other turn on. That will probably be too late though. Maybe some tape over the manual switches?

If the devices can only be turned on and off by HA, anywhere you have an automation that would turn one of them on, you could have a condition checking to see if the other is off. If that condition is met, the automation will run. If not, it won’t. Without more details (even the YAML of you’re best effort), it’s hard to say what alternate strategies might be available.

1 Like

Thanks. These relays will be only controlled from the HA, and therefore I am trying to set the condition that if one of tghem is ON, the second will never go ON, too. Sounds simple but somehow I may not find the way to do it.

I may of course add extra regular relay to use its Aux. contacts, but something tells me that there must be a more elegant SW way.

Which integration is providing the relays?

If you are using ESPHome then there is an interlock feature for two switches (connected to the same ESP) that will do what you want. Though you should read the warning.

SPDT or DPDT relays are the safest way.

If the relays are provided by another integration then you can create template switches that ensure the other switch is off before turning on. e.g.

configuration.yaml

template:
  - switch:
      - name: Switch 1 Safe
        state: "{{ is_state('switch.relay_1', 'on') }}"
        turn_on:
          - action: switch.turn_off
            target:
              entity_id: switch.relay_2
          - wait_template: "{{ is_state('switch.relay_2', 'off') }}"
            timeout: "00:00:05" 
            continue_on_timeout: false # if 5 seconds pass and  relay 2 has not turned off then do nothing
          - action: switch.turn_on
            target:
              entity_id: switch.relay_1
        turn_off:
          - action: switch.turn_off
            target:
              entity_id: switch.relay_1

  - switch:
      - name: Switch 2 Safe
        state: "{{ is_state('switch.relay_2', 'on') }}"
        turn_on:
          - action: switch.turn_off
            target:
              entity_id: switch.relay_1
          - wait_template: "{{ is_state('switch.relay_1', 'off') }}"
            timeout: "00:00:05" 
            continue_on_timeout: false # if 5 seconds pass and  relay 1 has not turned off then do nothing
          - action: switch.turn_on
            target:
              entity_id: switch.relay_2
        turn_off:
          - action: switch.turn_off
            target:
              entity_id: switch.relay_2
1 Like

Many thanks, will try the second YAML solution. And yes, of course I am aware about the consequencies of the SW solution - thanks again.

1 Like

What happens in power interruption, startup, shutdown, and brownout situations? If you are switching batteries with kilowatts, you never have them shorted, even for a nanosecond.

Use SPDT (double throw) relays. Use the NO (normally open) pole on one, and the NC (normally closed) on the other. Invert the NC relay status in software in your automations. That way a default hardware situation common to both relays will always have opposite values.

Alternatively, a third relay, acting as a master switch to only enable one of the slave relays to operate is the only failsafe way to ensure software clashes do not cause untoward situations.

You haven’t said what your use-case scenario is. In industrial control situations, multi-way, multi-pole contactors are designed for specifically this situation, make before break, break before make, etc. Similar to relays but often of high current and voltage capacity and often far more expensive. How much molten metal can you afford if your yaml doesn’t allow for all scenarios in real life?