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.
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.
Ok, fair enough - if it works, that’s great. I didn’t expect that as the protocol side is completely separated from the openHAB side, so the initialisation part of the binding will always try to initialise even if there is no thing added.
Ok, I misintepretted what you suggested. You have removed the associations using other software - not adding the thing in openHAB is not really relevant. openHAB will set the associations if there is a thing or not (as mentioned above) - if you then use other software, and don’t reconfigure the thing again in openHAB, then of course this would work. Sorry - I thought you were suggesting something different.
Note that you’ve still not answered my question about what commands this device is sending when it requests status? I would be interested to know what it’s actually doing as this is not standard for a scene controller.
I can now either:
a) edit the database to try and determine how to eliminate the bound associations of Node 1 in each of the four Association Groups. This would be nice so that we can determine whether openHAB could still learn of the active Scene status of the scene controller and we could enable additional “bonus” features via openHAB. Likely the “Active Scene” status from the scene controller is broadcast on the network, much like any other non-ZWave+ device, and probably still within openHAB and the Z-Wave bindings ability to learn anyways.
or
b) take a completely backwards approach program a rule in openHAB which looks for each of the 4 possible scenarios…Rule 1 = if this and that, then set Variable1 to true…if this and that, then set Variable2 to true, if this and that, then set variable3 to true, if this and that, set variable4 to true.
This would allow openHAB to learn whether Scene1, Scene2, Scene3 or Scene4 are active. A completely backwards/painful approach…but possible as a last resort.
Possibly because of my too many words! lol
This is simply a case of removing the controller from the groups in the database.
It won’t - if it’s not set in the association groups, then obviously openHAB will not receive the updates when the buttons are pressed.
Your other option, since you clearly seem to know what you are doing, is to remove the “Controller is master” configuration from the controller and this will prevent openHAB forcing these associations.
I would love to answer this question for you…I am still learning about openHAB and the understanding the debug log myself.
I can send you any debug log you want but I am honestly very thankful for your time and don’t want to waste it…I truly appreciate any second you spend on answering my questions.
When you say “what commands this device is sending”…I assume you are referring to the Scene Controller Device? And I assume you are meaning…when it requests status…it is actually sending a command out to other devices to request their status? If that’s what you mean, then maybe I gave you the wrong message…I never meant to imply that it sent a command out to request status…It actually listens on the network for regular network activity and captures the activity of the devices that are within it’s association groups. Any node within the association group that sends it’s own status report broadcast on the network to the all devices is captured by the scene controller and it then uses that as part of it’s management of the scene. nothing is going to show in the bindings debug log as far as activity from the scene controller. The only thing that may show up is the regular broadcast of the controlled devices when their status’ changes.
How would any other very dumb device inform the primary controller that it is on or off? Lets say…something very old…long before ZWave+ was ever thought of?
Would it not broadcast it’s status to the general network and the primary controller as a part of it’s job would be to capture that broadcast and update the status for the system of each node?
That would have been done without associations?
Why would this scene controller be any different?
