Fibaro Door Window contact FGK-10x

chris · August 8, 2016, 7:57pm

I think this is correct. The “new” NOTIFICATION command class (V2) sends notifications for events - I don’t think it sends an event with there is no tamper.

autoit · August 8, 2016, 8:42pm

I see. What about the switch (magnet)? I’m getting the same “zalarm CLOSED” as well, doesn’t matter if the switch is actually closed or opened. Surely it should say the correct state?

The log says:

2016-08-08 23:40:32.567 [DEBUG] [eController$ZWaveReceiveThread:1530]- Receive Message = 01 0D 00 04 08 06 07 9C 02 06 00 00 00 00 67 
2016-08-08 23:40:32.570 [DEBUG] [b.z.i.protocol.ZWaveController:1194]- Receive queue TAKE: Length=0
2016-08-08 23:40:32.571 [DEBUG] [o.b.z.i.protocol.SerialMessage:243 ]- Assembled message buffer = 01 0D 00 04 08 06 07 9C 02 06 00 00 00 00 67 
2016-08-08 23:40:32.572 [DEBUG] [b.z.i.protocol.ZWaveController:1195]- Process Message = 01 0D 00 04 08 06 07 9C 02 06 00 00 00 00 67 
2016-08-08 23:40:32.572 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 08 06 07 9C 02 06 00 00 00 00 
2016-08-08 23:40:32.573 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 6: Application Command Request (ALIVE:DONE)
2016-08-08 23:40:32.574 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 6: Incoming command class SENSOR_ALARM
2016-08-08 23:40:32.574 [DEBUG] [c.ZWaveAlarmSensorCommandClass:85  ]- NODE 6: Received Sensor Alarm Request
2016-08-08 23:40:32.573 [DEBUG] [eController$ZWaveReceiveThread:1446]- Receive queue ADD: Length=0
2016-08-08 23:40:32.575 [DEBUG] [c.ZWaveAlarmSensorCommandClass:104 ]- NODE 6: Alarm Report: Source=6, Type=General(0), Value=0
2016-08-08 23:40:32.576 [DEBUG] [b.z.i.protocol.ZWaveController:648 ]- Notifying event listeners: ZWaveAlarmSensorValueEvent
2016-08-08 23:40:32.576 [DEBUG] [.z.internal.ZWaveActiveBinding:449 ]- ZwaveIncomingEvent
2016-08-08 23:40:32.577 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 6: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 0
2016-08-08 23:40:32.577 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:66  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 06 02 84 08 
2016-08-08 23:40:32.582 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:67  ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 08 06 07 9C 02 06 00 00 00 00 
2016-08-08 23:40:32.585 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:68  ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false
2016-08-08 23:40:32.586 [DEBUG] [eController$ZWaveReceiveThread:1530]- Receive Message = 01 0D 00 04 00 06 07 9C 02 06 00 00 00 00 6F 
2016-08-08 23:40:32.591 [DEBUG] [eController$ZWaveReceiveThread:1446]- Receive queue ADD: Length=1
2016-08-08 23:40:32.592 [DEBUG] [b.z.i.protocol.ZWaveController:1194]- Receive queue TAKE: Length=0
2016-08-08 23:40:32.592 [DEBUG] [o.b.z.i.protocol.SerialMessage:243 ]- Assembled message buffer = 01 0D 00 04 00 06 07 9C 02 06 00 00 00 00 6F 
2016-08-08 23:40:32.592 [DEBUG] [b.z.i.protocol.ZWaveController:1195]- Process Message = 01 0D 00 04 00 06 07 9C 02 06 00 00 00 00 6F 
2016-08-08 23:40:32.592 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 06 07 9C 02 06 00 00 00 00 
2016-08-08 23:40:32.592 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 6: Application Command Request (ALIVE:DONE)
2016-08-08 23:40:32.592 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 6: Incoming command class SENSOR_ALARM
2016-08-08 23:40:32.592 [DEBUG] [c.ZWaveAlarmSensorCommandClass:85  ]- NODE 6: Received Sensor Alarm Request
2016-08-08 23:40:32.593 [DEBUG] [c.ZWaveAlarmSensorCommandClass:104 ]- NODE 6: Alarm Report: Source=6, Type=General(0), Value=0
2016-08-08 23:40:32.593 [DEBUG] [b.z.i.protocol.ZWaveController:648 ]- Notifying event listeners: ZWaveAlarmSensorValueEvent
2016-08-08 23:40:32.593 [DEBUG] [.z.internal.ZWaveActiveBinding:449 ]- ZwaveIncomingEvent
2016-08-08 23:40:32.593 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 6: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 0
2016-08-08 23:40:32.593 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:66  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 06 02 84 08 
2016-08-08 23:40:32.595 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:67  ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 06 07 9C 02 06 00 00 00 00 
2016-08-08 23:40:32.595 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:68  ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false
2016-08-08 23:40:37.835 [DEBUG] [eController$ZWaveReceiveThread:1530]- Receive Message = 01 0D 00 04 08 06 07 9C 02 06 00 FF 00 00 98 
2016-08-08 23:40:37.836 [DEBUG] [eController$ZWaveReceiveThread:1446]- Receive queue ADD: Length=1
2016-08-08 23:40:37.837 [DEBUG] [b.z.i.protocol.ZWaveController:1194]- Receive queue TAKE: Length=0
2016-08-08 23:40:37.837 [DEBUG] [o.b.z.i.protocol.SerialMessage:243 ]- Assembled message buffer = 01 0D 00 04 08 06 07 9C 02 06 00 FF 00 00 98 
2016-08-08 23:40:37.837 [DEBUG] [b.z.i.protocol.ZWaveController:1195]- Process Message = 01 0D 00 04 08 06 07 9C 02 06 00 FF 00 00 98 
2016-08-08 23:40:37.837 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 08 06 07 9C 02 06 00 FF 00 00 
2016-08-08 23:40:37.837 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 6: Application Command Request (ALIVE:DONE)
2016-08-08 23:40:37.837 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 6: Incoming command class SENSOR_ALARM
2016-08-08 23:40:37.838 [DEBUG] [c.ZWaveAlarmSensorCommandClass:85  ]- NODE 6: Received Sensor Alarm Request
2016-08-08 23:40:37.838 [DEBUG] [c.ZWaveAlarmSensorCommandClass:104 ]- NODE 6: Alarm Report: Source=6, Type=General(0), Value=255
2016-08-08 23:40:37.838 [DEBUG] [b.z.i.protocol.ZWaveController:648 ]- Notifying event listeners: ZWaveAlarmSensorValueEvent
2016-08-08 23:40:37.838 [DEBUG] [.z.internal.ZWaveActiveBinding:449 ]- ZwaveIncomingEvent
2016-08-08 23:40:37.838 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 6: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 255
2016-08-08 23:40:37.838 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:66  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 06 02 84 08 
2016-08-08 23:40:37.838 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:67  ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 08 06 07 9C 02 06 00 FF 00 00 
2016-08-08 23:40:37.838 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:68  ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false
2016-08-08 23:40:37.894 [DEBUG] [eController$ZWaveReceiveThread:1530]- Receive Message = 01 0D 00 04 00 06 07 9C 02 06 00 FF 00 00 90 
2016-08-08 23:40:37.903 [DEBUG] [eController$ZWaveReceiveThread:1446]- Receive queue ADD: Length=1
2016-08-08 23:40:37.903 [DEBUG] [b.z.i.protocol.ZWaveController:1194]- Receive queue TAKE: Length=0
2016-08-08 23:40:37.903 [DEBUG] [o.b.z.i.protocol.SerialMessage:243 ]- Assembled message buffer = 01 0D 00 04 00 06 07 9C 02 06 00 FF 00 00 90 
2016-08-08 23:40:37.903 [DEBUG] [b.z.i.protocol.ZWaveController:1195]- Process Message = 01 0D 00 04 00 06 07 9C 02 06 00 FF 00 00 90 
2016-08-08 23:40:37.904 [DEBUG] [b.z.i.protocol.ZWaveController:194 ]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 06 07 9C 02 06 00 FF 00 00 
2016-08-08 23:40:37.904 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 6: Application Command Request (ALIVE:DONE)
2016-08-08 23:40:37.904 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 6: Incoming command class SENSOR_ALARM
2016-08-08 23:40:37.904 [DEBUG] [c.ZWaveAlarmSensorCommandClass:85  ]- NODE 6: Received Sensor Alarm Request
2016-08-08 23:40:37.904 [DEBUG] [c.ZWaveAlarmSensorCommandClass:104 ]- NODE 6: Alarm Report: Source=6, Type=General(0), Value=255
2016-08-08 23:40:37.904 [DEBUG] [b.z.i.protocol.ZWaveController:648 ]- Notifying event listeners: ZWaveAlarmSensorValueEvent
2016-08-08 23:40:37.904 [DEBUG] [.z.internal.ZWaveActiveBinding:449 ]- ZwaveIncomingEvent
2016-08-08 23:40:37.904 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 6: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 255
2016-08-08 23:40:37.906 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:66  ]- Sent message Message: class = SendData (0x13), type = Request (0x00), payload = 06 02 84 08 
2016-08-08 23:40:37.906 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:67  ]- Recv message Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 06 07 9C 02 06 00 FF 00 00 
2016-08-08 23:40:37.907 [DEBUG] [.z.i.p.s.ZWaveCommandProcessor:68  ]- Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false

