I wondered what is going on. I just installed an older Schlage FE599 keylock. I have lots and lots of Zwave devices in the house, but had trouble pairing the FE599 to the hub.
Because the doorlock is difficult to install, I actually removed the door tonight and carried it next to the hub. When it was only a few feet away, it paired on the first try.
I then moved the door back to its location, but I can’t control it even though I have several Zwave wall switches very close by.
What does it mean “Zwave beaming?” What kind of repeaters will carry the Zwave signal from this Schlage door lock?
There is a community FAQ specifically on locks, I suggest you take a look at that. It also mentioned some specific issues that people have with older Schlage locks.
As far as beaming repeaters, pretty much any mains powered device released from 2020 on will support beaming. If it’s Z wave plus supporting S2 security it almost certainly supports beaming. Most of the other newer devices do as well.
The lock FAQ also explains how to find out whether a particular device supports beaming or not.
Hi - Quick question. Now that the old SmartThings API (see first link below) was replaced by My SmartThings (second link below), where is the best place to go to heal the network?
I used my Android SmartThings app on my phone to do it last night. It took 1 1/2 hours to complete. I have 25 devices that I set up over the course of 3 days and I had to move the hub all around the house to get many of them to work, so I am sure there was a lot of “healing” that needed to be done.
The problem with using the app on my phone is that it basically just looks like it is frozen and does not provide any information to indicate if it is working or to tell you which devices pass, etc.
I want to perform the procedure 2 more times as suggested above, but I would prefer to use a more robust tool, provided that one exists now that SmartThings is on edge drivers. I do not see a place to do it in the My SmartThings beta app.
Repair is a utility that runs on the hub itself, so it shouldn’t matter where you start it from, and at this point, most people seem to be just running it from the app. See post 31 in the following thread.
I haven’t pinned down how that works yet. I wouldn’t be surprised if it requires one of the various OAuth scopes that doesn’t get offered to developers or end users. The CLI seems to have its own private scope so might be able to do it in time, but otherwise they might consider it to be in the remit of the official client apps.
There is also the issue that while there is probably a ‘start repair’ command, that it may or may not be possible to use, there probably needs to be something listening for events as they come in.
It can be slow. If you wait long enough, eventually you’ll see errors for any devices that failed to update, and a “repair complete” message at the end. I’m not sure whether you’ll still get those if you leave the app and return, or if your Android device goes to sleep. The old way of doing it in the IDE certainly offered more reliable / visible feedback than we get now.
Yes that makes a lot of sense. I suspect I lost the error messages because I left and app and/or the phone went to sleep multiple times during the 1 and 1/2 hours that it took to complete. Surprisingly, I did get a “repair complete” message at the end. Next time I run it, I will set the screen timeout to the max (albeit the max is only 30 minutes) so I guess I will need to make sure to touch the screen periodically assuming it takes 1 1/2 hours again.
It may have taken longer the first time since a lot of your devices will have lost their original connection as you moved the hub from place to place. 25 isn’t a lot of devices - if they’re all communicating now, a I would expect it to take <15 minutes. They may not have produced any error messages on the first go-round either, if your mesh has good connectivity throughout.
