I have come across this before, and use the virtual binaries, but it did not quite do what I wanted for a more complex scenario, where I was using 2 switches to set the combinations, and was liable to use more, making it too complex.
I have therefore taken the liberty of adding a new DeviceType
of “MultiSwitch”, which can be set to have say 4 positions, and uses a quantised slider to return an integer (0-3 in this example). I forked it from the Stable branch in github.
To demo it I paired it with a gauge in Altui
The switch state is returned in Target and Status, and the max value (e,g. 3) is put in the “Text2” box. In case this is useful to anyone, the lua file is attached, feel free to incorporate / tweak etc.
Another day of playing with the switchboard, I have created an alternative icon for the tristate switch, as I wanted the “Void” mode to indicate “unknown” rather than “absent” which the X symbol meant to me.
I have loaded the icon into the /overlay/www/cmh/skins/default/img/devices/device_states folder on my Vera using WINSCP, ideally it would be with the other icons in github.
To select the alternative icon, set the subcategory of the device to 2 rather than 0.
I may create a new set of icons for my car charging some time, watch this space
OctoL_Switchboard1.zip (13.2 KB)
Version 1.6 is now released in the AltAppStore, and is expected to be available in the Vera Plugin Marketplace on Monday morning.
Add Lock, Water Valve, and Relay virtual devices. Note that lock has a separate service for Target and Status from all other binary on/off devices — it does not use urn:upnp-org:serviceId:SwitchPower1, but rather urn:micasaverde-com:serviceId:DoorLock1.
Make post-timer return state configurable via TimerResetState; this enables TriState virtual switches to return to off or void.
Two quick observations about locks (based on my own experience):
(a) There was a time – I hope it is not still true – that Vera was including “Lock/Unlock the door” access to Alexa, by default. I had to go manually remove that device from my “Manage Alexa” settings, to prevent someone from, say, talking through our window and having her unlock the front door.
(I mention this solely as precautionary advice to other homeowners.)
(b) Some (physical) door locks and deadbolts report themselves as “unlocked” when in fact they have not yet been “turned open” by the knob (and then they re-“lock” after a number of seconds). Just a consideration for those writing Reactor routines based on lock status, since the timings between states can be tight and/or not entirely representative of real world status.
@rigpapa I tried out the lastest update with the TriState switch, the TimerResetState, still doesn’t do quite what one would expect (or probably want) for a TriState Switch, basically the point of a TriState switch is that you don’t know what state the device is in (because it is not a device that has feedback and can be set via other means then Vera), so you always want it to trigger your On scene when you press On or Off scene when you press Off regardless of what the real state of the device was. So when the TimerResetState is 2, you want it to be triggers on both the On or Off command. They way it works now is that it only reset to Void if you turned the device On, but if you turn the device Off, it stays in the Off position (so I still have to have my scene take care of that condition).
Another oddity that I discovered, is that you can only set the state to Void using the Scene Wizard, you can’t set it directly from the Advance Editor, because the advanced editor only allows a True/False value for the switch, and for some reason doesn’t expose the VSwitch states at all (which might have been a potential work arround). So it took me a while to figure out how to put my delayed action back into my Off Scene to set the state to Void, since I never use the Wizard and only use the Advance editor generally.
Don’t get me wrong… absolutely love this thing! So thanks for continuing to develop it!
Well, that wasn’t the original request! But I can certainly see the logic in doing it the way you suggest. But now I have the problem that somebody may rely on the current behavior. So…
Will anybody care if tri-state switch is modified so it can timer-reset to void from both on and off modes? For clarity, that would be a change from the current behavior, where tri-states will only timer-reset to void when set on (off mode does not run the timer). Speak now or forever hold the pieces; if there are no objections, I will make the change.
This is a limitation of the way the involved subsystems work on Vera. The Scene Wizard uses the UI definition defined in the static JSON file D_TriStateSwitch1.json for tri-state switches, so in this case, I can affect what is shown for scene setup. When you go the Advanced Editor, however, it only shows what the related service defines as acceptable values, and since the service is the system-standard urn:upnp-org-serviceId:SwitchPower1 that only knows “on” and “off”, there is no way for me to tell it to also allow “void” and what value “void” would be. To change the service, I would have to change the device type, and if I do that, the device loses compatibility with the Vera mobile apps, Imperihome, voice assistances, and other facilities. It is a design guideline of Switchboard that these devices maintain compatibility with these facilities, so as a result, it requires that the system-standard device types be used. This then introduces the trade-off that all limitations inherited by the use of those types apply. I’m afraid there is no 100% solution that works for everyone and everything in the Vera world.
Not that I am using your version ATM, but it is the way I had set up the original Tri-State Switch. Once you make the changes then I can move over to your version!!! n:)
FWIW, I haven’t been following the development of this but what you have asked for is exactly how I would expect the Tri-State to work.
So please go ahead and make it what it should be…
The Up & Down needs to be momentary for that to work, I’m not sure if that could be programmed into the switch?
Better still to add a timer option to the Up & Down which would allow it to stop at predefined levels.
While we are at it make it Up - Stop - Down or On-Void-Off and go that extra step and allow your own text.
Tried searching this tread but it wasnt working very well - at least using control F in the browser. Would there be any way to easily change the virtual switch type - for example, from a light bulb to a switch?
OK. So to the first, there are ways to change the device type, but I do not recommend it, as any error made in the process runs the risk of the device becoming invisible and then a real tangle to fix, or in some cases, you can put your Vera into a reload loop. The safest way is to create a new device of the type you want and switch over to it.
With regard to the icon, this is a pretty widely discussed topic here on the forums, and the substance of it is simply changing the “subcategory_num” attribute in the device control panel Advanced > Params. Here’s some recent info on the category and subcategory icon relationship for binary light (category 3) devices: Making sockets not a light
If you have a dimmer device, you will need to recreate it as a binary light, as the only available icon for this device type (which is category 2) is a bulb in varying degrees of illumination.
You’ve got me wondering now, can a virtual switch be “associated” with a physical z-wave switch in such a way that turning on the physical one makes the virtual one respond, without any programming on Vera?
I was thinking along the lines of zWave Associations that one can employ with physical devices, giving master control to, say, one switch in a room that then turns on/off all the others. Would be neat if virtual switches could respond to that (rarely used?) setting.