ZwaveJS routing through battery powered locks?

Hi everyone. I am the last stages of completing a migration from Homeseer to Home Assistant. The last bit is migrating the Zwave network. As recommend in some discord chats, I successfully managed to move the stick from Homeseer to ZwaveJS without having to exclude and pair everything again.

This is very important because I have 5 Yale YRM476 zwave locks that are in doors and very hard to move! I had originally paired them by taking a Rapsberry Pi with the Zwave stick on it around close to each door and pairing it, but the ZwaveJS documentation says explicitly not to do this.

While my Homeseer network was fairly reliable, I am having a lot of problems with some of the nodes in Home Assistant. The topology graph is showing me several odd things, such as using the Yale locks as routers. I have moved some repeaters around, but even though the node shows neighbors that are not the battery powered locks, often times devices (according to the graph) are routing through them.

Here is what it looks like now:

Is the graph actually accurate? Also, the nodes that are grayed out still seem reachable. In Homeseer I had speeds for the links as well when debugging the topology. Is there a way to get that out of ZwaveJS for each link that is active?

Thx!
mike

You cannot do that. Locks require secure pairing and the encryption key does not exist on the stick, by design.

Perhaps you can move your HA system closer to the locks? Also, pairing needs to be done from a factory reset condition and completed within 15 seconds according to the standard…

I copied the network key from homeseer and it worked fine. I have secure pairing for the devices - that all worked out fine.

I can actually interview 4 of the 5 locks and control them easily. The 5th had issues with connectivity.

Mike

No

Not yet.

Side note: No battery powered zwave devices will route, they only consume and do not bolster the zwave mesh. Only mains powered devices will route.

1 Like

That’s what I thought. But why does the graph show what it does? How can I get a accurate read of the routing?

It’s doing a comparative list on the node’s neighbor listing, it has nothing to do with the actual routing at all.

At this time you can’t, unless you setup a zniffer (zwave sniffer).

Why have a graph at all it’s doing is misleading you? A table that shows all the neighbors would be more useful.

HA is so much better that homeseer in almost every way, but this is way worse than homeseer in terms of zwave support.

Did the older open zwave have better diagnostics?

No.

From what I understand routing/RSSI/speed/etc is on the zwavejs roadmap. Give it time.

Why have a graph at all it’s doing is misleading you? A table that shows all the neighbors would be more useful.

How would a table be more useful? It would show the exact same information as the graph does, the node neighbors. I would agree that the graph isn’t useful, which is why I ignore it, but lots of other people love pretty pictures.

HA is so much better that homeseer in almost every way, but this is way worse than homeseer in terms of zwave support.

You’re comparing a commercial software that has existed for many years, vs. a free project that has only existed for a few years, and has only seen wide usage in the last year. Not to mention, an integration that has only existed for 5 months. Not exactly a fair comparison.

Have you tried a network heal yet? When you move things around the controller gets confused about the routing. For example, when you paired the locks right next to the controller, it thinks it’s in direct range of the locks. When you move the controller back to its permanent location, that may not be true any longer and the routes will be mis-configured.

I have. I am having trouble with one of the locks that is on the other side of the house than the controller and other locks and zwave devices. I have pretty much converted to zigbee for everything that I used to use zwave for - zigbee is a dream compared to this craziness! If it wasn’t for the yale locks, I’d dump zwave completely.

Right now I am trying to put enough zwave switches in outlets to extend the network reliably to the lock on the other side of the house. I did a network heal, but that last lock still doesn’t work, even though it shows as connected on the network graph.

I guess I have to keep trying plugs in different spots to get closer to it and see if I can get it to be stable. This all used to work fine before the conversion, so I am not sure what is happening.

thanks everyone for the help.

I believe the individual devices determine their routing much as Wi-Fi clients determine their association. It can only be observed when the device is actually routing. A zniffer is likely the only way to do that.

How long did you wait> I have found that, due to device wakeup, some battery operated devices can take hours before they are dully interviewed. the zwavejs2mqtt control panel shows the interview status of each device.

Locks are a special case, they are battery operated but since they use FLiRS they don’t really “sleep” like a normally battery operated node.

It’s been about a day now, and the graph keeps changing, but that doesn’t mean anything. :slight_smile: Still no connectivity to the one lock. Interestingly, when I look at the “all neighbors” view in the graph, the BBQ gas valve reports only one of the locks as a neighbor, but it works just fine and ping responses come quickly.

Does that mean the actual neighbor info on the graph is wrong too, and not just the path that is supposed to be being used?

You might need to do a network/node heal to get the lock to update it’s routing.

I did do that, that’s how I got to this off configuration:

This is supposed to be showing all neighbors. But look at the BBQ gas valve. It looks like it has no neighbor except the Poolhouse Door lock (when I mouse over it, it shows only the poolhouse lock as it’s only neighbor). But battery devices can’t route, and yet the BBQ gas valve works just fine.

So either I am missing something or the neighbor information being displayed by the graph is just wrong, even at the neighbor information level.

Is the zigbee support for Yale locks decent? If so, I may just replace all the modules with zigbee ones and get rid of zwave completely. It makes me waste a lot of time debugging all this.

No idea, I haven’t a single zigbee device.

What’s the actual problem you’re having?

Sorry, getting the last yale lock on the other side of the house reliably connected via zwave. All the other devices are pretty close to each other. But I can’t seem to figure out how to put enough switches between the lock on the other side of the house and the controller to get connectivity to work.

If I could tell link strength and routing, it would help me get the network extended out to the remaining lock. It’s a larger house, and the construction seems to block zwave signals - maybe steel beams or ductwork etc…

Hard to say for sure right now as that information isn’t available unless you setup a zniffer.