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 
Aargh ā¦
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.
1 Like
Oh so you give me 4833 while youāre on something else! 
C
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.
C