chris · August 8, 2016, 9:01pm

The OH1 binding might not correctly process the NOTIFICATION command - I’ll take a look at the log…

Please can you post the log using the </> button to highlight the text - not a quote as I can’t process this - sorry.

autoit · August 9, 2016, 7:46pm

Thanks, I edited the post.

chris · August 9, 2016, 8:16pm

It looks ok to me - it’s sending 0 and 255 which is correct. What is the item definition for this - are you using the sensor_alarm command class - it looks like you might be using sensor_binary?

autoit · August 9, 2016, 8:52pm

My settings right now:

Contact zswitch "Z-Wave switch [%s]" {zwave="6:command=sensor_binary"}
Contact zalarm "Z-Wave tamper [%s]" {zwave="6:command=sensor_alarm"}
Number zbattery "Z-Wave battery [%s %%]" {zwave="6:command=BATTERY"}

Previously I had the zalarm item as “command=alarm”, which gave me the constant “zalarm CLOSED” when using the magnet or the tamper. Now I get nothing from either.

Experimented some more with the associations now that I have the zalarm item as sensor_alarm. I added associations for Sensor ZW3 and Tamper ZW3 (in addition to Lifeline). I now get correct states for both tamper and magnet, but it’s printed twice as such:
2016-08-09 23:47:10.265 [INFO ] [runtime.busevents ] - zswitch state updated to CLOSED 2016-08-09 23:47:10.282 [INFO ] [runtime.busevents ] - zswitch state updated to CLOSED 2016-08-09 23:47:44.267 [INFO ] [runtime.busevents ] - zswitch state updated to OPEN 2016-08-09 23:47:44.290 [INFO ] [runtime.busevents ] - zswitch state updated to OPEN 2016-08-09 23:47:52.672 [INFO ] [runtime.busevents ] - zalarm state updated to CLOSED 2016-08-09 23:47:52.695 [INFO ] [runtime.busevents ] - zalarm state updated to CLOSED 2016-08-09 23:47:58.486 [INFO ] [runtime.busevents ] - zalarm state updated to OPEN 2016-08-09 23:47:58.496 [INFO ] [runtime.busevents ] - zalarm state updated to OPEN.

