Just manually “delete” the value “0” from the devices in “setting” via the vera interface
Polling, unlike wakeup interval is not a parameter of the device. It is a parameter within vera. You don’t need to touch the device to do this. You can just go to the device/advanced/variable menu and change the pollsetting variable.
Polling is an initiative of the vera sending a packet to the device asking it to reports the state of its command classes. This is why the parameters are stored in the vera and not a configuration item within the device. (Unlike what the vera stupidly leads you to think when it asks you to reconfigure the device when you change this parameter in the UI, don’t do it that way. Just change the variable table and run a luup reload.
Wakeup is an initiative of a battery operated device, getting out of sleep state and sending a packet to the controller allowing the controller to either poll it, configure it, or just acknowledge that it is still alive. That’s why the parameter for it is in the device.
1 Like
@rafale77 Im having an issues with Neighbors not updating atm - I’ve tried individual device Neighbor Updates and whole of network Neighbor updates but im not seeing devices that have moved update.
one example is a Smart Switch 6 I had downstairs in my lounge room which I moved to the other side of the house and upstairs to the bedroom. It is working but I cant for the life of me get it to update its Neighbors.
any advice?
How did you determine that the device did not get update its neighbour nodes? The variable on the UI?
The neighbors list is stored in the device’ zwave chip and in the vera’s zwave chip. If it indeed went through the process, it should have its neighbours list stored there but maybe not be synced with the UI. On UI7 the network topology is managed by the zwave chipset and not by the vera software.
Note that You should also update the neighbors on the path to that device and actually, you may want to start from them first. What the vera actually reports matters little as long as the device works. The report on the UI relies on the vera getting the report back from the device after it is done and depending on how busy the network is, it is possible that it completely missed that frame or that it timed out, “got CAN’ed” itself when the response frame came. It would mean that the vera’s zwave chip would not have the neighbor data… or that you need to do luup reload for the vera software to read it.
Spending time looking at the zniffer with zway, I am able to see the hops and paths taken by frames and in spite of my large network, and long distances for some devices, I see that the preferred path is direct to the controller. It is only when this path fails that the devices look for repeaters. Out of 144 nodes, I have 2 devices relying of repeaters… Of course, much depends on how your house is set up.
This is a case, after such location change, where a couple of full network heal could be useful.
By going into Advanced / Variables and checking the “Neighbors” field.
That is exactly what I did (several days ago).
Many of my other z-wave devices show their Neighbors in the UI and they look logical. Btw I’ve never had anything but UI7.
Good! Then I wouldn’t worry too much about it if your devices in question all function.
What I would do is also to check that the devices around the location and further away from the location where device was still all work. I too noticed that it takes a ton of nightly heals for one to complete and a lot of time for the data to be published on the UI in the vera’s device data base.
I mentioned the UI7 thing but now I remember that it was more of a zwave firmware version change which drove the network topology to be managed by the zwave chip firmware instead of the vera software. By this what the UI displays really does not matter much. Also I did notice before I migrated that I had some newly included devices which had the same “problem” of not showing neighbors. I think it is either because they failed to report the result of their nnu or that they failed the process. Either way, it did not prevent them from working just fine. After migration, I just reran nnu on them and they showed their updated neighbors right away on zway.
I used your scripts to turn that stuff off ages ago.
Good to know.
I wish mine would update, it’s triggering my OCD! 
@rafale77 is your code embed now in the latest firmware please or we still have to run it manually.
many thanks for your post, it totally make sense to why Vera lag a lot…
Well then enable nightly heal and let it run for a week or so… This OCD thing is hard to cure!
The firmware enables and makes the code I provided effective. It is not embedded in it. The code changes the user-data so you only have to run it once and don’t need to do it again for future upgrades.
1 Like
where can i find the latest code to run please, and do i have to run them all?
appreciate your help,
Please read the first 4 posts at the top of this page.
I find this a useful summary as well Z Wave Network Healing · cdjackson/HABmin Wiki · GitHub
Cheers Rene
2 Likes
Thanks! After posting this thread, over the past few weeks, I have also learned quite a bit more about zwave from various researches on other forums and observing how zway works. I know more about why the vera struggles so badly with zwave.
Besides making the zwave network unnecessarily chatty, problem addressed in large part in this thread and by the new firmware, it also has very poor security support implementation paired with a shockingly and trivially absurd command queue logic. It is a domino effect of poor design decisions made on top of one another, every single one of them would have been bad but stacking them up, often one decision leading to the other, is what lead to this nightmare. There seem to have been too much pride to revert poor design decisions but instead to add bad patches over patches on top of patches. Very similar to what we observed on the UI with the unwanted plugins: Instead of deleting the functionality of force feeding/installing plugins, they added a blacklist for ones which have been deleted. This will for sure lead to other surprises, more things to manage, which will then require other patches. The wakeup nnu, nightly heal etc… same thing. These are bad ideas and should have been deleted from the firmware. The pause on a got CAN and the wait/timeout on the NONCE_Get flood. They are horrible and bizarre patches to problems which should have been addressed a long long time ago and these are only the ones I observed. I don’t know how many more I don’t know yet. Starting fresh is a better option for eZLO for sure.
3 Likes
so run
luup.attr_set("EnableNightlyHeal",1,1)
I think that should be device 0, not device 1…
luup.attr_set( "EnableNightlyHeal", 1, 0 )
3 Likes
Cheers, I don’t know much about LUA syntax.
“luup” calls the luup module which contains the functions
“attr_set” calls the function inside that luup module which writes an attribute
Then the parenthesis starts the argument field. “EnableNightlyHeal” is the name of the attribute to write.
the next argument, 1, is the value of the attribute.
the last argument, 0, is the device in which you want to write that attribute.
Just in case you wanted to know…
3 Likes
I like learning, so yes … thank you. 
1 Like
Hi,
This is the wiki documentation, but that does not say a reload is needed.
http://wiki.micasaverde.com/index.php/Luup_Requests#nightlyheal
However, in an alpha test thread the developer said it is not needed as the task is still scheduled, but not executed.