Yale Zwave YRD210 and YRD220 Deadbolt locks not discovering

[T_J]

I am trying a fresh install of OH 3.0.2 on RPi 3 and am running into problems setting up 2 different models of Yale deadbolts.

I can find them in the database here: YRD210 and here: YRD220

The things discover as ‘Unknown Device’ named “Z-Wave Node 028 (0109:0004:0000:25.24)” and “Z-Wave Node 021 (0109:0002:0000:25.24)”.

Notably, the manufacturer code appears to be a mistake (in the lock!) appearing as 109 instead of 129 (as noted in the z-wave developers guide here..

I can get the doors to lock/unlock if I do a text configuration in a .things file like the following and adding to the model.

Bridge zwave:serial_zstick:9ec17a59 "ZWave Controller - Manual Things File" [ port="/dev/ttyACM0", controller_softreset="false", controller_master="true", heal_enable="true", security_networkkey="F8 BB CC 06 D2 1E D1 72 84 E7 71 E6 E2 57 6D F8" ]
{
    yale_yrd220_00_000 manFrontDoor "Z-Wave MAN Front Door" [ node_id=21 ]
    yale_yrd220_00_000 manGarageDoor "Z-Wave MAN Garage Door" [ node_id=20 ]
    yale_yrd210_00_000 manPatioDoor "Z-Wave MAN Patio Door" [ node_id=28 ]
}

Not sure where exactly my troubles lie - is it in the manufacturing ID mismatch?

Any advice much appreciated. Though I can lock / unlock the doors using the manually configured thing, the door lock status reporting / alarming does not appear to be working yet. If I manually unlock the door, I don’t see the status update / alarm.

[Bruce_Osborne]

Perhaps they can only be included securely.

That means you need to factory reset the lock. The secure inclusion process must be completed within 15 seconds and can only happen with a freshly reset device.

[T_J]

Thanks Bruce. I tried an exclude, factory reset, and (secure) include to be sure. Same result. I don’t think it’s a secure inclusion problem as I was able to lock and unlock the door if I use the text .things file. Also, I can see in the unknown device Thing Properties that zwave_secure is ‘true’ and it has returned a set of User Codes in that properties page from the lock.

I turned on zwave debugging and do see the inclusion process, including:

2021-05-25 07:02:47.308 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 37: Manufacturer ID = 0x109
2021-05-25 07:02:47.309 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 37: Device Type     = 0x2
2021-05-25 07:02:47.309 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 37: Device ID       = 0x0

and

2021-05-25 07:02:59.182 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Unable to find thing type (0109:0002:0000:25.24)
2021-05-25 07:02:59.182 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Controller status changed to ONLINE.
2021-05-25 07:02:59.183 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 37: Controller is ONLINE. Starting device initialisation.

leading me to believe the Yale Lock (in this case a YRD220) is not in the database under manufacturer ID 109. I am a relative beginner at this stuff, but would it be OK to submit a copy of that lock in the database to a different manufacturer ID? Attached is the XML file for my YRD220 for reference.
network_f3b1b8c8__node_37.xml (77.4 KB)

[Bruce_Osborne]

It is here.

ASSA ABLOY YRD220

@T_J

I was able to lock and unlock the door if I use the text .things file.

I have never needed to use a .things file and it is strongly discouraged due to being prone to errors.
@chris may best help.

In the mean time, perhaps the log viewer can help you decipher the logs.

Z-Wave Log Viewer

[chris (Chris Jackson)]

@T_J

I was able to lock and unlock the door if I use the text .things file.

This indicates that you have a configuration issue somewhere. The binding doesn’t know that you have used a thing file, or the UI to configure the system - it just gets the configuration from the core.

My guess is that your device is a rebranded device and therefore you will need to add a new database entry. Manufacturer 109 is Vision Security, and there are other examples of this.

It’s also possible that the device is just poorly discovered due to a comms error, but this is unlikely. If you want you can remove the XML for this device and it should download this data from the device again. If it is still 0109 for the manufacturer, then it’s almost certainly correct and the database will need to have an entry added for any new device.

[T_J]

Thanks Chris. It does remain 0109 for the manufacturer on 3 locks, so I’m pretty convinced it’s not a comms error – Also, I note from the Yale manual:

*Please note:
ASSA ABLOY, the parent company of YALE, was originally assigned a manufacturer ID of
0x0109. This ID was assigned in error and a new ID, 0x0129, was recently issued. All locks
currently being manufactured are using this new ID; however there are locks in the field using
the former ID.
It is important that all controllers perform the following check to determine whether or not the
lock being included is a YALE product:
IF manufacturer ID = 0x0129
Lock = YALE Lock
ELSE IF manufacturer ID = 0x0109 AND Product_Type_ID < 5
Lock = YALE Lock
ELSE
Device is not YALE product

I put in the ticket to request update access. I’m sure there are a few of these out there still.

[Bruce_Osborne]

@chris

. If it is still 0109 for the manufacturer, then it’s almost certainly correct and the database will need to have an entry added for any new device.

Sorry I misread as 129 instead of 109

[T_J]

No worries - and thank-you for the pointer to that log file analyzer. It’s really good!

[Bruce_Osborne]

@Barth3254

Everything was going great until I got to my Yale lock

It is unclear to me what type of issue you are experiencing. If you have an issue and are using the zwave binding there are no DEBUG logs as instructed in the binding documentation.

How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community

[T_J]

For the record / help to future readers / potential help for Barth, I did get both of those types of Yale locks working with OH3 (which were bought in 2013).

I submitted two database additions for the Yale locks under manufacturer id 109 for future people by following the instructions here:

https://www.opensmarthouse.org/blog/zwave_device_database_guide

I was able to test those entries (and have left them in place…so far so good) by installing the z-wave binding to the addons folder and adding the new entries to the .jar by getting the .jar file here:

https://openhab.jfrog.io/artifactory/libs-release/org/openhab/addons/bundles/org.openhab.binding.zwave/3.0.2/

and following the instructions here:

Modify a zwave binding jar to add/change a zwave device while waiting for a build

**PLEASE don’t use this without also updating the device database! As a community, we make the most progress when everyone contributes!** I’ve seen several posts where people have made changes to the device database and they were eager to try out their new shiny gizmo, or wanted to test a change/fix an issue, before it was included in a build. Here is a method to update the zwave jar with a modified device Thing definition, without having to use an IDE to modify and compile the jar. This method…

My second issue was that the lock status was not initially reporting. i.e. If I twisted the lock with my hand, I didn’t get a zwave indication of that. This was fixed by adding the controller to the Alarm Reports association group in the Thing configuration section. I now see the alarm_raw signal come in on status change.

Thanks Bruce and Chris for what you do!

[Bruce_Osborne]

@T_J

This was fixed by adding the controller to the Alarm Reports association group in the Thing configuration section.

Did you also change that in the database entry? (the controller checkbox)

[T_J]

I copied from the Yale entry in the database - which sets controller to “True”.

It didn’t seem to be checked off in the configuration screen by default, though, under “Association Groups”. I have very little idea if this is normal, but it fixed it when I checked the box.

[Bruce_Osborne]

Your database entries have not yet been approved & exported to the binding so you would not see it unless you updated the database entry & exported the xml again.