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.
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?
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…
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.
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.
It’s been about a day now, and the graph keeps changing, but that doesn’t mean anything. 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?
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.
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…
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.