The log is currently 76M and i cannot upload it here. I can put it on a dropbox or do you have a public share?
76MB is too big for me to process.
I would suggest to ensure you have some sort of log rotation so that files are limited to something like 10MB each (I thought by default thatās how logging was configured).
Alternatively (or additionally) if the log is full of stuff from other bindings and the system, then you can create a ZWave only log, or, you can filter the current log to only display ZWave logs (but donāt filter on a single node).
Ok 
looks like default log rotation is 17M. I merged all logs to that 76M. There are 15 or so devices and they are a bit chatty now in debug mode. If we cant find the 
maybe the donkeycorn will do even if its not quite the unicorn we are looking for.
IĀ“ll post the last logfile when it stop sending data. Maybe we can see whatĀ“s leading to its muteness.
So, maybe not two yearsā¦ but losing associations (or what seemed like it) has affected me for a long while. Removing associations and then readding them corrected it, but with the number of devices I have, deleting/rediscovering the Things was easier. Status updates after manual operation continue to stop working occasionally, and seems to consistently correlate with updating the binding. My battery devices (using SENSOR_BINARY) and energy monitors are not afflicted with this. Currently, my Leviton dimmers and switches (using SWITCH_MULTILEVEL and SWITCH_BINARY) are not reporting. Iāve been watching the other threads about associations disappearing, in hope that this might be the same issue. I think this was the first report of how I was resolving thisā¦
Ok, this wasnāt something I was aware of, and I was just confused about the earlier statementā¦
All I can suggest is that you need to try and capture the logs to find out what is changing. I appreciate it may not be so simple, but without something to go on, itās pretty hard to work out what is happening. The binding does not go and change these things by itself - other than during the device initialisation.
The only thing I can really think of is that this is being changed through the UI - ie when you update a device, PaperUI, or HABmin, is sending invalid data, and this is causing the associations to be removed. We know there are UI issues in both programs with the select boxes that are used to select associations, so this is my favourite contender.
I think this can be ruled out, as I have devices affected that have not been modified through a UI. My WAG is that it somehow has to do with the binding definition being different than the current Thing definition. Possibly related to an OH upgrade or cache clearing.
Iāve been distracted with other things and havenāt focused much on zwave for a while. I donāt see this changing any time soon, but wanted to raise my hand again to say itās happening here too! And also, this does not look like specific to a particular device type.
Iāll get them working again and doing some debug logging next time I upgrade the binding or OH.
Ok, then Iām lost as there is nothing in the binding that will reconfigure the device by itself 
.
Iām not sure why this should affect it. The code that does the initialisation etc does not rely on the database. The binding effectively has 2 well separated parts - the ZWave code that does all the initialisation, and interaction with the devices, and the openHAB code that does all the interaction with the framework. There is very little link between them other than to send commands through the channels, and send configuration from the UI.
Ok, thatās fine, but as I said, without something to look at, I donāt see this being resolved as I donāt see a way for the binding is doing this by itself. I might be proved wrong, and Iām happy to be, but I canāt see a way for this to happen directly in the binding (ie without some sort of external influence that comes from configuration - either from the UI, or from thing definitions, or somewhere).
To track this down, I would need to see logs that provides some sort of pointer as to where it is coming from.
1 Like
Not sure if itās relevant here, but one thing I noticed recentlyā¦ This was giving me grief trying to track down why a thing config was being overwritten with some default values.
I think I knew this at one point, but likely forgot. During discovery, a thingās config parameters can be overwritten here, even if the thing is not in the inbox (i.e. it is a real thing). This was driving me nuts for a couple hours yesterday. Again, not sure if relevant, but thought Iād mention.
@chris
log is gziped. but im uploading it with .log extension.
just rename it.
When i got back home. None of the motion sensors reported motion even tho activated.
Maybe you can see some off the logs?
debug.log (270.8 KB)
Hmmm - good point. I saw that discussion. I would like to say itās not linked, butā¦ When things are added to the inbox, they shouldnāt have all this configuration - unless of course ESH is taking all the configuration and resetting it, but if that was the case, I think it would screw up all devices in all bindings.
Letās see.
What are the nodes that have problems?
@chris
14
19
20
9
12
13
15
How ever.
I downloaded the latest version available and the sensors are reporting changes when motion activated again.
Nothing in the log at all.
Only messages FROM the device in the log
This node is completely reinitialised for some reason? Anyway, the associations are reconfigured, but appear fine -:
This is basically just messages FROM the device, with a few commands sent TO the device to tell it to go back to sleep.
Same as above.
Same as above.
And again, the same - nothing other than standard transmissions. As an example, Iāve posted below -:
Iām pretty sure this is not the case. From what I saw yesterday, itās only when the discovery result contains parameters that already exist in the thing.
So, likely not the culprit here.
Hmmm - I guess the other point to note here is that the device is reporting the alarms just fine!
My guess here is that either the database is wrong, or your items are wrong. Can you tell me what version of the device you have so I can check the database. Also, please advise what channels you are linked to.
The other point of course is that even if this was the case, it would still end up showing up in the binding as the binding would still need to transfer the configuration to the deviceā¦
devices is the fibaro device as listed above as well as
node 9,12,13,15 are Aeotec Multisensor 6 ZW100-C .
I know i am running an āunstable releaseā and issues may occur, so I hope the debugging is of use.
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
node 9:
chan: zwave:device:faba8aa8:node9:alarm_motion
item: Z_MultiSensor01_MotionAlarm
node 12:
chan: zwave:device:faba8aa8:node12:alarm_motion
item: Z_MultiSensor02_MotionAlarm
node 13:
chan: zwave:device:faba8aa8:node13:alarm_motion
item: Z_Multisensor03_MotionAlarm
node 15:
chan: zwave:device:faba8aa8:node15:alarm_motion
item: Z_MultiSensor04_MotionAlarm
Yes, I know that, but I need to know exactly what device you have as there are two versions.
This is a ghost device. I tried to get rid of it by excluding it from the controller. But it is reappearing and is not that talkativeā¦
Node 20: FIBAR GROUP S A FGMS-001 zw5 v3.3 EU
Node 19: same
Is this the information you wanted?