Zwave - Yale YRD220 Lock

@5iver

Lol… I was slowly making sense of the rule and how it works and was closing in on it was well.

Anyone who takes the time to help others in their free time is a saint in my book. I know we all have real lives and other commitments.

1 Like

@5iver,
Thanks for the great solution for parsing the raw lock JSON. I’m using it with a YRD446 and it works great!

The one thing I would like to work in my case is which user code is used. It doesn’t tell me which code is called. It only reports code:99 for any keypad unlock.

2018-01-18 20:09:33.873 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:zwavedev:node10:alarm_raw to {"notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","type":"ACCESS_CONTROL","event":"6","status":"255"}

From what I have found here, the alarm_raw channel builds the JSON string from the available data from the zwave device. Is there any thing else that can be captured or is this all of it? There isn’t anything else in the zwave log. Does anyone with a Yale lock have experience with this?

See yale alarm document here.

Perhaps we could also add “level” to the string?

I believe that is what is supposed to come through in alarm_raw for the code key. @chris would have a definitive answer though.

You might want to open an issue for the dev binding on this (see what Chris says). It works well for my Schlage BE469 locks.

This is working for me with a Yale YRD220, see my code below. I simplified the user code parsing by using a map file, rather than needing to update the Lambda if I change the code slot assignments. Note that the alarm codes for the 220 don’t match those in the document linked above

import org.eclipse.xtext.xbase.lib.Functions

val Functions$Function3<GenericItem, GenericItem, GenericItem, Boolean> alarmRawParser = [
    lockAlarmRaw,
    lockItem,
    lockUser |
    
    logDebug("Rules", "Lock: Alarm events: {}=[{}]",lockItem.getName,lockAlarmRaw.state.toString)
    	switch (transform("JSONPATH", "$.type", lockAlarmRaw.state.toString)) {
                case "21" : {  
                    lockItem.postUpdate(ON)
                    logInfo("Rules", "Lock: Alarm events: {} updated to ON (locked)",lockItem.getName)
                }
                case "22" : {
                    lockItem.postUpdate(OFF)
                    logInfo("Rules", "Lock: Alarm events: {} updated to OFF (unlocked)",lockItem.getName)
                }
                case "19" : {
                	lockItem.postUpdate(OFF)                    
                	var codevalue = transform("JSONPATH", "$.value", lockAlarmRaw.state.toString)
                	var codename = transform("MAP", "locks.map", codevalue)
                	lockUser.postUpdate(codename)
                }
            }
    true
]

rule "Lock: Update lock states after alarm_raw event (Lock_FrontDoor)"
when
	Item Lock_FrontDoor_AlarmRaw changed
then
    alarmRawParser.apply(Lock_FrontDoor_AlarmRaw,Lock_FrontDoor,Who_Unlocked_Front_Door_Last)
end

rule "Lock: Update lock states after alarm_raw event (Lock_BackDoor)"
when
	Item Lock_Back_Alarm_Raw changed
then
    alarmRawParser.apply(Lock_Back_Alarm_Raw,Lock_BackDoor,Who_Unlocked_Back_Door_Last)
end

The YRD446 does match that document, I had to change all of the values for the switch function to work. An I have to use the $.event instead of $.type. It appears that $.level would correspond to the code slot (01-max
users) which would work well for me. I’m hoping @chris will be able to shed some light.

I like the map idea, I’ll use that in the future once we can get the codes.

Can you post an example of the json string you get. There are different formats depending on the version of the command class.

{"notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","type":"ACCESS_CONTROL","event":"6","status":"255"}

No matter which code is used, it always says ,“code”:“99”

@chris,

Here is a bit more of the log during an unlock using the keypad, I think it might give you more information than just the JSON string.

