Yes.
There isn’t any, and this doesn’t really make sense. The lifeline is an association group (required to be group 1) - it can’t be bound to another association group.
As we just said - this is not a ZWave plus device - it has no lifeline group.
In other words…the Scene Controller, using it’s Lifeline association to the Primary Controller may likely use that association to tell the Primary Controller that Scene 1 is active…or Scene 1 and 3 are active, and constantly update that when it activates or de-activates it’s “own” scenes. Or to your point…because it is not a ZWave+ device, it actually probably doesn’t use the lifeline to update status to the controller, and very likely any mandatory binding to Node 1 is irrelevant on this device in any kind.
I think it is very likely that forcing an association within each of the controllers individual Scene Association Groups is very likely breaking the ability for the Scene Controller to Control it’s own scene properly…and by that I am implying that Associations Groups for each possible Scene are not the same as Associations of the Scene controller device. Scenes are not devices. Scene do not give status updates to anything. There’s only one device, but multiple Scenes. If anything, the device needs to be associated to a lifeline, not the individual Scenes. The Scene Controller monitors and listens to all status updates of all devices in “Association Group 1” and compares the actual set value of each node within group 1 to the value commanded in the Scene Controllers stored scene programming for Scene 1. For example, Node 22 dimming value at 50%. If any of the actual device reported set values do not match, then the Scene becomes deactivated automatically by the Scene Controller itself with no reliance on the Primary Controller Node 1…but not shut off. It assumes that a user manually adjusted one of the nodes or it was adjusted by some other controller other than itself, so the Scene controller essentially gives up trying to control the Scene. If on the other hand, someone set all of the nodes manually and those set values matched all the preset programmed values that existed within the Scene Controllers stored programming, then the Scene Controller lights the LED up for that Scene and starts controlling it again.
When we force Node 1 to be within the Association Group, then what is the programmed commanded value of Node 1 within the Scene Controller? And what is the reported set value of Node 1 in response? What Command is it trying to use…Node 1 is not a device…it probably doesn’t have a Set value that it could respond with? Then add on to that…if it did have a set value to respond with…then is that set value different when the Scene 2 button is pressed as opposed to when Scene 1 is pressed? If it is different, then Scene 1 is now broken the second we press Scene 2 because the set value of Node 1 changed and therefore the Scene Controller disables Scene 1.
There is one more thing I thought of trying tonight…if in fact there is a reported set value from Node 1, and if that reported set value doesn’t change between Scene 1 and Scene 2 activation, then maybe I can find a way to program the Scene within the Scene controller with whatever value so that it doesn’t disable the Scene. I think this is a pipe-dream to work, but I gonna try anyways.
I may be out to lunch…and you can feel free to tell me so! I am enjoying learning!
Okay, I tried my last idea and as expected, it did not work.
The multi-scene controller cannot control multiple scenes with this setup.
So, to attempt to try my device without “forced” associations to Node 1 within each Button’s association groups…what would I need to do?
You mentioned that this comes from the database…but it’s a shared device…possibly not everyone would appreciate me changing the database settings, especially if they have managed some sort of work around and have their device working.
How can I experiment with a development version of the database…change something on my local existance of the database?
connect to github, compile the binding locally…any other options? probably no?
I did not read through all of that (too much, no time), why don’t you just catch the scene number in a rule and use the full flexibility of openHAB?
That is what other people do with this sort of devices.
The scene controller does not have a lifeline. As I said earlier - the lifeline concept is only for ZWave Plus devices and you confirmed that this is not a ZWave+ device.
It therefore just has association groups that the manufacturer defines. The binding will not detect a Lifeline and will therefore not add a lifeline (since it doesn’t exist).
It’s not that it doesn’t USE the lifeline - there is no lifeline.
This is how it is meant to work.
1 Like
I appreciate you are busy, and I confess, I wrote a lot of words!
I have it functioning just like your referred article…but this limits only a single scene and it breaks the scene controllers ability to use its own indicator lights. Without the indicator lights, a user would not know if a scene is running. Yes, I can capture the scene change events and control everything from openHAB, but openHAB has no way to light the scene indicator.
That’s exactly my point as well…i think we are saying the same thing. If it is does not use the lifeline, then why is it forcing mandatory binding to node 1? Not 1 time, but 4 times…once in each association group? This is what is wrong in my opinion.
I need to try this device without that mandatory binding and I fully believe we will have a fix for this device to be able to be used the way the scene controller was designed, in addition continue to have it communicate through the binding to openHAB can also be utilized for additional control.
That may be how openHAB is supposed to work, but I don’t think this is how the Scene controller is meant to work.
There is no lifeline. It is configuring the associations as per the database. I think I said earlier, but all associations are configured in the database to send their reports back to the controller when someone presses a button. Without this link to the association, there would be no reporting when someone presses the button.
Can you describe what you believe this is (briefly 
).
If you remove the associations, it will not send reports, so it cannot communicate to openHAB.
My understanding of a scene controller is it sends the scene IDs when someone presses a button. To do this, it needs to have an association linked, and in most gateways (as I understand anyway) this will trigger a scene (in openHAB, these are called rules rather than scenes).
If this is not the case, then please can you describe what is meant to happen as per the standard way.
In as short as possible 
Scene Controllers are meant to “control” the scene to reduce points of failure in the environment (the primary controller, or other repeating nodes), as well as to be able to control the devices quicker and more efficiently, simply because it’s directly. They are meant to speak directly to the nodes within their assosciation groups, relieving the primary controller from having to perform this task. They send command messages directly to the nodes under their control and listen directly for status messages that the nodes under their control send out. With the programmed scene within the scene controller, and the status’s it receives from the device nodes, it manages the scene completely on it’s own.
True Scene controllers are not supposed to rely on a primary controller node and something like openHAB to actually perform the work. Certainly having the primary controller and openHAB be able to harness the status’s of both the Scene controller and controlled devices is definitely an added bonus no doubt.
In my example I am able to add associations within each buttons group and turn on multiple devices. This was done without even telling openHAB to do anything. In fact, once I have the associations groups set with the devices I want to control, I can actually power down my openHAB server completely, and my Scene Controller is still able to control the devices within it’s association groups.
This is not unique to these Leviton devices…this is standard to Scene Controllers.
On my previous platform (4 letters which I don’t want to repeat!) we were able to have both full Scene Control and full primary controller knowledge of it…but because my hardware controller for that platform went up in flames, I am unable to check how the associations within the groups worked, and whether Node 1 was included. I really don’t think it was. I do have a second controller of that variety, I could if needed, set it up in a test environment to try and double check the associations as well.
Where did you get this definition? Your definition requires that the other device also handles the scene commands - I’m not really aware of too many that do this (but maybe you have one/some). Most devices are controlled using BASIC, or BINARY_SWITCH, or MULTILEVEL_SWITCH commands and not the SCENE commands.
This is actually nothing to do with Scene controllers even - this is standard of most ZWave devices. I have a load of Fibaro switches here - they use the BASIC etc commands to control other devices - it doesn’t need to go via openHAB - this is a standard feature of ZWave.
To do this, you should just configure the association groups to send a command to the appropriate node. It shouldn’t matter if the controller is also included in the same association group - if it receives the scene commands, it will just ignore them unless you have set up a rule to do something.
This is exactly what I have done, but because the node 1 is stuck in the Association Group for each button, the scene controller is attempting to monitor the status of node 1, just like it is attempting to monitor the status of each and every device in the entire Association group. If ANY status within the group doesn’t match the status within the controlled scene programming within the scene controller, the scene controller kills the LED and gives up on controlling the scene. I capitalized ANY, because ANY includes the status of Node 1.
My earlier post (long one) questioned the ability of node 1 to have a status period…because it in itself is not a controlled device. If it did report some sort of status, then I am positive that status would not be specific to a status in regards to any actively running scene specific to that specific scene controller.
If it has no status, or if it did have a status and the status was not the same every time because it was related to general network activity not related to the scene controller, then because it will never consistently match the programmed set status within the scene controller, the scene controller would never be able to control it’s own scene properly.
Forcing a node 1 association within each button group forces the scene controller to try and monitor the primary controllers status. Immediately, in my opinion, things are broken. These devices are not ZWave+, they don’t have logic in them to make them aware of the new lifeline concept and can’t possibly know that node 1 is not a regular device and to ignore attempting to monitor it’s status.
Please can you tell me exactly what this means - preferably providing a log showing this so I can understand what is happening.
Again - I need to know exactly what this means - what messages are sent - exactly.
Let me ask you this…
If I were to delete the thing from openHAB and ignore the thing if it reappears in the inbox due to a search for new things via the binding and then use other software to program the association groups on the scene controller itself to remove Node 1, then I would be able to test my theory without having to modify the ZWave database…correct? Then node 1 would never get inserted into the Association groups?
No - this will not work.
Correct, the ability for one device to send a command to another device is a basic Zwave concept enabled by the associations, I agree…but a controller does a bit more than that. A controller in addition to that, actually listens for the status messages of those same devices and tracks their On/Off State as well so it can take it’s own actions…like for instance, turn on it’s own indicator light.
No offense but I beg to differ.
These images are of me doing exactly as I mentioned…deleting the thing from openHAB…not excluding it from the network…then removing Node 1 from each of the 4 Group Associations using the “Z-Wave Pc Controller” tool.
Image of config of scene controllers assosciation after removing node 1 from each of the 4 groups.
Image of scene controller, finally able to have more than 1 active scene enabled.
Prior to this…I was unable to have multiple scenes(LED) indicators enabled at a time. Pressing button 1 would break button 2,3,and/or 4. Now they work/function independently.
Of course, I’ve detached my device from OpenHAB so it can non longer know what the device is doing.