If there are healthy routes to at least one node that can reach it then that would indeed get through if that node supports explorer.
If the RF is too far then no chance.
You notice in the zniffer it did not pick up the first and last hops to/from the controller. So no direct route from 1 to 54 so no way to 55 so no help from neighbours or any other basic routing attempts.
Sorry Colin way skirting around your issue. Relevant but tell us what your config is and what devices.
Personally I think it’s quite “dangerous” to suggest that people do this sort of thing as it is highly likely that devices will periodically drop out, leading to devices going OFFLINE periodically. This could happen due to weather, people moving around, cooking dinner - anything that impacts background noise or general propagation.
Yes, you might get lucky, but chances are it won’t be reliable, and an unreliable system is (IMHO) not a good one.
Sorry Chris I am at the opposite end on this unless heal is so great it predicts all these situations so makes your network better?
Nodes drop out because of heal not the other way.
Explorer is working all the time anyway so fixes transients which can be annoying but hey that is life.
No - of course not. However the point of establishing a 6dB link margin is to provide a reasonable level of reliability. You are saying that people should work around this and this will absolutely result in poor links.
I’m not saying that heal will help - I’m simply saying that it will identify that the link is poor, and if people desire a reliable system, they should respect these margins.
No - nodes drop out because the link is poor.
There is no magic cure to poor RF connectivity. That is an absolute and does not vary vastly.
There are two opinions
The ideal is get RF good and a nicely connected mesh.
Over this people need to choose their religion.
I did not expect to get to my shed with no link but it does and I have not healed the complete network for over a month. No dropouts no issues.
You like to heal.
No - you’re missing the point. My point is that you are advising people to bypass the mechanisms that ensure a robust network by not performing the neighbour search. I’m not saying that healing necessarily needs to be done every day, however it is there to detect network changes, and by not doing that you risk that your network will not be robust.
I just want people to understand what they risk, and recommending to bypass these mechanisms is not something that I would support.
No you misquote me again.
Sorry if I’ve misinterpreted your comments, but if I have, then others will likely have done so as well. I already see @Bruce_Osborne asking about bypassing the systems that we have to ensure a good network, and I just want to ensure that people understand the risk that they are taking.
I recommend that if people want a robust network, then they don’t try to bypass such checks.
I was just trying to get the terms clear in my own mind. Since the buffer is good to have, I will just need to handle that situation outside of Z-Wave like I did this year…
OK I recommend if nothing is broken do not heal.
If it ain’t broken why try to fix it.
I’m not going to go around this loop again 
I’ve already stated - things change - even if they don’t physically change locations or network. RF propagation will change and that may mean over time that link quality changes. This in turn may mean that the network topology could change.
Such issues are well known, and in my professional life I have an awful lot of knowledge about RF communications systems.
You are of course free to do what you like - I’ve provided many options in the binding to allow people to configure things as they see fit. However I’m also recommending how the majority of people should operate to try and provide the best network possible.
Yes, to have a house that large 
This case and a couple of issue people had with single nodes makes me wonder if it’s (easily) possible to implement a partial network heal, i.e. zwave things to be assigned a new parameter to mark them as either to be healed (standalone but automatic once a night) or to be left out of a general network heal. Today we only have the option of all or nothing. @chris wdyt?
There is also per device healing.
Yes but that’s manual, isn’t it.
You would not say that if you saw it. Built 1600s and it has been slowly falling down ever since.
You can use the REST API to heal a Thing…
curl -X PUT --header "Content-Type: application/json" --header "Accept: application/json" -d "{\"action_heal\":true}" "http://localhost:8080/rest/things/zwave%3Adevice%3A55555%3Anode5/config"
FTR, you can also use this approach to force a node to be reinitialized. This can come in handy when the HABmin UI won’t let you do a reinit (because the node has not yet completed initialization). Just change the action_heal to action_reinit.
curl -X PUT --header "Content-Type: application/json" --header "Accept: application/json" -d "{\"action_reinit\":true}" "http://localhost:8080/rest/things/zwave%3Adevice%3A55555%3Anode5/config"
Is that like deleting & rediscovering the Thing?
No. It does the same thing as selecting Reinitialize the device on the HABmin menu. But, HABmin only lets you do this if the node has completed initialization. In the past, I’ve had reasons to want to do it before initialization has completed.