I have the same Qubino devices, and works perfectly.
It sounds like you have other problems… and that your network mesh is somewhat broken and this could have been because of a failed nightly heal. Yes, the heal can break your network if abused and not used properly. See if the other issues get resolved first. As I said, none of the setting changes I made can possibly alter the instant status report which is a feature of the device, not one of the controller.
I hope this time vera support is able to help and pin point…
Still struggling with this. My FLiRS thermostats have “Poll this node at most once every” set to 0 (never poll), but I just caught one if them saying “Polling Device!” and shortly after “Timed out waiting for the node to reply”, with “Can’t Detect Device” as a result. I can understand that the timeout could happen due to the network being too busy, but why is Vera still polling, even though polling is set to 0?
Please Read my first 4 posts. The settings you changed as I described above doesn’t do what you expect. I provided a code to dsiable non battery devices polling.
Edit: I updated the post 4 with my new record uptime with the vera… over 23 days in production with 144 zwave nodes and 11 zigbee nodes bridged to both openLuup and homeassistant.
I did my best reading it, but must be misinterpreting this scentence? “You could do it manually for your FLiRs too by changing the “PollSettings” variable to 0.”
Changing what I did does indeed result in PollSetting = 0:
And for the other part in the script, I figured that PollNoReply does not impact polling, but is impacted by failed polling.
Did you reload luup after the setting change?
Yes … (the PollSettings has been set to 0 for several weeks, since your first posts)
I see… sorry I didn’t know that. This disables the “interval” automated polling the vera does. It doesn’t disable the device specific polling which is sometimes needed and embedded in the vera device specific code and is event based. For example, the vera may need to poll the device after a command to change temperature or change mode on the thermostat because the thermostat may not update status based on the device firmware. I have this for my locks for example. It’s the only polling which occurs to AC powered device and are correctly set by vera. Otherwise the vera should stop it’s polling. You could also try unchecking the “poll nodes” check box under the zwave menu if you have not done so. I had mine disabled for years and was still observing polling.
Thanks, that was still enabled. Didn’t dare to mess with that … But “funny” setting there: “poll a node every 30 seconds” … Anyway, disabled it now. Lets see what it does
and then of course …
Must be the other option then … hardcoded somehow.
the key is to figure out why the thermostat is either not responding to the poll command or the vera is not getting the response. When you manually poll it, does it go away?
No, manually polling fails as well…
From the device’s advanced/command/menu correct? Just trying to make sure…
If that’s the case you have a network range problem or a device problem. Have you had this problem for long? Does it update temperature correctly otherwise?
Yes, from that many, thanks for thinking with me.
And yes, the polling is a problem I (and others) have been having with this device, I think forever (see here, for those interested). Although the device works for the most part, I’ve figured that the device is not fully compatible and had actually given up on the polling. From this thread I had hoped to disable the polling, so that at least I got rid of the error message. Now especially, since it’s not possible to set temperature through Google Home if the device is set to failure .
I would have to dig in the logs and with verbose to see what is going on. Maybe ask support or submit a request for device compatibility. There are exotic zwave implementations out there. The polling is reasonably standard but it is also possible that your device is not replying the way the vera is expecting, causing all these problems. That being said, with these settings, there should no longer be any interval polling. There should only be event triggered polling.
After 25 days of uptime on the beta, I decided to upgrade to build 4833 given what I have observed with the extroot tests and the squashfs comparison, it appears that the changes for that segment alone is minor and most of the problems are likely in the kernel. So I am all reset. The level of performance and stability improvement observed is still quite stunning. On this last test, I never incurred a single luup reload in 25 days and it is the second consecutive test with 20+ days of luup uptime.
Oh so you give me 4833 while you’re on something else!
I have several units… I was on 4833 on my test unit and have been working to both extroot and find a solution whereby the Xmas light mode does not appear… Sad to say that I can’t reproduce it so far on the vera plus with the network monitor running with the old kernel… I am now fairly certain that the kernel is the source of the problems.
I’m actually curious about the set ups that some of you guys have. Do you have like devices of sensors lying around just for testing? I barely have 10 (they are not exactly cheap) I certainly can’t envisage a way in which I’d be running multiple parallel z-wave systems.
Like I say, just curious.