Ok, above you said it was after a “few hours”? Anyway, if there is some way to grep the logs to find when the updates stopped, and provide the log that has the alarms stopping, it would be appreciated. If we can’t get logs for these events, then really there’s not much I can do to help, so it’s in everyones interest if you can help…
Thanks.
Hello together, I also have the same problem with my Fibaro Motions Sensor. But it is not only the Motion Sensor. Also the Fibaro Wall Plugs FGWP102 do not send the meter watts anymore.
Besides, where can I find the log files?
@chris, yes I am pretty sure that alarms stopped quickly again after trying to update a parameter. Still I have the choice of 2 16M logfiles. I have put the one which I believe contains the right interval here:
But from my perspective the behavior was the same as what should be in this log:
You are still running 2.3 - please upgrade to 2.4. 2.3 is very different to 2.4 so I really can’t use the logs.
@chris Got it. OK, upgraded to 2.4 and re-created all things as described in the documentation. In general the system is working again. I have then reset this Fibaro sensor and included it again as Node 20. So far I am getting all motion alarms, but my configuration updates don’t go thru to the device yet.
From what I can tell, the device woke up at 19:10:32 local time in this logfile:
But seems the configuration updates didn’t go thru.
@Chris Hi Chris, I was also resetting my Z-Wave Controller and and all Devices and started with adding my FMGS001 and two FGWP102. Everything worked fine a few hours. I had my lalptop open, watching the log files all the time to see what happens.
At 11:04:40 the motions sensor (MagicEye_LivingRoom) changed the last time.
At 11:09:53 my node8 which is the motions sensor made an update.
After that update the sensor send no data anymore. And the mysterious thing is, that from this time on, either my FGWP102 didn’t send data to openHab. Nothing worked after that update. Maybe this helps.
Sorry - it doesn’t. Do you have the logs? Probably there was a configuration update that removed the associations - I have a PR I need to test to try and prevent these issues with errors in the UI etc removing necessary associations.
Do you use Habmin or PaperUI for configuration?
PaperUI never worked for me with the FMGS001.
@memphiz It doesn’t matter if I use PaperUI or HABmin. It’s both the same. @Chris What you see in the screenshot is all the logs.(event.log and openhab.log). Nothing else is in the logs between working and damage. Or are there other logs I can take a look in? Merry Christmas! 
I’m happy that I can still switch my lights with a normal wall switch :D.
Not “other logs”, but you can enable more logging in the same openHAB log. What is needed is debug level logging. @sihui posted the link to logging docs above. You should be able to enable ZWave debug logging with the following console command -:
log:set DEBUG org.openhab.binding.zwave
Ok, thanks. I’ll give it a try after Christmas
@Chris Hi Chris, tryed it today again. Reset the controller, add only the fibaro motions sensor. It worked. 13:35 was the last activity from motison sensor (node2). I left my house and came back and it was broken. I guess at 15:12 was the update that broke it.
http://www.chris-wohlbrecht.de/pub/logs.zip
That is the events.log.
We need to see your openhab.log with DEBUG enabled for zwave like earlier stated.
This is both.Debug zwave was enabled. If you unzip the file, you should see openhab.log and events.log. If not drop me a line.
Please can you provide the log from earlier in the day so I can see what was happening before this. This shows the first wakeup of the device, so commands get sent at this point, but it doesn’t why what triggered them to be queued in the first place.
Sorry, to many files in my unzip folder 
Thanks. It’s a bit strange, although the root cause is related to the UI configuration updates as I expected (which at least is one positive 
)…
This shows that there was a config update, and it didn’t process the association correctly, but I can’t see why not. The check looks fine -:
2018-12-30 13:11:19.016 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Configuration update set group_1 to [node_1] (String)
2018-12-30 13:11:19.023 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Invalid association [node_1]
The code looks like this -:
String[] groupCfg = paramValue.split("_");
// Make sure this is a correctly formatted option
if (!"node".equals(groupCfg[0])) {
logger.debug("NODE {}: Invalid association {}", nodeId, paramValue]);
continue;
}
So this tells me that the split of node_1 did not result in it detecting the node part. I have static tests in the binding to confirm this works, and it is working fine here in my tests, so I don’t know why this wouldn’t work 
.
What I will do in the first instance is to add some more logging so we can try and capture this again.
Crap - as soon as I re-read my message, I think I see the issue…