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
Not for me either, i reinitialize but cant set the LifeLine because of these errors. I’m at my wits end, i just cannot work out how to get a stable, problem free zwave network and I only have 10 or so devices.
I factory reset everything, delete all things, restart the binding and reinclude then I see devices stuck in GET_CONFIGURATION and other devices that wont accept a LifeLife and so will not function at all using ZWave, only using their mechanical button.
The items in question update values for their power metering just fine though so it can’t be a range issue (they are approx 4m apart anyway)
10-Jan-2019 11:26:32.023 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update received
10-Jan-2019 11:26:32.024 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Configuration update set group_1 to controller (String)
10-Jan-2019 11:26:32.024 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 4: Unknown association group 1
Have you tried the 2.5 Jar?
Thanks
Andrew
I’m on the 2.5 jar, unless theres a new one:
openhab> bundle:list | grep Z
264 x Active x 80 x 2.5.0.201812302011 x ZWave Binding
openhab>
2.5 fixed the AG issue for me when I picked controller, it either stuck or went to node_1 - think the null GUI error in habmin is still there - are you doing in habmin or paperui?
Both work just fine in my experience but yes the visual bug is there.
I’ve reset everything 4 times so far, and finally, with only 1 device to readd I think it’s working. I won’t hold my breath though!!
I find the only real way to fix this stuff is just reset the whole darn thing, delete all the XML, Things and start over.
Ive only got 15 devices.