Yes, node 1 is the controller.
Which node is the one losing its lifeline association?
First questionā¦ Is there a reason why node 24 is sending reports multiple times per second? Itās likely using a bunch of your Z-Wave network bandwidth. The log is literally full of these messages.
All nodes are being set to node_1 of lifeline association. As for node 24, I am trying to get information on a more timely bases but that is too much. I will look at the parameters for it.
From what I can see, thereās nothing in the log showing any associations being set. In fact, there are no association commands at all (set, get, report) in the log file.
Yeah, it looks like itās reporting every couple hundred milliseconds. Probably not what you want. 
This is not always the case. If youāve added a secondary controller and then shifted it to primary, your primary controller could have any possible node ID.
what are you using to breakdown the debug into the table you are showing?
Just wanted to chime in on this issue as Iāve run into it a few times as well (see ZWave device association/physical switches not registering)
Before when this happened to me I used the OZWCP tool (as mentioned in the other thread) to re-set/force the lifeline group back to the controller node (in my case node 1).
I had to upgrade my OpenHAB system to 2.4.0M6 yesterday and I had issues with several (but not all) Fibaro 212 dimmers (the new ones). Some of them were not reporting their state back to the controller when manually switched. I tried to reconfigure the nodes using OZWCP as I have done previously but now this didnāt work eitherā¦
What did work for me, howeverā¦ I went into PaperUI to the Thing of the Fibaro dimmer, pressed the āedit/configureā button and once again set the āLifelineā association group to āControllerā, but in addition I also toggled the āre-initialize deviceā toggle switch under āShow moreāā¦ And now all of a sudden my device is once again correctly reporting itās state when triggered manuallyā¦
I hope this will work for you too!
A small update (with no debug log).
My system had been stable with all lifelines working being set for about a month.
But I started editing some rules and suddenly I:
- I got a bunch of errors like the ones in this thread: https://github.com/openhab/openhab-distro/issues/587
- Had a non responding server
- Had to cut the power in order to restart.
- Observed that half of my z-wave nodes (Fibaro Dimmer 2s) had lost their lifeline.
I also use Visual Studio Code and will stop doing that as this seems to sometimes create problems.
TLDR: Everything worked well until a power-cut restart of the raspberry pi. Then nodes had lost their lifeline. Visual Studio Code most likely caused the necessity of the power-cut restart.
What version of openHAB are you running? There was a problem a while back where exiting VS Code would cause the openHAB process to exit, but thatās since been fixed. Otherwise, thereās nothing Iām aware of that would cause VS Code to introduce this type of instability.
2.4.0 build #1416.
Might an upgrade help?
Probably not. The problem I referenced above was fixed in early October.
For what itās worthā¦ I am using VS Code to edit my files, but Iām not (yet) using the OpenHAB plugin. So even if there is an issue with the OpenHAB process being stopped or interrupted by the faulty plugin, this wouldnāt have affected me.
I have had this problem a few times before where all of a sudden my lifeline associations would stop to work. (Although they hardly ever show up correctly in the PaperUI regardless). For me using the OZWCP to reconfigure my troublesome nodes has fixed this in the past. Recently I was also able to use the āRe-initializeā device option in the PaperUI while explicitly resetting the lifeline association group to node 1 (my controller). This didnāt work in the past but I suspect an update to the ZWave binding may have fixed that.
Noticed that logs rotated into the highest index first.
I prefer them rotating into the lowest. (log -> log.1 -> log.2 ā¦)
To achieve this add the following line in the config:
log4j2.appender.Zwave.strategy.fileindex = minI can confirm: Re-initializing is now working for nodes which have ālostā their lifeline.
Instead of the re-init, try just deleting the Thing and rediscovering. I typically have to do this after every zwave binding update to get my dimmers reporting their states when manually operated.
not for me unfortunately