What I meant was to disable polling on the entire network. Not just the locks. The nightly heal will put the locks back into repeaters again, so unpairing and repairing will end up back into the same state you were. What would help more will be to stop the vera from polling the locks’ neighbors or better yet if you have a sizeable network to disable (auto) polling on every single device.
Not disagreeing with your findings but I just don’t get it. If these devices are indeed repeaters, you would be seeing a 1-2 sec lag in response times (at least, due to wake-up delay) every time a lock was involved in a Z-Wave command re-transmission. Know what I mean?
Also I have at least half a dozen FLiRS devices in my network - Locks and Thermostats. I often don’t get around to replacing dead batteries for days sometimes and this has always had zero affect on my mesh.
There doesn’t seem to be a lot of detail around how this all works on the web - that I’ve been able to find, at least.
My understanding is that these devices don’t need to wakeup and that they are always on and always read to receive a command. M locks and vents which are all FLiRS would see a delay if they had to wakeup but they don’t have any. These devices are just always on or per what you quoted, wakeup every second which is effectively the same.
I think FLiRS wakeup every second in a very low-power state, listening for a beam. When received, they fully wake and process the request. This is why they take a second or two to process a command on demand. They don’t respond “instantly” like a mains powered device. At least not that I’ve ever seen.
In any case, @broconne, if battery consumption is still an issue, I have seen this on a lock which was genuinely faulty (dodgy Z-Wave module). Perhaps this is the case with yours?
I learned a little more about the lock’s behavior and the FLiRS through the zwave SDK documentation and the vera log analysis over the past couple of months.
- There is no doubt that FLiRS are mesh repeaters. The R is FLiRS stands for routing which means in zwave terms repeaters. The advantage of the FLiRS is to be a battery operated repeater and being able to respond to commands without having to wait for it wakeup. It uses the trick of getting into a constant low power mode and wakes up every seconds.
I have a lot of FLiRS… over 20 of them from locks to ecovents modules to sirens. They all behave the same way. If one runs out of battery and there is no alternate route to them, the battery operated sensors using them as routing node will go down with them.
- The Battery consumption issue is directly related to them being FLiRS and the vera… If they happen to route battery operated sensors… the vera does a wakeup poll (every poll) and a wakeup nnu (neighbor node update about once every other poll) for them. This latter process takes about 1 minute for each sensor and causes the nodes involved in this process to hang or slow down during that time. This is the source of zwave network delays and is a unique “feature” of the vera related to its network heal, which, when run nightly also is wasteful and superfluous, impacting battery life of the FLiRS if they also route AC powered devices.
After one day of testing the 7.0.30 alpha which enables disabling this “feature”, I can say that this is fixed in the next firmware. The battery consumption of the locks should be drastically improved.
Thank you, very glad to hear that and thank you for the write up!