morning.log (108.9 KB) (.gz)
I used your log analyze tool. But from what i could tell everything looked like normal traffic. I can not tell from where the devices stop sending data.
The log is captured before i rebooted the Pi, and stuff started to work again.
The devices don’t stop sending data - that is always working. The data is sent, and the binding receives and processes the data, but it is not sent to the channels, so it’s not available in the logs. Either the channels are unlinked, or something has gone wrong in the binding and it’s lost the list of channels.
In this log, it was not normal - ever - so whatever the issue is occurred before this log started. This log has no channels at all…
Ok thats good in a way. So when i restart the pi, openhab get restarted and the channels get linked proper.
Same thing probably happened yesterday when i upgraded.
As I mentioned earlier, when i create the channel to item binding im using PaperUI and just accepting the default values. Maybe I should try to generate the links in HABmin?
The log leading to the last log i posted, maybe there are some clues there.
midnight-morning.log (835.6 KB) (.gz)
It should make no difference - HABmin an PaperUI use exactly the same commands to generate the links.
This reminds me of something I saw a long time ago, but haven’t experienced in quite a while. It was so long ago that I don’t even remember if it was the old version of the binding or the new one. I had seen a couple cases where the channels were not being linked when the binding started. I noticed it because none of my nodes were being polled. But, in those instances, it affected all my channels, not just the channels for one/some nodes. Probably unrelated to this…
Here’s the post from back in July. Looks like it was on the new version of the binding.
I don’t think it’s an issue with channel links - it looks like the internal messaging between the ZWave protocol part of the binding, and the OH part is not working.
@JAFone if you get a chance, can you do a grep over your logs for the following -:
Controller failed to register event handler
My guess at the moment is that there is some sort of issue during initialisation where the event listener is not registering. Or, it might be getting removed…
This last log was useful and does narrow things down a bit, but we basically still need to capture a log that shows this issue starting - does it start when the binding starts, or does it start at some other random time.
Another thing to grep for is -:
Attempting to add listener when controller is null
No such messages.
I´ll let debug run over the night to see if i get the same issue tomorrow.
Ok, then we just need to catch when it starts to happen. It’s pretty obvious from the log viewer at least.
This morning all motion sensors, but the FGMS001´s were working 
Tried to reboot the controller again, but no luck.
Do you have logs showing when this stopped working?
yes, i added the file to an email as it was just to big to be posted here.
Thanks - what node is the faulty ones (ie the FGMS001)?
edit: Sorry - found it further up.
node 14 (fibaro):
chan: zwave:device:faba8aa8:node14:alarm_motion
item: ZWaveNode014FGMS001MotionSensor_MotionAlarm
node 19 (fibaro):
zwave:device:faba8aa8:node19:alarm_motion
item: ZWaveNode019FGMS001MotionSensor_MotionAlarm
node 20 (fibaro):
zwave:device:faba8aa8:node20:alarm_motion
item: ZWaveNode020FGMS001MotionSensor_MotionAlarm
thing: zwave:device:22bf04c5:node20:alarm_motion
item: Z_Eye_02_MotionAlarm
thing: zwave:device:22bf04c5:node19:alarm_motion
item: Z_Eye_01_MotionAlarm
I renamed items
I don’t see anything wrong in these logs. The devices are reporting state updates, and the binding seems to be sending them through to the channel updates. There are regular updates from temperature, luminance and battery, and some updates from motion (but that’s harder to know if it’s working as it is not sent on a regular basis - only when there is motion).
On looking further through the log, I can see that you have sent a reconfiguration to the devices at some point in the night, and this has removed associations -:
This may have come through the UI update, or some other method - I’ve not looked too closely, but this will ultimately stop reporting and probably is linked to your problem.
Thank you Chris. What i find strange is that i did the exact same thing with all the devices. And The Fibaro Sensors are the only ones having issues.
Events from last night.
Upgraded to latest version of openhab
removed all devices and the controller from openhab
re added controller and the devices.
Re made rules
Went to sleep 
//JAF
Well, you didn’t do “exactly” the same thing on all sensors then…
I see on node 20 that it was ok, and you set the values to something that, while different, is still ok.
If I look at other nodes, they are also ok.