I recently started having a problem but haven’t seen anything that indicated an update/upgrade by Samsung. It just stopped working and I don’t know why.
Here’s my setup…
Virtual Switch: Bedroom
Real Switch: Bedroom Light 1
Real Switch: Bedroom Light 2
Real Plug: Bedroom Light 3
I have a Smart Lighting Routine that basically says keep the real items “in sync” with the virtual switch. This way, I can tell Alex to simply “Turn on Bedroom” and all items get turned on. Same with off. One switch to rule them all!! One Smart Lighting routine instead of 2 Smartthing routines.
Where this setup really shined was in the fact that let’s say someone turned on just 1 real switch by itself or any combination of real switches. The virtual “master” switch remains off. I could tell Alexa or have a Smartthings routine that turned off the master switch (even though it was already off) and all the individual items would turn off. This way, I don’t have to care what actual lights were on. Turn off the master switch and whatever was turned on, would turn off.
And this worked even better as I added new items to a room. I just add that item to the Smart Lighting routing and it worked alongside everything else. Add once, work everywhere.
This stopped working a few weeks back. Now when I tell Alexa to turn off the virtual “master” switch or have a Smartthings routing turn off the virtual “master” switch, since it’s already off, it does nothing.
Yes, I could create a manual Smartthings routine and do the same thing, but I’m getting tired of constantly redoing everythign with Smartthings. I’d rather just understand why this might have stopped working.
Alexa doesn’t understand groups. Again, my current setup made configuration super easy. I don’t want to rebuild everything in 5 steps when Smart Lighting solved it in 2.
I simply use Manually Run Routines (formerly scenes) to achieve this. For example, I have “Evening Lights” which turns on a collection of lights and outlets and I tell Alexa “Turn on evening lights” (there is also a Routine that will do it automatically, but sometimes we want them on earlier). Regardless of the state of any individual light or outlet, they all get set to the on state. And I have another one called “Bedtime” which turns off a subset of the lights and outlets that were turned on in the evening. Again, regardless of the state of those devices, they get turned off since the Routine sets the state of the devices to off.
Yes, I have something similar. Manual routine called “Goodnight”. But it turns of each virtual “master” switch. So it turns off everything in Room 1, Room 2 and Room 3. But it uses Smart Lighting to do that. When I add something to a room, I don’t have to add it to the manual “Goodnight” routine. I just add it to the Smart Lighting routine and it gets turned off automatically.
What type of ‘Virtual Switch’ is it? I ask because SmartThings’s stock locally executing virtual switch device, and it’s predecessor based on a device handler, used to flag all events as if they were state changes so they always propagated.
About a month ago a preference was added to the Edge driver powering the switch that allows a reversion to the more typical behaviour of only propagating changes. I would imagine that went into production a couple of weeks or so ago. I haven’t looked in detail but conceivably that could have changed the default behaviour, in which case it can be switched back again.
This sounds like we’re on to something. This would explain the behavior I’m seeing. Driver details below. If that is the case, it means I’m forced to redo everything in a more complicated way. You mention it can be switched back, but there’s no setting for the virtual device, unless you mean revert the driver itself?
The date almost coincides as I started experiencing this problem around Oct. 7 or 8 but the drivers show Oct. 10
Yes, I meant that it wouldn’t be much of a surprise if the mobile app wasn’t actually implementing the new preference yet, even if not implementing it seems like it should be more work.
As long as the presentation was updated (which should be derived from the profile), the mobile app should pick it up. I would use the CLI or API Browser+ to check on the profile and presentation.
I think I see why the behavior changed. This is the new code to control the behavior:
local function force_state_change(device)
if device.preferences["certifiedpreferences.forceStateChange"] then
return {state_change = true}
else
return nil
end
end
It only returns true if the state of the preference state is “on”. Since there is no preference state, it will return nil which when passed to the event emitter results in the “no state change” behavior. Frankly, I think that’s a crappy way to implement it since there is no default state defined. And for backward compatibility, the function should default to true and be “no state change” if the preference is turned off. That’s just good coding practice to not break behaviors that already exist.
I thought perhaps existing virtual devices didn’t get the new preference since I don’t think doConfigure would get run. That’s why I asked about new devices.
At this point, I’d say there is some bug in the driver, perhaps the registered profile didn’t get updated or an error in the packaging of the driver. @nayelyz can you make an inquiry or file an issue against the production repo?
)
