FAQ: why would I need another beaming repeater if my zwave lock is already close to my hub?

Hey guys, I’ve been scouring these forums for a solution and haven’t quite figured things out. I bought a schlage camelot door lock about 3 years ago and have always had trouble with unresponsiveness to a point I gave up…until recently.

I bought the aeotec range extender 7 and it doesn’t seem to have helped. I’ve tried resetting my lock, have unpaired and repaired several times, repaired my Z-wave networks at least 10 times and gave it a full 48 hours. Not sure if this is accurate but the routing on IDE has always reported that my lock is routing through my upstairs thermostat. The lock never wants to route through my extender which is about 6 feet away that I was assume does a better job repeating than the thermostat which is closer to 25-30 feet away.

When I remove the lock and bring it right next to the hub, it updates beautiful but can never get it working well when I put it into position. Any suggestions would be helpful and if I get this working, would be forever in your debt.

UPDATE: Now there is a way to tell if it’s routing through a repeater. See my post above for details.

If you think the thermostat is causing an issue (it’s been known to happen depending on the model and how it was paired with ST, usually it’s best to keep a C-Wire connected to the thermostat and then pair it and continue to run it using a C-Wire). One way to make it change it’s routing, turn off your thermostat or better yet, exclude it. Then pair your lock with the hub, check the routing tables and the it’s going the way you like it, then pair your thermostat. If you don’t want your thermostat to act as a repeater, make sure the C-Wire is disconnected while pairing it.

2 Likes

I have a Yale Conexis L1 Smart Door and doesnt matter what I do my front door will not use a repeater. I have a aeotec range extender 6 next to the lock (like under 3 feet)

Is Supports Z-Wave AES-128 Security S0 important in this case?

Keep in mind that changes to routes after a repair can take hours/days to shows up if your hub firmware is using 0.30 or earlier.
Starting hub firmware 0.31.x, which should be out in the next few weeks, that time should be reduced to a minute or so for the changes to show up in the IDE.

3 Likes

If my lock (Kwikset 910) does not show a entry for Route in the IDE, does that mean it is connected directly to the hub? My lock seems to work fine, so this is more curiosity than anything else.

I’ll note I have a Monoprice 27481 midway between the lock ad the hub, as well as a few older-gen Z-wave wall switches.

Hi folks, I’m struggling with my z-wave network a bit. As documented pretty much everywhere, you require beaming repeaters on your network for it to function properly. I have two zooz light switches that have the most up-to-date device handlers published to them. I also have a Yale lock right next to one of the switches (all z-wave plus). I’ve reset and added the switches and the locked multiple times, repaired the z-wave network countless times, and they all continue to route straight back to the hub, based on IDE. There are no hops in between. I’m running the most current hub firmware. I’ve tried to do it one at a time, for example: excluded all the devices, ran the repair, added a device at a time, with a repair in-between, and still routes are directly with the hub. At one point the lock routed to one of the switches, but when I added another device (dome water valve), and did a repair, the lock re-routed back to the hub.

Help! What am I getting wrong here?

The route listed in the IDE is NOT the only route used by the device. It’s just the last LOGGED route. ZWave devices do not only have one available route they know about all routes they CAN take… That’s why Zwave routing tables are usually expressed as a grid of available connections. If you’re trying to force the route to one specific device and see it in the IDE - you will be very disappointed. If the lock is working and a beaming repeater exists - stop.

So does the lock work?

3 Likes

Thanks for the quick response, Nathan. Well that answers my question. I thought I had been doing something wrong since the route within IDE was always showing back to the hub. My lock is working fine. I just wanted to make sure the network was working optimally.

2 Likes

Like others, I too could use some help. I have a Gen 2 Smartthings hub, and am trying to get my two Schlage Connect locks to work in a reliable way. I am using the RBoys device handler and LUM.

Summary

  • My original Hub position was about 15 feet from the first lock. Second lock is an additional 15 feet away. Both connect directly to Hub, despite many beaming repeaters (mostly all GE 14294s) in the area. Locks work intermittently, notifications sometimes are missing, and my programming of user codes is hit/miss.
  • I move Hub hub as far away as I can… three rooms away and about 55 feet from first lock. Several GE 14294 dimmers are within 5 feet of the lock (and more exist physically between there and the new Hub location). I delete locks and a few dimmers, re-pair them all (with lock being last), and then z-wave repair.
  • Some devices now show going thru one of the 14294 dimmers, but no matter how many times I repeat this sequence, the locks always show routing thru the hub. Now locks even less reliable (presumably because Hub connection is weaker?)

