Cleanest way to program a virtual switch?


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)


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.


Nice breakdown, @orangebucket… Thank you!


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


Fine by me.


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?


Done, and thank you once again.

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


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.