Yale Zigbee Lock Driver Issues

Today I have received and installed my YMF40A Yale lock with Zigbee module and started testing it. Below is a list of problems/improvement opportunities I've found so far.

1) When you click the "Lock" command on the driver screen (or any other mean that triggers the lock action via HE), sometimes 2 events are sent to the lock in a short interval, sometimes just 1.

2022-10-20 11:05:06.862 info Yale YMF40A was locked via command [digital]
2022-10-20 11:05:06.830 info Yale YMF40A was locked via command [digital]

2) YMF40A supports 100 numeric codes and 100 fingerprints but in the driver "Current States" I have "maxCodes : 1", so it is impossible to use the "Set Code" command for any user other than 01.

3) When clicking "Configure" or "Get Codes" the following error shows up in the logs, and apparently the command fails

java.lang.IndexOutOfBoundsException: toIndex = 6 on line 179 (method parse)

I don't remember which one of the actions worked the first time I clicked, but it apparently fetched "correctly" 512 codes, then the error message mentioned occurred for the first time:

2022-10-20 09:32:06.499 error java.lang.IndexOutOfBoundsException: toIndex = 6 on line 179 (method parse)
2022-10-20 09:31:45.806 trace trying to fetch code:513
2022-10-20 09:31:45.805 info code:512 fetched
2022-10-20 09:31:30.731 trace trying to fetch code:512
...
2022-10-20 08:43:16.729 trace trying to fetch code:2
2022-10-20 08:43:16.727 info code:1 fetched

This problem might be related to problem 2 above, because there are only 100 password slots, but the driver is trying to fetch more than 500.

4) When unlocking with numeric code of any user (in this case user 11), there is an error in the logs and the status remains locked on HE, which is a very serious security issue!!

2022-10-20 12:51:08.297 debug descMap:[raw:catchall: 0104 0101 01 01 0040 00 9CF5 01 00 0000 06 01 0B00000000, profileId:0104, clusterId:0101, clusterInt:257, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9CF5, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:06, direction:01, data:[0B, 00, 00, 00, 00]]
2022-10-20 12:51:08.292 debug default response:[raw:catchall: 0104 0101 01 01 0040 00 9CF5 00 00 0000 0B 01 0689, profileId:0104, clusterId:0101, clusterInt:257, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9CF5, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[06, 89]]
2022-10-20 12:51:08.288 debug descMap:[raw:catchall: 0104 0101 01 01 0040 00 9CF5 00 00 0000 0B 01 0689, profileId:0104, clusterId:0101, clusterInt:257, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9CF5, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[06, 89]]
// I'm not sure if the logs above are related to the same unlock event, but I did nothing else in this period, so I'm including them here.


2022-10-20 12:51:05.340 error java.lang.NullPointerException: Cannot invoke method size() on null object on line 238 (method parse)
2022-10-20 12:51:04.526 debug descMap:[raw:catchall: 0104 0101 01 01 0040 00 9CF5 01 00 0000 20 01 00020B0000FABA181E00, profileId:0104, clusterId:0101, clusterInt:257, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9CF5, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:20, direction:01, data:[00, 02, 0B, 00, 00, FA, BA, 18, 1E, 00]]

Unlocking with fingerprint works, in this example with user 02:

2022-10-20 12:57:49.828 info Yale YMF40A was unlocked via unknown [physical]
2022-10-20 12:57:49.823 debug descMap:[raw:catchall: 0104 0101 01 01 0040 00 9CF5 01 00 0000 20 01 0402020000FABA181E00, profileId:0104, clusterId:0101, clusterInt:257, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9CF5, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:20, direction:01, data:[04, 02, 02, 00, 00, FA, BA, 18, 1E, 00]]

Unlocking with fingerprint, user 01:

