I know there are some topics already on this, but I’m wondering what people prefer. A virtual switch or simulated switch? I’m thinking in terms of webCoRE mostly. What works better. I know the virtual switch works locally.
Thanks
I use virtual since it is stateless. i.e. an On command will still process even if the device is already On.
3 Likes
The ‘simulated’ devices are really intended for test purposes, while the ‘virtual’ ones work with the Virtual Device Creator and could perhaps be considered as more ‘official’. Unfortunately they seemed to lose interest after creating the virtual switch and dimmer as I have a number of simulated motion sensors.
Obviously both switches have the standard ‘on’ and ‘off’ commands. The simulated switch logs a debug message. Both switches then just simply send an ‘on’ or ‘off’ event but the Virtual Switch also uses the ‘isStateChange: true’ parameter which might be useful as it forces the event to propagate even if the state hasn’t actually changed. It may also be a bad thing in some circumstances. I haven’t really thought about it.
Both switches can explicitly set the switch state ‘on’ or ‘off’ from the UI. The virtual switch just uses the ‘on’ and ‘off’ command for this. The simulated switch uses ‘onPhysical’ and ‘offphysical’ commands which add the ‘type: physical’ parameter, not that said parameter appears to be documented anywhere.
Both switches support Device Health but the simulated switch has ‘markDeviceOnline’ and ‘markDeviceOffline’ commands to manipulate the status.
As you know, the Virtual Switch is eligible to run locally.
I personally favour the Virtual Switch.
Thanks everyone for your input. Within the last few weeks, web core was missing commands. On pistons that were working fine for the last two years. Although it seems that the issues were on the ST side, most of my missed automations involved virtual switches. Everything seems to be fine now. Haven’t had any issues forA week and a half or so. Wasn’t sure if switching them from virtual to simulated would help. At this point I’m not gonna fix it if it’s not broken. @lflorack, Have your “piston not firing” issues from a week and a half ago subsided?
I was having issues with pistons not firing but in my case the problem was always with presence changes. The pistons aren’t active enough for me to say the issues have totally gone away (my gut feeling is that they haven’t) but the situation has certainly greatly improved. There was quite a bit of chatter suggesting location mode was also badly affected and some suggestion it still is.
My failing automations (webCoRE Pistons really) around 16 September and the following few days got much better on 19 September when ST made an unknown correction of some kind. Since then, they have continued to function properly. However, over the past two days - although still completing OK, they seem to be slowing down again. Responses are slower and my ‘insurance loops’ (i.e., loop until the desired outcome occurs or it fails after five attempts) are taking more than one loop. Still successful but slower.