Does that help at all…?

chris · August 9, 2016, 9:08pm

In this log, the log shows the ALARM command class, so I would assume from what you write that ALARM = TAMPER.

From this log, I see SENSOR_ALARM so I assume SENSOR_ALARM = CONTACT.

I’m a bit confused about your association comments. You should ONLY need the lifeline association. If you add more associations, then you will likely get multiple requests which might confuse your rules, and waste power in the sensor. I do see every message being duplicated in your logs, so I’m guessing you have multiple associations configured?

autoit · August 10, 2016, 4:20pm

I’m a bit confused about your association comments. You should ONLY need
the lifeline association. If you add more associations, then you will
likely get multiple requests which might confuse your rules, and waste
power in the sensor. I do see every message being duplicated in your
logs, so I’m guessing you have multiple associations configured?

That was just me experimenting to see what happens. Never mind about that
What I was trying to say is that while using the Lifeline association I’m not getting any response to my zswitch and zalarm items above. If I configure the association with Sensor ZW3 or Tamper ZW3 (one at a time, no multiple associations configured) I start getting correct responses to the items BUT they are duplicated. Just an observation.

Shrikant_Lahase · August 13, 2016, 12:55pm

Hi @chris

I’m facing issue with door sensor is that,

Sometimes the door sensor led is not blinking when door open/closed actions are happening.
and exactly at these moments state is not getting reported.
abruptly lot of states are coming (may be the missed states are coming).

Anybody faced this behavior before this…?
Please give any idea about this behavior…

Thanks,
Shrikant

chris · August 13, 2016, 1:17pm

Maybe there’s something wrong with the sensor or the location of the magnet?

It’s really hard to say what this is without looking at the log - I’d suggest you grab a debug log and process it with the online log viewer at cd-jackson.com.

peterd · August 16, 2016, 2:25pm

Hi Chris,

after editing your database … I was absent the last weeks and now I red the threat but I’m unsure, if you added the change in OH1 too. If yea, what is exactly the binding and where can I find it. Is it only an exchange in the respective raspberry directory. I’m using org.openhab.binding.zwave version 1.8. Many thx for any help…

regardly

Peter

peterd · August 16, 2016, 2:28pm

and HABmin Version 1.8 sorry I forgot …

chris · August 16, 2016, 2:28pm

It should be included in the OH1 binding, but you need to upgrade to the 1.9 snapshot version from cloudbees -:

https://openhab.ci.cloudbees.com/job/openHAB1-Addons/lastBuild/

Shrikant_Lahase · August 25, 2016, 6:39am

Hi @chris,

I posted a issue regarding fibaro fgk10x door sensor misses states,
Here my logs when state is send by door sensor successfully (NODE 78):

