Well, and this is what I do not understand. Take a look at a part of my debug log:
2016-10-09 15:51:17.326 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class SENSOR_ALARM
2016-10-09 15:51:17.326 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 8: Received SENSOR_ALARM command V1
2016-10-09 15:51:17.327 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 8: Alarm Report: Source=8, Type=Smoke(1), Value=0
2016-10-09 15:51:17.327 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmSensorValueEvent
2016-10-09 15:51:17.328 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
2016-10-09 15:51:17.328 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 0
2016-10-09 15:51:17.329 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Updating channel state zwave:device:157a888536a:node8:alarm_smoke to OFF [OnOffType]
There is an incoming value from the device for smoke with value=0 (line 3). And the zwave handler converts this to OFF (line 6). As the device lies here beneath me, it’s obviously in a “NO ALARM” situation. So value=0 seems logical, but OFF is - according to the channel types - the state for ALARM.
Does this makes any sense @chris ? Sorry for highlighting you again…
I updated the binding (just to be sure), deleted the xml and the thing, re-initialized the device and after some hours (=first wakeup), also alarm_heat send a value (OFF).
Problem solved.
Nevertheless I still have to try an alarm scenario. Which value will be reported and do my OH1 rules react as expected?!
BUT this is my log for one of my two offending sensors :
2016-12-19 19:24:45.263 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2016-12-19 19:24:45.264 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2016-12-19 19:24:45.266 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2016-12-19 19:24:45.268 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 254, type OnOffType
2016-12-19 19:24:45.269 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:1590c582342:node5:alarm_smoke to ON [OnOffType]
and this is my habmin screen, clearly stating “alarm” :
Given that there is no smoke in my house, I am a little confused as of :
how to get the 3rd sensor to send all values (I did remove it from the controler and re-include it, then I did wake it up several times)
what is the real “no alarm” state ? ON or OFF ? ( if “off”, why do I suddenly get alarms ? is the linked site not-up-to-date ? are my sensors failing simultaneously, if so why and what can I do about it ? did something in the code change recently ?)
my bassic values are :
“-1” for basic ON , can’t get it to update to the default 255 => issue with unsigned byte in habmin ? (or swave binding ?)
“0” for basic OFF
It works fine here. I spent some time to get this working well (I think).
When you say you updated the binding - did you also delete the thing and add it back? I guess not since I think the channels would have changed - this is necessary.
I did update OH2 globally with an offline snapshot so the binding was updated. I did delete the things and re-add them. I’ll try to play with parameter 2, but … is “ON” a “no alarm” state ? (habmin and cd-jackson.com thay the opposite)
Yes, the sensor works for me. And yes, ON means ALARM. I made some further tests yesterday and got sensor activity for both, HEAT and SMOKE channels. Both events got triggered when the device has reached it’s threshold. And the device also made some noise of course.
But unlike chris, I am using slighty different configuration parameters. In fact, I haven’t changed them after initialization, but I’m not sure if these were the default settings from the binding or if the settings were stored on the zwave stick and therefore taken over from my OH1 installation (were the sensor also already worked).
It looks like we are using basically the same configuration. I changed Parm4 as otherwise there was no sound for a heat alarm but otherwise it looks like it’s the same config. I started from a factory reset…
Hi, there is something wrong for me. I unboxed my 3rd fgsd-002, and it too is in “alarm” state under habmin (it’s battery is at 100%, so it’s not a power issue).
I noticed however that all association groups were emptied on all 3 fgsd (dooo how did this happen ?). So I set up back group 1, 2 and 4 on openhab controller.
I have also a different configurations for basic ON (-1 …) and OFF (0), but I’m not sure this is the problem. Also I did set sensitivity to LOW to see if it makes a difference…
edit : seems not, everything is still in smoke_alarm and heat_alarm state. I may have to factory-reset all 3 fgsd and hope they come back to normal … or else I don’t known what
@chris: May I ask you to have a look at my newest problem with this device? Santa brought me another FGSD002 smoke sensor and I have integrated it (as usual). Node 13 in the log.
This happened three days ago and until now I only could get values for temperature and battery from the device. No alarm and heat state (therefore undefined). In another thread you mentioned that these states will firstly be transmitted when a real alarm occurs. But it this really the way it has to be?
If you have a look at the debug log, the binding polls every 30 minutes the alarm/heat/smoke channels, but (as far as I can see) doesn’t get an answer from the device. Only temperature and battery (from time to time). Is this normal behavior of a zwave device not to react to pollings?
Furthermore, I have had a look at my “old” smoke sensor (node 8) and there also no value for heat/smoke/etc. is transmitted.
Do you get regular state updates for these channels from your own sensor?
Maybe he wants to make sure it’s safe to come down the chimney next year ;).
This is something I need to look at further. The sensor uses the notification class and it is possible to poll notification states, but a device doesn’t need to respond to the poll.
No.
This is something I want to look at further when I get a chance. This command class is one that I want to look to convert to use a new codebase that is autogenerated directly from the Z-Wave documents but it’s a complex class (which is of course why I want to use the auto coded version - to make sure we have a compliant implementation)… It will take a little time probably but I’ll try and take a look over the next couple of weeks…
Maybe - and I don’t necessarily disagree with you but many devices don’t respond to these polls.
When you think about it, it’s actually a little pointless - you don’t want to poll every 30 minutes to know your house is on fire - it’s the notifications you need. You just want to see the poll so you feel more comfortable that it’s working - that’s all (right? ).
I’ve not had a chance to test, but I’ve updated the binding tonight to improve polling of notifications to fix a problem with the Sensative Strip door sensor and I think it might also solve the problem with polling this as well…
Let me know if it works better with tomorrows binding - if it doesn’t I’ll take another look…
@chris, I suppose there is something going wrong again with this smoke sensors.
Yesterday I updated my snapshot release from #683 to 698. In #683 I had both sensors successfully integrated. Just out of curiosity I deleted the things and xml-files for both of my smoke sensors with the new build and re-added them.
They were discovered correctly as smoke sensor, but the initialization doesn’t seem to complete. About 18 hours later I still do not have new xml files. They woke up automatically and I also woke up one of them manually several times. And according to Habmin they are stuck at DYNAMIC VALUES:
According to the event log, I do get updates from the temperature channel. The other channels of course are quite non-operational as long as there isn’t some fire…
Could this be related to the recent changes of the polling mechanism?
If you need a debug log, I could create one while re-adding the device again. But as you also have this device, maybe it’s not necessary and you can verify this yourself?
