Smart locks

Airbnb smart lock automation

A per-guest door code is easy to describe and unforgiving to get wrong. The failure everyone fears is the same one: a guest at the door, in the dark, with a code that does not work.

Most of Homatic’s lock design is about that moment — specifically, about never telling a guest a code is ready when we have not confirmed the lock accepted it.

How a stay gets its code

1. A booking arrives from your calendar or PMS.
2. A PIN is generated for that stay and pushed to the lock.
3. It activates shortly before check-in — five minutes by default, adjustable per property.
4. It is removed after checkout, on a delay you set.

By default a stay gets one PIN across every enabled lock, so a guest with a front door and a side entrance has one number to remember. Switch it off and each lock gets its own distinct code.

When it fails, you hear about it

A push that fails is recorded against the code with the reason the vendor gave, and surfaces on the access-code screen rather than in a log nobody reads. The state you most need is the one most systems omit: the code is still on the lock and we could not remove it. That is the only one Homatic treats as urgent, because it is the only one where someone who checked out still has access.

A jammed deadbolt is not “unlocked”

A lock has four states here: locked, unlocked, jammed, unknown. That matters more than it sounds.

A deadbolt that stalls against the strike plate is jammed: not secured, and needing a person to go look. Modelled as a boolean it collapses into “unlocked”, which reads as an ordinary open door and gets ignored. Homatic reads jams from both signals the hub exposes — the lock attribute and the separate alarm capability, which is where a real jam usually lands — and reports false for both jammed and unknown wherever a boolean is unavoidable. Nothing renders a reassuring “Locked” for a door that is not.

Retry, then tell someone

“Ten minutes after checkout, if the door is unlocked or jammed, try to lock it — and if it still will not lock, text me.”

That rule needs three things most automation engines lack:

• A bounded retry. A watchdog retries for as long as its conditions hold, which is right for “maintain this setpoint” and wrong for “keep trying to lock the door”. Set an attempt cap — three means try, retry, retry.
• An escalation. When the attempts are spent and the door is still open, the actions you marked as escalation run once. Then the rule goes quiet until conditions clear.
• An occupancy gate. “While the property is empty, and at least ten minutes after checkout.”

Mark it once per stay and a cleaner opening that door in the afternoon will not earn a second round of retries and a second escalation text — which is the outcome the rule was written to prevent.

Which lock should you buy?

Ask what you want it to do, not whose logo is on it. Homatic ranks the routes to a given brand by three things: which integrations reach it, which are switched on in this deployment, and what the property already has connected.

The tempting rule — prefer what is already connected — gets per-guest codes wrong. A hub-paired lock can report no code capability at all, so lock and unlock keep working while the codes silently have nowhere to go. That is a failure discovered by a guest at a door, so a stated goal outranks convenience, and nothing is hidden: a route that is unavailable here says so rather than disappearing.