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)
endThe 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”
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).
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.
Again, please provide the debug log - without this I’ve no way to see what is happening - sorry.
What kind of logs do you want? Is there a specific log file or are the logs from the openHAB 2 Log Viewer good enough.
The OH logs are exactly what I’m after - you just need to enable debug logging for the zwave binding.