August Z-Wave lock alarm_entry notification handling

I just recently switched over to the dev version of the binding. One of the reasons for switching was to add my August Z-Wave lock. Inclusion worked on the first try. How sweet is that! Thanks, @chris!

One thing I noticed, however, is that the alarm channel (alarm_entry) is not updating when the door is opened/closed (there’s a sensor in the lock that knows if the door is opened/closed in addition to being locked/unlocked). I see in the log that it’s saying that channel alarm_entry is not implemented.

I see ZWaveAlarmConverter handles alarm_raw, notification_access_control, and alarm_number, but not alarm_entry. Can alarm_entry be added to ZWaveAlarmConverter’s notification report handling to return an OnOffType state?

2018-06-25 14:39:53.423 [DEBUG] [wave.handler.ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 23 00 04 00 5E 1D 98 81 2A F2 80 03 65 85 73 08 05 9A 37 49 CB 55 0A CE A6 F5 8B 15 0A 79 70 AB 7F E2 9E 9F 
2018-06-25 14:39:53.423 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=94, callback=0, payload=00 5E 1D 98 81 2A F2 80 03 65 85 73 08 05 9A 37 49 CB 55 0A CE A6 F5 8B 15 0A 79 70 AB 7F E2 9E 
2018-06-25 14:39:53.424 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=94, callback=0, payload=00 5E 1D 98 81 2A F2 80 03 65 85 73 08 05 9A 37 49 CB 55 0A CE A6 F5 8B 15 0A 79 70 AB 7F E2 9E 
2018-06-25 14:39:53.424 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=94, callback=0, payload=00 5E 1D 98 81 2A F2 80 03 65 85 73 08 05 9A 37 49 CB 55 0A CE A6 F5 8B 15 0A 79 70 AB 7F E2 9E 
2018-06-25 14:39:53.424 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-06-25 14:39:53.425 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 94: Application Command Request (ALIVE:DONE)
2018-06-25 14:39:53.425 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 94: resetResendCount initComplete=true isDead=false
2018-06-25 14:39:53.425 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 94: Decapsulating COMMAND_CLASS_SECURITY
2018-06-25 14:39:53.425 [DEBUG] [al.protocol.commandclass.ZWaveSecurityCommandClass] - NODE 94: SECURITY_RXD 71 05 00 00 00 FF 06 03 00 
2018-06-25 14:39:53.426 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 94: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-06-25 14:39:53.426 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 94: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2018-06-25 14:39:53.426 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: NOTIFICATION report - 0 = 0, event=3, status=255, plen=0
2018-06-25 14:39:53.426 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: Alarm Type = ACCESS_CONTROL (0)
2018-06-25 14:39:53.426 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-06-25 14:39:53.426 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-06-25 14:39:53.426 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-06-25 14:39:53.426 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 3, type OnOffType
2018-06-25 14:39:53.426 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 3, channel alarm_entry is not implemented.
2018-06-25 14:39:53.426 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 94: Commands processed 1.
2018-06-25 14:39:53.426 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 94: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@5c3ed412.

Glad it’s working (mostly) :slight_smile:

Can you provide the other state as well please and I’ll update the binding. I guess it will be 06 04 but it would be good to check.

Thanks!

Looks like 06 05?

2018-06-30 09:49:54.602 [DEBUG] [al.protocol.commandclass.ZWaveSecurityCommandClass] - NODE 94: SECURITY_RXD 71 05 00 00 00 FF 06 05 00 
2018-06-30 09:49:54.602 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 94: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-06-30 09:49:54.603 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 94: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2018-06-30 09:49:54.603 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: NOTIFICATION report - 0 = 0, event=5, status=255, plen=0
2018-06-30 09:49:54.603 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: Alarm Type = ACCESS_CONTROL (0)
2018-06-30 09:49:54.603 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-06-30 09:49:54.603 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-06-30 09:49:54.603 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-06-30 09:49:54.603 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 5, type OnOffType
2018-06-30 09:49:54.603 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 5, channel alarm_entry is not implemented.

How are you opening/closing this… Take a look at the following and you will probably understand why I ask :wink:

        ACCESS_CONTROL__MANUAL_LOCK("ACCESS_CONTROL", 1),
        ACCESS_CONTROL__MANUAL_UNLOCK("ACCESS_CONTROL", 2),
        ACCESS_CONTROL__REMOTE_LOCK("ACCESS_CONTROL", 3),
        ACCESS_CONTROL__REMOTE_UNLOCK("ACCESS_CONTROL", 4),
        ACCESS_CONTROL__KEYPAD_LOCK("ACCESS_CONTROL", 5),
        ACCESS_CONTROL__KEYPAD_UNLOCK("ACCESS_CONTROL", 6),

Yeah, I need to look at this more closely. Wife was in a hurry to go somewhere and I didn’t take the time to look at all the scenarios. :roll_eyes: :man_facepalming:

Don’t worry too much - it would be kind of nice to confirm it works as per the standards, but it’s more for interest. I’ve used all the LOCK and UNLOCK events to trigger this, so it should work no-matter what events are sent…

I have (incorrectly!) used an OPEN/CLOSED type for this - give it a test to see if it works, and then I’ll change it to ON/OFF (ON=Locked and OFF=Unlocked).

Here’s one log file (note this is still using the old binding).
https://drive.google.com/open?id=1wdwdyWDVywaLdTUZ_QKoiq3HSzoIQNJN

I made several comments in the log file that indicate what I did to cause the log entries.

From what I can see, unlocking and locking from openHAB causes it to report ACCESS_CONTROL 6 and 5, respectively.

When the door is physically opened/closed, it looks like it’s just reporting the state of the lock (i.e. OFF)

I’ll do a couple more scenarios

  • manually unlocking and locking
  • using the August app to unlock and lock

Second test – using August smartphone app to unlock and lock. Looks like ACCESS_CONTROL 4 and 3, respectively.
https://drive.google.com/open?id=17XFodetufMZqkO0pk67ZbFksEDjq733_

Using the August keypad to unlock and lock generates 6 and 5, respectively.

Manual operation to unlock and lock generates 2 and 1, respectively.

Moving on to the new version of the binding…

This looks good (other than replacing OpenClosedType with OnOffType).

For unlock I’m seeing this.

2018-06-30 16:23:11.514 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 94: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-06-30 16:23:11.514 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 94: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2018-06-30 16:23:11.514 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: NOTIFICATION report - 0 = 0, event=6, status=255, plen=0
2018-06-30 16:23:11.514 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: Alarm Type = ACCESS_CONTROL (0)
2018-06-30 16:23:11.514 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-06-30 16:23:11.514 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-06-30 16:23:11.514 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-06-30 16:23:11.514 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, type OnOffType
2018-06-30 16:23:11.514 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Updating channel state zwave:device:zstick:node94:alarm_entry to CLOSED [OpenClosedType]

And for lock, I’m seeing this.

2018-06-30 16:23:21.809 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 94: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-06-30 16:23:21.809 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 94: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2018-06-30 16:23:21.809 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: NOTIFICATION report - 0 = 0, event=5, status=255, plen=0
2018-06-30 16:23:21.809 [DEBUG] [ernal.protocol.commandclass.ZWaveAlarmCommandClass] - NODE 94: Alarm Type = ACCESS_CONTROL (0)
2018-06-30 16:23:21.809 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-06-30 16:23:21.809 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-06-30 16:23:21.810 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-06-30 16:23:21.810 [DEBUG] [nding.zwave.internal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 5, type OnOffType
2018-06-30 16:23:21.810 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 94: Updating channel state zwave:device:zstick:node94:alarm_entry to OPEN [OpenClosedType]

Cool - at least we fixed this one :slight_smile: .

I’ve just updated to change to ON/OFF here. This should also remove the disabled from the repoll config (although I didn’t double check this)…

Would it be possible to make the alarm_general work like this, in the YRD446 lock, so we don’t have to parse alarm_raw? The access control codes look the same.

Like what exactly? There are many different alarms - alarm_raw was added for a specific purpose (to provide a lot of information) but other alarms are available and they do process out to different types (and again, we’re talking about the development binding here - not the master/snapshot version).

I’d suggest if you have an issue with a device to start a thread to discuss the issue…