I’ve seen reports in the past where this type of two way mirroring/sync’ing using Smartlighting causes a race condition that results in the light being oscillated between on/off. If that happens, it might be better to use Routines so that you can add a precondition that insures the switch to receive the mirroring instruction is in the proper state. So something like:
If Switch 2 is off (precondition)
Switch 1 is turned on
Turn on Switch 2
If Switch 1 is off (precondition)
Switch 2 is turned on
Turn on Switch 1
and of course you’d need two more Routines for mirroring the off states.
Honestly, I just don’t worry about race conditions. Thousands of people have used z wave association to create virtual three ways, And at least as many have used them in SmartThings over the years. And probably less than a dozen have reported a race condition.
If you do get a race condition, just use A different automation. There are no safety issues, it’s just annoying.
(For those reading along who don’t know what a race condition is, it’s when switch A and switch B are supposed to stay in synch, But instead, switch A turns on, switch B turns on, And then there’s some confusion (it can happen a couple of different ways.), and both switches start turning on and off.
Like I said, annoying, but not dangerous if they’re just light switches. You might want to take more caution if one of the switches controls a motorized device.
If you need to stop this kind of loop, and either device has an air gap switch, that will do it. Otherwise, if you can, delete the faulty routine, and then look for other alternatives.
And most quality light switches, have a “de bounce“ factor which prevents them from processing multiple requests too close together. So it’s just a really rare condition. I do see it on some tuya dimmers that don’t have a de bounce, but even those are rare these days.
Well first I have to admit to being a dumb a… I created those sync routines in the Lighting App. Not the “If-Then” To kill the racing I shutdown the network for awhile. I should have deleted them in the Lightning App.
I’m starting over. I created one switch sync routine that didn’t work. I’ll add the second mirror routine and see if that works. If the racing happens then I’ll add the preroutine you suggest.
Thanks for everyone’s suggestions. I’ll keep you posted on my progress
You can usually stop the cycling cause by the race condition by shutting off power to one or both of the switches, either with the air-gap (if they have one) or by killing power to them at the breaker.
Add the precondition to check the state of switch to be mirrored just to be safe. It doesn’t hurt anything to have it there.
I’ve resolved my problem with creating a virtual three-wat switch. It turns out that one of the switches had a defective pairing. That combined with a poorly conceived set of initial set of routines prevented me from setting up a relatively easy application. I figured this out after I pulled the dummy switch and bench tested with a LED bulb. There was a fifteen-minute lag in it picking up the state change from manual input.
I excluded the device from the hub and performed a factory reset of the switch. Everything fell into place once I rewrote the routines. I didn’t have to create any decoupling logic to prevent racing.