Zwave Yale lock - YRD210

🎬 Get Started
21

I thought I would add my experiences here today that I went through with the YRL210. I did not succeed. I'll just get that out of the way right now.

I tried all possible combinations of the following:

  • Excluding the device with Hubitat (doesn't work)
  • Excluding the device with Ring (works)
  • Excluding the device with Zensys Tools (works)
  • Excluding the device with HomeSeer Z-Flash (works)
  • Adding the device with master code, #, 7, #, # (fails)
  • Adding the device with master code, #, 7, #, 1, # (fails)
  • Adding the device to Ring (works... from same location. No movement necessary.)
  • Adding the device from Zensys Tools from 1 foot away (fails S2 but joins insecure)
  • Adding the device from HomeSeer Z-Flash from 1 foot away (fails S2 but joins insecure)
  • Rebooting the hub
  • Repairing the Z-Wave network
  • Disconnecting all of the nearby nodes from power

I have performed all of the above steps in pretty much every combination they could be performed in. Of course I used just one type of action e.g. 1 exclude and 1 include method. I have literally been at this for 7 hours.

Given the fact that it can join Ring's hub instantaneously and that it can't join the hubitat USB stick from any software platform I think this is clearly not a hubitat issue. It's probably still a neighbor issue or something. However, I would love if somebody from hubitat could help me figure this out.

For the most part all of these Yale Real Living locks really only use two different Z-Wave devices, right?

Old AYR200:

New AYR202:

If we can figure out why they won't join we would be covering a lot of ground aka we'd have all of the level, button and touch Yale Real Living locks covered.

What else can I try?

22

The lock probably isnt S2, but using zensys and homeseer it didn't fall back to S0?
If it fails to join using S0 under zensys or homeseer, then there's something wrong with the device standards wise...

23

Are they allowed to do things off standards if it is certified? The log message just said joining device insecurely in both and it did so after hitting some time limit. I don't remember the exact message. Right now it's hooked up to the Ring hub but I will try it again with the USB stick and get the messages if you want. It didn't mention S0 specifically but I guess it could mean S0 if the developer of those tools considered S0 insecure. I just assumed insecurely meant without S0 though. I don't have any real experience with those softwares besides what I did today with them to try and troubleshoot this. If I can get more information from them let me know.

Also, since it's hooked up to Ring right now I can see that it is connected directly to their hub and it not going through any repeaters. I'll just dump what I can get about it from the Ring side.

      {
        "address": "${this_nodes_mac}",
        "fingerprint": {
          "extraVersions": [],
          "firmware": {
            "subversion": 32,
            "version": 72
          },
          "hardwareVersion": 0,
          "libraryType": 3,
          "manufacturerId": 297,
          "productId": 1033,
          "productType": 3,
          "protocol": {
            "subversion": 34,
            "version": 3
          }
        },
        "homeId": "${home_id}",
        "nodeId": 39,
        "reconfigureState": "idle",
        "routeSpeed": "40kb/s",
        "rssiTimestamp": 1557186434049,
        "signalStrength": [
          {
            "nodeId": 1,
            "rssi": -73.0,
            "status": "valid",
            "zid": "${the_id_of_the_neighbor_node}"
          }
        ]
      }

I omitted the values under zid, homeId and address because I don't know what you might be able to do with them against the private Ring APIs.

What I'm seeing under the certification doesn't match all the way what I'm seeing from the API though.

The cert says it supports S0 but not S2 like you guessed. Is it weird that the module is interchangeable yet they certified the lock as a whole and did it with all of the locks that use the same module?

I can also join this to ST if you want me to get info from there. It's reportedly working without any issue. I will probably confirm that next time I remove it from the Ring. My wife was getting frustrated with me though.

24

Insecure is insecure, ie not S0 or S2.
Standards compliant?, I'm not sure what that means in the end...

Thanks for trying, but that won't help, this is one of those devices that I would need in hand to sort out...

25

Oh boy. I just got my Hubitat and I'm about to move my YRD-220-ZW619 (from 2013) lock over from my Veralite. This topic has made me wonder if I'm better off keeping the Vera just for the lock. Is having two hubs an issue besides being really annoying?

I was also hoping to be able to set up the Yale to be able to arm/disarm the Hubitat via a code entry.

26

I have found that getting a couple (or 3 in my case for 3 locks) has significantly reduced and almost eliminated (only 2 days adding them so time will tell with settling down my mesh) the zwave lock issue. Plus Hubitat's driver guru (the guy in the post directly above) is working on this on their end as well.

27

I think you have to try it. You can always move it back to the Vera. :slight_smile:

I have a Yale (year older model) and it took some time and multiple attempts, but it did join. And has been 100% ever since. A good Beaming Repeater on a good mesh seems to be the recipe.

The Aeon Range Extenders mentioned are one of many Beaming Repeaters. I actually don't have one, BUT I do have 3 in-wall devices nearby.

1 Like
28

This! Yale guide specifically says 1 then # which does not work. Good catch.

I noticed you didn't mention hitting the number 1 key first in that menu. I tried this tonight and finally it paired secure doing this. It's the # key instead of a gear on my older lock but I just pressed it without pressing the number 1 key first.

1 Like