I have an Ecolink door open/closed sensor that I’ve added to my z-wave network. When the sensor is within range of the controller, it works fine - I get “on/off” binary sensor state changes as expected. This should indicate that my configuration is ok and that the sensor is included in the network.
When I move the sensor to a place that is out of range of the stick, but still within range of multiple other powered z-wave nodes, I stop getting state changes in HA.
It’s as though the sensor can talk to the z-wave stick, but cannot route through any of the other nodes on the network.
I have tried “healing” the network many times, with no change. I have tried excluding and reincluding the node many times, and have done that procedure in the physical location that the sensor will go. No change.
I am stuck. Any advice on how to further troubleshoot?
This was how I finally got it working. One of the keys was knowing that the way to wake the device is to take the cover off, which puts it in a special wake mode for 30 seconds. Without this, anything you try will be useless.
The final procedure which got everything working was:
Before each step below, put the cover in place and then remove it, starting a 30 second window in which you can communicate with the device.
Start fresh. Remove the device, and include it with it near the controller. Wait for the device to initialize fully. Stop the z-wave network, to write out the configuration. Restart the z-wave network.
Run a heal on the network with the device still near the controller, and wait for it to complete. The neighbors of the device will not be correct at this point, but they will be good enough to start moving the device closer to its final destination.
Move the device where it can still talk to a neighbor in its current neighbor list, but closer to where it finally goes. Run a heal again. This should adjust the neighbor list again, hopefully picking up neighbors near the final destination.
Move the device to its final location, and heal again. This should give a final, true, and complete list of neighbors.
Replace the cover, to take the device out of wake-up mode, and into normal operation. Done. The node now works as expected.
Here’s some additional info that is hopefully helpful to future readers of this thread:
Z-Wave Plus devices support “network-wide inclusion” which means that devices can be included even when they are not directly in range of the controller, as long as they are in range of some wired node.
In contrast, Z-Wave (non-Plus) devices must be in range of the controller to be included.
A device will only try talking to its neighbors and won’t magically find new neighbors if moved, except during the heal process.
Most battery-powered devices sleep most of the time and only wake up on some interval plus when manually told to do so. Triggering a sensor is not the same as waking it up. Removing the cover is a common method, but the wake-up method depends on the individual device.
Given the above, if you have a battery-powered Z-Wave Plus device it is best to include it wherever you plan to use it, and not carry it to the controller for inclusion. This way the route to the controller will be configured correctly at inclusion time. If that isn’t done, or the device is Z-Wave non-Plus, then your procedure here can be used to move it around later. For a Plus device it might be just as easy to exclude the device, bring it to where you want to use it and then re-include it.
I’m experiencing the same issue here. Since I moved my Aeotec stick to another place - my furthest sensors lost connectivity with the controller I’ve done the procedure here, but cannot get them to work. It seems that healing process may only be initiated by the controller. I mean another non-battery powered device will not re-transmit the heal command to its neighbors. That causes the problem, that the furthest battery device will not know or report its current neighbours and won’t route through them
Question - how do you check whether a device routes itself via another device or has a direct connectivity with the controller? Can you check it in HA? I knwo about a Z-Wave graph panel, but it doesn’t seem to be reliable enough to show the real network structure.
Another question - is the routing table stored on a device level or only in the controler? I mean who decides how devices should talk to each other? The devices themselves or the controller? In case the routing is not stored in a device - then it seems the healing process must be executed each time when the zwave network starts. And in my case this is every 2-3 weeks after I update HA. Will I every time need to move the battery sensors around the house a couple of times and run healing? If so this is ridiculous. I expected z-wave mesh network to behave smarter and I’m disappointed here. Nodes powered from the electricity network can talk to each other, but seems battery sensors can only talk to the controller
You can’t, particularly with Z-Wave Plus. With that, summarising what somebody posted in the Z-Wave channel on discord, the way it works is:
Direct communication attempted
If that fails it tries via peers
A broadcast is tried
So yeah, the graph… is a vague hint of how things may work, possibly.
Depends on whether those are Z-Wave Plus or not, and how impatient you are. If they’re all Z-Wave Plus they’ll find their own way soon enough, but being battery powered that may be a day, or a week, depending on the Wake interval.
This is simply how Z-Wave works.
I’ve never done that, never needed to. Indeed, I haven’t run a Heal on mine in months. Sending a Heal command tells all the devices (and yes, that includes the battery devices, when they wake) to probe for neighbours and work out how to communicate to the controller. That takes time, during which everything is busy and unsure about routes.
The best answer is to stop moving things around, and leave the mesh alone for a few days, longer if you can. During that time ensure all the battery powered devices Wake.
Thanks for the info.
I’ve managed to resolve my signal range issues! It turned out that my Neo CoolCam plug for some reason didn’t really expand the mesh network, altough it should have taking its distance from the sensors into account. I’ve bought a TKB home in-wall mounted switch and it solved all the issues. It has fantastic range. All the sensors detected it as their neighbour and started routing through it! Even the NeoCC is shown as being routed through the switch despite NeoCC is much closer to the Aeotec stick than the switch.
So my faith in zwave mesh has been restored. Everything works flawlessly now. And restarts of the zwave network do not brake the connectivity. The sensors know they should talk through the swith. Great stuff!
I have the same problem as described in the topic, but with a keyfob which resides in my pocket. It works only near the controller. As it roams around the house it will constantly meet other neighbours. Doesn’t any repeater pick up the signal, recognize the keyfob is part of the network and forward it to the controller? Then a keyfob is absolutely useless ??
I’ve done the procedure here, but cannot get them to work. It seems that healing process may only be initiated by the controller. I mean another non-battery powered device will not re-transmit the heal command to its neighbors. That causes the problem, that the furthest battery device will not know or report its current neighbours and won’t route through them 
It turned out that my Neo CoolCam plug for some reason didn’t really expand the mesh network, altough it should have taking its distance from the sensors into account. I’ve bought a TKB home in-wall mounted switch and it solved all the issues. It has fantastic range. All the sensors detected it as their neighbour and started routing through it! Even the NeoCC is shown as being routed through the switch despite NeoCC is much closer to the Aeotec stick than the switch.