Hope this helps some people. I just wanted to share my experience with the undocumented mechanism by which the current UI7 determines whether it determines whether a device will be detected or not and mostly how it will flag a communication failure.
The vera uses 3 logic loops as far as I can tell:
Polling. Can be disabled (should be disabled for battery operated devices which are not FLIRs)
The vera sends a polling message on a regular basis to the zwave device and expect a response. If the response is not received in timely manner, the device will be deemed not detetcted.
The device variables:
PollNoReply: Pretty obvious what it isā¦ the number of missed responses
PollOk: Number of succesful polls
PollRatings: score out of 5.00 based on the previous two parameters
PollSettings: Interval between polls which should be set in the device option screen.
LastPollSuccess: Last time the Poll got a response
ConsecutivePollFails: Obvious from the name
I would argue for disabling polling on as many devices as you can since it is quite unnecessarily adding traffic to the zwave network.
It seems like the vera flags the device as not detected after 2 or 3 consecutive unsuccessful polls.
Wakeup. This mostly for battery operated devices which are not expected to respond to polls since they should be asleep most of the time.
Uses the following device variables:
ConfiguredWakeupInterval: The last interval parameter sent to the device as part of the configuration process.
WakeupInterval: Expected interval between wakeup events by the UI. Should be the same as the previous unlessā¦ you have some weird devices like I did. (I have one device which somehow gets it configured wakeup interval in minutes instead of seconds so I needed to set them up differently)
LastWakeup: Last time the vera received a signal that the device was awake.
WakeupRatings: Score out of 5.00 wakeup vs. wakeup interval
The cycle seems to be 6hrs: If the device has not awoken within 6 hours after the last expected wakeup then the vera flags the device as ānot detectedā
Zwave Failed Node List: Embedded in the zwave radio firmware.
Took me some time to figure out but the vera gets a refresh every 5-6 minutes from the zwave chip and flags any node present on this list as ānot detectedā. This explains why I have observed at times a device get flagged even though the vera did not poll it or should not have expected the device to have awoken. The list is maintained by the zwave chip itself and its firmware and relies on the intrinsic zwave network mesh routing and polling. A failed node should get off the list once it is detected as awake but somehow with the vera, sometimes doesnāt so you could wake a device up and within 5 minutes find this device to be flagged as not detected by the vera. The only resolution I have found in this case is to reconfigure the device on the UI.
As you can see there is some redundancy between the polling the vera does and the one the zwave firmware does which is the reason why I would recommend to disable polling altogether on the vera.
Edit: Obviously forgot to mention the 4th one which is flagging the device as failed when it does not respond to a commandā¦
I can confirm that disabling polling on devices supporting instant status/reporting makes the Zwave mesh more stable. I can easily go with more than 10 days without a luup reload.
Iāve built a script to check for this setting, useful when rebuilding or optimizing things.
for deviceNo, d in pairs(luup.devices) do
local poll = luup.variable_get(āurn:micasaverde-com:serviceId:ZWaveDevice1ā, āPollSettingsā, deviceNo)
print(string.format(ā%03d ; %s ; %s ; %s ; %s \nā, deviceNo, d.device_num_parent, d.id, d.description, tostring(poll or -1)))
end
I then use Excel to filter and remove those with value <=0 (-1 is a special value for device without this attribute). I set this value to 1800 for battery operated devices to increase battery time. Itās working very well for me since the last two years and a half.
very useful indeed.
Since we are at it, I might as well share this script to disable polling on all battery operated devices which are not FLIRs:
for k, v in pairs(luup.devices) do
local var= luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings",k)
local bat = luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "WakeupInterval",k)
if var ~= nil and bat ~= nil then
if var ~= 0 then
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings", "0", k)
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollNoReply", "0", k)
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollRatings", "5.0", k)
end
end
end
[quote=ātherealdb, post:2, topic:200613ā]I can confirm that disabling polling on devices supporting instant status/reporting makes the Zwave mesh more stable. I can easily go with more than 10 days without a luup reload.
Iāve built a script to check for this setting, useful when rebuilding or optimizing things.
for deviceNo, d in pairs(luup.devices) do
local poll = luup.variable_get(āurn:micasaverde-com:serviceId:ZWaveDevice1ā, āPollSettingsā, deviceNo)
print(string.format(ā%03d ; %s ; %s ; %s ; %s \nā, deviceNo, d.device_num_parent, d.id, d.description, tostring(poll or -1)))
end
I then use Excel to filter and remove those with value <=0 (-1 is a special value for device without this attribute). I set this value to 1800 for battery operated devices to increase battery time. Itās working very well for me since the last two years and a half.[/quote]
Thank you for this. i ran it on my network and it seems that some battery operated devices as well as some plugged in devices show a poll setting of -1. there are a bunch of devices showing 60 (again both plugged in and battery operated), and then some with longer times that i had modified at some point in time. Question is should i add the variable to the devices which show a -1 and should be polling? I will modify the battery ones to 1800, but what should be done with the devices on direct power?
[quote=āsvaleb, post:5, topic:200613ā]Would you still get changes in temperature, light and so on if you do not poll them ?
I dont get changes from thermostats if they are not polled.[/quote]
It depends on your specific deviceā¦ Itās not one side fits all. Some older devices do not update the controllers without polling. All battery operated ones āwake upā and update on their own. Most AC powered devices have settings for users to setup a thresholds on the variable to trigger a data update. I am lucky enough to have no device requiring polling but I know some do.
[quote=āsvaleb, post:5, topic:200613ā]Would you still get changes in temperature, light and so on if you do not poll them ?
I dont get changes from thermostats if they are not polled.[/quote]
Same here so Rafale77 for me. I left my battery ones with a very long poll just to be sure to get the values in case of some missed events related to reloads. I could probably disable it and live well now that I stabilized the engine.
Having this same issue. 3 doors sensors and 3 motion sensors. They are zwave plus ring sensors purchased by the home owner. They workā¦but continue to show ādisconnectedā while continuing to function.
Polling is set to off for all devices.
Vera advised if the āconfiguredā variable was anything but 1 the device had not completed its configuration and would continue to show ādisconnected.ā
Manually changing this value from 0 or -1 to 1 would not fix the issue. The device had to be brought to the value of 1 through the ācommands/configure node right nowā option.
That worked for awhileā¦until it didnāt. I think if I understand the above correctly the zwave firmware on the vera is continuing to poll the wireless sensors despite the vera being set up NOT to poll?
I have unchecked the options to āpoll nodesā I also set all the poll values to 0. Each device is set to 0 so it should never poll. What am I missing? It looks like the devices continue to āpollā based on the error count in the variables tab.
The firmware does not poll battery operated device. It just maintains a list of āfailed devicesā based on the traffic record it is seeing. The polling is coming only from the vera. Setting the polling variable to 0 works only after you run a reconfiguration and a luup reload behind it. Having the device not fully configured is another problem. You should start by trying to get it to be fully configured first. If it worked for a while and it then shows to be offline, you may have a network issue. Read my first post, it is not just about polling. Battery operated devices actually rely on their own wakeup schedule. Since you are talking about sensors, I suppose that they are battery operated and therefore you should really look at the configure wakeup interval. I have one of my 15 or so vision 4 in 1 devices which somehow got flashed a erroneous firmware and sees the poll interval parameter in minutes. It causes a mess as the vera expects it to wake up every 15 min, and instead it wakes up every 11 hours. I had to manually change the parameters and set them to be different.
Thanks. I did as you described before I posted. (reconfigured/luup reload). I got several days of expected good performance then everything showed disconnected again. That is when I found your original post and commented.
I donāt think it is the network since the area is very small and I have multiple lamp modules boosting the zwave signal.
Looking back through logs I believe the battery operated devices defaulted to a previous state from several days earlier. I have installed a backup and everything is performing as expected.
What I donāt understand is how all of my devices could just fall back to a previous/corrupted state without input. All the variables were out of whack.
Wake up is set to 3600 on all battery devices. I think I am good there.
I am starting to consider that it was a blip? ORā¦I have had weird issues surface after customer support trying to help. I had a ticket in and after the email came advising everything was fine I logged in to see the disconnected devices.
This!!! Very likely what happened. They might have reset you to an older backup condition or may have tried to reconfigure your devices. As I discovered the mios default recommendations are not always the best for all networks.
So I decided to completely eliminate polling from my network with the following code:
for k, v in pairs(luup.devices) do
local var= luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings",k)
if var ~= nil and v.device_num_parent== 1 then
if var ~= 0 then
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings", "0", k)
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollNoReply", "0", k)
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollRatings", "5.0", k)
end
end
end
followed by a luup reload and the traffic on my zwave network has decreased so much that I have nearly 0 latency. (I had very little to begin with but could occasionally run into an overflow). I initially thought that disabling polling from the zwave settings screen would stop polling but the logs showed otherwise. This will significantly, I believe increase the battery life of my FLIR devices which were getting polled every minute like the yale deadbolts and econet vents while resolving the occasional command queuing I have previously been dealing with.
Thanks for the great info on this Rafale77! I still experience inexplicable reboots of my Vera Edge every day, so i will definitely try your advice on the polling settings.
How do you monitor the traffic on your zwave network?
On the vera I look the luaupnp logs located in /tmp/log/cmh.
Also after some testing, I am no longer recommending zeroing polling on battery operated devices. They are not getting polled anyway but for some strange reason, vera wants to reconfigure the devices when you ask it to stop polling them. It is fine with the FLIRS and non battery operated devices but the others need to wait for a wakeup and I just woke up yesterdy with 50+ undetected devices. A quick recovery from back up and then a selective modification of the polling rate fixed the whole thing.
This code below disables polling on all non battery operated devices. I can also share my code which removed polling from my econet vents and locks which are FLIRS and set polling to once a day for my sirens which are also FLIRS.
for k, v in pairs(luup.devices) do
local var= luup.variable_get("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings",k)
local bat = luup.variable_get("urn:micasaverde-com:serviceId:HaDevice1", "BatteryLevel",k)
if var ~= nil and v.device_num_parent== 1 and bat == nil then
if var ~= 0 then
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollSettings", "0", k)
luup.variable_set("urn:micasaverde-com:serviceId:ZWaveDevice1", "PollNoReply", "0", k)
end
end
end
Best Home Automation shopping experience. Shop at Ezlo!