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