Handling zwave notifications - Need Help

[FRamos (Filipe Ramos)]

Many thanks for all your explanations @chris.
I steel think the type=BURGLAR should be replaced to the newest type=HOME_SECURITY despite they uses the same ID (0x07).
I’ll try to do some tests. Then I’ll report here any conclusions

Hug

[chris (Chris Jackson)]

@FRamos

I steel think the type=BURGLAR should be replaced to the newest type=HOME_SECURITY

I don’t disagree that it would be nice to do, however this is a big change as it will impact a lot of configuration - everyone will need to reconfigure their system. In my new branch, I’ve started to make some of these changes, but this one is very difficult to accommodate as we’d need to have two databases with the different configurations.

OH has been around a few years - I’ve been working on the binding for 3 years and the standards have only been released in the past few months. It’s just not easy to swap everything around at the drop of a hat - the impact is high…

[FRamos (Filipe Ramos)]

@chris

It’s just not easy to swap everything around at the drop of a hat - the impact is high…

I perfectly understand you.
Since the ID (0x07) is the same and you said the binding just looks at the ID, then it is just a matter of “cosmetic”. It will be refined on future"releases/versions"

[FRamos (Filipe Ramos)]

I’ve updated DB for DCH-Z110 with CC_ALARM_V4. The sensor channel was already correct "sensor_door"
Also updated DCH-Z120 with CC_ALARM_V4 and alarm_type=BURGLAR

Awaiting review

[chris (Chris Jackson)]

I’ll update the binding tonight, but I still don’t see the update to add the event filter so I doubt it’s going to change things much…

[BlAcKMoUsE (Matias Ochoa)]

@chris

helps explain this further. I’ve added some of this to the database already but I would strongly urge you to try and do it yourself. I know you said you weren’t confident to change the database, but you clearly have an understanding of things here, and you at least should be able to copy from other entries in the database, or just copy in what I’ve said earlier in post 7 of this thread.

If you’re really stuck, then let me know and I’ll do the changes, but it would be really appreciated if you can try yourself - with around 420 devices in the database, it would be a full time job for me to keep up with everyones requests (which is why I wrote the online database editor - to make it easier for people than having to edit XML files and manage this in Git).

Thanks.

Hi @chris hris, it is my first time posting here, but i found this topic, and currently i think that i have exactly the same issue with the fibaro fgsm001 eye sensor, with some wake up reports I got an motion event. In the logs, i can see the same debug messages that was in this case of this topic

So what should be the steps to help to fix this? I should do the same changes for the fibaro fgms001 sensor? i think…

I am using the lastest snapshot

225 | Active | 80 | 2.1.0.201705081517 | ZWave Binding

here are the logs.

2017-05-10 21:03:58.023 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:DONE)
2017-05-10 21:03:58.024 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 14: Starting initialisation from DONE
2017-05-10 21:03:58.024 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1b02d85 already registered
2017-05-10 21:03:58.025 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
2017-05-10 21:03:58.026 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received ALARM command V5
2017-05-10 21:03:58.027 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Process NOTIFICATION_REPORT V5
2017-05-10 21:03:58.027 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=8, status=255
2017-05-10 21:03:58.028 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = BURGLAR (0)
2017-05-10 21:03:58.029 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2017-05-10 21:03:58.029 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-05-10 21:03:58.030 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2017-05-10 21:03:58.031 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-05-10 21:03:58.032 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 8, type OnOffType
2017-05-10 21:03:58.033 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:b79ca813:node14:alarm_motion to ON [OnOffType]
2017-05-10 21:03:58.035 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-05-10 21:03:58.036 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 8, type OnOffType
2017-05-10 21:03:58.037 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=14, callback=70, payload=0E 02 84 08
2017-05-10 21:03:58.039 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0E 09 71 05 00 00 00 FF 07 08 00
2017-05-10 21:03:58.040 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=70, expected=SendData, cancelled=false MISMATCH
2017-05-10 21:04:27.773 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 07 00 01 08 6A
2017-05-10 21:04:27.781 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-05-10 21:04:27.785 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 07 00 01 08 6A
2017-05-10 21:04:27.788 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 07 00 01 08 6A
2017-05-10 21:04:27.791 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0E 0A 71 05 00 00 00 FF 07 00 01 08
2017-05-10 21:04:27.793 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:DONE)
2017-05-10 21:04:27.794 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 14: Starting initialisation from DONE
2017-05-10 21:04:27.796 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@1b02d85 already registered
2017-05-10 21:04:27.797 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
2017-05-10 21:04:27.798 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received ALARM command V5
2017-05-10 21:04:27.799 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Process NOTIFICATION_REPORT V5
2017-05-10 21:04:27.801 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=0, status=255
2017-05-10 21:04:27.802 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = BURGLAR (0)
2017-05-10 21:04:27.803 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2017-05-10 21:04:27.805 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2017-05-10 21:04:27.806 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
2017-05-10 21:04:27.808 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-05-10 21:04:27.810 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 0, type OnOffType
2017-05-10 21:04:27.811 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:b79ca813:node14:alarm_motion to OFF [OnOffType]
2017-05-10 21:04:27.815 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2017-05-10 21:04:27.816 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 0, type OnOffType
2017-05-10 21:04:27.817 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:b79ca813:node14:alarm_tamper to OFF [OnOffType]
2017-05-10 21:04:27.821 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=14, callback=70, payload=0E 02 84 08
2017-05-10 21:04:27.824 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0E 0A 71 05 00 00 00 FF 07 00 01 08
2017-05-10 21:04:27.826 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=70, expected=SendData, cancelled=false MISMATCH
2017-05-10 21:04:52.932 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 04 00 04 0C 60 0D 01 00 32 02 21 32 00 A9 00 00 07
2017-05-10 21:04:52.939 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0

Thanks !!

[dastrix80 (Kris K)]

Does anyone know how to remove these events, but still maintain other zwave events?

2.4 Snapshot seems to have added these and I cant find anything on google as to what they mean.

09:00:00.870 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_ack changed from 580 to 581
09:00:00.876 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_sof changed from 1603 to 1604
09:00:00.934 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_sof changed from 1604 to 1605
09:00:05.870 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_ack changed from 581 to 582
09:00:05.876 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_sof changed from 1605 to 1606
09:00:05.933 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_sof changed from 1606 to 1607
09:00:10.872 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_ack changed from 582 to 583
09:00:10.877 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_sof changed from 1607 to 1608
09:00:10.935 [INFO ] [smarthome.event.ItemStateChangedEvent] - zwave_serial_zstick_0a604f67_serial_sof changed from 1608 to 1609

[5iver (Scott Rushworth)]

If you look at the Thing for the zwave controller, you will find these channels. You may have added items or OH auto added them for you. If you find the items and delete them, you shouldn’t see this in the log anymore.

[dastrix80 (Kris K)]

Thanks Scott! That fixed it