Fibaro Door Windows Sensor 2 (FGDW-002) problems

anon59120616 · June 12, 2017, 10:07pm

Hi, i’m pretty new to this and im setting up a new system based on OH2 and a bunch of FGDW-002 door/window sensors.

I cant get the door sensor to report if its open or closed.
After some browsing it appears that this device is brand new (i noticed that it got added to the database just 2 weeks ago).
I using the latest snapshot of OH2.1, as OH2 stable would not recognize the device.

When open and closing the door (moving the magnet close to the device an then away) i get this in the logs :

Open

2017-06-12 23:54:52.331 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 02 09 71 05 00 00 00 FF 06 17 00 65
2017-06-12 23:54:52.336 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-06-12 23:54:52.339 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0F 00 04 00 02 09 71 05 00 00 00 FF 06 17 00 65
2017-06-12 23:54:52.342 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0F 00 04 00 02 09 71 05 00 00 00 FF 06 17 00 65
2017-06-12 23:54:52.344 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 02 09 71 05 00 00 00 FF 06 17 00
2017-06-12 23:54:52.346 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (ALIVE:DONE)
2017-06-12 23:54:52.347 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Starting initialisation from DONE
2017-06-12 23:54:52.349 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@fa0c72 already registered
2017-06-12 23:54:52.350 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class ALARM
2017-06-12 23:54:52.351 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: Received ALARM command V5
2017-06-12 23:54:52.352 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: Process NOTIFICATION_REPORT V5
2017-06-12 23:54:52.354 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: NOTIFICATION report - 0 = 0, event=23, status=255
2017-06-12 23:54:52.355 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: Alarm Type = ACCESS_CONTROL (0)
2017-06-12 23:54:52.356 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2017-06-12 23:54:52.358 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-06-12 23:54:52.359 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2017-06-12 23:54:52.361 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:54:52.362 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:54:52.363 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 23, type OnOffType
2017-06-12 23:54:52.365 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:02c877b5:node2:alarm_access to ON [OnOffType]
2017-06-12 23:54:52.369 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:54:52.371 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:54:52.373 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=2, callback=119, payload=02 02 30 02

Close

2017-06-12 23:55:03.555 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 02 09 71 05 00 00 00 FF 06 16 00 64
2017-06-12 23:55:03.566 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-06-12 23:55:03.569 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0F 00 04 00 02 09 71 05 00 00 00 FF 06 16 00 64
2017-06-12 23:55:03.572 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0F 00 04 00 02 09 71 05 00 00 00 FF 06 16 00 64
2017-06-12 23:55:03.575 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 02 09 71 05 00 00 00 FF 06 16 00
2017-06-12 23:55:03.577 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Application Command Request (ALIVE:DONE)
2017-06-12 23:55:03.578 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: Starting initialisation from DONE
2017-06-12 23:55:03.580 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@fa0c72 already registered
2017-06-12 23:55:03.582 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Incoming command class ALARM
2017-06-12 23:55:03.583 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: Received ALARM command V5
2017-06-12 23:55:03.585 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: Process NOTIFICATION_REPORT V5
2017-06-12 23:55:03.586 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: NOTIFICATION report - 0 = 0, event=22, status=255
2017-06-12 23:55:03.588 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 2: Alarm Type = ACCESS_CONTROL (0)
2017-06-12 23:55:03.589 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2017-06-12 23:55:03.591 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-06-12 23:55:03.593 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2017-06-12 23:55:03.595 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:55:03.596 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:55:03.598 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 22, type OnOffType
2017-06-12 23:55:03.599 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Updating channel state zwave:device:02c877b5:node2:alarm_access to ON [OnOffType]
2017-06-12 23:55:03.603 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:55:03.604 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-06-12 23:55:03.606 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Message has Ack Pending: Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=2, callback=119, payload=02 02 30 02

It looks like it triggers the node2:alarm_access to ON in both cases.

I’ve read some other posts about the Z-Wave binding triggering the wrong channel(s) but no reports on FGDW-002 yet.
I think that these to notifications should go to the Door Sensor channel instead of the Alarm (access) channel.
Anyone got this device working?
Any clues on where to dig to find a solution?

This is how the device got discovered in paper-UI :

petzlux · July 5, 2017, 9:39am

Just like you, I bought 3 of these, and I can include them fine and configure them, but the values don’t get updated. This is the case for the Door Open/Close Channel, as well as the Temperature Channel.

I also have a previous generation Fibaro Door Sensor, which works fine …

I already two weeks ago made a bug report in Github, but with no reply. Surely we are not the only onea using these devices with OpenHab2 ?

