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.