My understanding is neighbors and routing are 2 different things in Z-Wave. I have seen devices work while displaying no neighbors on a map. For me, the map is just a curiosity.
The graph is really useless. They should remove it until they manage to make it represent the true routing situation or it will only confuse people. Just ignore it.
Thereās one point I donāt really understand. So you moved from Homeseer to HA. I assume the network worked fine in Homeseer, including the fifth lock ? Did you physically move anything around at all or reincluded any device after the transfer ? Because if the network was fine before and you simply moved the stick over to HA without touching the network topology, thereās no reason it should suddenly break. So maybe this is a bug somewhere in the HA zwave integration or zwavejs rather than a physical problem with signal strength or mesh connectivity.
Fully agreed but I do not think there is a good way to get the routing information. openHAB has a similar useless chart.
Thatās not how zwave works. A fully setup stick will not be plug and play when switching softwares because a large amount of the settings are cached in the softwares. In order to get these settings to a new software, actions need to be performed by the user. Every device is different, so these actions will vary per device.
As for the graph, itās not supplied by HA, itās supplied by ZwaveJS2MQTT. If you wish for it to not be displayed, take it up with them.
1 Like
This is exactly how zwave works. The low level mesh topology and message routing is entirely managed by the controller stick and the source nodes it communicates with. The controller driver, Homeseer, zwavejs, ozw, etc, are not involved in this part of network control, other than some high level management functions and queries over the zwave API. The routing tables are stored in the stick nvram, as are node associations. In fact, you can view the actual real node routing by plugging your stick into your PC and running the Silabs diagnostic tools, which will read the mesh routing data out of the stick.
When you change controller applications, this routing will not change unless you start including / excluding new nodes. A heal can also readjust the mesh. If a mesh was functioning with one controller application, then it will function with any other because the mesh topology is handled by the controller hardware and the firmware inside the Silabs chip. So if the OPs fifth lock was visible and functioning with Homeseer, then this means that the mesh topology was intact (although maybe not optimal) and the node is physically reachable either directly or over repeater nodes and that a route was established to it by the controller. If it stops working on HA, then the either something changed due to a manual include / exclude operation / physically moving nodes or there is a problem with zwavejs or the HA integration. The former case should be fixable with a network heal.
The reinterview process a new controller application performs after moving the stick to a different system queries node data that is typically only available at node inclusion time and may not be entirely stored in the stick. None of that data involves the mesh topology. In fact, a lot of data can actually be extracted from the controller nvram directly, but is not by current open source zwave implementations. A lot of commercial controller drivers do, for example, support node inclusion by physically moving the stick and doing the inclusion on the stick itself. The data is then later read out from the stick.
I suggest you read this post at the OpenHAB forums to learn the basics about how zwave manages routing. The official zwave API specs are also a good read, specifically chapter 3 describing the Zwave protocol layer, the routing principles and the application layer.
Or the HA stick could be located in a different location than the Homeseer hub.
Reinterview is is part of the actions I was talking about. I understand how it works and donāt need to read it 
. Your previous post made it seem like it would be seamless without a reinterview on the new software which is not true.
It was actually located in the same place. It may have actually worked, but I made the mistake of looking at the network graph just after importing everything into ZwaveJS and started doing chasing my tail on why the routing was so messed up and tried to move things around beacuse the graph showed a bunch of things as not connected
I should have pulled up the debug window and checked them manually instead of using the graph. That was my mistake!
Now that I know the graph is useless, I ignore what it says, but the topology is certainly messed up.
1 Like
If you think your network mesh is messed up a network heal may help or jus heal the devices you think are messed up.
I have done a couple network heals, but the one yale lock is not pingable. I need to move things around I guess to try and give it better signal.
I do have an old 500 series stick, and it may just be easier for me to get another raspberry pi and set it up with another zwaveJS instance and fix it that way.
Ouch. Before restarting from scratch, did you try to move all devices back to their original physical location, especially repeaters, and do another heal ? Considering your original mesh worked, your lock would have had signal coverage with the original setup. Then again, locks are complicated.
Maybe you should, itās still good read 
As heyImAlex said, that should still work without moving it.
Secure inclusion does require a fairly strong signal.
Iāll give it a read later. Iām sure thereās something to learn from it.
What annoys me most about zwave is that companies donāt always follow the standard so this kind of stuff happens on a regular basis
1 Like
Itās much harder to break things this way on zwave than on Zigbee, for example. The strict certification process helps a lot and also that on the low level protocol handling side, everything is guaranteed to be the same regardless of manufacturer. It doesnāt mean that some bad apples wonāt slip through, but Iād bet a beer on the fact that most of these problems are due to bugs or unsupported features in open source zwave implementations.
Zwave used to be a one company (silicon labs) spec, so conformity should be easier. That said, my experience is that zigbee routing is 10x better than zwave, and I never heave to deal with graphs that are wrong and routing that is unclear.
I have had to tweak device specs very rarely, but the network in zigbee has always been very reliable for me. Devices seem to be a lot cheaper too - zigbee is much more common in the world than zwave is.
I used to have all my landscaping lights controlled by zwave, and the network would get into strange situations from time to time and response was slow or not working. I scrapped all that, and replaced it with zigbee power strips with 4 outlets on them, and things have been super reliable, even at distances that were greater than zwaveās.
The only thing left for me are the zwave locks and a valve controller, and a WD200+ switch (the wall switch functionality is better in zwave than zigbee). Everything else was switched over to zigbee (I do use Lutron for most of the house lighting).
Maybe Iām just lucky, but I never had any issues with my fairly extensive zwave network. I think itās the most stable and reliable part of my entire home automation setup. If Iām not in the mood for tinkering and want something that just works without headaches, I usually grab a zwave device.
But hey, thatās the advantage of having several standards. Use whatever works best for you 
Oh and the graph thing is not a zwave problem. The official zwave API has a function to retrieve this data from the stick. zwavejs just doesnāt use it (yet).
Not all of the official Z-Wave Plus v2 specifications have been publicly released. Last I saw SiLabs was having the zwave alliance do that.
BTW, I went over to the zwaveJS-MQTT github site to report a bug on the network graph, but they have a checklist for reporting bugs, and if you are running home assistant, that fails their checklist, unless you have been told to post there by a ādeveloperā.
So it looks like complaints are supposed to be filed here and not there. Not sure what I should do in terms of reporting how bad the network graph is. My bet they donāt get a lot of bug reports if they are asking people who run home assistant to not file there.
See their text:
Checklist:
- [ ] I am not using HomeAssistant. Or: a developer has told me to come here.
- [ ] I have checked the troubleshooting section and my problem is not described there.
- [ ] I have read the changelog problem was not mentioned there.
The checklist is to help triage bugs related to Home Assistant to the Home Assistant project. Obviously, the graph has nothing to do with HA and when you are using the graph you are not using HA. You can check the box if you want, or not. It doesnāt prevent you from submitting a bug.