You said it can be necessary to make manual reboots during the upgrade, if that’s the case, how will i know?
Wait for 15 minutes. If the vera has not come back up yet, power cycle it.
aiight, i will give it a try! The link in the description, do i copy and paste that in the vera ui interface?
In the vera UI under firmware, you have a location for custom url for an upgrade. Copy and paste the url corresponding to your unit from @edward’s post I have linked above and click download.
Thank you!
It worked! Running 7.0.30 now 
Thank you
Before jumping to 7.0.30, what is the right way to estimate “chattiness”?
Rafale, again thank you. Do I understand correctly that you mean to return to your first posts in this item? I am having troubles to understand and find out what to exactly do/change in my vera and with the battery and/or not battery devices… sorry 
This is a tough one. One not so scientific or accurate way is to look at the size of your logs if they get rotated daily but I customized my log rotate script so it is already not behaving the same way yours may be. At the end of the day the best judgement to be made is how stable your network becomes: How often you get command lags, how often you get those ghost “device cannot be detected” and luup crashes.
Yes, look at the first 4 posts of this thread. I keep editing them to add more details and luup codes as well as correcting typos. I think it is better this way rather than have people scroll up and down the thread to find the information. I prefer to keep the top post updated as you folks request more info which I think are useful to the general community.
This is cool.
Am I right in assuming that your luup code above to make things more sane only works on 7.30?
Cheers
C
The lua codes all work but except for the poll settings, none of them will be effective until after you upgrade to 7.0.30. Meaning the variables will be set but the firmware will not be making use of them until you upgrade. Changes to the Poll settings is the only one which will be effective on 7.0.29.
1 Like
So pasting that (formatting excepted) into the test lua code should stop all my battery powered devices polling?
Sorry for going over old ground, I know you’ve covered this before 
C
Seems like I was not clear in my original post. I will try to make it better…
AC powered devices get polled. i.e the controller sends a query frame and gets a response from the device. This mechanism cannot work on battery operated device if initiated by the controller alone. In that case, polling becomes a response from the vera to the battery operated device when it wakes up. It is what vera calls the “wakeup poll” and this far can’t be disabled.
The luup code you pasted is disabling polling on AC powered devices.
Thanks, that was a brain fart on my part.
Is my implementation correct, though? i.e paste in the test luup code and hit ‘Go’?
Cheers
C
Yes it is! In the lua test code area of course.
1 Like
Updated the original posts with some more details and latest screenshot. Day 20 this is an absolute record uptime for any of my veras even with much smaller installations.
3 Likes
Im now running the Beta, but still my devices seems to be polled continuously. 2-3 devices still shows “Cant detect device” all tho they work just fine.
Same here. But I suspect the LUA code need to be run before this will change.
It’s very frustrating having can’t detect device as I control my lights via Alexa and 8 out of 10 times it doesn’t work. It works fine via the App or GUI.
I have ran the lua in the beginning of this topic, but still Cant detect device. Same problem here, i use Google Home and those doesent work by Voice but via app or switches.
Did you disable device polling in the zwave menu? What type of devices are still being polled? Did you extend the interval between wakeup of battery operated devices?
The Alexa control not working through voice but through the app or GUI is a cloud issue. It has nothing to do with what I discuss here. It has more to do with my other big principle of avoiding cloud dependance and in terms of voice control, killing all the “native” integrations and using local bridges instead.