I use Smart lighting to keep the devices in sync so that when I turn on the virtual switch, all the other devices turn on and when I turn the virtual switch off, all the other devices in the room turn off. This makes it easy to just tell Alexa to “Turn on/off dining room” and everything turns on/off. This way, I don’t have to do it for each device.
However, the real benefit with this setup was that regardless of what combination of devices were actually on, and even if the virtual switch was off, telling Alexa to turn off the dining room would somehow trigger the virtual switch off (even though it was already off) and turn off all the other devices, regardless of their status. For example, if this was the status of my devices…
OFF - Dining Room - Virtual Switch
OFF - Dining Room - Outlet
ON - Dining Room - Switch 1
OFF - Dining Room - Switch 2
When I would trigger the virtual switch to “off”, it would fire and turn off switch 1. With the new smart lighting, it appears this is no longer working as the virtual switch doesn’t get trigger anymore. Anyone have any insights or a good alternative?
Have you tried using ST scenes instead of Smart lighting (one scene to turn everything on and a second scene to turn everything off). Alexa can control ST scenes though I did have to create two Alexa routines (separate on and off routines) that executed the ST scenes in order for Alexa to always understand the trigger phrase.
And with a ST scene there is no need for the virtual switch (but keeping it the scene won’t hurt)
Is the problem that Smart Lighting no longer works when you turn the switch on and off at all, or is it specifically a problem with the case you described where you tell Alexa to turn a switch on or off when it is already on or off?
If the latter, do you know if the problem is that Alexa no longer ‘turns on or off’ the switch, or is it that Smart Lighting no longer triggers when it does?
Could you also be more specific about the ‘virtual switch’ that you use? The legacy DTH based Virtual Switch would propagate events regardless of state changes (so on / on / on / on was possible) and the same seems to be true of the new locally executing replacement. However the cloud executing variation, which for some reason I have recently suggested also behaved like that, actually only propagates state changes ( so you only ever see on / off / on).
The problem I thought I was addressing was with a virtual switch triggering a Smart Lighting routine. The only involvement of Alexa I could identify was in voice control of said virtual switch.
I was looking for clarification whether the issue was specifically with triggering when a switch that is already ‘on’ (or ‘off’) was ‘turned on’ (or ‘turned off’), something that would seem to be feasible when using Alexa for voice control. Assuming that was the issue I was looking for clarification over whether those consecutive ‘on’ (or consecutive ‘off’) events were still happening as that would point the finger at the virtual switch and not Smart Lighting.
To me it sounded like the OP had been using a stock Virtual Switch DTH and that might have recently been migrated to a new integration. Now if it had migrated to a local VIRTUAL based on an Edge driver its behaviour shouldn’t have changed. On the other hand if it had been migrated to a cloud based switch it would have done, as I checked this morning and those only propagate state changes so a switch that was already ‘on’ could not be ‘turned on’.
Alexa still triggers the virtual switch and works great. I can turn it on and off via Alexa.
The problem is when the switch is already off and I say, “Alexa, turn off switch”, an “off” event is no longer triggered because the switch is off. Not so long ago, when the virtual switch was off, I could turn the switch “off” again and again, and each time, it would trigger an “off” event, even when the switch was already off.
Something that I would suggest trying is to create a new virtual switch. Specifically one of the new VIRTUAL type that can be created via the API, choosing the ‘switch’ prototype and local execution. The easiest way to do that is probably to use Todd’s API Browser+ to create one using Devices > Virtual Devices > Create and choosing to create a ‘Switch’ with ‘Local Execution’ selected. The local execution part is critical. This is the only virtual switch that I know for sure will allow you to repeatedly turn the switch ‘off’. You might have one already, in which case the problem lies elsewhere.
This solved my problem. Can’t thank you enough. But I did discover something that may be helpful.
If I use the @TAustin vEdge driver to create a virtual switch, the “off” functionality doesn’t trigger if the switch is already off. However, using the API Browser to create the virtual switch does trigger an “off” event every time, even when the switch is already off.
I was curious the difference between between the 2 solution’s and of course, the driver being used is the key here. If I create a vEdge virtual switch using @TAustin solution then change the driver to use the Smartthings driver, I get the same result as if I used the API browser.
SmartThings will prevent device events propagating if the state hasn’t changed, and by default it works it out for itself if it has or not. Obviously there are situations where this causes issues. A button, for example, doesn’t have a standby state (what you see in the mobile app is artificial) so you need the event to get through every time it is pushed. So this default decision can be overridden.
The way this is achieved is with a setting in the handler/driver called state_change. Setting this true forces ST to treat the event as a change regardless. The developer could also set it to false if they wanted ST to treat the value as unchanged but more often when you see that used it is in a legacy handler and it is a relic of the time before the default behaviour existed.
I used to set state_change true for regular events like battery reports as although the value might not change, they provided a (then) visible heartbeat for the device.
It is likely that some developers didn’t grasp the meaning and set state_change true anyway. It looked that way to me.
Typically switches keep the default behaviour but the Virtual Switch device handler didn’t, it set state_change true.
This resulted in some unfortunate behaviour when Routines were migrated to use Rules. The original Routines would not set a switch on if it is already on (and the same for off). This may have been explicit or it may have been that they only subscribed to events state changes, as is possible. The Rules didn’t behave like this.
Unfortunately at the time there was a particularly popular workaround to allow STHM/Security to be handled in ActionTiles. It used three virtual switches as a proxy for the mode. So for example turning the Disarm switch on would set Disarm to true. Similarly setting Disarm to true set the Disarm switch to on. You can probably spot the potential for an infinite loop there. With old Routines there wasn’t a problem. With Rules and default event handling there wasn’t a problem. With Rules and switches using the Virtual Switch handler … not pretty.
The Virtual Switch Edge driver mimics the behaviour of the Virtual Switch device handler and that is used by the new stock VIRTUAL_SWITCH virtual device if executed locally. That is what Todd creates in his API Browser+.
The VIRTUAL_SWITCH virtual device with cloud execution doesn’t appear to have the same setting.