sorry for bothering you (again), but this is really odd. I am using two Fibaro FGSD002 smoke sensors. They are working (quite) good until yesterday. I updated to the latest OH2 snapshot (and zwave binding), and after the update strange things happened.
During the first regular wakeup of the first smoke sensor after the update, the channel states for alarm_heat and alarm_smoke switched from OFF to ON. I didn’t noticed this immediately since the sensor itself didn’t do anything (no audio, no visual signs. Of course also no smoke and no heat in the room).
In the night at 2AM, also the second smoke sensor did it’s regular wakeup and also changed the states from OFF to ON. This was noticed by me since I have a rule to send a broadcast message in case of alarm.
Until now, both sensors are still in ON state for both channels.
Since this wasn’t expected, I have no DEBUG log. I only have the events.log:
2017-01-10 18:08:56.676 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: WAIT to ONLINE
2017-01-10 18:08:56.705 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE to ONLINE: Node initialising: DETAILS
2017-01-10 18:08:56.708 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: DETAILS to ONLINE: Node initialising: GET_CONFIGURATION
2017-01-10 18:08:56.750 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: GET_CONFIGURATION to ONLINE: Node initialising: DYNAMIC_VALUES
2017-01-10 18:08:56.972 [ThingUpdatedEvent ] - Thing 'zwave:device:158bb98dc23:node13' has been updated.
2017-01-10 18:08:56.974 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-01-10 18:08:57.153 [ItemStateChangedEvent ] - Rauchmelder_Wohnzimmer_Rauch changed from OFF to ON
2017-01-10 18:08:57.229 [ItemStateChangedEvent ] - Rauchmelder_Wohnzimmer_Hitze changed from OFF to ON
2017-01-10 18:08:57.313 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: DYNAMIC_VALUES to ONLINE: Node initialising: DYNAMIC_END
2017-01-10 18:08:57.319 [ItemStateChangedEvent ] - Rauchmelder_Wohnzimmer_Temperatur changed from 23.7 to 24.4
2017-01-10 18:08:57.420 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: DYNAMIC_END to ONLINE: Node initialising: HEAL_START
2017-01-10 18:08:57.424 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: HEAL_START to ONLINE: Node initialising: DELETE_ROUTES
2017-01-10 18:08:57.586 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: DELETE_ROUTES to ONLINE: Node initialising: RETURN_ROUTES
2017-01-10 18:08:57.928 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: RETURN_ROUTES to ONLINE: Node initialising: NEIGHBORS
2017-01-10 18:08:57.952 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node13' changed from ONLINE: Node initialising: NEIGHBORS to ONLINE
The second log at 2AM:
2017-01-11 02:01:07.622 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE to ONLINE: Node initialising: GET_CONFIGURATION
2017-01-11 02:01:07.664 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE: Node initialising: GET_CONFIGURATION to ONLINE: Node initialising: DYNAMIC_VALUES
2017-01-11 02:01:07.859 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-01-11 02:01:07.860 [ThingUpdatedEvent ] - Thing 'zwave:device:158bb98dc23:node8' has been updated.
2017-01-11 02:01:08.028 [ItemStateChangedEvent ] - Rauchmelder_Kinderzimmer_Rauch changed from OFF to ON
2017-01-11 02:01:08.112 [ItemStateChangedEvent ] - Rauchmelder_Kinderzimmer_Hitze changed from OFF to ON
2017-01-11 02:01:08.195 [ItemStateChangedEvent ] - Rauchmelder_Kinderzimmer_Temperatur changed from 16.4 to 16.3
2017-01-11 02:01:08.198 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE: Node initialising: DYNAMIC_VALUES to ONLINE: Node initialising: DYNAMIC_END
2017-01-11 02:01:08.267 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE: Node initialising: DYNAMIC_END to ONLINE: Node initialising: HEAL_START
2017-01-11 02:01:08.269 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE: Node initialising: HEAL_START to ONLINE: Node initialising: DELETE_ROUTES
2017-01-11 02:01:08.384 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE: Node initialising: DELETE_ROUTES to ONLINE: Node initialising: RETURN_ROUTES
2017-01-11 02:01:08.723 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE: Node initialising: RETURN_ROUTES to ONLINE: Node initialising: NEIGHBORS
2017-01-11 02:01:08.743 [hingStatusInfoChangedEvent] - 'zwave:device:158bb98dc23:node8' changed from ONLINE: Node initialising: NEIGHBORS to ONLINE
Do you have any explanations for this? What could have happend? And more important: What to do that this doesn’t happen again. I feel quite uncomfortable when I don’t know if an alarm is triggered now…especially when I’m not at home…
I will try and set the state back to OFF manually now and see what happens during the next wakeup.
I changed the state for one of the two sensors manually to OFF, and until now knockonwood the state stays OFF. When I come home this evening, I will have a look if there was a wakeup in the meantime.
It might be related - but I’m a fan of having a log, or some other information on which to draw a conclusion ;). It’s too easy to say something is the same just because it has similar symptoms…
@jaydee73 A log would be useful if you can get one (no hurry ).
I just checked and realized that currently it seems to be ok. Self-healing . Like a car which starts working when being at the mechanic.
I check the behaviour tonight an send you the complete trace log when I can recreate the issue.
Sorry @mrohmann, but what are you talking about? Haven’t seen anything else in this thread from you. Is this related to the initial issue described in this thread?
sorry man, posted - or at least i intented to - the same issue 2 weeks ago and while searching for it i just thought that it would be this one. but i can confirm that i observed the same behavior as described here. as i have wrote before currently it’s working. sorry for confusing you
Interesting! And is it working again? For me it seems to work now. One device woke up an hour ago and I haven’t got new alarm messages. But I will continue monitoring this closely.
@chris: Manuel posted a DEBUG log in the thread he linked above. Might you have a look what caused this? At least now we are two with exactly the same issue on the same device.
the log posted on the other thread looks to come from a slightly older binding. It is still processing event 254 which I added a check for last weekend…
unfortunately, the issue still persists. I got the alarm triggered from both sensors last night. Again, it happened during the regular wakeup. The first one (node 8) triggered at 02:12 (2017/01/12) in the night, the other one (node 13) at 06:16 in the morning.
Thanks. I’ll take a look at the log - maybe it’s a different issue or maybe the fix didn’t work. The thing I fixed over the weekend was to ignore the 254 reports and I thought I saw a log to show that this had worked.
I might not get the chance to look at the log till tomorrow as we will be back late tonight, but let’s see.
Thanks Chris. Maybe your fix indeed isn’t included in my binding version. It’s from last sunday. And maybe because of the switch from cloudbees to bintray there was a slight delay.
I haven’t had the chance to look at the exact binding version on the Karaf console. And yesterday, the apt-get upgrade process didn’t work due to a small error. So I will try again and update this evening. After that, I will have another look if the issue still persists.
Even more strange, the following automatic wakeup of the two sensors (both of them are defined for a 6 hour wakeup cycle) went without a new alarm trigger.