randomname872634 · August 3, 2017, 12:01pm

I also experience problems with two FGDW-002 EU 3.2 ZW5 model door door/window sensors.

I’m running the latest snapshot build (as of today) of OH 2.x in whose zwave databae it is included.

The device keeps being reported as unknown.

chris · August 3, 2017, 12:29pm

It just says “Unknown” or something else? If it’s just unknown, then you need to wake the device up so that it can be discovered. If it has a bunch of other information other than just “unknown” then it would be useful if you can provide this as your device might be different to others and may not be in the database.

randomname872634 · August 3, 2017, 1:37pm

Thanks for your response Chris.

I’ve made a screenshot of how it looks in Paper UI. Hope this helps.

This is what I get from my zwave debug log when I re-insert the device’ battery:

2017-08-03 15:40:32.377 [icationCommandMessageClass] - NODE 62: Application Command Request (INITIALIZING:PING)
2017-08-03 15:40:32.377 [ZWaveNode                 ] - NODE 62: Node is ALIVE. Init stage is PING.
2017-08-03 15:40:32.378 [ZWaveNodeInitStageAdvancer] - NODE 62: Node Status event during initialisation - Node is ALIVE
2017-08-03 15:40:32.378 [ZWaveNodeInitStageAdvancer] - NODE 62: Node advancer - PING: queue length(0), free to send(true)
2017-08-03 15:40:32.378 [ZWaveNodeInitStageAdvancer] - NODE 62: Node advancer: loop - PING try 1: stageAdvanced(false)
2017-08-03 15:40:32.378 [ZWaveNodeInitStageAdvancer] - NODE 62: Node advancer: PING - send NoOperation
2017-08-03 15:40:32.378 [aveNoOperationCommandClass] - NODE 62: Creating new message for command No Operation
2017-08-03 15:40:32.378 [ZWaveNodeInitStageAdvancer] - NODE 62: Node advancer - queued packet. Queue length is 1
2017-08-03 15:40:32.378 [ZWaveThingHandler         ] - NODE 62: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2017-08-03 15:40:32.378 [ZWaveThingHandler         ] - NODE 62: Setting ONLINE
2017-08-03 15:40:32.378 [ZWaveController           ] - NODE 62: Node Status event - Node is ALIVE
2017-08-03 15:40:32.378 [ZWaveSerialHandler        ] - NODE 62: Sending REQUEST Message = 01 08 00 13 3E 01 00 25 DB 25
2017-08-03 15:40:32.378 [icationCommandMessageClass] - NODE 62: Incoming command class WAKE_UP
2017-08-03 15:40:32.378 [icationCommandMessageClass] - NODE 62: Command class WAKE_UP not found, trying to add it.
2017-08-03 15:40:32.378 [ZWaveCommandClass         ] - NODE 62: Creating new instance of command class WAKE_UP
2017-08-03 15:40:32.378 [ZWaveCommandClass         ] - NODE 62: Command class WAKE_UP, endpoint null created
2017-08-03 15:40:32.379 [icationCommandMessageClass] - NODE 62: Adding command class WAKE_UP
2017-08-03 15:40:32.379 [ZWaveNode                 ] - NODE 62: Adding command class WAKE_UP to the list of supported command classes.
2017-08-03 15:40:32.380 [ZWaveWakeUpCommandClass   ] - NODE 62: Received Wake Up Request
2017-08-03 15:40:32.380 [ZWaveWakeUpCommandClass   ] - NODE 62: Received WAKE_UP_NOTIFICATION
2017-08-03 15:40:32.380 [ZWaveWakeUpCommandClass   ] - NODE 62: Is awake with 0 messages in the wake-up queue.
2017-08-03 15:40:32.380 [ZWaveNodeInitStageAdvancer] - NODE 62: Wakeup during initialisation.
2017-08-03 15:40:32.380 [ZWaveNodeInitStageAdvancer] - NODE 62: Node advancer - PING: queue length(1), free to send(false)
2017-08-03 15:40:32.380 [ZWaveNodeInitStageAdvancer] - NODE 62: Node advancer - queued packet. Queue length is 1
2017-08-03 15:40:32.380 [ZWaveThingHandler         ] - NODE 62: Got an event from Z-Wave network: ZWaveWakeUpEvent
2017-08-03 15:40:32.393 [SendDataMessageClass      ] - NODE 62: Sent Data successfully placed on stack.
2017-08-03 15:40:32.527 [SendDataMessageClass      ] - NODE 62: SendData Request. CallBack ID = 219, Status = Transmission complete and ACK received(0)
2017-08-03 15:40:32.527 [SendDataMessageClass      ] - NODE 62: Already processed another send data request for this callback Id, ignoring.
2017-08-03 15:40:33.380 [ZWaveWakeUpCommandClass   ] - NODE 62: No more messages, go back to sleep
2017-08-03 15:40:33.380 [ZWaveWakeUpCommandClass   ] - NODE 62: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2017-08-03 15:40:37.379 [Controller$ZWaveSendThread] - NODE 62: Timeout while sending message. Requeueing - 0 attempts left!
2017-08-03 15:40:37.379 [ZWaveWakeUpCommandClass   ] - NODE 62: Is sleeping
2017-08-03 15:40:37.379 [ZWaveWakeUpCommandClass   ] - NODE 62: Putting message SendData in wakeup queue.
2017-08-03 15:40:37.379 [ZWaveWakeUpCommandClass   ] - NODE 62: Putting message SendData in wakeup queue.
2017-08-03 15:40:37.379 [ZWaveWakeUpCommandClass   ] - NODE 62: Message already on the wake-up queue. Removing original.
2017-08-03 15:40:37.379 [ZWaveWakeUpCommandClass   ] - NODE 62: Putting message SendData in wakeup queue.
2017-08-03 15:40:42.778 [icationCommandMessageClass] - NODE 62: Transaction not completed: node address inconsistent.  lastSent=62, incoming=255

