Schlage Encode Plus in Apple Home (w/ HomeKey) and Home Assistant

So you have a Schlage Encode Plus door lock (deadbolt) and want to use it with full functionality in both Apple Home and Home Assistant? Good news — it is possible! But… there are compromises that you’ll have to make along the way.

I have all the necessary hardware for testing this:

  • Homepod Mini Thread Border Router
  • Home Assistant Bluetooth
  • Home Assistant Skyconnect Thread Border Router
  • Wifi (of course)

My focus is to integrate with Home Assistant but also with Apple Home such that HomeKey and the Home User Access Codes continue to work. That is mandatory — the Encode Plus is very expensive ($350 when I bought it) and the only reason you can justify that cost is because it supports HomeKey. There are notably less expensive locks if HomeKey isn’t a requirement!

Here are the possible combinations:

Combination 1 (Pair directly with Apple Home first)
Apple Home

  • Lock/Unlock
  • HomeKey
  • User Access Codes
  • Connected via Thread

Home Assistant

  • Not possible to connect in any way!!

Combination 2 (Pair directly with Home Assistant; Pair with Apple Home using HA HomeKit Bridge)
Apple Home

  • Lock/Unlock
  • Not entirely certain how it’s connected to HA

Home Assistant

  • Lock/Unlock
  • Paired with Bluetooth; Connected via Thread

Combination 3 (Setup with Schlage app via Wifi; Pair with Apple Home through app; HA to Schlage Cloud)
Apple Home

  • Lock/Unlock
  • HomeKey
  • User Access Codes
  • Connected via Bluetooth

Schlage App

  • Lock/Unlock
  • Access Codes
  • Remote Access
  • Cloud
  • Connected via WiFi

Home Assistant

  • Lock/Unlock
  • Connected with Schlage Cloud Polling integration

Let’s talk about these combinations.

Apple Home Only
The first is the default case if you just buy the lock and set it up using Apple Home. It works like a charm in Apple Home and connects via Thread, which is great. Alas, the lock will not allow you to connect to more than one HomeKit controller at the same time. That is, you can pair with Apple Home or you can pair with HomeKit Device, but you cannot do both! It’s not “discoverable” in HA if you start with Apple Home and if you start with HA, then Apple Home gives a message about “This lock is already in Home”.

This combination isn’t a feasible option for me since HomeKit doesn’t allow you to automate door locks very much (and doesn’t expose the battery level for automation), so I really want this lock in HA.

Restricted Feature Set Local Push
The second combination required that I paired with Apple Home, then removed it from Apple Home, then it showed up as a configured integration in HA and I paired with Bluetooth/Thread, then I “exported” that using the HA HomeKit Bridge and was able to connect Apple Home to that! So yes, this allowed me to use the lock in both HA and Apple Home using full Local Push. What’s not to like?

Well, HA HomeKit Bridge doesn’t advertise that the lock supports HomeKey or has a keypad (I don’t think HA even knows about either) and so Apple Home doesn’t know about them either. There is no “Manage Access” section for this lock in Apple Home. The only thing that works is Lock and Unlock… and since non-working HomeKey makes this lock pointless, this also is a (deeply unfortunate) pointless combination.

Fully Working with Cloud Polling
That leaves us with the final very compromised combination. I do a factory reset and start out by setting it up with the Schlage app. This requires an account with Schlage and then it sets up the lock using 2.4Ghz WiFi. At this point, you can remotely lock and unlock the door and setup access codes using the Schlage app. This does not require a hub.

From the Schlage app, I was able to initiate the Apple Home integration. When doing it through the app via directly, the Thread radio is turned off and the lock connects with Apple Home using Bluetooth (verified using the Eve app). On the plus side, HomeKey and the Home User Access Codes all worked like a charm and it is Local Push so it’s pretty responsive. But Bluetooth isn’t quite as nice as Thread and the active WiFi is going to likely require monthly or bi-monthly battery changes.

With WiFi, though, I could connect to HA using the Schlage integration. This gives me Lock and Unlock (plus exposure to the battery level) but it is, of course, Cloud Polling which is the worst way to connect. It does work, which is better than not working at all.

TL;DR: It is possible to integrate the lock with full functionality into both Apple Home (with HomeKey) and Home Assistant and can do so without any external hub… but you must forego Local Push and compromise with Cloud Polling.

3 Likes

What is the battery drain so quickly without thread? I’m trying to determine if I should enter that world or not? I don’t use matter for anything else at least not yet. Is it worth it to buy a hub just for one door lock?

