ZWave associations are implemented in the mesh… they are specifically an instruction for a device in the mesh to send a message to another identified device in the mesh. Once configured, that occurs without the involvement/awareness of the controller, so aside from the fact that we can’t (easily, in a Vera-supported and -endorsed way) intercept and handle ZWave messages in current firmware, there would be no message to intercept.
As I later realized, the more apt term may be ‘Group’ - see Z-Wave Groups, Scenes & Associations — Vesternet - but your point is well taken!
I have vera (actually openLuup) connected to Home Assistant through the Vera integration. The switchboard devices show up in Home Assistant but do not function (no control and do not reflect current status). Is there a way to make them work?
Switchboard 1.7 is now released and will shortly be available in the Vera App Marketplace and AltAppStore.
This version contains two feature enhancements:
- Tri-state switches can now have the delay-reset timer reset the switch to any of the three possible states by setting
TimerResetState(0=off, 1=on, 2=void) on the device. - Support for virtual scene controllers. Please see the README.
This is an exciting update. Although I haven’t yet found a use for the Scene Controller aspect, I do like that its state can be set a number of ways, including a bit mask. I hope users read the documentation on that and ponder some innovative use cases for us to explore.
Since SetLight is just a regular UPnP-Vera action, it would follow the standard form for an action invokation via HTTP:
http://your-vera-ip/port_3480/data_request?id=action&DeviceNum=NNN&serviceId=urn:micasaverde-com:serviceId:SceneControllerLED1&action=SetLight&Indicator=1&newValue=1
2 Likes
Here’s how I’m using one now:
I have a single-state mode Virtual Scene Controller that is driven by my house-wide ReactorSensor. It has four modes/scenes: Morning, Day, Evening, and Night. The ReactorSensor sets the appropriate mode for the time of day. Other ReactorSensors then look at the VSC rather than the ReactorSensor’s group states to control lighting and period-of-day tasks in each room.
1 Like
Love it. You are the only forum member who (literally) wrote the book on constructing your own plug-in that instructs another plug-in to set yet another plug-in, to be monitored by the first plug-in!
1 Like
I’m actually blown away by the extent of the cleverness people apply to getting things done on Vera. I hardly consider myself among the top in that respect–we’ve got some very creative minds at work here. It’s one of my favorite things about this community.
3 Likes
@rigpapa, is there any way for a virtual scene controller to be added to the alexa managed devices? i created one, but it seems it is not picked up in the home.getvera.com manage alexa page. Most likely it’s the vera integration with alexa, but thought you may have some trick up your sleeve. i have a few uses for this and it would replace a few reactors and individual switchboard switches making the interface much cleaner.
Same for me. I don’t see any of my scene controllers, real or virtual, listed among the devices in the Alexa configuration at home.getvera.com. I guess that device type is not part of the integration.
The only way i see of doing it would be having a virtual switch and using that via scenes/reactor to affect the virtual scene contoller.
Unless Ezlo decide to use there experience in adding to Ezlo/Alexa integration, over to Vera.
I’m not sure these are supported by Alexa at all:
maybe with a custom skill you can map these to single device. ha-bridge could be capable, since it allows you to call HTTP endpoints with custom devices.
1 Like
maybe Vera could use streaming device or entertainment device for a scene controller and use the channels as the toggles?
Maybe, but the current firmware is not supported anymore, and I doubt they will ever patch the current Vera skill. In fact, yesterday they launched the new eZlo skill with new features long awaited on Vera.
Hi RigPapa,
I think I have found a couple of problems with the Tristate reset…
The first is that the init call to create the TimerResetState Var is never actually run. It is nested in the Case Select where b is Binary, so the “if b == Tristate” clause cannot work…
if b == "Binary" or not df then
luup.variable_set( MYSID, "Behavior", "Binary", switch )
luup.attr_set('category_num', "3", switch)
luup.attr_set('subcategory_num', "0", switch)
luup.attr_set( 'manufacturer', DEV_MFG, switch )
luup.attr_set( 'model', DEV_MODEL, switch )
initVar( "ImpulseTime", "0", switch, MYSID )
initVar( "ImpulseResetTime", "0", switch, MYSID )
initVar( "AlwaysUpdateStatus", "0", switch, MYSID )
if b == "TriState" then
initVar( "TimerResetState", "", switch, MYSID )
end
This change fixes that:
if b == "Binary" or b == "TriState" or not df then
I now get the var, can set it to 2, but the switch dropped back to OFF rather than VOID. If I then clicked on VOID it goes ON, then OFF. If I click ON, it goes on, then OFF.
I think I have traced that to the Behaviour of the switch, which defaults to Binary. I have changed it to TriState, and it now works as I would expect a tristate to, and have changed the code to
if b == "TriState" then
initVar( "TimerResetState", "", switch, MYSID )
luup.variable_set( MYSID, "Behavior", "TriState", switch )
end
Not sure if any other params should also be set?
HTH
Cheers
Octo
1 Like
I completely revised the initialization in the stable branch release of Switchboard a couple of weeks ago, but have not released it yet to the Vera App Marketplace. Your code changes have some issues and aren’t complete. My official version can be found in Github stable at the moment. Please don’t post unofficial versions of code here. The preferred procedure if you want to suggest a change is to use a pull request on Github.
3 Likes
Thanks Rigpapa; I had not seen any response so did not know the basecode was updated. I cannot edit the post to take out the code, so have just deleted it. I have uploaded the new version and will give it try.
Keep up the good work, and I’ll have a look at how to fork in Github 
Cheers
Octoplayer
I’m looking at this for similar use - I change the native house modes via reactor as an activity and then have conditions based on said state. I was already looking at changing that to a new variable in one of my RS and creating perhaps a 5th or 6th state that could further tune conditions. I just stumbled across switchboard yesterday, installed to replace all my VS and uninstalled that plugin to clean up. So far so good (thanks as always for solid dev) - But I’m a little confused as to the benefit of using the VSC in place of just variables. My guess is the interaction is easier - UI, etc. and of course the multi-state ability. My ignorance is probably stemming from the fact I’ve never used a scene controller - just had scenes and either: (1) imported into Reactor activity or (2) used a VS to trigger a scene
I’d love to flex the power of this, just not sure how lol.