Creating automation scenes for your smart lock

I set up smart lock automation with Home Assistant to stop the constant fiddling at the door. I keep it local where I can, avoid cloud-only unlocks, and use presence and door sensors so I do not unlock the door at the wrong time. This is the setup I use, the scenes I run, and the checks I make to keep it sensible.

Pick a smart lock that supports a local API or a mesh protocol Home Assistant can talk to, such as Z-Wave, Zigbee, or a vendor with a documented local integration. I look for a lock that exposes battery level, lock state, and a tamper sensor as entities in Home Assistant. Pair the lock using Z-Wave JS or ZHA integration, or add a local MQTT bridge if the lock speaks MQTT. After pairing, rename entities to readable IDs, for example lock.front_door and binary_sensor.front_door_contact. Test basic control from the Home Assistant UI: call lock.lock and lock.unlock in Developer Tools and watch the state change. If the state lags, check the integration logs and radio range before moving on.

For automation scenes, I translate real behaviour into triggers, conditions, and actions. One routine I use: when my phone connects to my home Wi-Fi and the front door contact is closed, unlock the door between 07:00 and 22:00. A simple automation looks like this in practice: trigger on device tracker state to home; condition that the lock state is locked and the time is within the window; action call lock.unlock. I add a second presence check too, such as a Home Assistant person entity or a BLE tracker. For guests, I use a scene that activates an entry code on the lock, sets a temporary access token in Home Assistant, and logs the event to a persistent notification and the audit log. To avoid unsafe behaviour, require the door contact to report closed before locking or unlocking, or add a manual confirmation for remote unlocks. Test automations by firing the triggers in Developer Tools, watching events under Events → live event stream, and checking the history for the expected state changes.

I also fold a few simple IoT devices into the same scenes. A porch motion sensor can delay auto-lock by 30–60 seconds when someone is leaving. The smart lights can turn on for 2 minutes after unlock so the porch is not dark. For privacy and access control, set locks to local control only where possible, disable vendor cloud unlocks unless you need them, rotate long-lived access tokens every six months, and keep Home Assistant long-lived tokens to the minimum scope that works. Put IoT devices on a separate VLAN or guest SSID so a compromised camera cannot talk directly to the lock. Keep the Home Assistant host patched and use two-factor authentication on the front end. I use a 30–60 second auto-lock, 15-minute temporary guest codes, and log all unlock attempts with timestamps.

If it breaks, the order is usually simple: check entity availability, then look at the integration logger. Add a retry with a short delay and a fallback notification if the lock does not report the expected state. Watch battery levels and set low-battery alerts at around 20 per cent. Review the automation scenes monthly, confirm presence detection is still accurate, and check that no cloud service still has persistent unlock rights. Keep the logic local, use redundant sensors, and treat every remote unlock as something that needs a couple of checks before it happens.

Related posts

Weekly Tech Digest | 06 Jul 2026

Stay updated with the latest in tech! This digest covers AI ethics, auto industry shifts, and the impact of politics on technology, exploring today's pressing issues.

wolfCOSE zero-allocation parsing in embedded C

wolfCOSE looks sensible only if you care about what your firmware actually has to carry. I like that, because on small targets the wrong crypto feature can cost more than the message itself, and there...

restic | v0.19.1

restic v0 19 1: safer FUSE mounts and mountpoint checks, robust backup source and exclude handling, clearer CLI JSON output, Windows SFTP deletion fixes