Kwikset Z-wave Door Locks never update status in OpenHab

  • Platform information:
    • Hardware: Raspberry PI 3B+ CPU = 1.4 GHz / Architecture = 64Bit / RAM = 1 GB/Storage = 32 GB
    • OS: Linux (OpenHabian)
    • Java Runtime Environment: 1.8.0_152-b76
    • openHAB version: 2.4

I have 5 Kwikset Z-Wave Door locks and I’m trying to get things setup so that if someone unlocks or locks the door without using OpenHab, OpenHab gets updated.

A lot of posts that I’ve seen recommend putting the controller into Association groups/Lifeline Association Groups on the locks.

I used Habmin to do that and think I have it setup correctly but it still doesn’t work.

I have noticed that when I look at event.log the alarm status is coming through in close proximity to when I manually lock\unlock the door.

2019-01-08 15:42:18.808 [vent.ItemStateChangedEvent] - Lock_LivingRoom_BasementDoor_Alarm changed from 0 to 21
2019-01-08 15:42:18.822 [vent.ItemStateChangedEvent] - Lock_LivingRoom_BasementDoor_AlarmRaw changed from {"type":"0","value":"0"} to {"type":"21","value":"1"}

But there is never any event indicating that the door lock changed from ON to OFF.

Several posts suggested turning up debugging on ZWave. This is what I get in openhab.log

2019-01-08 15:42:18.775 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 19: Application Command Request (ALIVE:DONE)
2019-01-08 15:42:18.777 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 19: resetResendCount initComplete=true isDead=false
2019-01-08 15:42:18.779 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 19: Decapsulating COMMAND_CLASS_SECURITY
2019-01-08 15:42:18.783 [DEBUG] [mmandclass.ZWaveSecurityCommandClass] - NODE 19: SECURITY_RXD 71 05 15 01 
2019-01-08 15:42:18.785 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 19: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-08 15:42:18.787 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 19: Received COMMAND_CLASS_ALARM V1 NOTIFICATION_REPORT
2019-01-08 15:42:18.788 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 19: ALARM report - 21 = 1
2019-01-08 15:42:18.790 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 19: Alarm Type = null (21)
2019-01-08 15:42:18.792 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-08 15:42:18.793 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 1
2019-01-08 15:42:18.796 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 19: Alarm converter processing ALARM
2019-01-08 15:42:18.797 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Updating channel state zwave:device:9fca719e:node19:alarm_number to 21 [DecimalType]
2019-01-08 15:42:18.800 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 19: Alarm converter processing ALARM
2019-01-08 15:42:18.803 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 19: Updating channel state zwave:device:9fca719e:node19:alarm_raw to {"type":"21","value":"1"} [StringType]
2019-01-08 15:42:18.807 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 19: Commands processed 1.
2019-01-08 15:42:18.808 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 19: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@ca38ac.

The only way I ever see the change register is if I wait for my polling interval to elapse (currently set at 10 minutes) but there’s no shortage of documentation or posts advising against speeding up the polling interval so I don’t want to rely on polling if I can avoid it.

2019-01-08 15:42:18.790 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 19: Alarm Type = null (21)

This line would suggest that the binding doesn’t have an AlarmType defined for an alarm code of 21 for this version 1 alarm.

As a hack, I suppose you could write a rule that triggers on an item linked to the alarm_number channel. If that item changes to 21 (see table below), you could do a postUpdate(ON) to the item linked to the door lock channel. I think this will work, but I’m not 100% sure. @chris might have a better suggestion. :wink:

To be fully complete in this hack, you also might need to deal with the other alarm codes generated by the device.

021              001                      Lock Secured using Keyed cylinder or inside thumb-turn  
022              001                      Lock Un-Secured using Keyed cylinder or inside thumb-turn  
026              001                      Lock Auto Secured – Bolt Jammed (Not fully extended)
027              001                      Lock Auto Secured – Successful (Fully extended)  
017              001                      Lock Secured at Keypad – Bolt Jammed (Not fully extended)   
018              000 or User-ID#*   Lock Secured at Keypad – Successful (Fully extended)   
019              User-ID#*              Lock Un-Secured by User (User-ID) at Keypad  
023              001                      Lock Secured by Controller – Bolt Jammed (Not fully extended)   
025              001                      Lock Un-Secured by Controller – Successful (Fully retracted)  

The 914TRL also has the alarm_raw channel. There are plenty of examples in the forum for using this channel to set states. Here’s one (I think there is an example in there using ALARM v1)…

