I have a Schlage/Allegion BE469ZP that has been working pretty well for at least a year or so. Suddenly, I noticed the node is dead and can’t be reached. After trying to ping the node, replace the batteries, restart/reboot home assistant, disable & enable z-wave, exclude the device, include the device, rebuild the routes, and factory reset the lock I’m unable to keep the node alive in its installed location. Save long-term testing, it appears things work well so long as I’m within range for secure inclusion, but shortly after I install it in the door, HA deems the node dead and I can’t get it to recover. Any ideas what changed and how I can fix this?
Oh, and I rolled back zw-js twice to 0.6.0 with no change.
Yes I know ‘used to work’. That said, That’s usually an indication you’re out of range of a repeater.
Also do you know if the devices it would usually repeat through are actually still working?
If it’s the ZP-Zwave Plus version of the 469 you SHOULD be able to pair it in place. What happens when you do that.
Also are you using builtin JS, or the JsUI or JS server addon?
Yes, there are 2 repeater devices it could use between here and there. While my z-wave network seems congested right now (commands are taking awhile to happen in reality) both are working.
Pretty certain it is, based on part number, but nothing in the supplied paperwork says anything about being Z-Wave Plus. Schlage Connect™ Smart Deadbolt with Century Trim, Z-Wave Plus enabled
Home Assistant times out without seeing an inclusion request.
Builtin JS - Z-Wave - Home Assistant
1 Like
Dang Scoob, I was hoping you’d say JSUI and you had a routing map. 
Yeh congestion isn’t good for these guys, I went through my network trying to eliminate as many S0 joined devices as possible trying to troubleshoot the problem I’m about to describe - but my ZPs seem (mostly) immune to the issues I had with the non plus versions.
Which yours sounds strikingly similar to the issue I had with my back door lock. But that lock is a non-plus (no ZP) 469. It kept getting orphaned on an island and refused to use the three wall switches RIGHT NEXT TO THE DOOR.
I don’t know what part of the black magic did it (I was frustrated at the time and just resorted to the sledgehammer) but I excluded the lock and every single device within 10’ and rejoined them all in order starting distance wise from the coordinator outward. When I finally rejoined the lock, moved it, then repaired routes to it (again - not necessary if it’s actually a zp) it finally stuck.
It led me to believe the routes to the lock were busted somehow but unfortunately I never figured out exactly what it was and it hasn’t happened again.
Interesting experience you’ve had there… It’s frustrating to me because z-wave is supposed to be so rigidly standardized that I expect it to just work, but more and more, I’m starting to really like Zigbee because of issues such as these…
I’ve used JSUI previously and I’m trying to recall why I abandoned it… Perhaps a migration is in order soon.
Well… my network map is… lets call it unexpected. There are things taking hops across the house and back again to the controller, going to their physical neighbor instead of the controller, just all kinds of strangeness.
Not being SUPER familiar with JSUI, is there a way I can clean this up manually?
Just curious, what makes you so confident you know the better routes than the devices?
That’s a fair question but, considering the layout of my house, I think the blue route makes a lot more sense that what the system had worked out on its own (green).
Since the z-wave devices have no idea of the above diagram or straight-line distances between themselves, how do you suppose they are working out the best route? Perhaps they are taking into account details that aren’t shown on your diagram?
1 Like
I dunno, man. I just know 1 hop is better than 3 and if another switch in the same switch panel is going directly to the controller, then something probably didn’t get negotiated correctly when the route was being established, regardless of the signal fidelity.
Back to my issue with the lock - I fiddled around and made it so none of my nodes have more than 2 hops and then included the lock again. This time it joined faster than it ever has and has remained alive for around 4 hours (8x longer than previously). I think this speaks to the issue @NathanCu was experiencing with his repeaters (although mine is communicating directly with the controller now) - there was too much chatter bouncing around for communication to happen effectively. Having a bunch of unnecessary hops in a network that communicates slower than dial up is certainly going to clog the network and cause packets to be dropped.
I’ll continue to monitor but I think combing the tangles in my network is the solution to my problem. Thanks for the suggestion!
2 Likes
Glad it was helpful. Keep going there was a point where mine seemed to break the logjam… Let us know what you find
Do you have logs from JsUI in debug about the time when it drops?
No logs - fortunately or otherwise, it hasn’t been marked as a dead node since switching to JSUI 
1 Like