Is it better to use a virtual switch OR a hub variable with a Boolean connector as a setting on a dashboard?
I am going to a dashboard and turning the virtual switch OR the hub variable/connector on or off, and referencing that value in a rule to determine if a notification should be sent when my dryer cycle is done.
I can make either work, but what is the most “efficient”.
Had the same fundamental question yesterday, and opted for the virtual switches approach. At least until the known issue with booleans misbehaving in the Dashboard UI gets rectified.
Switches give you added benefits of being easier to integrate into rules, set Auto Off time, etc.
Originally I didn't want to clutter my devices list with Virtual Switches but I've come to accept them. I created a room called Virtual as a small way to segment them. I also name 'Virtual xxxx' so... Virtual DW Run Switch is my trigger for Device Watchdog...
Lately, I have been experimenting with Button sets. It allows me to condense things dramatically. Buy setting Buttons on a button controller where I can use 9 buttons allows moving the Virtual switches off the devices list and stack them neatly under Button Controller. Since switches often are used for triggers - and as such are set to auto-turn off a second or so later, they are effectively buttons. Buttons are easily found in rm 5.1 ... so truly - after all these words - I'd say use Buttons when possible, Virtual switches as needed (some apps won't support a button for a trigger) then go with the more obscure stored variables. IMHO of course! Update* - on re-reading my own post, I realized I didn't mention auto-off is something that can be set on a periodic. so you can do auto off in 500ms 1 sec, 2 sec etc. that really adds some juice in certain cases. I wrote (modified) an existing virtual driver to have auto-off, toggle and flash as a sort of learning task and now use it for all my Virtual switches. I minimize how many drivers I load this way since drivers are re-entrant.
I went down the buttons rabbit hole as well, in fact before turning to virtual switches or hub variables. Thing is, while buttons make excellent triggers, they do not preserve state (on/off) in the way I needed for my particular application. So I went with switches.
But unquestionably you've landed on a gold mine, since you can essentially create a virtual button controller with arbitrarily many buttons, each with multiple states, and from that you could certainly whip up lots of fun automations without the dreaded clutter in Devices.
@LibraSun thanks for the compliment. Sadly, before anyone else dives into this pool - it's shallow.
Buttons are an afterthought on Dashboards. The HE dashboard- will allow you to manually create single buttons on a tile, regardless of the button controller thet're a part of. Worse, my favorite tool - Android Dashboard really is only beginning to bridge buttons into / onto his app. While I can currently get up to 4 buttons on his app, I can't colorize 'push', nor add up/down states. Basically it's an icon only and doesn't allow for the 4 js states of a button - ideally someday someone will setup the button images so the Pushed, Held, double-tapped and released states can be signified via differing icons/background colors.
The best part about virtual devices is that they provide a great integration point for external integrations to poke at. It's nice to be able to harmonize all of my presence sensors for a person into one virtual switch -- and further harmonize all people's presence into one "someone's home" switch.
I also really love being able to flip a switch in Home.app which enables or disables an automation, or changes how some other automation works. With a virtual switch I can publish a switch into HomeKit and NodeRed, and use HomeKit to enable or trigger an automation in NodeRed.
The above is entirely the reason I recently asked Hubitat to consider a FEATURE (Driver) REQUEST: Virtual MultiSwitch which could accommodate arbitrarily many vritual switches in a single parent device. Much the way we can with a button controller.
I realize the request may go nowhere, but it's food for thought and definitely has use cases, as explained over at the linked post.
Conversely, if we had the ability to "toggle" Hub Variables between two (or more?) values directly in Dashboard, that would open up lots of new possibilities as well. Even if this functionality were limited to booleans, the fact that tapping a tile in DB could cause a variable to alternate between 1 and 0 might be sufficient for a number of practical uses.
Right now, since "Variables" is such a new part of DB, I don't think we can manipulate their values aside from direct entry, which is error-prone. (Will have to look again to see if I'm right about that.) "Toggle", "Pick from Presets", "Radio Buttons" and/or "Dial Up/Down" might be welcome additions to the Tile UI.