I thought about suggesting alarm_raw, but it would’ve involved a wee bit more work (using JSONPATH) to extract the alarm code, and I wasn’t sure if there was any extra benefit to doing it that way.

That’s a great link. There are some good examples of how to deal with those alarm codes.

1 Like

The ZWave standard doesn’t define any alarm types for CC_V1. These were only added at V3 (I think - maybe V2) when the command class name also changed to NOTIFICATION. This is why there is a V1 alarm type in the V3 message… Because of this, there are no definitions of the alarms in the binding for V1 - only notifications.

Please can you provide the device types…

It should be possible to add a channel to the database that associates with this event - but I’d need to know the device to check what is there, and add something if needed.

Super bizarre that I had this exact same question/problem about a Kwikset lock today and found this… Thanks for doing the gruntwork for me @Steve_Cutler :smile: I did as suggested and do a postUpdate(ON) for the succesful locked codes and OFF for un-secured:

rule "Auto-Unlock Door"
when
        Item Door_Lock_Alarm changed to 19 or
        Item Door_Lock_Alarm changed to 22 or
        Item Door_Lock_Alarm changed to 25
then
        Door_Lock.postUpdate(OFF)
        if(PARTITION1_ARM_MODE.state != 0){
                PARTITION1_ARM_MODE.sendCommand(0)
        }
end

rule "Update Locked Door"
when
        Item Door_Lock_Alarm changed to 18 or
        Item Door_Lock_Alarm changed to 21 or
        Item Door_Lock_Alarm changed to 27
then
        Door_Lock.postUpdate(ON)
end

@chris if it is helpful mine is a 910. Didn’t do more verbose logging on it though…

3 Likes

Thanks for all the help!

I had thought of writing a rule that triggers on the alarm updates but I didn’t know if there was a better way of doing it. I’ll definitely look at setting up some rules for it.

I’m new to OpenHab so I hope this is what you need, if not let me know and I would be happy to do some more digging.

All the devices are the same.
Thing Type Label: 914TRL Touchpad Electronic Deadbolt

However, when I went looking for a download of the manual the actual device looked more like a 910 then 914.

Here are the attributes that Habmit lists.

How reliable has this rule been for you? I set up a similar one, and it doesn’t seem to always work.

Maybe I’ll try something closer to your syntax and give it another try. I just made one rule for when the alarm value changed, and had if statements to set the state depending on the value.

Its been working great for me. If it helps this is my rule that updates the lock status from the alarm raw event for all my locks.

rule "Lock: Update lock states after alarm_raw event"
when
    Item Lock_DiningRoom_DeckDoor_AlarmRaw changed
    or
    Item Lock_FrontRoom_FrontDoor_AlarmRaw changed
    or
    Item Lock_DiningRoom_GarageDoor_AlarmRaw changed
    or
    Item Lock_Garage_RVPadDoor_AlarmRaw changed
    or
    Item Lock_LivingRoom_BasementDoor_AlarmRaw changed

