The short answer: a smart lock for Airbnb or a homestay in Malaysia only saves work if every booking gets its own PIN that opens the door from check-in time and stops at check-out time, without anyone typing it in by hand. The lock is the easy part. The hard part is the dates: extensions, late checkouts and guests who leave without telling you.
Most of what you find when you search for this is a buying guide: which lock, which brand, Wi-Fi or Bluetooth. Vendor pages describe the same promise. Third-party tools that connect TTLock to Airbnb say the code is valid from check-in to check-out and is revoked when a booking is cancelled (Homeit, Minut). Airbnb's own help pages describe a unique code per booking that only becomes active at check-in and expires at the end of the trip (Airbnb).
This article is about what happens after you buy the lock. It describes how our own system, AntlerHub, handles TTLock door PINs for the units we manage in Johor Bahru, including the bugs we found the hard way.
What should a per-booking door PIN actually do?
Four things, and a lot of setups only do the first two:
| Rule | Why it matters |
|---|---|
| One PIN per booking, not one PIN per unit | A shared code that never changes is a key you handed to every past guest |
| Opens at check-in time, not when the PIN is created | A booking made in March must not open the door in March |
| Moves when the stay moves | Extensions and paid late checkouts must stretch the same PIN, not issue a new one |
| Gets deleted after the stay | Old codes pile up on the lock and block the next guest's choice |
Our system works out the window from the stay itself: check-in date at the listing's check-in time, to check-out date at the listing's check-out time, in Malaysian time. If the operator has not set times, it uses 15:00 and 12:00. The window is never moved forward to "now", which is exactly the mistake you make if you reuse code written for long-term tenants, where a PIN can be live the moment it is set.
When does the guest get the PIN?
Not at booking. In our flow the guest gets a PIN when they check in on their guest portal (in buildings where we require eKYC, that comes first; see our check-in guide for guests). The PIN is written to the lock with the stay window, so a guest who checks in on the portal at 10:00 still cannot open the door until the listing's check-in hour.
Which number does the guest get?
By default, the last four digits of the guest's own phone number. If the booking came through WeChat or email and there is no phone, it is the last four digits of the ID or passport they checked in with. If neither is known, it is four random digits from a proper random generator, not the clock.
The reasoning is practical. A guest standing at a keypad at midnight with a flat phone battery still knows the end of their own phone number. The guest can change it to any 4 to 9 digit code in the portal (TTLock keypads accept 4 to 9 digits), and the change keeps the same window.
There is a trade-off we should be honest about: a PIN built from a phone number is easier to guess for someone who knows that phone number. It is only valid for that stay, and it stops working at check-out, but if a guest is worried, they should change it.
What happens when a guest extends the stay?
This is where we had a real bug. In our system a pay-to-extend creates a child booking instead of moving the original check-out date. Until August 2026, every window was calculated from the original booking's own dates. The result: the portal showed the old expiry, changing the PIN shrank the lock's window back to the old date, and remote unlock refused the extra nights.
The fix: the system now walks the chain of bookings to find when the stay really ends, and the extension inherits the parent's PIN. Same PIN, same ID on the lock, new end date. The guest keeps the number they memorised.
A paid late checkout works the same way, on the hour rather than the day. If the receipt says the guest can stay until 15:00, the PIN stays live until 15:00, and later recalculations are not allowed to cut it back to the standard check-out time.
What if the guest just leaves without pressing check out?
Pressing "check out" in the portal deletes the PIN from the lock straight away. Many guests just walk out. For them, a background job looks for bookings whose check-out has passed and still hold a PIN, checks the real end of the stay (including extensions), waits a two-hour grace period, and then deletes the code.
To be clear, the lock already stops accepting the PIN at the end of the window. The clean-up is not mainly about security. It is because a lock full of dead codes eventually rejects a future guest's chosen PIN as "already used", and nobody can tell why.
What if two guests want the same PIN?
On a homestay lock, a stream of guests share one keypad. If the PIN a guest asks for already exists on that lock for another booking, the system refuses with "already used on this lock" instead of quietly taking it over. The guest picks another number. This is rare, but taking over a code that belongs to the guest still sleeping inside is the one failure you never want.
Can the guest open the door from their phone?
Only if the lock has a gateway (or is an NB-IoT model). Remote unlock goes through the internet; a Bluetooth-only lock can hold the PIN but cannot be opened from the portal. Remote unlock is also only allowed after the guest has checked in and only inside the stay window. If you are buying locks for a building where Wi-Fi in the corridor is weak, ask your supplier about this before you buy, not after.
What still goes wrong?
Things we cannot promise away:
- The lock or the TTLock cloud cannot be reached. Setting the default PIN is "best effort": the check-in message still goes out, but it may not contain a code, and a person has to step in. We chose a message without a code over no message at all.
- The unit is not linked to a lock in the system. Then the portal says there is no smart door, which is a normal answer, not an error. Someone has to link it.
- Battery. A lock with a flat battery opens for no PIN at all, however correct the software is. Check battery levels and change them on a schedule, not when a guest calls.
- Cancelled bookings are blocked from getting or changing a PIN, and remote unlock refuses them.
- Dates edited by hand on a channel have to reach the booking in the system first. If your channel sync is unreliable, fix that first (seven things channel sync gets wrong).
Do you need a PMS for this, or is Airbnb's built-in lock feature enough?
If you only sell on Airbnb and your lock is on Airbnb's supported list, the built-in feature may be enough. The problem starts when the same unit also sells on Agoda, Booking.com and direct: each channel would issue its own codes, or none. A PMS that keeps every booking in one calendar can issue one PIN per stay no matter where it was booked, and keep extensions and late checkouts in sync with the lock.
| Setup | One PIN per booking | Follows extensions | Works across channels |
|---|---|---|---|
| One fixed code for the unit | No | Not needed | Yes, but unsafe |
| Changing the code by hand | Yes, if someone remembers | By hand | By hand |
| Airbnb's built-in lock feature | Yes | For Airbnb bookings | Airbnb only |
| PMS connected to the lock | Yes | Yes, if it handles chained bookings | Yes |
How to get started
Before connecting locks to any system, do three things: make sure every unit's check-in and check-out times are set, decide whether you need remote unlock (and so a gateway), and test one full stay, including an extension, on one unit before rolling it out.
If you want to see how this works on your own units, AntlerHub connects TTLock logins per operator and handles the PINs described above. Details and current pricing are at /antlerhub.