I am curiously not seeing a significant difference in battery drain between Thread-only and WiFi. I expected a notable drop to maybe even “once every month or two” when switching because even Thread-only mode drained batteries incredibly quickly (a few months at best). But no, it’s been essentially the same.

I will say that choosing my batteries made a notably bigger difference than Thread vs WiFi. My standard rechargeable NiMh batteries drained the fasted, by far. Alkaline latest longer but still not long enough to justify throwing out batteries. I have since switched to rechargeable AA Lithium batteries and those last remarkably longer – maybe double.

1 Like

Thanks for this write up. I have the same scenario, where I would like to lock/unlock from HA, but cant. My feedback -

Second scenario - non-starter. We bought this lock specifically for Homekey. No homekey, no point.

First Scenario - here’s the only way to lock/unlock from HA successfully. You can create virtual switches in HA and expose to HomeKit, and use HomeKit automations to sync them. The problem is that there’s a race condition then. A lock may cycle through lock and unlock constantly. The workaround, which is crappy, is to only sync from state from actual lock to virtual switch (from HomeKit). If you want to lock from HA, you need a second switch (I call it an activator) that actually triggers a HomeKit automation to lock. Then you shut the activator off. It works, but its clunky.

Third Scenario - what’s providing bluetooth? Is it a nearby AppleTV or HomePod? Also, can you see from Schlage who exactly is unlocking the door, and if they’re using HomeKey? That’s one of my biggest gripes - I want to automate if I, or a member of the family, physically unlock the door, to disarm the system. Cant do it from Apple Home. I can see from notifications who did it, but cant use that info in an automation.

It looks like the Schlage app itself shows which access code was used to unlock the door as well as if HomeKey was used – but not whose HomeKey it was. None of that is exported to HA using the Schlage cloud integration, however. All I see in HA is “locked” or “unlocked” with no indication who or how.

And yes, the bluetooth in question for the “fully working” scenario is coming from a HomePod Mini. I’m not 100% certain if HomeKit in the Schlage log would even work without a Home hub of some sort – I never tried it, in any case.

so frustrating we can’t have an easy way to use homekey and home assistant.

1 Like

Is there no way to get the thread share mode turned on to pull in the matter identity into Home Assistant?

It paired with thread/matter with Apple HomeKit and I have keys (secondary home keys with other family members don’t work!). But now I can’t find the option in the Schlege accessory in Apple Home to put it in pairing/sharing mode.

I just got one of these locks and not sure if anything has changed since you wrote this guide but I followed your process for combination 3 and my lock is connected via Thread according to the Eve app.

1 Like

I confirm. Still on Thread using method 3.

Adding one more datapoint here to confirm thread works with homekey and home assistant on this lock. Wanted to post here in case someone else stumbles on this thread in the future!

I originally had a Gen 1 version of the appletv 4k. On that, the Eve app showed it was connected via Bluetooth. Battery life was ok for almost a year (replacing every 3 months or so), then Schlage pushed an update and suddenly batteries died every 2 weeks, even after a factory reset.

Turns out only the gen 2 and 3 appletv 4k models can be used as a thread router in HomeKit. As soon as I set up my new gen 3 model, both of my locks moved over to thread according to the Eve app. Fingers crossed the battery life improvement is as good as people claim!

I chose a slightly different route. I don’t need things like battery life in home assistant, I just wanted the ability to see the lock status in HA plus the ability to lock and unlock.

To do this I first paired the lock with HK directly. Then I created a template lock in HA:

  1. Create 3 helper toggles
    a. The first one is called “X Door is Locked”. This will represent the actual state.
    b. The second one is called “Lock X Door”. When enabled, will lock.
    c. The third one is called “Unlock X Door”. When enabled, will unlock.
  2. Create an automation in HA
  • This automation will reset the second and third toggles
  • I added the second and third toggle as trigger (when it turns on) with a 1s delay.
  • As an action I turn them both off.
  1. Expose the 3 switches to HK.
  2. Setup 4 automations in HK:
    a. When lock is locked, enable “X Door is Locked”.
    b. When lock is unlocked, enable “Y door is Locked”.
    c. When “Lock X Door” is enabled, lock the lock.
    d. When “Unlock X Door” is enabled, unlock the lock.
  3. Lastly, create a template lock in HA. In your configuration.yaml add:
lock:
  - platform: template
    name: X Door
    unique_id: x_door
    value_template: "{{ is_state('input_boolean.x_door_is_locked', 'on') }}"
    lock:
      service: input_boolean.turn_on
      target:
        entity_id: input_boolean.lock_x_door
    unlock:
      service: input_boolean.turn_on
      target:
        entity_id: input_boolean.unlock_x_door