then
    //Take use item name of triggering event to determin the name of the Lock Item
    val actionItem = gAll_Locks.members.findFirst[ item | item.name.toString == triggeringItem.name.toString.replace("_AlarmRaw","_DoorLock") ]

    //Process the JSON from the raw alarm to get the Type and Value
    val actionType = transform("JSONPATH", "$.type",triggeringItem.state.toString)
    val actionTypeValue = transform("JSONPATH", "$.value", triggeringItem.state.toString)

    //Log the values
    logDebug("RULE_SYSTEM", "DiningRoom Deck Door Event Triggered")
    logDebug("RULE_SYSTEM", "Lock: Alarm events: Item Name: {}, Item State: [{}]",actionItem.name.toString,triggeringItem.state.toString)
    logDebug("RULE_SYSTEM", "Lock: Alarm events: TFormed State: {}, StateValue: {}", actionType, actionTypeValue)


    /*  Alarm types and levels from the documentation
    Alarm Type    Alarm Level            Notification Event
    021              001                 Lock Secured using Keyed cylinder or inside thumb-turn
    023              001                 Lock Secured by Controller – Bolt Jammed (Not fully extended)
    024              001                 Lock Secured by Controller – Successful (Fully extended)
    026              001                 Lock Auto Secured – Bolt Jammed (Not fully extended)
    027              001                 Lock Auto Secured – Successful (Fully extended)
    017              001                 Lock Secured at Keypad – Bolt Jammed (Not fully extended)
    018              000 or User-ID#*    Lock Secured at Keypad – Successful (Fully extended)

    019              User-ID#*           Lock Un-Secured by User (User-ID) at Keypad
    022              001                 Lock Un-Secured using Keyed cylinder or inside thumb-turn
    025              001                 Lock Un-Secured by Controller – Successful (Fully retracted)

    161              001                 Failed User Code attempt at Keypad

    167              001                 Low battery level
    168              001                 Critical battery level
    169              001                 Battery level too low to operate lock

    112              User-ID#*           New User Code (User-ID#) added to the lock
    032              001                 All User Codes deleted from lock
    162              User-ID#*           Attempted access by user (User-ID#) outside of scheduled


* User-ID# values: 001 to 030
    Rule inspired by this but modified to work with our locks
    https://community.openhab.org/t/zwave-yale-yrd220-lock/34180/5
    */
    switch (actionType) {
        //Locking actions
        case "17": {
            actionItem.postUpdate(ON)
            logDebug("RULE_SYSTEM", "{} Lock Secured at Keypad – Bolt Jammed (Not fully extended)", actionItem.name)
        }
        case "18": {
            actionItem.postUpdate(ON)
            logDebug("RULE_SYSTEM", "{} Lock Secured at Keypad by User [{}] – Successful (Fully extended)", actionItem.name, actionTypeValue)
        }
        case "21": {
            actionItem.postUpdate(ON)
            logDebug("RULE_SYSTEM", "{} Lock Secured using Keyed cylinder or inside thumb-turn", actionItem.name)
        }
        case "23": {
            actionItem.postUpdate(ON)
            logDebug("RULE_SYSTEM", "{} Lock Secured by Controller – Bolt Jammed (Not fully extended)", actionItem.name)
        }
        case "24": {
            actionItem.postUpdate(ON)
            logDebug("RULE_SYSTEM", "{} Lock Secured by Controller – Successful (Fully extended)", actionItem.name)
        }
        case "26": {
            actionItem.postUpdate(ON)
            logDebug("RULE_SYSTEM", "{} Lock Auto Secured – Bolt Jammed (Not fully extended)", actionItem.name)
        }
        case "27": {
            actionItem.postUpdate(ON)
            logDebug("RULE_SYSTEM", "{} Lock Auto Secured – Successful (Fully extended)", actionItem.name)
        }

        //Unlocking actions
        case "19": {
            actionItem.postUpdate(OFF)
            logDebug("RULE_SYSTEM", "{} Lock Un-Secured by User ({}}) at Keypad", actionItem.name, actionTypeValue)
        }
        case "22": {
            actionItem.postUpdate(OFF)
            logDebug("RULE_SYSTEM", "{} Lock Un-Secured using Keyed cylinder or inside thumb-turn", actionItem.name)
        }
        case "25": {
            actionItem.postUpdate(OFF)
            logDebug("RULE_SYSTEM", "{} Lock Un-Secured by Controller – Successful (Fully retracted)", actionItem.name)
        }

        //Misc Informational actions (No Locking\Unlocking with these)
        case "161": {
            logDebug("RULE_SYSTEM", "{} Failed User Code attempt at Keypad", actionItem.name)
        }
        case "167": {
            logDebug("RULE_SYSTEM", "{} Low battery level", actionItem.name)
        }
        case "168": {
            logDebug("RULE_SYSTEM", "{} Critical battery level", actionItem.name)
        }
        case "169": {
            logDebug("RULE_SYSTEM", "{} Battery level too low to operate lock  ", actionItem.name)
        }
        default : {
            val String message = "Unknown door lock Event, " + triggeringItem.state.toString
            logDebug("RULE_SYSTEM", "Lock: Alarm events: {}",message)
            //SMS_Notification.sendCommand(message)
        }
    }

end
1 Like

This is my first post so forgive me/tell me if I’m out of line. I found this thread while trying to set up my Kwikset ZWave 914TRL. I ended up using a different route to do what I believe you were asking about and thought others could benefit. I used the “MAP Transformation” service, created a number item for state of the lock. I populated the .map file using the lock documentation which provides numerical codes for state changes for manual and openhab based activation as well as successful/unsuccessful lock activation’s. I included a text item in my sitemap to the mapped item and get quick and correct returned state. Is this a viable solution to the original question? Only thing I haven’t determined is if the message persists until the next state change.