I got introduced to the ‘development version’ of the z-wave binding and that binding together with a couple of updates in the device database did the trick.
My FGSD-002 now reports everything as it should. Most critically the REAL smoke alarm events. (I need to clean my oven more often).
You need to remove all Things and re-add them. The development bindning have a different naming convention for node xml’s. More info how to install the development binding can be found in this thread.
Ok, here comes the funny thing: Now the heat_alarm is never canceled. Not just on OH2, the blue led keeps blinking even if temperature is way below the threshold… have any of you had a similar behaviour? I got excited very quickly about the sensor fully working!
For completeness, here is the answer from Fibaro. Excellent support from the Fibaro team.
Hello,
The device is designed to start the overheat when the temperature exceeds value specified in parameter 30.
In order to clear the overheat alarm, the temperature drop by at least 2 degrees below the set level with param 30.
We tend to use such practises. For example the Dimmer`s overheat is at some 70 degrees, but the notification will stay until the temperature drops below 60 degrees.
This is just to ensure the temperature are really dropping. I do understand the need to test it with 30 degrees, but note the default “real” overheat protection is set at 50 degrees.
You don’t say what version of anything (binding/OH) you are running? Is it the latest, or 2.3, or something else? If it’s not 2.4 M4 or newer, then please change to a new version.
As commented in linked above second thread i was using "binding-zwave - 2.4.0.M4” to gather logs.
Recently updated as well. I haven’t checked zwave logs on M5, but items does not look to updated.
Sorry, but it’s note very practical if you’re cross posting to have to follow multiple threads to find out what you’re doing
If nothing is received from the device, then it will be a device or device configuration issue. Polling will not normally work with these sort of devices as they normally use notifications which can not be polled.
Alarm_smoke shows OK, because i have turned the switch on and off, from that moment i got the OK as a value for Alarm_smoke.
The heat Alarm i didn’t trigger the switch, so there is no value for this.
I have changed the parameters of association groups of the device and i get the alarms!
2018-11-13 15:46:06.581 [GroupItemStateChangedEvent] - gRookmelder_Hittealarm changed from NULL to ON through Rookmelder_Wasplaats_Hittealarm
2018-11-13 15:46:06.583 [GroupItemStateChangedEvent] - gRookmelder changed from OFF to ON through Rookmelder_Wasplaats_Hittealarm
2018-11-13 15:46:06.600 [GroupItemStateChangedEvent] - gAlarmen changed from OFF to ON through Rookmelder_Wasplaats_Hittealarm
2018-11-13 15:46:06.607 [vent.ItemStateChangedEvent] - Rookmelder_Wasplaats_Hittealarm changed from NULL to ON
When openHAB is running, I get the alarm notifications from the Fibaro Smoke Sensor (FGSD-002) through the binding. The easiest to test is the tamper alarm: it gets triggered when you detach the smoke alarm from its base. It clears when reattaching it to its base.
However the Z-Wave binding apparently doesn’t receive an update of the alarm states when restarting. This results in all states being reported as NULL in such cases.
A side-effect of this behaviour, is that a group aggregation function that is based on the states of the smoke/heat sensor, will report NULL state on system startup (or when the Z-Wave binding (re)starts).
Maybe I lack some documentation of the smoke/heat sensor reporting behaviour. I didn’t yet test if a smoke/heat alarm unit in alarm will report it’s in alarm upon restarting the Z-Wave binding.
