Z-Wave Smoke sensor issue

Hi there,

My Fibaro smoke sensor (node 10 in the picture below) doesn’t connect properly to the Z-Wave network.
I’m running openHAB 2.4 on raspberry 3b with aeontec z-wave controller

From habmin Z-Wave network viewer:


It’s quite strange since it used to work in the past.

Accordding to paper UI the device is online and channels are linked:

But it doesn’t show up in the sitemap nor in the logfile:

Here’s the code:


Bridge zwave:serial_zstick:controller "Z-Wave Controller" @ "Z-Wave" [ port="/dev/ttyACM0", controller_softreset="false", controller_master="true", heal_enable="true", heal_time=2, security_networkkey="xxxxxxxxxx" ]
     Thing zwave:fibaro_fgsd002_00_000:controller:node10     "Z-Wave: Rauchmelder FGSS001 - Node10"              (zwave:serial_zstick:controller) @ "Z-Wave" [ node_id=10 ]   // Smoke sensor Fibaro (FGSD002)


Number   TBP_rauch1_temp        "Rauchmelder1 - Temperatur Sensor"      <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:sensor_temperature"}
Switch   TBP_rauch1_alrsmoke    "Rauchmelder1 - Rauch Alarm"            <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:alarm_smoke"}
Switch   TBP_rauch1_alrtamper   "Rauchmelder1 - Tamper Alarm"           <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:alarm_tamper"}
Switch   TBP_rauch1_alrbatt     "Rauchmelder1 - Batteriestand Alarm"    <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:alarm_battery"}
Switch   TBP_rauch1_alrsys      "Rauchmelder1 - Hardware Fehler"        <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:alarm_system"}
Switch   TBP_rauch1_alrheat     "Rauchmelder1 - Hitze Alarm"            <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:alarm_heat"}
Number   TBP_rauch1_batt        "Rauchmelder1 - Batterieladung"         <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:battery-level"}
Number   TBP_rauch1_timeoffset  "Rauchmelder1 - Zeit Offset"            <fire>  (gM,Gzwave,Gstatus,Gsensor,Grauch,Gad)    {channel="zwave:fibaro_fgsd002_00_000:controller:node10:time_offset"}

Any ideas @chris or @sihui ?

If it’s not in the sitemap, then this is an issue with the sitemap. The sitemap is manually produced by you.

If it’s really not in the logfile, then I would say the device doesn’t exist. Since it does exist, I think there must be something in the log? Have you enabled debug logging?

1 Like

Thanks for the quick reply.

In sitemap I use the Group item:
Group item=Grauch where - among others - TBP_rauch1_batt (for battery level) is included

I did it according to this documentation

Please advise how to proceed …

If it doesn’t show up in the sitemap then it’s a problem with the sitemap and has nothing to do with the binding. The sitemap one step removed from the binding.

So please post your sitemap and a description of what you expect to see and a screen shot of what you are seeing. Are the Items indeed not showing up at all or is it just the state that is remaining NULL?

Which logfile are you looking in? events.log? openhab.log? Both?

PaperUI is showing the Thing exists and it is online. That means, if I understand correctly, that the binding has successfully loaded your Thing and the controller is communicating with the device.

Here is another test version of the sitemap:

    Frame label="Z-Wave fault" {
        Switch   item=OUT_p_zpir1_motion
        Text     item=OUT_p_zpir1_batt 

        Switch   item=TBP_rauch1_alrsmoke
        Text     item=TBP_rauch1_batt

I expect to see whether there is motion triggering and the battery level of OUT_p_zpir1 - which both is ok.
For TBP_rauch1 I expect to have the alarm status and the battery level displayed - this doesn’t work.

Both things are battery-powered Z-wave devices.

I use openHAB 2 Log Viewer in browser tail -f /var/log/openhab2/openhab.log /var/log/openhab2/events.log on info level

and Zwave.log on debug level - this only shows the following for the smoke sensor:

2019-07-18 20:01:15.644 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Polling...
2019-07-18 20:01:15.646 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Polling deferred until initialisation complete

I’ve just removed the battery from the smoke sensor and put it in again.
Atfer clicking on “search for things” / “z-wave binding” in paper UI NODE 10 appears but without any further information.

zwave.log says:

2019-07-18 20:29:18.161 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 9: Device discovery completed
2019-07-18 20:29:18.166 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 9: Device discovery resolved to thingType zwave:everspring_sp103_00_000
2019-07-18 20:29:18.185 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 10: Device discovery completed
2019-07-18 20:29:18.190 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 10: Device discovery could not resolve to a thingType! Manufacturer data not known.

NODE 9 = PIR-Sensor
NODE10 = Smoke Sensor

Something doesn’t look right. You are using mappings to get the buttons in the screen shot but there are not mappings in your posted sitemap config. Are we really seeing the sitemap version that generated the screenshot?

All the Items appear but the second two may be NULL. I say may because you do not show the mappings and that could be incorrect.

The logs for Node 10 seem to indicate that OH isn’t able to determine what type of device it is. How does it work if you allow the binding to atuomatically discover the device instead of trying to define it yourself in a .things file?

Do you mean the label “tiggered/untriggered” and “ok/alarm”? I’m not sure where to find the mappings. I’ve searched the whole openhab directory for the term “untriggered” but didn’t find it.


Actually, I have a text-based installation. The discovery was only an attempt to see what’s happening in zwave.log

These are coming from the zwave binding.

1 Like

I had no idea a binding could reach all the way to the sitemap. Good to know.

Interesting fact - but unfortunately it doesn’t solve the problem :frowning:

I would try watching the log while replacing the batteries and waking the device up until it has completed initialization. If the device has been moved or it does not wake up, try bringing it close to the controller. Once initialized, make sure the associations are set properly (newer versions of the binding do this for you), heal it, then move it back to it’s original location and heal it again. You’ll need to manually wake it up several times in order to set the associations and to complete the heal.

1 Like