Wireless 3-Way Issue

@chrisb, have you had any problems with your Wireless 3-Way app? I hit the physical switch on one of my GE light switches last night and it freaked out, switching on and off repeatedly every half a second or so.

I had this switch tied to a Virtual Tile with the Wireless 3-way app. As soon as I uninstalled the app, the light stopped flipping on and off. Any ideas?

No ideas @csader, but I have seen similar behavior with the Double Tap app on a switch. I came home one day and the primary lamp was off as expected but the secondary lamp I was controlling with Double Tap was pulsing on and off as you describe - it was on a GE Lamp module. The primary switch was a GE on/off. I Uninstalled that Double Tap app and have not seen the problem since.

Yeah… um…well…this is bug in the program. The program is really a very simple little bit of code. You just setup your switches, and the program watches for any one of them to turn on or off. When that happens it turns ALL of the switches on or off.

So, let’s say you have two switches, A and B, tied together. You turn on A… the program see this and sends out a command: Turn on switch A, and turn on Switch B. Switch A is already on, so nothing changes there. Switch B was off, so it turns on. But wait! The program just saw Switch B turn on… so it sends out a command: Turn on switch A, and turn on Switch B.. Both switches are already on, so no big deal, no problems there.

But, what if you go into a room, turn on Switch A, but then immediately think: “Wait, that’s dumb… I wanted to go into that room, not this one.” So you flip off Switch A. But, because there is a slight lag in SmartThings, this happens:

ST sees A is turned on, sends command: Turn on switch A, and turn on Switch B.
but before Switch B turns on, switch A is physically turned off, so:
ST sees A is turned off, sends command: Turn off switch A, and turn off Switch B.
But before this command is received, the previous switch on command is sent to B
ST sees B is turned on, sends command: Turn on switch A, and turn on Switch B.
Again before this on command is sent, the off commands are received and the switches turn off, so…
ST sees A (or B, or both) is turned off, sends command: Turn off switch A, and turn off Switch B.

…and on and on we go until there’s finally enough lag between commands that things settle down or you uninstall the program or remove one of the switches and update (and then add it back in later).

It doesn’t happen often, only when there’s real quick on/off action on one switch or if over lapping commands happen from different sources (for example, when I turn off my hallway light at the same time I open my door which is setup to turn ON my hallway light).

Ideally the program should be written in a way that it differentiates each switch in the group and when switch B turns on commands are only sent to switches A and C AND ignores the fact that those lights just turned on. But something like this is much more complicated and probably beyond my meager abilities with an open ended program that allows for any number of switches to be linked.

I may write a revised program that ONLY lets two switches be linked together. I anticipate that this is really the way the most people are using the program. And in this case it would be relatively easy to set it up as discrete subscriptions which point to discrete procedures rather than “If you see any on/off, then send on/off commands to EVERYTHING.” This should reduce the possibility of getting into the ‘freakout loop’, but until I can figure out a way to ignore the fact that a switch was turned on/off by my app and so don’t fire the command, it won’t eliminate it.

Hmm… not that I think about this more… I don’t think the fault lies in sending commands to all switch. Rather, I should focus on the ‘ignore when I turn on the other lights’ part. What I ideally need to do it essentially make the program go “blind” for a couple of seconds after it sends an switches on or off command. This would be easier then ignoring specific events… just ignore them ALL.

This should prevent the ‘freakout loop.’

I’ve got a few ideas swimming in my head… I’ll and to do some testing and tinkering when I get a chance over the next few days. I’ll update when/if I come up with anything.