August Z-Wave lock bug uncovered

🛎️ Get Help
1

It looks like Hubitat doesn't recognize August Z-wave lock status responses when an August keypad is used to lock/unlock the device. Here are log entries showing this:

[dev:196](http://hubitat.tpg/logs#dev196)2020-06-07 09:39:15.209 am [warn](http://hubitat.tpg/device/edit/196)skipped zAlarmType:6, zAlarmEvent:6, alarmType:0]
[dev:196](http://hubitat.tpg/logs#dev196)2020-06-07 09:39:15.204 am [debug](http://hubitat.tpg/device/edit/196)alarmv2.AlarmReport: AlarmReport(alarmLevel:0, alarmType:0, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:6, zwaveAlarmStatus:255, zwaveAlarmType:6)
[dev:196](http://hubitat.tpg/logs#dev196)2020-06-07 09:39:15.194 am [debug](http://hubitat.tpg/device/edit/196)parse: zw device: 09, command: 9881, payload: 00 71 05 00 00 00 FF 06 06 00 , isMulticast: false
[dev:196](http://hubitat.tpg/logs#dev196)2020-06-07 09:39:14.894 am [debug](http://hubitat.tpg/device/edit/196)DoorLockOperationReport: DoorLockOperationReport(doorCondition:3, doorLockMode:0, insideDoorHandlesMode:1, lockTimeoutMinutes:254, lockTimeoutSeconds:254, outsideDoorHandlesMode:0)
[dev:196](http://hubitat.tpg/logs#dev196)2020-06-07 09:39:14.884 am [debug](http://hubitat.tpg/device/edit/196)parse: zw device: 09, command: 9881, payload: 00 62 03 00 01 03 FE FE , isMulticast: false
[dev:196](http://hubitat.tpg/logs#dev196)2020-06-07 09:38:56.314 am [warn](http://hubitat.tpg/device/edit/196)skipped zAlarmType:6, zAlarmEvent:5, alarmType:0]

Keypad Lock/unlock events are also part of the zwaveAlarmType=6 status report. Here is the complete table of responses:

zwaveAlarmType=6,
zwaveAlarmEvent=

1 locked manually
2 unlocked manually

3 locked digitally
4 unlocked digitally

5 locked keypad
6 unlocked keypad

The problem is complicated by the fact that the lock will respond to Hubitat lock/unlock commands using the digital zwaveAlarmEvent responses until a keypad is used to lock or unlock. Then, it will respond to hubitat lock/unlock commands using the keypad zwaveAlarmEvent responses for both digital and keypad actions. Hubitat will consequently ignore the 5/6 zwaveAlarmEvents and lose track of the lock state. When I pull the battery from the lock to reset, it will again respond using the digital zwaveAlarmEvent responses until a keypad is used again.

I'd like to request that the driver code be fixed to correctly recognize zwaveAlarmEvent 5 and 6 so that hubitat device state gets updated when a keypad is used to lock/unlock. This will also work around the lock firmware bug as I work with August to get it fixed.

2

Bump. Any thoughts from Hubitat support on this? Will the august lock driver be updated? Or is the driver source code public so I can build a custom variant? This problem may be root cause of many August Lock connectivity issues that get reported here.

3

I can confirm that I See this same behaviour on my August Lock

4

@mike.maxwell says the driver side of this will be fixed in 2.2.4:

1 Like
5

thanks for the heads up!
@mike.maxwell : Thanks for all your hard work!