This is not ideal but it does enable you to control the lock and see its status from HA.

I’m eagerly awaiting the reports on the battery life when using option 3 however :crossed_fingers:

2 Likes

Apparently when you add the lock to HomeKit via thread after first setting it up in the Schlage app (over WiFi), the lock is both connected to wifi and thread. My batteries drained 3-4% PER DAY when connected via method #3.

Once I figured that out, I reset the lock and only connected with HomeKit. Battery hasn’t dropped at all in the last 12hours or so, which is promising, but it’s still a little early to say for certain if the issue is resolved for me.

Looks like the only option for me is to control the locks via HomeKit or try to integrate the hacky workaround posted above (thank you for the detailed instructions btw - I don’t have much free time these days to tinker with this stuff but will definitely try it out as soon as I can).

It’s a shame the Aqara u100 or Aqara u50 didn’t exist at the time, but I needed new locks and at least the Schlage ones work well enough and might finally have good enough battery life to not be a constant concern!

1 Like

Is this what happened? My batteries were previously going strong when connected to both WiFi and Thread. I got the notification to change them last month and am being told to change them again after only three weeks. I wonder if the polling in HA is now causing Schlage to poll the lock every time. I really don’t want to give up having the lock in HA via the Schlage app and in Home app via HomeKit.

It does feel like that’s what happened to me. I didn’t even have thread set up on my locks before, so my thinking is something changed on Schlage’s end that is killing batteries much faster.

I’m trying to figure out the hacks way to sync the lock between HA and HomeKit via bridge, but haven’t had much luck yet. I’ve come to terms with leaving the locks on HomeKit since it lets my family control them from the iPhones control panel, but hopefully someone figures out a better way

I followed your seupt to get my Schlage Encode Plus lock status & trigger capability into HA. I’m far from an expert, but it seemed simpler to me to just make a single entity (Toggle Helper) in HA named “X Door Lock”, import it into HK, and then make 4 automation to have them control each other.
• When HK Lock locks, turn on HA Toggle Helper
• When HK Lock unlocks, turn off HA Toggle Helper
• When HA Toggle Helper turns on, lock HK Lock
• When HA Toggle Helper turns off, unlock HK Lock

I’m not super aware of the Templates within HA, but this is working great for me.

I primarily wanted to be able to monitor status of the locks in HA (logging purposes), but I now have more control over the auto-locking (I can turn it off in the Schlage app) based on other automation or entities.

So I think I found out the cause for my battery drain issue for me. I had an automation setup that was triggered based off the status of the lock. The battery drain started around the time I set up that automation and seems to have stopped now that I have disabled the automation. Not sure why this would be the case though as I don’t believe Home Assistant should be polling for the status on every automation check. I will have to keep a closer eye on the battery indicator, but it has only dropped about 3% since I disabled the automation four or so days ago.

Ever since the last firmware update that happened back in June, I noticed my battery usage took a dive. The batteries barely last a month.

I’ve been using method #3 since I installed it in March.

The screenshot of my battery usage shows it starts to go down right around the update rollout.

So looks like my issue was definitely not resolved. Has anybody tried to get comment from Schlage on the issue? I’ve really liked the locks up until this point and just cannot justify buying more if I have to replace the batteries every ~3 weeks.

This might not be an acceptable solution for you, but buying a newer Appletv capable of being a thread router and using the hacky workaround to sync the locks between HomeKit and HA continues to work great for me.

After 45 days using my two locks multiple times per day, battery life dropped 5% on one door and 8% on the other. Using rechargeable envelop batteries though, so %readout isn’t exactly accurate but I would have had to replace batteries twice in the same timeframe back when they were connected to Schlage’s wifi cloud.

Still - seems unacceptable that a manufacturer nerfed the performance of a product with no communication or ability to roll back the update. I wonder if they even know this is an issue yet - I did not reach out to them personally

I’m not sure if it was intentional or not though. I did some digging, and it looks like the Allegion servers communicate with the lock every time a request to update its status is received. I’m not sure if this behavior changed in the June/July update. Home Assistant tries to poll the lock’s info every 5 minutes. If this is new behavior, then the integration (using pyschlage) is likely preventing the lock from going into a deeper sleep to save power.

Fortunately, though, there is a way to subscribe to the lock’s status (seemingly using MQTT) instead of polling every 5 minutes. It seems like the developer of pyschlage has been experimenting with this, but this will require significant changes in the pyschlage library as well as the Schlage integration for Home Assistant.