I’m considering re-adding the device?

chris · August 3, 2017, 1:42pm

Since there is no manufacturer information showing, I would suspect that you need to wake up the device so that it can be properly discovered. This is the second point in the image - ie the device initialisation is not complete.

randomname872634 · August 3, 2017, 1:43pm

I’ll give that a try. I’ll also place the device close to the zwave controller, as suggested by others before.

chris · August 3, 2017, 1:46pm

Ok, so this does show that the binding is receiving wakeups. For some reason the binding has nothing to send - maybe the initialisation failed for some reason - although I’m not sure what.

You could try restarting the binding to see if that resolves it as that will restart the initialisation in case there was some early error.

randomname872634 · August 3, 2017, 1:52pm

Restarting the binding did not work, but something else did. I removed the device and let the zwave binding detect/find/recognize it again. The device was directly found and recognized as a FGDW-002!

Can’t explain it, but thank you for helping out.

anon59120616 · August 7, 2017, 8:09am

I have a different problem described in my original post. The device works fine and are recognized properly, but the channels does not get updated as they should.

It looks like when moving the magned away from the device (and opening the door/windows) the alarm converter is receiving a NOTIFICATION of type ACCESS_CONTROL (OnOff type), and there is no code for that.

github.com

openhab/org.openhab.binding.zwave/blob/master/src/main/java/org/openhab/binding/zwave/internal/converter/ZWaveAlarmConverter.java#L166


}


// Don't trigger event if there is no event match. Note that 0 is always acceptable
if (alarmEvent != null && event != 0 && alarmEvent != event) {
    return null;
}


// TODO: Handle these event to state specific conversions in a table.
State state = null;
switch (channel.getDataType()) {
    case OnOffType:
        state = event == 0 ? OnOffType.OFF : OnOffType.ON;
        break;
    case OpenClosedType:
        state = event == 0 ? OpenClosedType.CLOSED : OpenClosedType.OPEN;
        switch (eventAlarm.getAlarmType()) {
            case ACCESS_CONTROL:
                switch (event) {
                    case 22: // Window/Door is open
                        state = OpenClosedType.OPEN;
                        break;

If the notification had been a “OpenClosedType”, there are code to convert between event 22/23 and set the proper state of the door/window.

randomname872634 · August 11, 2017, 6:49pm

Thank you, that clears thinks up a bit.

Sorry for hijacking your thread with my different problem, although I think I’m experiencing the same problem now. I think might have the same cause for the binary value not being updated: Fgdw-002 door sensor not showing status

julius.spudvilas · September 20, 2017, 8:10am

Hej,

It seems that I am having same issue. Sensor reports :
OPENING (magnet away from sensor)
Alarm converter NOTIFICATION event is 22, type OnOffType
Updating channel state zwave:device:15e807f3529:node6:alarm_access to ON [OnOffType]

CLOSING (magnet next to sensor)
Alarm converter NOTIFICATION event is 23, type OnOffType
Updating channel state zwave:device:15e807f3529:node6:alarm_access to ON [OnOffType]

Is this something that should be updated in OpenHab or Binding plugin ? And if anyone has ideas how to solve it let me know