Schlage FE599 Door Lock Battery Level

I am finally moving my Schlage Door locks over to HA. With all the features of the latest release, it looks like I can manage user codes now. So I guess I finally get to ditch my Vera Controller.

I moved one lock over and all has gone well. The only hang up is that I cannot see battery levels for it.

{{ states.zwave.lock.schlage_fe599gr_wireless_door_lock_locked_82_0.attributes.battery_level }}

Unfortunately, using that I get:

Error rendering template: UndefinedError: 'None' has no attribute

So does anyone have any ideas how I can get battery levels for the locks?

Another issue, though not really a deal breaker is that when I manually unlock the lock, it does not reflect the change in HA. Is this just how things are with these locks in HA or is there something I am doing wrong or that I need to do?

I checked the zwave node info for the lock and I can see Battery_level: there, so I guess I am just trying to retrieve it wrong, but after trying a few different variations I am not getting anything.

You were part of this thread, but I’ll mention it… I bookmarked this for when I get around to moving my Schlage lock from Vera. He mentions keeping track of lock/unlock from the keypad and manual knob separately via a template.

1 Like

This is what works for me:

{{ states.zwave.front_door_71.attributes.battery_level }}
1 Like

Oh, yeah, I had forgotten about that. Thanks for reminding me.

@BendedArrow are you using the friendly name for it in the template?

@StormStrikes I am using the Zwave state Name in the Developer Tools <>. If you scroll down, all devices also have a Zwave Name, and that is what I am using instead of the name.lock.

My other lock works like this:

{{ states.zwave.garage_side_door_68.attributes.battery_level }}

I am sure you know, but they changed the battery_level attribute so that it is a zwave attribute instead of an entity_id attribute.

Yeah, I knew about that, it was just your node name is considerably shorter than mine. Thanks for the info and the help.

@StormStrikes Last but not least, I had problems with HA keeping up with the state of lights, switches and even the locks, as well. If I tailed the Ozw log, alot of what was sent out said sent (pending). What I think made the biggest difference is making the “recorder” as minimal as possible and moving MQTT off of the PI. I had a home-assistant_v2 database that was growing to 500megs a day because I had tons of things being recorded. The “recorder” attribute really decides what is logged or not. The history and logger are just a view into the recorder database. Make the recorder as minimal as possible so that your v2 db stays under a meg, If you can’t do that, try to move the database off the PI.

I also had MQTT sorting and collecting from 4 happy bubbles. I measured it and I saw the 4 happy bubbles would send 1.5 gigs of traffic a day to the raspberry PI. I moved the MQTT and the presence server to another linux host. That combined with pruning the recorder meant that my PI is not handling all of that traffic and my v2 db is at 355k after 8 hours. My Locks maybe takes a couple seconds, and sometimes my lights are a few seconds behind, but they are never mismatched after I made all of those moves…

1 Like

You bring up some good point. I moved my HA off the Pi to a dedicated server, so I have a little more processing power. I have nibbled at the recorder aspect and have excluded a few things, but I have so much more to remove. I need to figure out how to domain level exclusions, I just have never sat down with it long enough to sort it all out.

@StormStrikes Interesting comparison point. I still have the PI with maybe 50 devices at it is working much better that I put the recorder on a diet. It would be interesting to see if you only included a few things on the recorder if it would make a difference. If yes, that would mean that the database writes are what makes Zwave so dodgy…

I know like no other I need to seriously sit down and work with the recorder. I have about 40 devices and growing. I sometimes think it would just be better to turn it all off and just add back, one by one, that which I really want to see in the history.

Actually, turn it all off, by commenting out the recorder entry and see if there is a difference. Remember to wait for the 10 minute or so Zwave startup to really test. If things don’t work better, you can just remove the # and you’re back again. Once I have things the way I want them, I turn off the recorder, except for troubleshooting…

I think you are pretty darn wise there. I will have to try that. I don’t spend a lot of time looking at the history, but there are things I want to see there but nothing so critical I could not turn the recorder off for a while and see what the difference is.