2022-10-20 13:02:12.031 info Yale YMF40A was unlocked via unknown [physical]
2022-10-20 13:02:12.028 debug descMap:[raw:catchall: 0104 0101 01 01 0040 00 9CF5 01 00 0000 20 01 0402010000FABA181E00, profileId:0104, clusterId:0101, clusterInt:257, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:9CF5, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:20, direction:01, data:[04, 02, 01, 00, 00, FA, BA, 18, 1E, 00]]

From the received Zigbee unlock messages it is clear that the user/slot number is the third information in the "data" section, and apparently the method (code or fingerprint) is the first. It would be great if these infos could somehow be provided, like they are in other platforms. Also the "via unknown" part of the logs could be replaced with "via fingerprint" and "via code".

PS: I didn't know it existed so I didn't have "Lock Code Manager" app installed when all the info above was collected. All the logs are from the Yale device only.

Tagging @mike.maxwell

This is an issue with your mesh, not the driver, despite what the live logs state there is only one lock event committed to the database (check the events link at the top of the driver details)

Fingerprints?, as in actual fingerprints?

Its hard to say how many codes the lock supports, you're saying 200, the lock at one point said 512, which is what the device itself is reporting btw...

debug logging is the only place this error is posted, if you disable debug logging the "security issue" goes away...

The bottom line is that this driver was never tested with this lock and it isn't in our compatible devices list.
Checking Yale's site doesn't show the Zigbee module as an option (despite the fact that it actually fits in there)
I will reach out to Yale to see if they will send us an engineering sample with a zigbee module in it.
Without that there's little I can do here.

1 Like

This is an issue with your mesh, not the driver, despite what the live logs state there is only one lock event committed to the database (check the events link at the top of the driver details)

My mesh currently consists of Hubitat as Coordinator and 3 end devices, one of them being the lock itself. I have just plugged an XBee to take the following image, but it was not connected when I was testing the lock.

Also, since I'm testing and I want to know what is happening, my lock is speaking out loud what it is doing. When there are 2 log entries it is also saying twice that it has been locked.

Fingerprints?, as in actual fingerprints?

Yes, to use the physical fingerprint sensor on the lock.

Its hard to say how many codes the lock supports, you're saying 200, the lock at one point said 512, which is what the device itself is reporting btw...

I can get more logs if you need, but I think you might have read my initial post too quickly. The driver was still trying to get code 513 when it failed with the mentioned error message. I have the feeling that it would go "forever" if it wasn't for the exception thrown by the driver's own code.

debug logging is the only place this error is posted, if you disable debug logging the "security issue" goes away...

The problem is not only in the logs (it's an error message, not a debug one). The scenario is: I go to the lock and unlock it physically using a numeric code, the driver throws an exception, logs an error and the status in HE remains "locked".
So if in an unfortunate event that an unauthorized person gets a working code and unlocks the door, any rule that I might have created to warn me of that situation will not trigger. Dashboards show the wrong status and etc.

The bottom line is that this driver was never tested with this lock and it isn't in our compatible devices list.

It should work exactly like YMF40. The sales person told me it just has an improved hardware (fingerprint sensor notably).

Checking Yale's site doesn't show the Zigbee module as an option (despite the fact that it actually fits in there)

Probably different options for different markets, here is Brazil it is available, the same module fits on several Yale Lock models. I bought it together with the lock directly from Yale.

1 Like

Right, that ones not in the list either. Bottom line is this lock wont work with the generic driver.

It would be great if you could at least have a look into the 2 exceptions that are being thrown. It might be something silly, because it seems that it is close to working.

I have now removed it from HE and added it again. Tried not to use anything related to user management and at least in the first attempt I got a proper status update on HE when unlocking it with a code, despite not having the expected info message in the logs, just the debug ones.
But playing a bit more with it, soon after that I got the same 2 exceptions again.

java.lang.IndexOutOfBoundsException: toIndex = 6 on line 179 (method parse)

and

java.lang.NullPointerException: Cannot invoke method size() on null object on line 238 (method parse)

I could live without user management on HE, but without lock status synchronization it is impossible.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.