Schlage Door Lock Battery Died Suddenly

Devices & Integrations Connected Things
1

My Scalage Door Lock battery died this morning after just about four month of use. Interestingly, the battery state was last reported at 96% 6 days ago .There was no low battery warning, so I was caught completely off-guard. Needless to say, not a good user experience and big negative XAF since family relies on keyless entry. What’s your experience with Scalage battery life?

2015-02-17 2:11 AM PST - 18 hours ago	battery	0 %
2015-02-11 4:30 PM PST - 6 days ago	battery	96 %
2015-02-11 3:26 AM PST - 7 days ago	battery	97 %
2

You’ve probably already thought of this, but have you checked for an increase in polling or refresh recently? Fastest way to kill a battery is to keep waking up a device that’s supposed to spend a lot of time sleeping.

3

I never trust battery powered locks without keeping a spare key available in a hidden or non-battery powered keybox for backup. I’m an n+1 guy.

https://community.homeaway.com/sbsstatic/legacy/Getting%20Started/ge%20supra%20lockbox.jpg

1 Like
4

I do see a suspiciously irregular and disturbingly frequent polling pattern: 32 polls within 3 hours interval, i.e. 6 minutes average polling interval. What’s even worse, sometimes I see clusters of less than 1 minute polling intervals.

Here we have 3 polls within 40 seconds interval:

2015-02-17 7:33:05.822 PM PST poll command was sent to Front Door
2015-02-17 7:32:42.452 PM PST poll command was sent to Front Door
2015-02-17 7:32:26.604 PM PST poll command was sent to Front Door

I don’t know why a door lock needs to be polled. As far as I know it always reports its status whenever it’s opened or closed. It seems wasteful and probably causes unnecessary battery drain.

P.S.

Opened support ticket.

Support request #87100: Schlage door lock polled too frequently, causing battery drain

2 Likes
5

(I’m assuming a zwave lock, btw.) Were you running any zwave utilities, particularly a heal?

Was your hub going on and offline, however briefly?

Have you installed any new devices near the lock, particularly a beaming repeater?

Were you using the minimote near the lock?

Have you installed any new smartapps or hello home actions in the last few days?

Do you have any actions triggered by sunset?

Just looking for things that might poll the lock.

Also, just to be sure-- are you using rechargeable batteries in the lock?

6

I don’t think any of these apply. The polling comands seem to come from the system, not from the apps.

7

My Schlage lock is about 6 months old. 97% battery.

8

Well, what do you know? SmartThings drained my Schlage Door Lock batteries again.

I installed fresh Alkaline batteries a week ago, on October 28th. The batteries were from the same batch that lasted 8 month of heavy use. I tested each battery before installing and they were perfectly good, measuring solid 1.6V.

The door look worked just fine until it died today. All four batteries are totally drained, measuring 1.15V.

Now, the interesting clue is that looking at SmartThings logs, I see that the last event from the lock is dated 10 PM Saturday, Oct.31, i.e. four days ago. The battery level before the last communication was 100%.

So it seems to me that the lock lost connection to the hub 4 days ago and drained its batteries trying to reconnect.

Needless to say, I’m very annoyed. SmartThings should have a notification in place warning that device has lost connectivity. Vera, for example, has this feature.

Last battery level:

2015-10-31 2:46:51.951 PM PDT 4 days ago	DEVICE		battery	100		Front Door battery is 100%	true

Last event:

2015-10-31 10:08:29.786 PM PDT 4 days ago	COMMAND			poll		poll command was sent to Front Door	true
1 Like
9

My first lock’s first set of batteries died quickly too.
Hasn’t happened again… Yet.

Definitely worth escalation.

10

How the polling works for battery in the zwave devicetype…

It polls for individual status frequently, however, that isn’t battery, its every status, one at a time at each poll.

It can take like 50 polls to get the battery value.

It should be much better at it, but ultimately, this is the way the built in devicetype is written.

11

Hi Patrick… Are you referring to the Z-Wave Lock Device Type Handler as published by SmartThings?

If so, then at least we have a place to direct the bug report / feature request, while, in the meantime, look at the couple (?) of other Community created Types, and using this thread to confirm they do a better job …?

12

I haven’t tested them all, don’t have the devices. but yes, essentially they all work the same, polling battery on locks is very flawed.

13

If polling is the problem, then the device is connected to the network.

I’m having a hard time imagining the lock being drained because it wasn’t connected to the network, though. Because that’s battery management 101 for the lock itself. If that were the case it would happen anytime with any controller when the controller went off-line. That’s just not supposed to happen unless the lock itself is defective.

Battery drains are usually a problem of runaway polling. Why the lock wouldn’t show as being connected is a whole separate issue.

1 Like
14

@geko’s battery was at 97% a week ago…I would change the batteries in yours now…:slight_smile:

15

Just checked 71% :sunglasses:

1 Like
16

Did you run a Zwave repair after you replaced the batteries? If so, do you remember getting a status for the lock? Or just a complete message?

17

Polling isn’t the problem, its how it is polled. You can’t just get all the statuses of the lock in one poll. In order to keep the devicetype up to date, you have to loop through all the statuses, lock, codes, battery status, etc. and that’s how the devicetype was written.

Battery status is only updated once out of like 50 polls. However, you can hard code a battery poll, but this would be overkill, since excessive polling can lead to battery drain…

I suspect that everytime the platform resets (has been a lot lately) the polling sequence starts over, so battery can take a day or more to update, and if the devicetype resets, it may never get updated. As it is one of the last poll items to get refreshed, after user codes.

Anyway, I’m not a zwave expert, but this is how it was explained to me.

Zwave has alarm codes, 167 = battery low, 168 = battery crit, 169 = battery too low to operate.

However, ST has a zwave function to get battery level response(secure(zwave.batteryV1.batteryGet())) which should get the actual value, but will only be called if alarm 167 is the case.

Also, look at the poll section, every hour a single code is checked, it could take days to get to the battery code, if ever.

2 Likes
18

FYI, my door lock just died, was sending alarm 169, but never fired 167 which would have updated the battery level.

Yes, the devicetype is flawed… Replaced my batteries and all is good again.

Guessing we all bought our locks near the same time :smile:

19

No, I didn’t. The lock’s been working flawlessly for the past 8 month (since the first battery issue), which included a transition from V1 to V2. The batteries finally gave ghost a week ago and I installed fresh ones. I had absolutely no changes in my setup during this time - no devices added or removed. In fact, I’ve been so busy, I haven’t even noticed that the lock stopped communicating four days ago. I cannot be 100% sure it’s SmartThigngs’ fault. It might as well be a lock firmware problem. However, a notification of communication failure would prevent an unexpected battery power loss.

20

Yeah, it’s hard for me to judge. I came from a working environment where we ran a Z wave repair every night just as part of normal maintenance. But they would also be a lot of network changes over the course of a month.

With Zwave plus you’re not supposed to have to do as many repairs, and I home set up doesn’t have as many changes so…