ZWave Lock Battery Consumption

I am getting poor battery life from many of my z-wave locks.

I have 1 Schlage lock that is fairly old and gets acceptable battery life.
I have 1 Yale Touchscreen lock (YALD226ZW20BP)
I have 5 Yale Push button locks (YRD110ZW0BP)

The pushbutton locks have started getting poor battery life and I don’t know why.

Here is an image of battery life so far this year.

I replaced several batteries around Feb 15th and I have been getting two months for batteries in each of those 5 locks. The Schlage (red line) seems to last forever and the touchscreen lock hasn’t needed a battery replacement since February and is reporting 98% currently.

The mudroom lock gets a lot of use (it is the main door we use) and gets automatically unlocked every morning. Some of the others like the basement door get almost no use. All locks are in a single scene that locks them which gets executed whenever my alarm is armed.

There’s a couple of reasons for this in my experience:

  1. The lock needs to be able to move freely, without obstruction. Example: if there’s any friction preventing the deadbolt pin from locking/unlocking easily, this will cause the lock mechanism to work “harder” and therefore use more power.

  2. The lock is being polled too frequently. Check your poll settings. I personally disable polling unless absolutely necessary.

  3. The lock doesn’t have enough powered nodes within close proximity to communicate with the controller (ie, poor mesh). In this case, you could try an “Update Neighbor Nodes” but the most sure fire way to correct this, would be to exclude and re-include the lock again.

As a new user of the forum I tried to edit my post and got locked out so the above posting wasn’t complete…

Last month I started pulling the vera logs over to my server so I could do some analysis on the network activity for each lock. The activity, with a few exceptions, seems reasonable:

The dot is a total for each day of transmissions, polls, errors.

…I can only post a single image per posting as a new user so the next post will have more info…

…Continuing here per posting limitations for new users…

Taking a closer look at a single lock with very little activity, my basement door lock:

We can see that I am getting about a month life on a battery with a small amount of activity. I average two commands and 1 poll per day. The commands are the arming of the alarm instructing the door to lock - the door is almost always locked, so it should just need to wake up and indicate success. The poll I believe follows the command to lock.

I have polling set to 0 for all of these locks. I am a bit out of ideas on what else to try? Could I have multiple defective lock modules? Is 1 month the right life for a door lock that doesn’t really have to do very much? Could I have some sort of routing issues where traffic is passing through these locks (I can’t imagine why that would be). What is the next step to diagnose this?

@sm2117 - Thank you for the info. Looking at my more detailed example (now that I can post again). I believe polling is off, the lock really isn’t being used (almost always locked) so the shouldn’t be a binding issue… That just leaves me with a mesh issue. How can I diagnose the mesh? Is there any way to visually see the neighbors for each node and/or determine if the mesh is a problem?

I am also seeing this across a lot of my locks and some that are right next to powered nodes… I don’t have a lot of devices in the mesh, it is mostly locks and fan controls (my lighting is UPB).

Did a little more investigation and wrote a quick program to graph my neighbors based on the JSON API. I have some concerns. It appears a lot of my devices have neighbors that are pointing to neighbors that never or no longer existed? Is this normal?

It also seems odd that my workshop lock has no neighbors, including the vera yet functions fine. Is the neighbor list in the API reliable?

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? :slight_smile:

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.

Edit: Nevermind, it appears it is the altid.

Wow, that’s impressive! Would you be willing to share this? :slight_smile:

Yes. Happy to package it up and share it once I am sure it is working… It appears maybe the information isn’t accurate?

Ok… New graph using the altid instead of deviceid… This seems better:

1 Like

I have created a docker container to generate these graphs in case it is useful for anyone else.

Just execute:
docker run --rm -e VERA_HOST=<IP_OF_VERA> --name vera boctothefuture/vera-graph:0.0.1 > graph.png
The graph will be stored in graph.png

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.

Not that I know of… The zwave heal would bring them back. Have you tried lithium batteries?

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.