The lock not having neighbors is odd. The database needs to come from the zwave controller chip so it should be accurate. I would recommend to run a neighbor node update on that node if you can. It is in the device advanced/command menu.
Now on the battery, Sam’s recommendations are excellent and I will only add one:
The locks are what is called FLIR nodes. They are technically constantly on even when not polled and are always ready to receive commands. They are also de facto zwave relays/network extenders in spite of being battery operated. Because of this, the current draw on them is fairly high and for this particular application, I would recommend the use of Lithium batteries which have longer life at high draw. There is some science behind the battery technologies and alkaline batteries will not have good life (neither will NiMH rechargeables). I am getting 3-6 months out of lithium batteries Vs ~ 1-2months on rechargeable NiMH and Alkaline. There is some dependance to how much zwave traffic is being relayed by the lock…
Just a thought… you know that Z-Wave node numbers and Vera device numbers are not the same thing, right? The neighbors list contains node numbers, not device numbers.
Wow, that’s impressive! Would you be willing to share this?
Not sure exactly how the JSON API works but if I look at the neighbors variable on each of my 2 locks, one of them shows 0 neighbours but works perfectly fine and has no excessive battery drain. I have at least 4 other devices on my network which also display no neighbors when I look at this variable. My point is, I’m not all that convinced that Vera is actually showing us the full story when it comes to Z-Wave neighbor nodes.
Just a thought… you know that Z-Wave node numbers and Vera device numbers are not the same thing, right? The neighbors list contains node numbers, not device numbers.
Does vera share the Z-Wave node numbers anywhere? I don’t see it in JSON or in the docs.
Is there anyway to have these locks not act as repeaters? I am not even getting a full month on these things. Which is fairly aggravating.
My understanding is that they are not repeaters. Unless I’m mistaken, a FLiRS device is NOT a repeater as it is still a battery operated device. Only continuously (mains) powered devices can act as repeaters.
Unfortunately I have proof that this is not the case as I had one of my locks going out of battery causing a whole section of devices losing communication. FLiRS definitely act as repeaters…
When you read the FLiRS Document it indicates how useful it is for battery life:
The FLiRS implementation in Z-Wave is extremely reliable, robust, and capable of extraordinary power
savings to extend battery life. Using the 1-second rate for frequently listening, a typical (Sigma 500-Series)
Z-Wave radio listening device will consume, on average, just 50-μA of power. For smart door locks, battery
replacement at 1-year intervals, or even longer, becomes possible thanks to FLiRS.
It really doesn’t make a lot of sense to implement FLiRS then turn around and have those nodes also act as repeaters.
I am going to swap the batteries in a few of my locks that are now low and at the same time remove them and re-add them to the network to see if that changes battery consumption.
I will say that I find it odd that locks are z-wave neighbors of each other. That would imply you would route between them which doesn’t make a lot of sense.
also did you already disable polling on them? I disabled polling on my entire network but it also needs to be done on all the devices one at a time since the device parameter overrides the zwave menu one. But may help to also disable the one on the zwave menu as it may poll neighbor devices of the lock.
At then end I would still try the lithium batteries. I found my energizers to now be on their 3rd month.
I did disable polling on all the locks. On the lock I just unpaired and re-added to the network it has a poll setting of 10800 which is every 3 hours. I am going to leave that alone for a bit and see how everything is in the default setting. I will then drop that to 0 later and see how battery life is impacted.
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.
