Ah I can’t resist it …
The behaviour of the legacy ST platform is to suppress propagation of events when there isn’t a state change. So for the Simulated Switch DTH apps that subscribe to the switch can only ever see
on, off, on, off etc. Nothing has changed about that.
The Virtual Switch DTH is different. It uses an option that flags all events as state changes. If you keep turning it on you will see
on, on, on, on etc. Some call that being ‘Stateless’. Nothing wrong with that behaviour as it can be useful, and nothing has changed about that.
In the ‘new’ environment you can subscribe to all events, or you can choose to subscribe to only state changes. It isn’t clear how changes are identified. Nothing has changed about that.
A number of users adopted a method to expose their STHM status outside Automations using virtual switches to represent the 3 states being on or off. There were pairs of Automations that did, for example:
If STHM is disarmed then turn on Disarmed and turn off the other two.
If Disarmed is on then disarm STHM.
Well I don’t know know about you, but I just see a potential infinite loop there and so am on guard instantly.
So why wasn’t it an infinite loop?
Well if you used the Simulated Switch DTH or similar behaving ones, it wasn’t a loop because you only ever got the Disarmed switch
on event once. The worst case was you could manually disarm STHM, the first automation set the switch, the second automation disarmed STHM again, and then if the first automation ran again and set the switch again the event never propagated. End of loop.
Lots of people used Virtual Switches though and they can keep sending
on. So something else had to be breaking the loop. What was it?
Well it could be that you can only disarm STHM once. Except we know that’s not true.
It could be that the Automations were doing webCoRE style command optimisation and only, for example, turning stuff on when it is off. That would be unlikely though. WebCoRE has to pick and choose when to do that (you couldn’t do it with a button for example as the attribute never clears) and has to make it optional. That would be a daft thing to do in an intro level Automation.
What else is there? Well perhaps something is going on at the subscription level and only actual changes are being subscribed to. Not always, you couldn’t do that for a button for example, but sometimes. That’s maybe a possibility.
The bottom line is that I don’t actually know for sure why it worked. I don’t like not knowing, but that’s me.
So what changed? Well Automations moved to the Rules API. Now I only have a few Rules so am not an expert. However given it has to handle ‘if … then … else’ loops it certainly isn’t going to be limiting what it subscribes to by default. It has the same auto / always / never subscription option as webCoRE but I can’t see any option to only subscribe to changes.
Could it be that the mechanism that stopped the infinite loop was no longer there? I don’t know. Does it make any difference? Not to the logic per se. It makes a difference to when the Automation runs and tests its logic. Should that actually matter?
One piece of advice I give to users of webCoRE is to press the Test button now and again. If it results in something happening that you wouldn’t want it to, perhaps you need to think about beefing up your piston. Same with Automations but you have to imagine it at the moment. Shift happens.