11:32:03.849 [DEBUG] [eController$ZWaveReceiveThread:1508 ] - Receive Message = 01 09 00 04 00 4E 03 30 03 FF 73
11:32:04.168 [DEBUG] [eController$ZWaveReceiveThread:1432 ] - Receive queue ADD: Length=1
11:32:04.169 [DEBUG] [b.z.i.protocol.ZWaveController:1168 ] - Receive queue TAKE: Length=0
11:32:04.171 [DEBUG] [o.b.z.i.protocol.SerialMessage:239  ] - Assembled message buffer = 01 09 00 04 00 4E 03 30 03 FF 73
11:32:04.172 [DEBUG] [b.z.i.protocol.ZWaveController:1169 ] - Process Message = 01 09 00 04 00 4E 03 30 03 FF 73
11:32:04.173 [DEBUG] [b.z.i.protocol.ZWaveController:196  ] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 4E 03 30 03 FF , callbackid = 0
11:32:04.173 [DEBUG] [ApplicationCommandMessageClass:39   ] - NODE 78: Application Command Request (ALIVE:PING)
11:32:04.174 [DEBUG] [ApplicationCommandMessageClass:138  ] - NODE 78: Incoming command class SENSOR_BINARY (0x30)
11:32:04.175 [DEBUG] [.ZWaveBinarySensorCommandClass:82   ] - NODE 78: Received Sensor Binary Request (v1)
11:32:04.176 [DEBUG] [.ZWaveBinarySensorCommandClass:102  ] - NODE 78: Sensor Binary report, type=Unknown, value=255
11:32:04.177 [DEBUG] [b.z.i.protocol.ZWaveController:616  ] - NODE 78: Notifying event listeners: ZWaveBinarySensorValueEvent: org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveBinarySensorCommandClass$ZWaveBinarySensorValueEvent@cefc30
11:32:04.178 [DEBUG] [.z.internal.ZWaveActiveBinding:443  ] - ZwaveIncomingEvent org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveBinarySensorCommandClass$ZWaveBinarySensorValueEvent@cefc30
11:32:04.179 [DEBUG] [.z.internal.ZWaveActiveBinding:460  ] - NODE 78: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 255
11:32:04.181 [DEBUG] [b.z.i.protocol.ZWaveController:627  ] - NODE 78: Processing event ourselves`

and logs when it misses state:

11:32:10.402 [DEBUG] [.z.internal.ZWaveActiveBinding:193  ] - NODE 78: Polling list: item BATTERY_162_163_78_1 is not completed initialisation
11:32:10.412 [DEBUG] [.z.internal.ZWaveActiveBinding:193  ] - NODE 78: Polling list: item DOOR_SENSOR_162_163_78_1 is not completed initialisation

and when misses state it continuous to blink 4-5 times…
Can you have look at logs please…
and tell me any reason

Thznks

chris · August 25, 2016, 7:32am

Sorry - I don’t know what the issue is that would make the device blink. I don’t think this is anything to do with the binding. The fact that the binding doesn’t poll is because it won’t if it hasn’t completed the initialisation stages with the device - this will take some time after you restart the binding, but this also won’t stop the device sending unsolicited data to the binding.

If the device doesn’t send data, then there’s nothing the binding can do.

Shrikant_Lahase · August 25, 2016, 8:42am

ok @chris ,
i have one question…
Is the problem of not completing initialization can be solved by restarting openhab OR
by re-adding device in zwave network…?

chris · August 25, 2016, 8:43am

It would normally just be solved by waking up the device so the binding can communicate with the device.

Shrikant_Lahase · August 25, 2016, 8:48am

ok @chris

Is the initialization of device happens every time openhab starts…or only once when device is added…?

chris · August 25, 2016, 8:52am

Full initialisation happens only once. The information is then persisted between restarts, but the binding will still complete a couple of initialisation stages every time the binding starts (it’s very minimal).

As I said though, this won’t impact the device. It won’t stop the device sending updates, and it won’t stop the binding processing those updates. It just stops polling which doesn’t really work on battery devices anyway since the device is asleep, and the polling is really only there to check if the device is still functioning.

jlemmer · November 25, 2016, 12:12pm

Are there any new information about this device in OH 1?

I bought one three weeks ago, and it worked fine with z-way-server. As it did not work in OH1 (gray) I ex- and including it with habmin. Since then it shows up in habmin, but did not report any values in OH1 first (tried ex- and including it sometimes, updated to z-wave Binding 1.9.0.20161113).

Suddenly - over night - I got a value for the battery and a status for the sensor (open). But this sensor state does not change. Over one of the next nights it changed to close, but still does not change.

As I am quite new to OH1 I am not so familiar with all the tools yet. So please be Patient if I have to ask back (or give enough detailed explanations