FEATURE (Driver) REQUEST: Virtual MultiSwitch

I'm formally requesting a new type of virtual device driver type, which I will call a Virtual MultiSwitch, that behaves as follows:

  • Install and look similar to current "Virtual Button" driver;
  • Allow user-assigned number of switches on a single device;
  • Permit association of each switch (1-N) to a Dashboard tile;
  • Allow user-defined Auto Off timer setting per switch;
  • Bonus feature: Allow user-defined string value for each switch's On/Off state;
  • Stretch goal: Allow setting all switches' states simultaneously using a bit mask!

I hope this isn't too far in left field, but considering we enjoyed a similar 3rd party plug-in (Switchboard by Patrick Rigney) back on the Vera platform, I can attest that this type of device has practical applications. It also spares us creating and managing large collections of individual virtual devices that relate to a single task.

THANKS! - Libra

To do all of this, you would basically just need a parent device with a bunch of "child" switch devices. I'm not aware of anything that exists, but it wouldn't be hard to write. However, I'm not sure if the "child device" thing is undesirable for you. These would be separate devices technically, but in the device list, they'd be grouped under the parent. The reason you couldn't do this all from the parent is that you can only implement a capability once per device, at least with standard commands, and the Dashboard "switch" template--and Dashboard in general, really--can only work with standard commands (you could do custom commands, like on1(), on2(), etc. on the device, but there's no way to directly call those from Dashboard). Customizing the on/off text (the value of the switch attribute) is also not possible because that is standardized and would cause problems,though again anything is possible with a custom attribute. It just won't be much help for manipulating with a Dashboard.

If you just want a button, that's all do-able in a single device, but I don't think it would be that different from the virtual button device. You could make a "hybrid switch/button" device, but you'd still need separate "switch" (child) devices to track each state and be able to manipulate it via standard means, so I'm not sure that would add much.

Just trying to think through the options... :slight_smile:

1 Like

Actually, while there's nothing at all wrong with the Parent-Child concept – after all, it accomplishes some of the wish list qualities, like easier grouping – the problem there is you'd still be stuck (a) creating N+1 virtual devices where one might suffice, (b) naming them all correctly, (c) passing them individually through Maker API and others (like Dashboard!) when needed, etc.

Yes, let's keep thinking through this out loud, because I sense that it is doable without too much hassle or need for a new, complex User Driver.

Another data point I might mention, is that such a construct almost exists in the form of the device driver "Virtual Omni Sensor", which has something like 12 (a fixed number of) state variables – moisture, contact, motion, activity, temperature, etc. – associated with it.

That's essentially what I'm after, only with a non-fixed number of these attributes, and all of them basically a binary on/off or TRUE/FALSE. (Heck, it could be a fixed number, to make designing the driver easier, but the number should be on the higher side, like an even 20 or so.)

Just more food for thought on the topic.

You wouldn't (necessarily) have to create the child devices; the parent device could do that for you. The parent could also handle naming (or it could be left to the user).

But to get multiple standard "switch"-capabiltiy devices, you would need separate devices of some sort. Whether those are all child devices of some parent device or just independent devices you create on you own, the idea is the same (but some people would prefer the former for organizational purposes, and the parent could provde some help with some tasks like alluded to above).

If you don't care that they are all literally switches, then something like the virtual omnisensor could work. But that driver works by just exposing a bunch of capabilities: switch, contact, motion, water, temperature, etc. That's how it can fit so much in one single device. If you wanted two (or more) motion, temperature, etc. attributes and wanted to use the standard Hubitat capabilities, you'd be in the same boat. Also, the name of each attribute (and thus the number of attributes you have) is statically defined in the driver and cannot be dynamically changed at runtime, which is another area where child devices make this easier (you can create/remove these devices at will).

1 Like

It occurs to me that this entire discussion could be rendered moot by having a new variable type that is effectively an object or map. With that in place, one could programmatically toggle or set arbitrary internal parameters within the single container variable.

Example:
TESTvar = {animal: dog, sound: woof, status: off, state: false}

Variable > Set key > "state" = TRUE

Although I realize this presumes quite a bit on the part of the Hubitat developers. Perhaps a bigger ask than my original proposal.

Increasingly looking like I'll be making multiple virtual devices for my purposes, lol.

While not a variable per se, that much could already be done with a custom driver if you really want. :slight_smile: But the trick would be being able to actually use those attributes and commands in Dashboard or really most stock apps, most of which are geared around the standard commands and attributes found in the predefined device capabilities.

2 Likes

You are right to caution against that solution. I got accustomed to certain variable functionality over on Reactor Multi Hub, where changes to objects and other types could trigger rules, so I need to be careful not to request parity here.