I noticed today that my virtual switches stopped triggering location mode changes. This was odd because until today’s morning it’s been working flawlessly. It worked before on IDE/Groovy and it was working even after they were discontinued. During the root-cause that I conducted I noticed that when creating a virtual switch it now asks if you want it to be “local” or “cloud” based. Interestingly, I found that all the ones that used to trigger the location mode changes were local (not sure if they’ve always been, or they were recently migrated) so I did some tests with newly created cloud and local virtual switches and concluded that that local virtual switches are not triggering location mode changes while cloud ones are.
Additionally, I did some trials using real physical switches to trigger routines that change the location modes and they did not worked (i.e. if switch is ON, then Location Mode is Away)
Is this a known issue? or something that may have happened inadvertently by ST programmers? Any hints?
I had an issue today where a Rule failed to set the Location Mode to Home, which is unprecedented for me, though an earlier Rule successfully set it to Away. Both rules test for the current state of the Location Mode but are triggered by VIRTUAL devices, in my case custom local ones. I do note that the ‘away’ Rule is running in the cloud, and the ‘home’ Rule is local, so that aspect of it is consistent with what @SableBlack found.
I have 2 virtual devices, 1 for each cell phone, using @TAustin’s driver. I use them to display the presence/not present status of the cell phones within ST, as well as for some routines. This way, if for some reason the location of the physical phone does not update properly, I can just turn on or off the affected virtual device and my routines will function.
Recently (not sure when it started) the routine I have to set the mode of my house to home or away does not work. Basically, when both virtual devices go “not present”, then it should set my location to away. There is a precondition that the location mode is Home or Night. Similarly, with a precondition of Away, another routine will change the mode to Home if either virtual device becomes present.
The virtual devices do change based on the state of the cell phones. I have another routine that turns on some lights when either virtual device becomes present after sundown. This routine works.
I just don’t understand why the house mode change is not working.
I’ve combined the threads for you, and retitled the original to make it a little clearer that it’s about routines that were previously working now failing. Hopefully that will make it easier for others to recognize it as being the same is the issue they are having.
If anyone having this issue is not using a custom edge driver to create their virtual devices, then I would strongly recommend reporting it to support. The first person you get will probably be a general Samsung employee working from a script who may not know much about smartthings, but persevere and it should eventually get reported to a smartthings engineer. And the more people who report, the more resources, are likely to be assigned to look into it.
Unfortunately, if you are using a virtual device created through a community created edge driver like those from @taustin, support is likely to blame the edge Driver, and say they can’t help you.
But if you created the virtual device through one of the official features like the wizard in the android app and you are having this same problem, then definitely report it.
Also, if anyone is having this problem with a non-virtual device, definitely report that.
I noticed last night that neither one of my virtual devices triggering the Routine that changes the Location mode to Night actually did. I have a Routine with both a calendar virtual device, and a virtual motion device working together that change the Location mode to Night and putting my system in Armed Stay mode. But twice last night the system did rearm (I had to take out the trash after dark), but the Location mode was still in Home mode and not Night mode. The Routine ran both times since it toggles my Alexa virtual switch that runs an Alexa announcement that the security is now On in Armed Stay which I heard.
I wish there was a way to see all my Routines that use the built-in Location mode like devices have. Having said that, I’m going to setup one of the virtual text device field’s as a Location mode so that I can see which Routines I’m using the Location mode in (which I’ll need to data-mine). Then I’ll setup some Routine(s) to give me a notification when they don’t match. I’m thinking if pre-condition Location Mode is Away or Home, and virtual text field is Night, then send a notification. Guess I’ll need three Routines for Home, Night, and Away. (Troubleshooting…)
But since I’ve already switched the STHM to using the virtual text device instead, I might just do the same thing with the Location mode now as well.
Since I’m using Todd’s driver, I thought I would experiment with the native virtual device. Dumb question, how do I create it? I can’t find where to create the device in my Android ST app.
I’m not that familiar with the app (it’s not voice-navigation friendly), but I think it’s under labs. Someone else should know and hopefully will post.
There’s also an option at the advanced page of the web interface to your account. Go to Devices, and then add a device. But I’ve never tried it and I don’t know how well it works.
OK, I use iOS. I just created a virtual switch using the option on the advanced page of the web UI to the smartthings account, and routines using it. (change to home when the switch turns on, change to away when the switch turns off) are working fine for me. But I don’t have the other kind to check against. And virtual switch is created through the advanced page are cloud-based.
In my case, the original ones that started failing were created with “Labs” / Virtual Switch, not thru an Edge Driver, so I really believe is an ST issue.
Right, cloud based ones are working well, local ones are the ones that I found are failing to trigger mode changes. Both local and cloud can be created thru “Labs”
Unable here to track down a common denominator in the failed routines I have. Seems that rule triggered virtual switches run OK.
Have found an Alexa multi trigger (that have never failed for me) did not fire from within its ST routine. Another case a trigger to Alexa started the routine which left out one task.
Confusing.
So I created new virtual switches for my phones using the app. If you do not select a hub it tells you the switch gets created in the cloud. I then created new routines for Home and Away using the new virtual switch. If I turn the switches off, my location is set to Away. Turning one on sets the location to Home. So it works. BUT, the switches must be in the cloud as has been suggested. If I look at my routines, the ones using Todd’s driver have a little house icon in the box. I think the house means the routine runs locally in my hub. My new routines do not have the house icon as they run in the cloud.
I confirmed this by creating a local switch and a cloud based switch. If the routine uses the local switch, the routine displays the house. If it’s a cloud based switch, no house icon.
So the big question is, what all of sudden changed to cause the original local hub based routines to not change location status?
If local virtual switches created through the official ST tooling are not working, then we should all open a case with support. It’s likely whatever is causing the official virtual switches to not work is also affecting those created with 3rd party drivers like @TAustin’s.
Indeed. From what I’ve read and experienced I actually favour the problem being that the Location Mode isn’t working properly with local Rules, with the virtual switches quite possibly being a red herring, but I’ve not attempted any further diagnosis yet.
Entirely possible. I just tested using a physical device in a Routine to change location mode and it failed to make the change just like the virtual devices. What I’m trying to figure out is how this suddenly broke when there has been no firmware version change on my hub and I haven’t touched my existing Routines in ages.
Who knows what other work goes on behind the scenes between releases. Maybe some engineer thought they were tweaking some code, and they unknowingly broke part of it.
