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.
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.
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: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)
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.
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.
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.
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:
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:
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.
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.
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.
