Large zwave network settings

I never stop learning with this thing… sigh

Just wanted to share some settings I uncovered over the past couple of days which may help someone looking for this. The zwave network can be a source of instability to the entire vera engine and can cause luup reloads when you expect it least. I have been going through my logs to try to understand some of the sources and found a few pointers.

  1. Polling: On a large network, you should try to disable polling by default both on the zwave menu as a general polling setting but also on each of the devices by setting the PollSettings variable to 0.

a. I recommend doing it via luup code and not the vera UI because… for some odd reason the luup engine wants to reconfigure the device when you change this variable from the Device Settings menu. It is purely a controller setting and does not need any communication to the device to change. You just have to do a luup reload after running the code.

An example below allows me to disable polling on battery operated devices. You can also do the non battery operated devices by changing the condition.

  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

b. Oddly some devices did not even have this variable and are polling in the background anyway. It was the case for me for all my EverSpring sensors. I kept on getting polling list full messages in my logs. I ran that code above to target these devices and create the variable, setting it to 0.

c. Note that in practice, the vera is not polling the battery operated devices which are asleep. However if you do not set this variable to 0. The vera will keep a polling list record in its memory which really is unnecessary. These devices get polled in any case whenever they wake up as it is part of the wakeup function.

I have very few devices benefiting from enabling polling by the vera: devices which don’t wakeup (FLiR, and AC powered) and which have have something to update (FLIR battery levels, actuations from something other than the vera)

  1. Lifeline Associations: Most devices support associations and the associations are listed into groups. You can do many things with these associations including making one device actuate another without a controller in between but here the problem I encountered was the Lifeline. It is generally the 1st association group and is used by the device to report its status updates to the controller. The vera does not display or control this very well and I at some point added a secondary controller, the zway as I was considering migrating to that platform. Well, as it turns out some devices can have multiple controllers in their lifeline association group and for me it caused a mess on my network.
    a. I excluded the zway device from my network sometime last week thinking I did not need it anymore. I suspect that this caused the devices which had it on their lifeline association group were still sending messages to it causing errant frames on my network and the vera to reload luup frequently with callback processes hanging.
    b. Even after I removed these rogue associations (I re-included zway as a secondary controller) I still had some “tardy” messages but with very low delays. I suspect this was because some of the devices sent their updates to either or one of the controllers on their lifeline list and called it good causing the vera to still be waiting for a response to its comm requests… I ended up deleting all the zway associations. No more tardiness in my network.

  2. Got CAN. Credit to @sm2117 on this one who noticed the frequent appearance of this message. It is another factor affecting speed on a large network and is mitigated by disabling instant status. I have not disabled mine and am still getting these zwave dongle freezes of 0.1s (although the log says 1s) and am living ok with it.

Feel free to share your tips on this thread!

I disabled polling as you with a script, on all non battery operated devices. Everything is good, except fibaro universal sensors, that need polling in order to always stay in sync. It’s a known bug as support told me. Network stability has improved a lot.