You installed a Yale, Schlage, August, or similar smart lock. You added it to Apple Home through the included HomeKit code and it works perfectly: lock and unlock through the Home app, voice commands through Siri, automations trigger on lock state. You then try to add it to Alexa or Google Home. They cannot find it. The manufacturer app shows the lock as online. Why is one ecosystem happy and the others not?
How smart locks reach each ecosystem
Most smart locks expose themselves to multiple ecosystems through different mechanisms:
- HomeKit: usually directly via Wi-Fi or BLE, sometimes through a manufacturer bridge
- Alexa: through the manufacturer’s Alexa skill, which talks to the manufacturer cloud
- Google Home: through the manufacturer’s Google Home integration, again via the cloud
- SmartThings: similar cloud-relay model, or Z-Wave direct for Z-Wave locks
The HomeKit path is local and self-contained. The other ecosystems usually require you to sign into your manufacturer account from inside their app to enable the integration.
Verify the manufacturer integration is enabled
For Alexa: open the Alexa app, go to More, Skills & Games, search for the lock manufacturer (Yale, August, Schlage). Tap the skill and enable it. Sign in with the same account you used in the manufacturer app. The lock should appear within a minute.
For Google Home: open the Google Home app, tap your home, Settings, Linked Services. Search for the manufacturer, link the account, complete the OAuth flow.
For SmartThings: tap Add Device, By Brand, find the manufacturer, link the account.
If the manufacturer is not in the list for that ecosystem, that ecosystem does not officially support that lock. Some locks only support Apple Home and a single other ecosystem.
The Wi-Fi bridge requirement
Many smart locks need a separate Wi-Fi bridge to reach Alexa or Google Home, even though they reach HomeKit over BLE. The Yale Smart Cabinet Lock and the August Smart Lock Pro both have this requirement. If you do not have the bridge plugged in, the lock works locally with your phone but does not reach the cloud-based integrations.
Verify the bridge is plugged in, online, and showing the lock in the manufacturer app. The bridge has its own LED status; check that it is green (or whatever the healthy color is for your model).
The two-account problem
If you signed into the manufacturer app with one email and then signed into Alexa with a different email, the integration cannot find the lock because it is looking in the wrong account. Verify that the email or phone number you used in both places is the same. If not, you have two manufacturer accounts and the lock is in only one of them.
Fix by either consolidating accounts (most manufacturers cannot merge accounts; you have to delete one and re-add the lock to the other) or by re-linking the integration to the correct account.
The HomeKit-only mode
Some users set up their lock in HomeKit-only mode, where the lock never connects to the manufacturer cloud and only talks to HomeKit. This is more private but completely disables Alexa and Google Home integration because those rely on the cloud.
To check: open the manufacturer app. If it says “Lock is offline” or “Connect to cloud” but you can control it from HomeKit, you are probably in HomeKit-only mode. To enable cloud, complete the manufacturer’s cloud setup flow, which usually requires re-pairing the bridge.
Z-Wave locks through SmartThings
If your lock is a Z-Wave lock and you want it in SmartThings, you do not need a manufacturer skill. Pair it directly to SmartThings as a Z-Wave device. The Z-Wave path is local and does not depend on the manufacturer cloud.
However, the same lock cannot be Z-Wave-paired to SmartThings while also being Wi-Fi-paired to HomeKit through a different mechanism. You have to choose one ecosystem as the primary pairing.
The discovery sync delay
After linking the manufacturer integration, the device may not appear immediately in the ecosystem app. Sync usually takes 30 seconds to 5 minutes. If after 10 minutes the lock has not appeared:
- Trigger an explicit sync. In Alexa, say “Alexa, discover my devices”. In Google Home, say “Hey Google, sync my devices”.
- Toggle the integration off and back on.
- Reboot the smart speakers (Echo, Google Home), which can clear stale discovery cache.
Verify in the manufacturer app first
Before troubleshooting downstream ecosystems, confirm the lock is fully operational in the manufacturer app. If the manufacturer app shows the lock as offline or unresponsive, no downstream integration will work. Fix that first by power-cycling the lock’s bridge, checking batteries in the lock, and confirming the lock’s local control still works.
The lock’s privacy mode
Some locks have a privacy mode that disables remote control entirely. When engaged, the lock only responds to keypad or physical key, not to any digital command. This is great for safety but blocks every ecosystem from controlling the lock. Verify privacy mode is off in the manufacturer app.
If voice control works but app commands do not
An odd pattern: “Alexa, lock the front door” works but the lock does not appear in the Alexa app’s device list. This usually means a previous integration is partially active. The cloud knows about the lock (so voice works) but the app’s device list cache is stale. Force-quit the Alexa app, reopen, and the lock usually appears.
The single-app principle for locks
Many users add a smart lock to every ecosystem they have because they can. Then they discover that locks behave inconsistently across ecosystems, with each app showing slightly different state, and a manual unlock from one ecosystem sometimes fails to update in the others for several minutes.
The cleaner approach is to designate one ecosystem as the source of truth for the lock. Use voice control from any ecosystem, but only check status and unlock from the chosen primary. This eliminates the confusion of cross-ecosystem state lag. The broader pattern for handling devices that live in multiple ecosystems is in our cross-ecosystem voice guide.
