[2.0.4] Schlage FE599 Not Reporting Keypad Events

srwhite · January 12, 2019, 8:08pm

The Generic Z-Wave Lock driver is still not reporting lock events generated by the keypad after the 2.0.4 update.

Event Log:

[dev:361](http://192.168.X.X/logs#dev361)2019-01-12 02:59:22.193 pm [warn](http://192.168.X.X/device/edit/361)skipped zAlarmType:0, zAlarmEvent:0, alarmType:16]

[dev:361](http://192.168.X.X/logs#dev361)2019-01-12 02:59:22.192 pm [debug](http://192.168.X.X/device/edit/361)alarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:16, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:0, zwaveAlarmStatus:0, zwaveAlarmType:0)

[dev:361](http://192.168.X.X/logs#dev361)2019-01-12 02:59:22.187 pm [debug](http://192.168.X.X/device/edit/361)parse: zw device: 4C, command: 9881, payload: 00 71 05 10 01

Using a ported/modified Z-Wave Lock driver from SmartThings I can get the lock to report lock/unlock events generated by the keypad. I just cannot get code get/set to work due to the undocumented way HE implements codes. The lock will correctly report which slot was used.

[dev:361](http://192.168.X.X/logs#dev361)2019-01-12 03:00:39.618 pm [debug](http://192.168.X.X/device/edit/361)[DTH] zwaveEvent(hubitat.zwave.commands.alarmv2.AlarmReport) returning with result = [[name:lock, value:unlocked, isStateChange:true, descriptionText:Unlocked by "{code=????, name=Steve}", data:[codeId:1, usedCode:1, codeName:{code=????, name=Steve}, method:keypad, lockName:Lock, Kitchen Door]]]

[dev:361](http://192.168.X.X/logs#dev361)2019-01-12 03:00:39.599 pm [trace](http://192.168.X.X/device/edit/361)[DTH] Executing 'handleAlarmReportUsingAlarmType' with cmd = AlarmReport(alarmLevel:1, alarmType:16, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:0, zwaveAlarmStatus:0, zwaveAlarmType:0)

Hope this can get fixed. Thanks!

mike.maxwell · January 13, 2019, 5:05am

The virtual lock driver code is published in our public github repo.

srwhite · January 13, 2019, 4:03pm

What about the code for the Generic Z-Wave Lock? It would require considerably less time to add code to parse the missing alarm report than to rewrite the codes portion of the SmartThings driver

mike.maxwell · January 13, 2019, 4:20pm

There's still a bug in that section of the code (apparently) for the FE599

srwhite · January 13, 2019, 6:12pm

The alarm report isn’t being parsed at all, the logs indicate it's "skipping unhandled event type".

If you look at the ST driver, the event follows this flow:

Parse() calls zwaveEvent(hubitat.zwave.commands.alarmv2.AlarmReport cmd)
zwaveEvent(hubitat.zwave.commands.alarmv2.AlarmReport cmd) calls handleAlarmReportUsingAlarmType(cmd) (default in the if/else block)

handleAlarmReportUsingAlarmType(cmd) matches alarmType==16

 	case 16: // Note: for levers this means it's unlocked, for non-motorized deadbolt, it's just unsecured and might not get unlocked
 	case 19: // Unlocked with keypad
 		map = [ name: "lock", value: "unlocked" ]
 		if (cmd.alarmLevel != null) {
 			codeID = readCodeSlotId(cmd)
 			codeName = getCodeName(lockCodes, codeID)
 			map.isStateChange = true // Non motorized locks, mark state changed since it can be unlocked multiple times
 			map.descriptionText = "Unlocked by \"$codeName\""
 			map.data = [ codeId: codeID as String, usedCode: codeID, codeName: codeName, method: "keypad" ]
 		}
 		break

And the rest is history as we know it.

mike.maxwell · January 14, 2019, 1:50am

Yeah, I know what it's missing, and I added the code in build 2.0.4 to capture it, obviously that's worked out well, which is why i despise modifying drivers without having the device on hand, I'll look at it some more soon.

srwhite · January 14, 2019, 4:04am

I am certainly willing to help you Test since I have got several of these. Please let me know how I can assist

tinypocket · January 15, 2019, 7:39am

Unfortunately lock user code reporting broke for me too -- I think it was 2.0.4 also. It was working up until a few days ago. I have both a yale lock and a kwikset lock -- both stopped reporting unlock events with keypad code. Both are using the Generic Z-Wave Lock and I see the same "skipped zAlarmType" lines as srwhite.

I have one lock on an outside door that unlocks the inside one too when unlocked with my code. One of the main reasons I got Hubitat -- it reduced the dealy between unlocking one door and the other door from 20+ seconds (sometimes 1 min) on Smarthings down to 3 sec or less on Hubitat!

Hoping it can get fixed soon!

mike.maxwell · January 16, 2019, 1:07am

Will be sorted out in the next release.

srwhite · January 16, 2019, 5:38am

Thank you.

JasonJoelOld · January 16, 2019, 8:21pm

Just an FYI, my Kwikset 914 isn't reporting lock codes any more either.

Last one was on 1/10, and it has been unlocked with code many times since then.

Looking at the events, it seemed to work fine before then... I've installed all the updates. Was there one on 1/10 perchance?

Edit... Last time it reported correctly was on 2.0.3... hasn't reported code use once in 2.0.4...

Was definitely annoying when the maid lock code didn't turn off the alarm today (via an RM rule I have built)...

JasonJoelOld · January 18, 2019, 11:40pm

Any word on if lock codes for makes other than Schlage will be fixed soon? I miss my uinlock lock code events... @mike.maxwell

tinypocket · January 20, 2019, 6:06pm

Can this be fixed via a hotfix instead of waiting for a new release @mike.maxwell ? Or is there a trick to roll back to 2.0.3? I tried to roll back but I couldn't go that far back, only to previous 2.0.4 biulds.

srwhite · January 20, 2019, 8:13pm

If you are referring to the FE599 it has not reported code usage on any build so far. It’s just a waiting game at this point.

JasonJoelOld · January 20, 2019, 9:24pm

I get the exact same "skipped zAlarmType" message when unlocking my Kwikset locks with the keypad.

This is frustrating, as I have RM logic based on lock codes. Obviously all that has been broken since 2.0.4 was installed.

@mike.maxwell When will this get fixed? Can you just do a hotfix and put it back to the 2.0.3 functionality if it is going to be a while? You guys broke my automations that worked fine before, that seems like something that shouldn't have to wait for another release to me.

This is another case where if you posted your built-in driver code, I could have fixed/reverted it myself... But in absence of that, we need to rely on timely fixes from the Hubitat team.

srwhite · January 21, 2019, 12:19am

This gets my vote too.

This I completely agree with. I realize things change quickly with the rapid updates, but it would be nice to at least have the “Generic” line of drivers published.

mike.maxwell · January 21, 2019, 1:32am

I'll bring this up in engineering.

rayzurbock · January 21, 2019, 5:35am

I'm glad I found this thread. I submitted a support ticket Wed 1/16 but haven't heard back from anyone. I did get the automated reply which doesn't include a ticket number so I can't reference it here.

I'm having the same issue with my Kwikset 914 z-wave lock. I get reports of lock/unlock but it's not sending keypad unlock data (codes used, etc).

deviceType: 1
zwaveSecurePairingComplete: true
inClusters: 0x72,0x86,0x98
deviceId: 1
manufacturer: 144

I am also seeing "skipped" messages around the time that I unlock with the keypad:
warn skipped zAlarmType:0, zAlarmEvent:0, alarmType:19]

JasonJoelOld · January 21, 2019, 2:04pm

Yup. That's what I see on all 3 of my Kwikset locks since installing 2.0.4. I REALLY hope they fix this soon - has already been 11 days...

matommy · May 17, 2019, 9:46am

Schlage * 3 not notifying on lock code either. New to Hubitat and lock codes across more than one is cumbersome, Is there a third-party equivalent like RBoy on ST?

I don't want to revert my locks back to ST, but if this is what HE has for locks, I will.