2018-02-08 12:56:06.623 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = REDAC
2018-02-08 12:56:09.718 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=9, payload=REDAC
2018-02-08 12:56:09.721 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[19], type=Request[0], dest=0, callback=9, payload=REDAC
2018-02-08 12:56:09.722 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=9, payload=REDAC
2018-02-08 12:56:09.724 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 12461: [WAIT_REQUEST] requiresResponse=true callback: 9
2018-02-08 12:56:09.725 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2018-02-08 12:56:09.725 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 12461: [WAIT_REQUEST] requiresResponse=true callback: 9
2018-02-08 12:56:09.726 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 12461: (Callback 9)
2018-02-08 12:56:09.726 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = REDAC 
2018-02-08 12:56:09.728 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2018-02-08 12:56:09.730 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 12461: callback 9
2018-02-08 12:56:09.733 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=9, payload=REDAC
2018-02-08 12:56:09.736 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 116: SendData Request. CallBack ID = 9, Status = Transmission complete and ACK received(0)
2018-02-08 12:56:09.737 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 116: resetResendCount initComplete=true isDead=false
2018-02-08 12:56:09.738 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 12461: Transaction COMPLETED
2018-02-08 12:56:09.739 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 12461: TransactionAdvance ST: DONE
2018-02-08 12:56:09.743 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 12461: TransactionAdvance WT: null {}
2018-02-08 12:56:09.745 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 12461: TransactionAdvance RX: Message: class=SendData[19], type=Request[0], dest=0, callback=9, payload=REDAC
2018-02-08 12:56:09.749 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 12461: TransactionAdvance TO: DONE
2018-02-08 12:56:09.750 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 116: Response processed after 3248ms
2018-02-08 12:56:09.752 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 116: TID 12461: Transaction completed
2018-02-08 12:56:09.753 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 116: notifyTransactionResponse TID:12461 DONE
2018-02-08 12:56:09.757 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2018-02-08 12:56:09.758 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-02-08 12:56:09.760 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=116, callback=0, payload=REDAC
2018-02-08 12:56:09.762 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=116, callback=0, payload=REDAC
2018-02-08 12:56:09.765 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = REDAC
2018-02-08 12:56:09.769 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=116, callback=0, payload=REDAC
2018-02-08 12:56:09.770 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-02-08 12:56:09.773 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 116: Application Command Request (ALIVE:DONE)
2018-02-08 12:56:09.774 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 116: resetResendCount initComplete=true isDead=false
2018-02-08 12:56:09.775 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 116: Decapsulating COMMAND_CLASS_SECURITY
2018-02-08 12:56:09.777 [DEBUG] [mmandclass.ZWaveSecurityCommandClass] - NODE 116: SECURITY_RXD REDAC
2018-02-08 12:56:09.778 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 116: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-02-08 12:56:09.779 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 116: Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT
2018-02-08 12:56:09.780 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 116: NOTIFICATION report - 19 = 1, event=6, status=255, plen=4
2018-02-08 12:56:09.781 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 116: Alarm Type = ACCESS_CONTROL (19)
2018-02-08 12:56:09.781 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2018-02-08 12:56:09.782 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-02-08 12:56:09.783 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-02-08 12:56:09.785 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-02-08 12:56:09.786 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, type OnOffType
2018-02-08 12:56:09.788 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, channel alarm_access is not implemented.
2018-02-08 12:56:09.790 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-02-08 12:56:09.790 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=116, callback=0, payload=REDAC
2018-02-08 12:56:09.791 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, type OnOffType
2018-02-08 12:56:09.792 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-02-08 12:56:09.793 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, type StringType
2018-02-08 12:56:09.794 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=116, callback=0, payload=REDAC
2018-02-08 12:56:09.796 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Updating channel state zwave:device:de0bde91:node116:alarm_raw to {"notification":"ACCESS_CONTROL__KEYPAD_UNLOCK","code":"99","type":"ACCESS_CONTROL","event":"6","status":"255"} [StringType]
2018-02-08 12:56:09.800 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-02-08 12:56:09.806 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, type OnOffType
2018-02-08 12:56:09.807 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 6, channel alarm_general is not implemented.
2018-02-08 12:56:09.808 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 116: Commands processed 1.
2018-02-08 12:56:09.809 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 116: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@e5905b.
2018-02-08 12:56:09.810 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-02-08 12:56:09.811 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-02-08 12:56:09.812 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=116, callback=0, payload=REDAC
2018-02-08 12:56:09.813 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-02-08 12:56:09.814 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 116: Application Command Request (ALIVE:DONE)
2018-02-08 12:56:09.815 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 116: resetResendCount initComplete=true isDead=false
2018-02-08 12:56:09.816 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 116: Decapsulating COMMAND_CLASS_SECURITY
2018-02-08 12:56:09.817 [DEBUG] [mmandclass.ZWaveSecurityCommandClass] - NODE 116: SECURITY_ERR No valid NONCE! null
2018-02-08 12:56:09.818 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-02-08 12:56:09.819 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start

Just looking at the code here

+            case "alarm_raw":
 +                Map<String, Object> object = new HashMap<String, Object>();
 +                object.put("type", eventAlarm.getAlarmType());
 +                object.put("event", eventAlarm.getAlarmEvent());
 +                object.put("status", eventAlarm.getAlarmStatus());
 +                return new StringType(propertiesToJson(object));

Do you think it would be as easy as adding a line like:

object.put("level", eventAlarm.getAlarmLevel());

I’m fixated on the level because of the column in the Yale support document, see snippet here:

Can you email/PM me the line above from your log please…

What command class version is this? Is it V2?

If so, I suggest we wait for the next version as I’ve recently changed the way V2 alarms are handled and this is currently being processed (incorrectly I think) as a notification rather than an alarm.

I’m actually not sure how to answer that. According to the log version 4? Is that possible?

Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT

Hmmm - ok, strange, but yes, it’s possible. It’s a bit strange that they didn’t use the special features for providing codes rather than the old V1 data…

In that case, it won’t change anything, but as I’ve already updated the binding tonight let’s see and if (when) it doesn’t change anything, I’ll take another look tomorrow.

Sounds good.

Just looking back at the support document (where I pulled that table).

http://www.cd-jackson.com/zwave_device_uploads/594/Yale-Real-Living-ZWave-Plus-System-Integrators-Guide-YRL-deadbolts-Rev-4.pdf

On page 8 they also call it: Command Class Notification, Version 4.

Thanks. I’m assuming nothing has changed with the latest version?

Correct, no changes.

Ok - I’ll take a look at adding this in the next day or so (fundamentally as you suggested earlier).

I am trying to move away from using SmartThings, because they keep having terrible network problems, and so I would just prefer to get everything working locally.

But then I come across this problem with only code 99 showing instead of an actual user code slot number, and I have no idea what to do about it now. It would be nice to get the User Code Label of the slot number as well.

If you can provide a debug log showing the incoming responses I’ll take a look at this.

I also can’t seem to be able to set the user codes and settings correctly. When I tried adding a code, all of the codes except for my master code stopped working on the lock, and the settings such as auto lock were also changed.