Change the Values Reported by a Virtual Switch - Feature Request, Maybe

I have a couple tiles that display the status of virtual switches that are actually aggregated device statuses for leak sensors and garage doors. The purpose of the tile is to report when any of my leak sensors detect water or report when any of the garage doors are up. (Using ST.)

I’m using virtual switches for these, as AFAIK there isn’t a virtual leak or a virtual garage door type. So when a leak is detected or one of the garage doors is up, the tile value is displayed as “On”. I’ve changed the tile labels so they display as “Leak” and “Garage”, but it would be cool to be able to change the values reported to “Wet/Dry” and “Up/Down”.

@Bry there are simulated water sensor and garage door. You can aggregate the device status in the same way you did but update to these simulated water sensor and garage door instead. See below.


Thanks, that’s perfect.

Now I know I looked at that list before posting and I only saw three simulated items . . . gremlins, obviously . . . :thinking:


So I figured out why it was that I didn’t see all of the virtual device types when I looked in the IDE. I was looking at Virtual types, as they’re newer and run locally. There are many more choices for Simulated device types, which unfortunately run in the cloud. At least now I know I wasn’t seeing things!!! :sweat_smile:

1 Like

So while the solution suggested by @James will work, it’s using simulated devices which run in the cloud solution. Using a virtual device runs locally.

So given the preference to run devices locally, I’d still like to make a feature request to allow changing the labels for the values reported. Thanks!

@Bry I’ve noted your feedback. Thanks. Meanwhile, I’d also suggest to change the tile color to red if the VS is turned on so that gives you a bit more visual alert that I found helpful for me based on the aggregated tile icon and color to tell the status at distance.

Thanks for the additional feedback, @Bry - can you help me better understand the use case for having a virtual contact sensor that aggregates multiple sensors together and runs locally?

If it’s related to automations running locally (which only Smart Lighting does at the moment), then I wonder if the request might be better targeted to SmartThings to get the whole gamut of virtual/simulated devices to run locally.

Sure, Josh. The “runs locally” is easy. I think that local processing is preferable so it eliminates cloud hiccups. Speed isn’t an issue regarding here, just reliability. And at least according to the IDE, virtual switches run locally in addition to the SmartLighting app you mentioned.

The sensor aggregation is just so I can have one tile on a dashboard instead of multiples. I use it for a couple things, for example, leak sensors. I have a number of leak sensors, but don’t want to take up screen real estate with multiple tiles. I use ST on both tablets and my phone. Not to mention that I don’t plan on having any leaks, so one tile will do, lol.

Basically, I aggregate the leak sensors via webCore, which I know runs in the cloud. So that may cut against my argument for wanting local processing. In any event, if any leak sensor goes “wet”, it throws the virtual switch for which I have a tile. ( … and turns it off when they’re all dry.)

Of course, if SmartThings would implement additional virtual devices to match the number of simulated devices available, this would solve the issue. But I know there is a way better shot of you guys implementing something than Samsung responding to a feature request.

So basically if I stick with a virtual switch, then the value displayed on tile is On/Off, which is not that big of a deal. It would just be neat if you could say instead of displaying On/Off, map On to Wet and Off to Dry.

Thanks for listening!!

1 Like

@Bry, I might have misunderstood what you mean by the reliability in this particular case, but when there’s a network issue, you will not be able to see the aggregated tile turning active in the dashboard, or even ST app, even though the aggregation was executed locally, until the network is resumed. However, if you have the local automation rule to turn a RGB light red in case of leaking, it’s a different story though. (which should work without relying on network.):joy:


Yep, that’s a good point! I think I’m too focused on the device type when there is more to the equation!