Any suggestions on what I can change, to get the locks to route via anything but the Hub? Am I doing the sequence wrong? Try different dimmer model? (these are z-wave-plus and show as beaming) Would V3 Smartthings Hub be of any help? Are these locks (despite expensive) just not that reliable?

Appreciate any ideas.

I’m sure that’s very frustrating. :disappointed_relieved: however, there’s going to be quite a bit of discussion and trial and error that doesn’t really belong in this FAQ thread.

Could you please start a new thread for this and then we’ll see about getting some people to help you with it. I suggest titling it “trouble communicating with schlage Z wave locks“ in order to get the most helpful replies.

You can create the new topic in the following section of the forum:

2 Likes

One of the key points to note in the 2nd post above is about Ghost devices in your mesh. These can, in some cases severely, disrupt communications, cause a slow down and negatively impact the reliability of the mesh. I would highly recommend start with removing ALL ghost devices in your mesh as described on this page. If you’re still having issues then as @JDRoberts suggested start a new topic and we can take the discussion over there:

2 Likes

Hi everyone,
@RBoy, hope you’re still doing the great work of helping the community.

I use the Universal Enhanced Z-Wave/Plus Lock Device Handler for my Schlage Connect (probably not the newest, 4-year-old version).
I’ve updated most of my z-wave devices to Edge drivers, and now I’m facing problems with z-wave range, like half of the lock commands delayed or lost. Maybe the problem is not related to moving some devices to Edge, I’m not sure. There are 2 AC plugged devices nearby (a FortreZZ siren and an Aeotec micro dimmer), both on Edge drivers now, and when I open my lock in the Groovy interface, the Route shows to be through a device, that is far away from the lock.
Does the route in Groovy interface wrong, or does it really skip the Edge devices when creating the route?
Is there a way to see the real route of the devices?
I assume the FortreZZ siren and an Aeotec micro dimmer should play role of range extenders. Am I right, or do I need another range extender?

Thanks in advance for the help

There’s an issue with the edge hub firmware. It doesn’t seem to work with FLiRS devices (battery operated devices which require beaming repeaters like locks and thermostats), there appears to be almost total one sided packet loss from the device initiated communication to the hub and limited loss in the reverse direction. Have reported it to SmartThings and awaiting their acknowledgement.
This isn’t happening with the groovy device handlers and only seems to be affecting edge drivers.

2 Likes

@RBoy thanks for the reply. I really appreciate it.
Do you think I need to change the dimmer and/or the siren to groovy device handlers? Do you think it would help? I don’t see any real advantages of Edge rn, so rolling back isn’t a problem. Is it enough to just select the device type instead of “placeholder” in groovy, or should I exclude/include them again?

Once a device shows “placeholder” in the IDE, you should no longer change the device type handler through the IDE or you can break communication with the device.

That’s because the IDE is part of the old groovy architecture and devices showing “placeholder” are using the new architecture.

So, yes, you have to remove the device from your account and re-add it to pick up the custom DTH.

Also note that once a device is using the new architecture, other information in the IDE, including the routing, may be incomplete or incorrect.

See the community FAQ:

FAQ: Why does the IDE list “placeholder” for my device? Can I change that?

@rboy, did you get a reply from Smartthings about the package loss from FLiRS devices?

If I understand correctly, we’ll have to switch to the edge drivers in the coming months, so the groovy drivers are not a solution anymore.

Thank you again for your help.

They’re looking into it but it may be an issue also with the default driver association groups for some devices. Specifically there are some changes required to the zwave lock driver for the FE599 lock that have been made but don’t know when it’ll hit production. I think there are more changes required which I’ve submitted to them for review.

@RBoy
As we’ll have to eventually switch to Edge drivers, I decided to experiment and converted all 3 mentioned devices (Schlage Connect z-wave lock, the FortrezZ z-wave siren, and the Aeotec micro dimmer, positioned nearby) to Edge drivers. Now the lock commands seem to be working rather well. I mean, when operating the lock manually, the locked/unlocked state is always updated in the app in less than 10 seconds (previously it wasn’t updated at all in 50% of cases).
The biggest downside is that now it isn’t using your DTH, so I guess I can’t use the 2 apps I used before: “Lock User Management” and “Schlage Lock Alarm Mode and Sensitivity Change and Monitor”.

Probably this question was asked/answered million times, but I couldn’t find an up-to-date answer.

Is there a way to have the functionality of those apps using the edge drivers?

@RBoy @maddie someone asked you a question.

I’m also looking to get my Schlage FE599 to an edge driver, in hopes of getting it more responsive, but it keeps going back to the groovy handler after exclusion/inclusion cycle. I have no custom DTHs, and I’ve tried going through the pairing with the “Scan for nearby…” route as well as “Select from list…” by brand, selecting “Schlage Keypad Lever, Z-wave”