Cleanest way to program a virtual switch?


#9

no sorry haven’t counted them BUT i’d say i was a little short of 100 maybe?


#10

Even though they use different DH, I presumed that essentially they are identical for our purposes. Correct?


#11

No no no problem yet with ST IDE… My problems started when I was trying to add them to Alexa App…
I started erasing some old ones and it allowed me to add new ones.


#12

In the past, I have seen many strange things with Virtual Switches, that did not happen with Simulated Switches. I cannot remember specifically, but it was dozens of differences over many months from multiple clients.

Long story short, I will never use Virtual Switches, or recommend them to others.


#13

This makes me think that Alexa has a limit on the number of devices… not necessarily Simulated devices.


#14

How do you manage voice commands then??
As you know my triggers are mainly variables but when it comes to alexa integration???


#15

I will have to ask Michael Struck, author of Alexa_Virtual_Device_Creator.


#16

I manually create a SimSwitch using the IDE.

(I do not create Virtual Switches, nor use some Wizard to create them)


#17

Oh ok ok i get it know… Sim switch vs virtual switch and where you create them.
I never used switch creators. I also always create them in ST IDE.


#18

Haha I didn’t expect this to become a virtual vs simulated switch debate. I seem to have multiple device handlers for both and i’m never sure which to use - plus I use a lot of momentary (virtual/simulated) switches for things.

I’ve started using ADT Tools as a push switch which apparently works with the new Smartthings App and V3 hub (neither of which i’ve got but thought I might as well future proof)

I will try to swap to simulated switches working on the above - funnily enough I use SmartThings to create fake switches for Homekit too and have a lot of automation done over there now as well (especially as there are many things added to Homebridge that don’t exist in SmartThings unfortunately) - i’d love a plug that would sync my Homekit only stuff with SmartThings, so I could use Webcore for more advanced stuff (without having to use simulated switches like I do)

As for simulated/virtual switches being physically switched - it seems to work ok for me, that’s how i’ve always done it?


#19

Now I have to do some testing :slight_smile:


#20

MichaelSMicheal SmartThings Published Contributor - author of Alexa Virtual Device Creator

“I am not aware of any limit, but was surprised there is a physical limit to devices so being a limit on virtual ones doesn’t surprise me.”


#21

Funnily enough I think I ended up using physical because often when I used no qualifier just “on” or “off” it wouldn’t work for me - maybe this was a mentioned quirk of the virtual vs simulated switches!

At the minute simulated switch and ADT Tools switch for push momentary are both working reliably for me (and i did remove physical, it worked just as well)


#22

Funnily enough, I was making some notes about this earlier today. The meat in the sandwich was:

Virtual Switch

  • The device handler supports the Switch, Actuator and Sensor capabilities.
  • The device handler can run locally.
  • Device Health is NOT supported.
  • Only the standard ‘on’ and ‘off’ commands are available.
  • The ‘on’ and ‘off’ events are sent with ‘isStateChange: true’ so the events are always propagated even if the state hasn’t changed.
  • The Classic UI has on and off buttons to force a particular state, as well as the main button for toggling.

Simulated Switch

  • The device handler supports the Switch, Actuator, Sensor, Relay Switch and Health Check capabilities.
  • The device handler can NOT run locally.
  • Device Health is supported.
  • As well as the standard ‘on’ and ‘off’ commands, there are custom ‘onPhysical’ and ‘offPhysical’ commands which mark events as physical interactions, and ‘markDeviceOnline’ and ‘markDeviceOffline’ commands to change the health status.
  • Events do not explicitly set the ‘isStateChange’ flag.
  • The Classic UI has buttons to send the four custom commands, as well as toggling.

#23

Nice breakdown, @orangebucket… Thank you!


#24

@orangebucket, would you mind if I copy/pasted those differences on the Wiki?


#25

Fine by me.


#26

So I am relatively new to webcore programming. I use virtual switches often. However, I ONLY use them for the ON/OFF feature. I cannot imagine when I would ever need the Device Health or frankly any of the other capabilities. Maybe I should/will.

Should I convert all of my Virtual Switches to Simulated Switches?


#27

Done, and thank you once again.


I probably would not spend the time unless something was not working as expected.


#28

I use Virtual Switches myself. Things like Device Health are of no import to virtual switches. The Simulated Switch handler needs it so it can better simulate the behaviour of a hardware switch in various circumstances, just as it can generate ‘physical’ interactions (for what that is worth). That is its design purpose, after all. I have noticed negative comments about the Virtual Switch which surprises me as a device handler couldn’t be much simpler and still do anything. There is very little to break

I have heard of comments from webCoRE users who suggest that their piston is triggered by the switch changing to on, for example, and yet the trigger condition ‘changes to on’ returns false. I suspect that is down to the ‘isStateChange: true’ flag being set on the events so a switch being set to ‘on’ when it is already ‘on’ can reach webCoRE as an event. That can’t happen with the Simulated Switch. The piston fires because a state change event has been received. It is the piston itself that decides if there is actually a state change and if it is of interest.

Other apps or connected services might perhaps not be geared up to double check if a state change really has occurred, so perhaps the Virtual Switch can cause problems with them.