UI7 "device not detected" mechanisms for zwave

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:

  1. 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.

  1. 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”

  1. 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.

print("DeviceNo; Parent; Zwave ID; Description; PollSettings; device names on " … os.date() … “\n”)

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

1 Like

[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.

print("DeviceNo; Parent; Zwave ID; Description; PollSettings; device names on " … os.date() … “\n”)

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?

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=“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.

AFAIK blank means default. Try to set one of them and see how it goes. Default polling behavior is under settings.

Yes blank means default. 0 disables polling. Not sure what -1 means.

-1 is coming from my script when variable is nil. I assume that is the case when not set and blank.

Thanks Gents, i will play around with this a bit and report findings. Really appreciate the work you both do.

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.

@Inzax

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.

Thanks for your post.

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.

1 Like

@rafale77

Agreed. Again. Thanks for the post.

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