RM 4 Possible Bug with Lock Code Trigger

OK, just ran a simple test, rule 4.0:

With encryption set to off in the lock driver, the rule worked as expected:

I ran the same test again after enabling lock code encryption in the driver, the rule ran as expected again:

The lock in question is a Yale Zigbee model:YRL220 TS LL using the stock Zigbee driver.

So a question for the two of you, The lock rule and the lock are running on the same hub correct?

@bravenel

I finally had time to test the issue I initially reported above on the newest release and verified it's working now on RM 4.0.

1 Like

@mike.maxwell Yes lock and rule are running on the same hub.

I am using the Generic Zigbee Lock driver. The Schlage fingerprint isn't contained in this driver as it originally paired as a device and I had to change it to this driver. I clicked configure once changed. I have both a zwave version and a zigbee version.

Via logging I can see that certain codes were entered to unlock the lock, but no events are ever created for it in the device events list:

When I compare this to my Schlage Zwave lock, it is entering events:

Is this the cause of the rule not firing? I asked a few owners of this same Schlage lock if events are logged for specific lock codes in this thread:

Yes, that's the reason.
I'll have a look at the other thread.

@bravenel tagging you so you know the answer to my issue with the rule not firing when I unlock my Zigbee lock by certain codes.

@mike.maxwell Thank you! If you need the fingerprint of this lock to add to the driver, I am happy to provide that. I can even pair it to my dev hub temporarily so I get the full details if need be.

Could this driver be updated so that unlock by code events are logged? I would like to automate things based on who unlocks the lock. I am happy to gather any logs or test things for you so let me know how I can help. Thanks!

I may or may not be able to fix this without one of these locks in hand, I need to have a look at the code first...

Given the lock joined and selected Device as its driver, did you click configure in the Lock driver after switching it?

Yes I did click configure. FWIW in the hub logs the code used is logged:
image

Maybe it is something simple like ensuring a device event is captured?

The only thing I see that's perhaps not correct being we're sending two unlock events it seems, the first with no user info, the second with the correct info, whilst this isn't quite correct it should still work...
If you could enable debug logging in the driver, the unlock it with one of the codes, then PM me the live log results, then maybe it is something simple...

@mike.maxwell done! Thanks.

1 Like

Has there been any progress on this issue, I have a couple of Kwikset 914 Zigbee units that the lock code events were triggering RM rules fine, but no longer are, the logging shows both the unlock and the unlock by xx but the device event log isn't showing a user at all and the RM rule isn't triggering.

1 Like

@mike.maxwell Were you able to determine the issue? I am have a dev hub and happy to temporarily pair the lock to that hub and load beta/test firmware to help you with this issue. Please let me know how I can help.

We may have to do that as the only zigbee locks I have on hand are Yale, and they will now have a dedicated driver in 2.1.4

Just don't break it for the rest of us... My kwikset 914 and my two 916 all are working perfectly with the zigbee modules. They report user codes when unlocked as expected, and I don't get any duplicate events in the event list.

It might be something device-specific in his install.

That's exactly why I spun up drivers just for Yale, you're seeing the trend no?

1 Like

Cool, let me know how I can help.

I'm chiming in here. Having the same problem as others. Old rules that worked stopped. Just did on site testing and confirmed.

This from the event log from the device:

The rule:

The events from the rule:

Lock is a Yale YRD210(zigbee). Using new driver. Lock is on different hub than rule. Using HubConnect. All screenshots above are from "Control" hub. NOT Hub that lock is connected to. So not sure if this is a HubConnect issue or HE issue. But having same issues as others. This WAS working and then stopped. Can not pinpoint when. But I used to get notfications (different rule). But then realized I was not. Created dedicated rule for testing as shown above.

Oh come on! It can't be the "same issue as others" with HubConnect and two hubs. You're going to have to show a lot more logging and context to determine where this failure is. You should put this rule on the hub with the lock for testing, and determine if it works there or not.

Same issues as others meaning everything to do with triggering on the locks has been fine, until recently. Now triggering specfically on lock codes is not working. I was going to start a separate thread but found this one and thought best to post here. If you feel this is a different issue (which I stated I could understand if it is) I will gladly move to a different thread as I do realize I have hubconnect.

To that end...exactly what logging would you like to see?

First, I'd like you to discover if this problem exists without HubConnect in the middle, by running the rule on the hub with the lock. Turn on all rule logging, and the lock logging (not debug). Clear the Logs page, work the lock, and show the results.

Didn't have anything on the hub with the lock on it to test with. I added a bulb and a rule to toggle the bulb on/off. That is working fine. So something broke in HubConnect. I apologize and will take to that thread. Sorry that it seemed similar to me.