New Plugin: Switchboard -- Virtual Switches Re-imagined

If your overarching goal is to use HomeKit with Vera, I recommend that you checkout homebridge-vera. That will eliminate the mqtt element of your current solution because it bridges HomeKit to the Vera via http.

If you really want to continue down the mqtt path, make sure you have the version of the mqtt client that can receive messages in addition to sending (there is a fork somewhere).

The SetTarget action in the urn:upnp-org:serviceId:SwitchPower1 service is supported (otherwise the device’s own dashboard card would not work). You might check your LuaUPnP log file to see what is logged there. I don’t use NodeRed or Home Kit so I can’t be of much help there, but these virtual switches implement all of the standard behaviors and actions.

I already have a Homebridge. I want to learn how to manage through “Node red”.

Cool. Are you using one of the forks that extended the mqtt-client with subscription capability? I believe @vosmont added it here - Commits · vosmont/vera-mqtt · GitHub Not sure why the various forkers haven’t submitted pull requests to the original repo so there is a single source but it is what it is so you might want to inspect the various forks to see if there are other changes that apply to your use case.

I don’t use Mqtt . I use conversion functions

@sagos, I guess I don’t fully understand your setup but if the conversion functions run in node-red which in turns sends an mqtt message to your Vera, then you need the version of the Vera mqtt client that can “receive” the node-red messages - the original Vera mqtt client can only publish messages, not receive messages.

That said, maybe the folks in the Node-Red Vera-MIOS thread can lend a helping-hand.

On another topic,
Is there a way to have the default go to “void” instead of off in the timer?

Not in the current released version 1.5. The 1.6 stable branch (development) version supports it by setting the “TimerResetState” variable to 2.

Hi! I have a huge number of legacy virtual switches set up. Is there a way to migrate them to switchboard switches en masse without recreating them and their associated scenes one by one? Appreciate any advice I can get, thank you.

I’ve only recently discovered as part of the Sonos project that there’s a way I can “adopt” a device and make it a child that seems to work. Switchboard does not yet have this capability, but if you want to wait a day or so, and you happen to have a thick skin and an unhealthy taste for risky experiments, I can add it to the current development version and you can try it out. I’m not kidding. Are you game? If it works, it would be an undeniably huge benefit.

Edit: Well… there’s good news and there’s bad news. The good news, adopting the existing devices works, no problem. The bad news, unfortunately (and obviously, now that it’s staring me in the face), is that when they change from the VSwitch device type to the Vera-standard device type, the old VSwitch1 service goes away. This means that if you have code that uses the VSwitch1 SetTarget action instead of the SwitchPower1 SetTarget action, that code will not be able to manipulate the switch. The old VSwitch plugin should never have implemented its own version of SetTarget–it was unnecessary, given that it could have simply used the standard SwitchPower1 action of the same name. But it did, and I suspect a lot of people have ended up using it, rather than using the standard one.

So, while I can adopt the switches and preserve the device numbers and have them inherit the benefits of Switchboard virtual switches, I cannot replace or continue the old service actions, and that’s going to send you running to fix all your code/scenes anyway–you’ll need to modify them to use the standard service ID urn:upnp-org:serviceId:SwitchPower1 (otherwise it’s the same, though).

The stable branch on Github has been updated with the adoption code, in any case. It’s still a step in the right direction, even if the upgrade isn’t completely seamless/effortless, so I’ll leave it. There’s now an “Adopt” button under the list of switches in the Switchboard control panel.

1 Like

A feature that would be useful is to be able to make multiple virtual switches in bulk at once! Like you can do with reactor.

There’s no “easy button” in the UI, but you can invoke the AddChild action on the master/plugin device with a count:

luup.call_action( "urn:toggledbits-com:serviceId:Switchboard1", "AddChild",
   { DeviceType="Binary", Count=number_of_devices },switchboard_master_devnum )

The DeviceType parameter can be: Binary, TriState, Dimmer or Cover, These are case-sensitive.

1 Like

HI Rigpapa
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
image
and
image
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.

Cheers
Octoplayer
L_Switchboard1.zip (10.1 KB)

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.
image .

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 :slight_smile:
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.
1 Like

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. :wink:
(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.

  • Libra

@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!

1 Like

Well, that wasn’t the original request! :joy: 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…

1 Like

Concur (as in, I vote “Yea”).

1 Like