I was finally able to install this integration this weekend, and it has worked seamlessly so far. Thanks to @dknowles2 and for everyone else who has contributed to getting this to work!
I tried out the recent update that included the changed_by attribute. So far I have observed the following states for the changed_by attribute:
keypad - Name – when using a code
mobile app - Name – when triggered by HA or mobile app
thumbturn – when physically turning the thumbturn or key
Schlage button – when locking with the keypad button
I used these to pull together this basic door unlock greeting automation, that welcomes the name of the person with a Nabu Casa TTS announcement. So far it seems to work! This should work with the automation visual editor, if you’d like to try it out:
alias: Door unlock greeting
description: Play a greeting when the front door is unlocked
trigger:
- platform: state
entity_id:
- lock.front_door_lock
to: unlocked
condition: []
action:
- if:
- condition: state
entity_id: lock.front_door_lock
attribute: changed_by
state: keypad - Person1
then:
- service: media_player.play_media
target:
entity_id: media_player.speaker_pair
data:
media_content_id: >-
media-source://tts/cloud?message=Welcome+home+Person1%21&language=en-US&gender=female
media_content_type: provider
metadata:
title: Welcome home Person1!
thumbnail: https://brands.home-assistant.io/_/cloud/logo.png
media_class: app
children_media_class: null
navigateIds:
- {}
- media_content_type: app
media_content_id: media-source://tts
- media_content_type: provider
media_content_id: >-
media-source://tts/cloud?message=Welcome+home+Person1%21&language=en-US&gender=female
mode: single
Context: I accidentally broke the underlying library for Sense locks. (I had forgotten why that user_id attribute was being saved! D’oh!) I have Encode locks in my house so I didn’t notice that I broke it. I also fixed up the tests to catch this case so it won’t happen again in the future.
Again, sorry about that! Thanks for letting me know, as I probably wouldn’t have noticed if you hadn’t said something!
Thanks again @dknowles2, that worked flawlessly. I really appreciate you explaining how the states work as well. Do you have a “buy me a coffee” link by chance? I’d love to give back.
I did setup with Encode Plus with the Apple Home Key support.
While setting up I did the normal Wifi setup with Schlage app and then did the home kit setup.
I think so this addon supports the former Schlage API not the homekit api.
It works fine for me, just my current iPhone X doesn’t support Home Key in Apple Wallet for seamless door locking/unlocking.
Ditto @dknowles2, thank you! Quick and easy setup for my Schlage Encode Plus.
I (long ago) first set up the lock via Apple Home and the Schlage app, because Apple Home Key is very convenient. This new integration allows me to get the lock’s battery info into HA!
I wanted to share this in case there’s anyone else (who’s an idiot) like me and was having issues updating their changed_by attributes to match the access codes from the Schlage app.
I have an automation that triggers when the door is unlocked and a condition checks to see if it was unlocked by any of the mobile devices or keypad codes. The tricky part is that my keypad codes are constantly changing, and each change requires I update the automation, which can be difficult when I’m on the go.
I spent months trying to come up with a solution that would automatically include new codes. Unfortunately, wildcards (*) cannot be used to call out the state. I pondered if there was a way to set up a binary template sensor to evaluate if the changed_by attribute started with “keypad” or “mobile device”, but sadly my coding skills aren’t that far along yet. I thought to myself, why is this so hard? All I want to do is confirm it wasn’t unlocked by a thumbturn!
confirm it wasn’t unlocked by a thumbturn!
not unlocked by thumbturn
condition: not
conditions:
- condition: state
entity_id: lock.front_door_lock
attribute: changed_by
state: thumbturn
Hey folks! As a heads-up, support for Schlage locks has been merged into Home Assistant core and will be included with the 2023.9.0 release. Consider my custom integration deprecated, and be prepared to remove the custom integration when 2023.9.0 drops.
There are a few changes that had to happen between the custom integration and what’s been merged into core, as the core developers are much pickier about how things are implemented. There’s a chance this will cause issues if you’ve set up automations with your locks, so be prepared to spend a little time fixing that.
Also note that any custom integrations you have installed take precedence over the native version, so if you want to keep up-to-date you’ll need to remove the custom integration once you upgrade to 2023.9.0 and re-run the setup with the native integration, otherwise you’ll be perpetually stuck on the old custom integration.
When HA 2023.9.0 is released I’ll push one final release of the custom integration which will raise an issue in HA to give the same warning. After that, I plan to remove the code from Github in ~October 2023 to signal the final breaking change.
Post-2023.9.0, feel free to open bug reports directly in the Home Assistant core github. They should get routed to me and I’m happy to keep supporting this until I remove the locks from my own house. Also feel free to open issues in GitHub - dknowles2/pyschlage: Python 3 library for interacting with Schlage Encode WiFi locks. instead if there’s something that seems fundamentally broken about the interaction with the lock.
Thanks for all the work on this! Curious, is there a place we can find what changes you mention had to be made? I do have automations setup and am in the process of adding more automations based on the “changed_by” attributes
The major potential breaking change is adding compliance with Changes to entity naming | Home Assistant Developer Docs. But I’m also not sure if it affects existing entities you would have from the custom integration or if it only affects newly added entities.
Hey folks, I have been following this thread intently hoping that a solution would pop up for this model (Bluetooth / HomeKit)
I’m not sure how the Schlage Home app does it, but It seems to me that since I can control my lock away from home, that for some reason @dknowles2 excellent pyschlage python script would find it, but alas, when I log in (using pyschlage) it cannot find my lock.
Is this a WiFi locl only solution? Is there any way to have pyschlage ‘see’ my lock?
I have the Schlage Sense as well, but I use it with the Schlage BR400 WiFi to Bluetooth adapter. I think adding it to Apple homekit allows outside connection for the Schlage app, but it doesn’t work for Home Assistant. I’m not sure how that works, my house is all Android phones.
The integration is meant for Wi-Fi locks and has only been thoroughly tested on Encode locks. I think the v2 Encode locks work as well if you don’t add them to HomeKit.
The bluetooth protocol is very complicated and I haven’t had time to reverse it. There’s a FR tracking it here: FR: Bluetooth support · Issue #28 · dknowles2/pyschlage · GitHub. But it’s very low on my priority list and I probably won’t get it done any time soon.
I’ve heard multiple reports of the BR400 connected locks taking a long time to respond. I’m not sure what the cause is. From what I’ve been able to ascertain from the decompiled Android app, I’m calling the right endpoint. The code is mostly obfuscated though so it’s hard to follow in places. It’s possible there’s some switch to Bluetooth if it detects the lock is nearby. Bad Gateway when Locking/Unlocking with Schlage Integration · Issue #99777 · home-assistant/core · GitHub is tracking the problem with br400 if you want to follow along.
If by V2 you mean the Encode Plus, the one with Apple Home Key support, then yes it works with that.
You can add it to HomeKit as that appears to use the Bluetooth pairing, and then to Home Assistant (through the cloud), which appears to use WiFi. I think the delay is because the lock sleeps WiFi as much as possible. Interacting with the lock through the Apple Home app is significantly more reliable than the Schlage app.
It seems like HA can see the lock through Bluetooth, but the pairing process doesn’t work properly at the moment, potentially because of this:
I suspect even if it’s fixed, if you add the lock to HA, even if you export it back out to HomeKit, the Home Key functionality won’t work anymore.
At this point I’ve only installed one door lock (the Schlage Sense / Homekit) so I think it would be easier to just circle back and go with a different lock that would integrate well w/HA.
Not to derail this thread but are there thoughts about what that might be? I still like Schlage, are there any Schlage locks that integrate well w/HA and don’t rely on the cloud?
Also feel free to open issues in