Two-way switch with two one-way switches

Configuration
21

If neo_1 is turned on, the automation’s action will turn on neo_2:

  action:
    - data:
        entity_id: 
          - switch.shenzhen_neo_1
          - switch.shenzhen_neo_2
      service: switch.turn_on

Which will trigger the same automation (i.e. self-referential).

  trigger:
    - entity_id: 
        - switch.shenzhen_neo_1
        - switch.shenzhen_neo_2

In fact, this is also how the ‘all-in-one’ version of the automation works. Theoretically, it shouldn’t be a problem because the first execution of the automation is done so it shouldn’t be stepping on its own toes.

Nevertheless, in practice, it doesn’t work according to this clean theory (not for me or the OP). If you tell me that the all-in-one version works flawlessly for you, then there’s something specific to our systems that is causing this misbehavior.

Here’s the all-in-one version that definitely fails to work for me. Initially, turning on one light will turn on the second one. However, turning the first light off causes the second one to blink twice then both lights come on. Nothing in the automation’s code suggests it should behave this way.

- alias: 'Sync Lights'
  trigger:
  - platform: state
    entity_id: switch.shenzhen_neo_1, switch.shenzhen_neo_2
  action:
  - service_template: "switch.turn_{{trigger.to_state.state}}"
    data_template:
      entity_id: "switch.shenzhen_neo_{{'2' if trigger.to_state.object_id[-1:] == '1' else '1'}}"
22

I confirm this solution works for me. There is no repeated effect at all again. Thank you very much.

1 Like
23

Any news on this? Have several stairs that need Two-Way switching and cant understand why its so dificult to do something that with smart devices should be really easy :confused:

btw, tried all the above automations.

24

The above automations will only work if you named the switches xxxx_1 and xxxx_2. Did you fully read these automations? If so, you’d know they are streamlined for the shortest possible automation, not necessarily easy to understand without reading the full thread (I.e. not skimming it).

Making an automation by itself is simple, when one switch turns on the other turns on. Use the automation editor if this thread is too complicated. You’ll have 4 automations per light pair:

  1. When light a turns on, turn on light b.
  2. When light a turns off, turn off light b.
  3. When light b turns on, turn on light a.
  4. When light b turns off, turn off light a.

If you want to use only 1 automation, FULLY read this thread and understand what’s going on. It will require entity_id renaming.

25

Yes i changed the entity to reflect my 2 switchs, and like i said it worked to a extent, it would turn on the light and righ after turn it off, and sometimes go on a loop of turn on/off.
Will read everything again carefully, maybe missed something.

26

Got it working.
Still if they would make a new rule for when a switch on a group turns on everything on that group would turn on, there would be mutch less confusion, less scripts/automations, in my 2 cents.

27

mind sharing your code?

28

Would you mind sharing what you have done, or do you remember what you did wrong?

I’m seeing exactly the same thing you mentioned in an earlier post. Once a switch turns on, then they both go into a loop going on / off / on forever.

I have two switches:
switch.hallway_1_switch (a 1-gang switch)
switch_hallway_2_switch (a 2-gang switch)

The actual entity I want to control on the 2-gang one is switch_hallway_2_switch_2

So I modified the above template with:

alias: 'Hallway 2-way'
trigger:
- platform: state
  entity_id: switch.hallway_1_switch, switch.hallway_2_switch_2
action:
- service_template: "switch.turn_{{trigger.to_state.state}}"
  data_template:
    entity_id: "switch.hallway_{{'1_switch' if trigger.to_state.object_id[-1:] == '2' else '2_switch_2'}}"

Now I’ve also tried the same naming the device switch.shenzhen_neo_1 and switch.shenzhen_neo_2 respectively, And I’m always seeing the same thing as above ; on/off/on/off super quick without ever ending.

Adding a 1s delay in action fixes the problem, but this is my main hallway and 1s delay between the time you press a button, and the light turning on is just too weird.

any ideas?

29

Are you running 0.113? If so, make your mode single and add the 1 second delay after your service.

30

0.112.4

I mentioned above that I added a 1s delay, but this isn’t very good for my use. This is used for our entrance hallway, and that would add 1s delay between turning the switch in and actually having the light turning on.

Unfortunately, the actual lights are actually connected to the secondary switch.

For now I’ve done two automation, one with a trigger if either of the switch change to off, and the other if either switch nto on.
And if so, set both switches to the new state.

I now longer get the on/off/repeat forever issue. But this is cumbersome to maintain and replicate.

I’m rather surprised HA doesn’t have a simple way to emulate 2-way switches. Smartthings let you join the switches to a group, and the state will be automatically replicated across all members.

31

Or is 0.113 adding a new mode of operation here? Reading the changelog right now.

32

Yes, in 113 if you add the delay at the end of the automation, it cannot fire again within 1 second but will fire immediately when clicked.

1 Like
33

I see, awesome, will try first thing tomorrow morning

34

Hi.

I can confirm that using mode: single and a delay no longer cause the system to switch on/off repetitively, however it doesn’t behave in what you would expect at all

alias: 'Hallway 2-way'
trigger:
- platform: state
  entity_id: switch.shenzhen_neo_1, switch.shenzhen_neo_2
mode: single
action:
- service_template: "switch.turn_{{trigger.to_state.state}}"
  data_template:
    entity_id: "switch.shenzhen_neo_{{'2' if trigger.to_state.object_id[-1:] == '1' else '1'}}"
- delay:
    seconds: 1

it doesn’t achieve:

When switch a turns on, turn on switch b.
When switch a turns off, turn off switch b.
When switch b turns on, turn on switch a.
When switch b turns off, turn off switch a.

What it does is make switch a be always the opposite of switch b.

It does achieve a 2-way switch, pressing either a or b will turn off the light as expected ; but how it achieves it is not desirable. The switches have a little LED indicating if they are on of off: blue == off; red == on.

So what happens now is that the light of one switch is always contrary to the state of the light.

It’s puzzling, because I can’t explain looking at the template why it would behave that way.
We are switching the second switch to the state the first switch is switching to.

so if I turn switch a from off to on; then trigger.to_state.state should be on; and yet it turn the other switch off.

what’s going on?

35

If these are zwave switches, couldn’t this be resolved with just scenes?

36

They are zigbee; but I don’t see how setting a scene could achieve that

Plus I have other devices I’d like to sync such as a fan and a switch. I want to turn on the fan’s light when pressing on the switch. But if the fan light is turned off with the remote (or via alexa) I want the switch light to reflect the status of the fan’s light.

37

does zigbee have a way to associate the 2 switches together like zwave? so when one turns on so does the other, that way they’re always in sync?

38

not my switches no, I don’t know if it’s a zigbee things or not. They do sell switches for use with a 2-way setup, but those are paired from factory.

39

I assume if the switch is already “on” pressing it “on” again doesn’t trigger your light you’re working with right?

40

I wonder if the switch devices are taking longer than 1s to report a state change to HA? I have some ge zwave dimmers that need a polling delay for automations to work. Otherwise operating the switches themselves would give weird behavior, but from the gui all worked fine (similar to the OP). I think it had to do with “non-standard” zwave implementation. Just wondering if something similar is underlying here.