Do not know!
Should?
Did you sign up for an account on the database site? You need to do this then email me for access - sorry I can’t remember if you did or not as I get many such requests every day.
Done ;).
I will look to update the database to add the filter.
I’v updated the alarm_motion on the Z120
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/308
Youll need to delete the current thing and add it again.
@chris, I tried load this new Z120 device configuration, but without success. Certainly my fault.
Mean while i’ve been following your new topic ‘Z-Wave refactoring and testing… and SECURITY’ and have already installed this new Binding.
So, I will stop this topic now and will proceed on the new one.
Many thanks for all the support
Advised by @chris I´m back to this topic, since the issue on the DCH-Z120 PIR remains.
I’m now using (bundle:list):
168 | Active | 90 | 2.1.0.201702032321 | openHAB Core
169 | Active | 80 | 2.1.0.201702032321 | openHAB Karaf Integration
172 | Active | 80 | 2.1.0.201702032321 | openHAB Dashboard UI
177 | Active | 80 | 2.4.5 | Jackson-annotations
178 | Active | 80 | 2.4.5 | Jackson-core
179 | Active | 80 | 2.4.5 | jackson-databind
180 | Active | 80 | 2.0.0 | json-path
182 | Active | 80 | 2.1.1 | json-smart
185 | Active | 75 | 0.9.0.201702010824 | Eclipse SmartHome JSonPath Transformation Service
192 | Active | 80 | 2.1.0.201702032321 | openHAB 1.x Compatibility Layer
196 | Active | 80 | 2.1.0.201702032321 | ZWave Binding
my devices DCH-Z110 (Node5) and DCH-Z120 (Node6) have this configuration:
node5.xml (13.2 KB)
node6.xml (13.3 KB)
and gives this results when detects a door open (Node5), or a motion (Node6):
//dchz110 door opened
22:13:07.039 [DEBUG] [dclass.ZWaveMultiCommandCommandClass] - NODE 5: Incoming command class ALARM
22:13:07.041 [DEBUG] [dclass.ZWaveMultiCommandCommandClass] - NODE 5: Calling handleApplicationCommandRequest.
22:13:07.043 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: Received ALARM command V4
22:13:07.046 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: Process NOTIFICATION_REPORT V4
22:13:07.050 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: NOTIFICATION report - 0 = 0, event=22, status=255
22:13:07.053 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: Alarm Type = ACCESS_CONTROL (0)
22:13:07.055 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
22:13:07.057 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveAlarmValueEvent
22:13:07.058 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
22:13:07.061 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
22:13:07.062 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 22, type OnOffType
22:13:07.063 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:frs:node5:alarm_general to ON [OnOffType]
//dchz120 motion detected
20:14:51.142 [DEBUG] [dclass.ZWaveMultiCommandCommandClass] - NODE 6: Incoming command class ALARM
20:14:51.143 [DEBUG] [dclass.ZWaveMultiCommandCommandClass] - NODE 6: Calling handleApplicationCommandRequest.
20:14:51.146 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: Received ALARM command V4
20:14:51.149 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: Process NOTIFICATION_REPORT V4
20:14:51.151 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: NOTIFICATION report - 0 = 0, event=8, status=255
20:14:51.153 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 6: Alarm Type = BURGLAR (0)
20:14:51.155 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
20:14:51.158 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Got an event from Z-Wave network: ZWaveAlarmValueEvent
20:14:51.161 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 6: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
20:14:51.165 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
My interpretation for the fact DCH-Z120 (Node6) can’t handle the “Alarm converter processing NOTIFICATION” is because:
I’ve read CC_ALARM (0x71) is deprecated. CC_NOTIFICATION (0x71) is the successor.
CC_NOTIFICATION_REPORT_V4 (0x05) uses notification type
- NOTIFICATION_REPORT_ACCESS_CONTROL_V4 (0x06) with events “Window/Door is open” (0x16) and “Window/Door is closed” (0x17)
- and NOTIFICATION_REPORT_HOME_SECURITY_V4 (0x07) with events “Tampering, Product covering removed” (0x03), “Motion detection” (0x07) and “Motion detection Unknown Location” (0x08)
Instead, the deprecated CC_ALARM (0x71) uses alarm type
- ALARM_REPORT_ACCESS_CONTROL_V4 (0x06) with events “Window/Door is open” (0x16) and “Window/Door is closed” (0x17)
- and ALARM_REPORT_BURGLAR_V4 (0x07), but doesn’t support event (0x08), then it fails for the motion event
My conclusion is that DCH-Z120 should uses CC_NOTIFICATION (0x71) (instead of CC_ALARM)
[CC_NOTIFICATION_REPORT_V4 (0x05) with NOTIFICATION_REPORT_ACCESS_CONTROL_V4 (0x06) and NOTIFICATION_REPORT_HOME_SECURITY_V4 (0x07)]
Despite DCH-Z110 being working it should also be configured with the same CC_NOTIFICATION (0x71)
Reinforcing this, the ‘D-Link-DCH-Z110_120-manual’ never refers CC_ALARM, but mentions:
COMMAND_CLASS_NOTIFICATION_V4,
Notification Type: Home Security (0x07)
Event: Motion Detection, Unknown Location (0x08)
Notification Type: Access Control (0x06)
Event: Door/Window is open (0x16)
Door/Window is closed (0x17)
So, lets adapt the DB in order to replace CC_ALARM by CC_NOTIFICATION_V4 and replace alarmType_BURGLAR by alarmType_HOME_SECURITY for event 3 on both DCH-Z110 and DCH-Z120 and events 7 and 8 on DCH-Z120.
Do you agree?
I’ve changed configuration for the two devices, to Sensor Binary Report instead of the previous Notification Report.
This makes me to have both devices working, now with channels sensor_door and sensor_binary instead of using the alarm channels.
This new configuration (Parameter 7, Bit4 = 1) permits the plain use of this devices, but I steel think my last suggestion should be implemented for those who would prefer use the Notification Report type.
1 Like
You’ll note that both of these are the same 
- 0x71.
The binding uses the appropriate type depending on the version. NOTIFICATION is the same as ALARM - as I mentioned above, they are both the same command class - just the version changes.
As above - they are the same, and the binding does process your notifications correctly I think.
We can’t have both types in the database since they are the same. It doesn’t matter what we call it - ALARM, NOTIFICATION, ALARM_NOTIFICATION, or anything else - this is simply a human readable name. What matters is the class number (0x71). ZWave ensures backward comparability with these classes.
Again, this is just a name - it doesn’t matter to the operation of the protocol. For historical reasons the binding uses names that aren’t 100% consistent with the standard since the standard was only released recently, but it’s only the human readable name - it still processes the data exactly the same.
As I’ve said a earlier in this thread, this is configured in the database. Simply setting the filter in the configuration will make the binding react to the correct events - so long as you are using a recent snapshot of the binding and not the released version.
The following configuration is used for the door open event -:
type=ACCESS_CONTROL, event=22
The following configuration is used for the motion event -:
type=BURGLAR, event=8
Note that the event could also be 7 - depending on the device.
The following configuration is used for the tamper event -:
type=BURGLAR, event=3
Note that the event could also be 4 - depending on the device.
I hope this 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.
Chris
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
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…
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"
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
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…
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 !!
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
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.
1 Like
Thanks Scott! That fixed it 
1 Like