[Z-Wave] Fibaro Smoke sensor FGSD-002 stays "Unknown Device"

Hi @chris

I have bought a few Fibaro Smoke sensors. I included them in my zwave network through domoticz.

When I move the USB z-stick to my OH2 system, the sensor stays listed as an “Unknown device”. What would you need from me to add this (new?) version to the database?

Thanks

Please wake up the device so that the binding can discover it. Until the binding can read the information from the device, it will not be able to decide what type of device it is.

Does the device itself decides what information it sends to the master controller? Is this random? Because I can wake up the devices as much as I want, they don’t get recognized.

I performed a hard reset of the aeotec z-stick and included my DSB45 Water sensor again but it also remains an “unknown device”.

Not at all - the binding will request it during initialisation.

No - the binding requests what it wants. I don’t really understand what you mean by this?

I guess you’ve checked the debug logs to confirm that you are waking up the device, and that the wakeup messages are being received? If not, this is where I would start looking.

When I wake up the Water sensor, the following command is received:

==> /var/log/openhab2/openhab.log <==
2019-06-19 21:39:19.998 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 49 84 02 0B 04 20 01 30 80 84 71 70 85 86 72 4B
2019-06-19 21:39:20.019 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 20<>108 : Message: class=ApplicationUpdate[73], type=Request[0], dest=2, callback=132, payload=84 02 0B 04 20 01 30 80 84 71 70 85 86 72
2019-06-19 21:39:21.021 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 00 02 02 84 07 70
2019-06-19 21:39:21.031 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 21<>107 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 02 84 07
2019-06-19 21:39:54.382 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling...
2019-06-19 21:39:54.385 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling deferred until initialisation complete

When I wake up the Smoke sensor:

==> /var/log/openhab2/openhab.log <==
2019-06-19 21:40:46.861 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 1C 00 49 84 03 16 04 07 01 5E 20 86 72 5A 59 85 73 84 80 71 56 70 31 8E 22 9C 98 7A F6
2019-06-19 21:40:46.883 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 22<>106 : Message: class=ApplicationUpdate[73], type=Request[0], dest=3, callback=132, payload=84 03 16 04 07 01 5E 20 86 72 5A 59 85 73 84 80 71 56 70 31 8E 22 9C 98 7A

My guess is that you are suffering from the same problem that others seem to be experiencing recently with the queue overflowing caused by some sort of issue with inclusion. :frowning:

@chris Thanks for your reply and assistance.

I can include 4 Fibaro smoke sensors and the water sensor without any issues in Domoticz on Windows. Funny thing is that when I wake up a device when the Z-stick is bound to Domoticz, the led indicator of the z-stick responds to the wake ups with a series of acknowledgements. You can see the led flicker blue a few times.

I don’t see this led behaviour when the stick is attached to my OH2 setup? Is this expected behaviour?

Link to video:
LED ACTIVITY

What can I do to help you debug these issues?

This event often appears in my logs too:

==> /var/log/openhab2/openhab.log <==
2019-06-20 07:14:55.031 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 1: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@74f6d9
2019-06-20 07:14:55.038 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 1: Adding to device queue
2019-06-20 07:14:55.043 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 1: Added 44 to queue - size 6
2019-06-20 07:14:55.046 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-06-20 07:14:55.053 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 05 00 48 01 1B A8
2019-06-20 07:14:55.058 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 05 00 48 01 1B A8
2019-06-20 07:14:55.062 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2019-06-20 07:14:55.065 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 44: [WAIT_REQUEST] priority=Controller, requiresResponse=true, callback: 27
2019-06-20 07:14:55.066 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2019-06-20 07:14:55.074 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 63<>65 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-06-20 07:14:55.099 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 05 00 48 1B 23 8A
2019-06-20 07:14:55.106 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 64<>64 : Message: class=RequestNodeNeighborUpdate[72], type=Request[0], dest=35, callback=27, payload=1B 23
2019-06-20 07:15:00.068 [DEBUG] [sactionManager$ZWaveTransactionTimer] - NODE 1: TID 44: Timeout at state WAIT_REQUEST. 3 retries remaining.
2019-06-20 07:15:00.071 [DEBUG] [sactionManager$ZWaveTransactionTimer] - TID 44: Transaction is current transaction, so clearing!!!!!
2019-06-20 07:15:00.073 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 44: Transaction CANCELLED
2019-06-20 07:15:00.076 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 1: notifyTransactionResponse TID:44 CANCELLED
2019-06-20 07:15:00.079 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-06-20 07:15:00.079 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 44: Transaction event listener: DONE: CANCELLED ->
2019-06-20 07:15:00.087 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 1: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@401c12

Ok, so it took until today to get all devices fully initialised… I guess we just need to be very patient for zwave devices :slight_smile:

To be honest, I’ve never really looked at what the LEDs do on the Aeon dongle. I don’t use this dongle on my development system, and I don’t tend to look at my production dongle as it’s in the loft.