Absolutely not. I want something that works - I don’t want to “tune and fiddle”. These features don’t tend to do any harm, and they have definitely helped in the past. With the wide range of devices that are out there, in my opinion, on the balance of risks it is better to leave it enabled.
I’ve not really heard of any problems with the heal over the past 6 years that it has been running in the binding (and again, I exclude the present bug that was introduced recently in this!). Most people have it enabled (by default it is enabled, and I’m assuming most people don’t disable it) and we don’t have lots of complaints about it.
What I would expect if people disable the heal is more complaints that the network graph is not working, as the neighbour tables are updated during the heal.
That is an interesting thing I had noticed that the two were tied.
I was going to go and have a look but use zniffer so it does not add a lot.
I also have the extended send data hacked into a version and the extra info that returns to the app is also useful if I did not have zniffer recording and the node supports. Hey it all works so not rushing to change and I am no Java developer or fan of Java.
Just reread that. That is a very interesting observation.
If you have not run heal the routing is what the routing was when it was last running well. All that can happen is that through a series of fails LWR changes to something and in your case something not reliable.
So if you have not run heal how did the routing get in a mess?
So you have healed the culprits and now the LWR will settle to what works. If it does not you must be getting intermittent failures and LWR is hopping around or even finding brand new route using explorer frames because unless there is a bug in the firmware that is the only time it will change.
Now if you do not run heal again the only way routing will change is if explorer frames find things that are not in the neighbours list. The only other thing that can become LWR is based on the neighbours in the routing table so is not a change beyond the routing table.
Please could you keep your zniffer running and see how things work. It is the sort of thing I have been tracking but unfortunately my production network is behaving too well. It would be interesting what in your network is triggering the new less good LWR
I’ve no idea - I don’t use versions off the web. It’s from a couple of months back though. Heal is enabled.
It is almost certainly from before the change was made to the neighbour update. Unfortunately until the IDE gets fixed I’m a bit screwed with doing developments which is (to put it mildly) a little frustrating.
From reading this entire thread with the back and forth, I understand some more about how Z-Wave works, and I’m also more confused than ever, and I’m thinking that probably means I’ve understood correctly.
It still seems like more intelligence with regards to when to heal could be a good idea though.
And, at some point I should turn one of my sticks into a Zniffer.
I have an Aeotec Gen 5 stick with its jurassic never-changing firmware and annoying disco light, could that one be turned into a Zniffer since I will never use it in production?
jwiseman
(Mr. Wiseman (OH 4.2 Snapshot on Pi4))
53
I have the same thing and I’m interest in doing the same. I would buy another and connect it to a different box to not interfere with OH’s stick.
Your home and your setup is unique and what works for you is not always best for another.
The variables go on and on: materials in the building; the physical distances; the number of devices; the mix of devices; the electricity supply: the amount of reporting configured; the ratio of sleeping device and number of devices that have reporting and how often.
Is there even a quiet time on your network that can support the volume of traffic of a full rebuild? If there is not it is not necessarily going to do good things.
My advice is understand the specific issue you have before taking the medicine. If the network is not ill why does it need to be healed?
I don’t know. I believe daily heal is on by default in the binding, I did not specifically choose to turn it on. I could be remembering wrong, it’s been a while since I installed openHAB at this point.
Yeah, I believe you’re stretching that analogy too far. Unlike actual medicine, I don’t see how calling heal unnecessarily is going to cause heal-resistant future network problems.
Preventative maintenance is always a good idea. As I’ve repeatedly said, it doesn’t do any harm (at least it hasn’t for the past 6 years!) and it is required for older devices that have no other way to form routes. Therefore, on balance it is more likely to benefit than not.
Cool. I’ll create an issue about stateful heal intervals and hopefully some rainy day in the future after the IDE works again you’ll feel like writing the feature?
Thanks - I have to fix a bug in this area so will have a think about it when I’m looking at that. The big issue at the moment is that until the IDE is up and running again, development is somewhat difficult
Is there any difference between how heal is handled with battery devices versus mains devices. Since battery devices don’t route (because they’re mostly asleep), I’m curious about the benefit of regular healing for battery devices versus mains devices.
That’s not correct - battery devices are normally routing slaves. If they didn’t route, they would only be able to communicate with devices in direct range of the device.
From what I know of Z-Wave I’m guessing he probably meant that battery devices don’t route frames originating from other devices. But indeed, in order for frames originating from a battery-powered device to reach the destination, the battery powered device itself has to specify which path its frames will take, i.e. routing, right?
