I confirm this solution works for me. There is no repeated effect at all again. Thank you very much.
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
btw, tried all the above automations.
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:
- When light a turns on, turn on light b.
- When light a turns off, turn off light b.
- When light b turns on, turn on light a.
- 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.
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.
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.
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?
Are you running 0.113? If so, make your mode single and add the 1 second delay after your service.
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.
Or is 0.113 adding a new mode of operation here? Reading the changelog right now.
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.
I see, awesome, will try first thing tomorrow morning
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?
If these are zwave switches, couldn’t this be resolved with just scenes?
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.
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?
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.
I assume if the switch is already “on” pressing it “on” again doesn’t trigger your light you’re working with right?
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.
The reaction between the two switches is certainly lower than 1s; pressing the button on one switch almost instantly set the other.
If I set the two rules automations (one for one, and one for off) then everything works nicely.
When I press one switch, the other will go the other direction.
In my current setup, the light is only connected to one switch; but like in a 2-way switch setup, you should be able to control the light with a 2nd switch.
In any case, I’d prefer we stop on the “why do you want to do that” type of things, and concentrate on why we’re seeing this behaviour with 0.113
It’s certainly unexpected.