Feature request. Would it be possible to add a “partially on” flag to the virtual switches? My use case is to get rid of the lighting groups. The only thing I like about them is that if any device in the group is on, the light shows as on, and toggling will turn them all off.
Idea is this:
If the flag is on, the device shows as “on” in ST view, but the actual ON state is not triggered (so routines based on ON don’t fire).
Toggling a partially on switch will turn it off.
Turning on a partially on switch will set state to on.
Turning off partially on switch will set state to off.
I might give that a shot.
I’ve now got a bug report, depending on how you see it.
When you send an OFF command to a switch which is already off, it is ignored. The Samsung virtual switch will still run routines. Same goes for sending ON to a switch that’s on. In my scenario, I’m encapsulating some additional logic (setting LED indicators) to the on/off so that I can reuse it in other routines and scenes. I get that it’s odd to flip switch ON thats already on, so… Maybe a setting that allows you to override that?
There also seems to be some weirdness that forces me to add a delay to the additional logic in order to get it to run correctly. Delays that “fix” an issue always make my race condition spidey sense tingle. A quick look at the IDE shows the switches involved (ZOOZ zen32 and zen71) are cloud controlled (probably the light grouping). I’ll keep mucking around to see what I can come up with.
That is the default behaviour of events in SmartThings. Only changes of state are propagated to apps etc.
The behaviour can be overridden where events need to be propagated regardless - buttons being the obvious example as they don’t have a standby state (despite what the mobile apps suggest). For whatever reason, the stock virtual switch also does this override, as a lot of users found out the hard way.
Just be aware that depending on the brand/model of the device, changing this behavior can create an infinite Loop if you have two devices set up to mirror each other.
This is most commonly done in a three way set up where two switches control the same light fixture. Like one at the top of the stairs and one at the bottom of the stairs.
You may want to create routines so that when the bottom switch turns on, the top switch turns on, and vice versa, so that their statuses always stay in sync.
That will work under the current design. But if you start triggering off of the on command when the light is already on, your mirror may create an infinite Loop where the two switches continue to try to activate the other one even though both are already on.
I just tried this with the virtual blinds, and it worked exactly as I’d like. If I could change the icon to a lightbulb or a switch, I’d be all over it. Even better if it had the force event routines override I suggested.
There must be something about experienced devs that just makes us avoid scenarios such as this. The idea of using a device to mirror itself using a grouping switch is just so bad that it never occurred to me. I just use the virtual switches to group all on and all off, with “any” routines to handle intermediate states if needed, and “all” routines to force the virtual switch to change state. But, in that scenario, a device which also does this forced forwarding of routines might be subject to an infinite loop too.
My understanding is that Andriod users already can do this as a built-in feature of the mobile app. I have other virtual devices where I provide options for the icon (done before that feature came out), but I thought better of propagating this, assuming the icon selection feature would be coming to iPhone as well. If that’s not in the cards any time soon (not sure how we will even know…), I could provide it as part of the virtual device. Unfortunately it requires some minor code change and duplicate profiles to be created.
Sorry if I wasn’t clear. This is a very common use case in the community, but the device doesn’t mirror itself. Again, imagine two switches which control the same ceiling fixture. One at the top of the stairs and one at the bottom of the stairs. With dumb switches, you would have to run a traveler wire between them. With smart switches, you don’t. You just set up two routines:
If Switch A turns on, turn on Switch B.
If Switch B turns on, turn on Switch A.
So A mirrors B and B mirrors A. This keeps them in sync and makes the statuses correct in the app, but if you trigger the routine even if the switch is already on, they can go into a loop. Again, depending on the exact models.
I can’t see why not as it is surely the equivalent of the isStateChange: true that was used in Groovy device handlers. You see it suspiciously often in custom device handlers, suggesting that the developers of said handlers may not have actually realised what it is for, or possibly that things worked slightly differently in the very earliest days of SmartThings.
With regard to momentary buttons, the ‘momentary’ bit is neither here or there. It is required on all buttons because without it the apps subscribing to the event will only see the event when it changes. So if you single pressed a button six times, then double pressed it, then single pressed it another six times, the apps would only see ‘pushed, double, pushed’. It might also make sense when you are reporting something like battery levels or temperature where there is obvious value to the end user in a positive confirmation that nothing has changed.
Obviously users are best advised to not assume anything about incoming events and work things out for themselves but sometimes they get a bit of help without realising it. For example, the ‘changes’ trigger in webCoRE decides for itself if something has changed based purely on the current and previous evaluations. In the opposite direction ‘command optimisation’ is used by default so devices are only sent commands that would change their state.
@aaronburro, you may perhaps have missed out on some of the fun and games we have had with this. Once upon a time, Routines (or Automations as they were then), would not let you use a device in both the condition and the action to protect users from doing anything silly like creating infinite loops. ‘We would never do anything that silly’ we all said indignantly and so we got the functionality we craved. Then when SHM was turned off and it was discovered that the new Security Mode couldn’t be used in webCoRE and ActionTiles, there was a mass adoption of a fudge that involved using three Virtual Switches and six Routines. Turning a switch on ran a Routine to change the mode, and changing the mode ran a Routine that turned the relevant switches on and off. So basically infinite loops, however in practice something was preventing the loop from happening. I don’t know what for sure, but I suspect it was the Routines only subscribing to changes of state. Then Routines were switched from a bespoke solution to the Rules API. As Rules have to consider what to do when conditions aren’t met they have to take the events as they are. Suddenly nothing was breaking the loops and things went tits up. The cure was to switch away from the stock Virtual Switch to the Simulated Switch, or any other virtual switch that used the default state change handling.
Anyway the bottom line is yes it can be very useful to have the option of what is sometimes called a ‘stateless switch’, though I don’t like the term, but it arguably isn’t a safe default in the SmartThings environment.
Speaking of… I worry that the “simulated switch” device will go away when the IDE and Groovy do, at least it won’t be accessible once set. Do the new virtual Edge drivers offer a solution that will allow us to replace the simulated switch with a more modern virtual one, without creating this infinite loop?
Just to make sure I’m clear, this would mean that I can replace my STAY, AWAY, and DISARM Simulated Switches (from the IDE) with virtual switches created from this driver, without the fear of creating the infinite loop within my routines for the use case you described previously? Thanks.
I think so much would be improved if there were the ability to have more direct control over STHM - including dismissing activation once it happens. I would finally be able to end use of the miserable iOS app myself.
I’ve seen this occasionally on my app (iOS). I’m not even sure what it means. It’s not referring to a new driver being downloaded, since I see this message completely independently of driver changes. Sometimes that state even gets ‘stuck’ and keeps showing for a long time.
The following is my understanding in very broad terms …
Something has to decide how to turn a device presentation into the device UI you work with in the app. That something is vaguely referred to in various permutations of device, controller and plug-in and it is a modular thing. Many/most devices use a standard module and occasionally the app will download updates to it outside of the normal app update cycle. If you have a device using widgets you don’t see anywhere else then it is likely to be using a custom module which again needs downloading before use and may be occasionally updated. Somewhere there is, or was, documentation telling you how to create them for your own custom devices.
If you see the message occasionally that is probably things working correctly. If you see it frequently or repeatedly that is probably something going tits up.