Handling zwave notifications - Need Help

For the notifications, probably the database needs to be updated to filter the events. I looked at the database for the DCH-Z110 and the door sensor uses the binary sensor class - not the notification so this will also need to be changed in the database.

Regarding the network view - this is not reliable in the current version since the neighbours are not updated. The development branch fixes this so it will be available in future.

Thanks @chris
I will follow any database updates

Original post was changed/deleted, my comment is obsolete … :grinning:

I´m very sorry @sihui , I’ve asked for comments without seeing @Chris reply

@Chris - but the DCH-Z110 is working “well”. At least is handling the NOTIFICATION_REPORT V4, with event=23, updating the correct node channel.

My problem is with DCH-Z120 that produces a NOTIFICATION_REPORT V4, with event=8 (motion detected). It handles the notification, but stops on the ZWaveAlarmConverter with the message “Alarm converter processing NOTIFICATION”.

I’ve take a look at the source files, on the ZWaveAlarmConverter.java and found the conversion for event=23 (Door CLOSED) as for event=22 (Door OPEN), but not for other events/DataTypes. I believe this can be solved on this file (ZWaveAlarmConverter.java). Don’t you?

I don’t see why the converter needs updating? It is already capable of filtering events.

I think the database needs to be updated for this device so that it filters the events. You need to add the correct notification type, and the correct event filter. So, I think type=BURGLAR, event=8 should work.

Additionally the channel type should be changed to alarm_motion instead of alarm_general.

The same sort of updates probably need to be done to the Z110 as well - even if it is working “well”. For starters the channel type is wrong - it should be sensor_door… Filters don’t really mater for the door sensor since it is handled a little differently in the converter.

@Chris, please feel free to ask me some help on testing with this devices (DCH-Z110 and DCH-Z120)

I think the database needs to be updated first - as per my comment above. Do you have a login for the database to make the changes? If so, it would be good if you can update?

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.

OK. Thanks @chris
Registed
Awaiting for activation

Done ;).

Thanks @chris
I’m going to do some tests.
As soon I get conclusions (if any) I will share it here.

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 :slight_smile: - 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