Put a repeater close to the lock, that should help with battery issues. That said, first thing in diagnostics is if it can be unlocked/locked from the device page
I’m pretty sure batteries are dead. I don’t understand why there aren’t periodic status traffic from the lock to hub in 4 days. I would have expected some traffic. As a minimum a battery warning before dropping to critical level.
When I get there I’m going to put an ammeter on the battery supply to see what the draw is. Maybe lock is never dropping to a sleep state.
I don’t think it’s a Zwave issue. Zwave path is a direct shot to hub @77dB and there are 3-5 repeater options with 4’ of the lock.
I suspect rogue hardware. Now to see if Schlage’s warranty replacement is friendly or endless trip wires and water torture……
alkaline but I have used single use Lithium for other things.
Regardless of battery type a 3-4 day draw down is seriously off. Lithium is in the order of 35% more capacity than alkaline so all things being equal my 3-4 day life with the Schlage lock would extend to 4-5 with lithium single use cells?!? That would be expensive to fund, 80 change outs a year @ almost $13 per would be $1,030/year.
My question about alkaline vs lithium is because lithium will show a 100 percent to almost end of life then drop to 3 percent or just stop working. Alkaline shows mostly correct.
Yes that is what I thought as well. Tells you more about the author of the comment than the recipient.
Anyway despite the attempt to insult me, it was an uninformed reply.
The point I was making was that new batteries were installed in the around 1PM 11/02 There are no log entries since that time until I tried an unlock on 11/6 at 1:49PM where the lock responded with a fatal battery level message before completely going off line.
Why didn't the lock report batteries low before hitting a fatally low level? I believe there are multiple steps in the battery monitoring such that a xx% fuel gauge can be show on the device template. So shouldn't the lock have reported well before 11/6 1:49PM, ..."hey my batteries are low, change them soon"...?
...
4. Poorly designed firmware in lock such that it doesn't send an unsolicited message to hub as battery drops voltage.
5. Poorly designed driver/system such that it doesn't periodically poll the lock to get a health status.
6. Faulty lock hardware and or firmware such that is never goes to a sleep mode and prematurely drains batteries.
I am quite convinced it isn't an RF link issue. When battery was strong RSSI was reported -77dB better than most of my devices. Further the ZWave details page showed a direct hop to hub pathway, no mesh dependencies. In case a mesh hop was needed there are 4 candidates within 4' of lock. Hub is only 12' away.
I believe its fundamentally problem hardware draining battery prematurely compounded by poor software/firmware that doesn't self report dying battery and a hub that doesn't periodically poll the lock for health status check.
The hub should not poll battery-powered FLiRS/LSS devices. The devices have to report to the hub. So you can eliminate this as a possibility.
These locks can go into high power mode, which will cause battery to drain very rapidly. Make sure your lock hasn't done that. High power mode will be described in documentation accompanying the lock. Locks enter this mode when the deadbolt is misaligned. The only way to resolve it is to exclude the lock, hard reset it, and pair it again.
This could be due to differences in battery tech.. For example Lithium batteries keep higher voltages before the drop off than alkaline batteries do..
Discharge curve: Alkaline batteries' voltage drops steadily over time, while lithium batteries maintain a more stable voltage until they are nearly depleted.
Not sure what kind of batteries you are using, just posing a possible cause..
Good suggestion. With the swap device feature it is easy enough to create a tempory device while you delete and repair the real one. I'll give that go b4 I start warranty noises to manufacturer.
Perhaps you are right. As a test I guess it would be easy enough to create a rule to "refresh" the lock once or twice a day just to get stats all updated. I wouldn't think the traffic load of a couple refreshes a day would be a problem.
I think high power mode is merely a higher current option for the deadbolt drive motor. Its true it will draw more current in that mode but the majority of the battery life is determined by the sleep current of the electronics and the sleep to awake duty cycle as needed to listen for messages from the hub. So even if a poorly fitting deadbolt ratchets into high power mode I wouldn't expect it to drain batteries much faster especially when the dead bolt is electronically operated less that 1 time per month.
I have the same lock in a different location on a different Hubitat. It has worked fine. I wrote a rule to refresh it twice a day to see if that causes a noticeable decline in battery life. Not a fix, just trying to profile the issue a bit better. Also want to see if the lock issues a warning message before batteries go to critically low as in the rogue lock.
If anyone knows of the inbound messages these locks might send I'd like to learn more. Obviously there are messages for manual open close of deadbolt, entry of a successful and failed keycode entry, but maybe a bunch of administrative messages as well? My log shows virtually no traffic from the (working) lock. Perhaps by design to prolong battery life but no health checks whatsoever.
Meanwhile my temp-humidity sensor in the fridge and freezer powered by 2032 battery are chirping away all day long without poor battery life.
I measured my good Schlage BE469 lock for current draw.
It appears the (deep) sleep current is around 23 micro Amps. That is the deepest sleep state the lock enters.
Per the FLiRS protocol within ZWave it appears the lock wakes up every 2 seconds to listen for a beam from the hub. I wasn't able to measure the partially awake duration but my best guess is it is about 200ms. I've read the wakeup interval is supposed to be every second for FLiRS, but Schlage appears to have stretched this to further extend battery life. The current in this partially awake level (beam listening) was 130 micro Amps. So based on the duty cycle above, average current should be around 34 micro Amps. A AA battery is conservatively rated at 2000mAh therefore at @ 34 micro Amp draw it should last well into a year.
I am not factoring in higher current levels from keypad activity or deadbolt motor actuations. That will reduce the battery life further but if it seldom occurs then it won't be a major factor in battery life. But like MPG your results may vary.
Anyway a good deadbolt should get many months of battery life.
Now I have baseline data to compare my rogue lock to. Working backward from a full battery and four days until dead suggests my rogue lock is drawing 21mA continuously or 623x what it should be drawing. I can't do a current measurement there for a few weeks so this has to pause until then. Maybe an LED is stuck on? Hardware never drops to deep sleep mode? CPU churning away and not allowing sleep mode?
OK I have had a couple weeks with my problem Schlage lock but as luck would have it, it hasn't been a problem (original problem of rapid battery drain). I replaced batteries and after 3 weeks everything is fine and batteries say 100% still.
So I don't know why the batteries were draining so fast before (2 sets only last a few days (3-5) until drained). I did current measurements as I did on my good Schlage lock and they were a bit higher but low enough that battery life should easily be 6 months or more. So not sure why it isn't repeatable.
Anyway a little more drama today. I swapped out the batteries with AA Lithium's just to give me maximum duration as I'll be away for a while. After turning lock back on, the ZWave connection to hub was messed up and I couldn't control the lock remotely nor did it receive updates from the lock. Local codes at the lock opened the deadbolt but ZWave was amiss. Showing pending in ZWave details page. After trying to refresh, configure, power cycle, ... and the usual things I gave up and did a device (factory) reset and repaired it with my system I then had to reprogram my codes into the lock and clean up some rules that got messed up (I did a device swap with a virtual lock then back after real lock was OK but that didn't cleanly transfer into the couple of rules). Anyway it works now but I have to say these Schlage locks are junk. A battery change-out shouldn't be a major event. There doesn't seem a soft reset mode, only a factory reset which wiped the lock to step 1. I only got these locks so I could key alike all the locks in the home. I had a Kwikset ZWave deadbolt for years and it NEVER gave me issues. Schlage, it seems there is always something.
I believe the device supports OTA firmware upgrades but Schlage doesn't make the firmware drops available. More Schlage weirdness. So if my issues have been fixed in firmware I can;t take advantage of it.
Anyway if you are on the fence about a ZWave deadbolt steer clear of Schlage, they don't seem to be committed to ZWave.
p.s. I have found the device driver (Schlage BE468/BE469 Lock) for this lock doesn't work to change the code length. It works to enter and remove codes but fails when you want to change code length. I had to change code length at the lock keypad then I could enter my 7 digit codes from Hubitat.
