Managing Guests and Rentals

Managing guests and rentals

A short-term rental, a spare room, a cleaner who comes on Tuesdays: somebody other than the household needs a code, but not all the time.

Start by asking what actually changes — because in the most common case, nothing does, and there is no per-visit work at all.

---

The short version

	Permanent user, recurring condition	Rotate a standing user	Add and remove
Use when	The same person, on a repeating schedule	Same number of guests, different people	Ad-hoc, and the count varies
Example	The cleaner, every Tuesday morning	A rental unit's guest	A contractor for one week
What changes per visit	Nothing	Name and PIN	The user itself
Entity IDs	Never change	Never change	Change every time
Automations	Keep working	Keep working	Need repointing each time

Work down that table and stop at the first row that fits. Most recurring access — cleaners, dog walkers, a neighbour who feeds the cat — is the first row, and needs no automation whatsoever.

---

Pattern 0: a permanent user on a recurring schedule

The cleaner comes every Tuesday. The person is not temporary; only the window is. So this is one permanent user with a schedule attached as their condition — and once it is set up, there is nothing to do per visit, ever.

1. Add a user named for the person: Cleaner, or their actual name.
2. Create a schedule helper covering when they should get in — Tuesday 08:00–12:00.
3. Attach it as their condition entity.

Their PIN is written to the locks while the schedule is on and removed when it is off. You do not enable and disable anything; the schedule reverses itself. The code is dead for the other six days without you thinking about it.

Use a calendar instead of a schedule when the pattern is irregular — a cleaner who comes fortnightly, or whose day moves — since a calendar can hold arbitrary dates while a schedule repeats weekly. Everything else is the same.

This is also the right shape for a dog walker, a gardener, a carer, or anyone else who comes back on a rhythm. If the person is not changing, do not rotate or re-create them.

---

Why renaming is free

Lock Code Manager identifies a user internally by the slot number they hold, not by their name. The name is the label you see; it is not the key.

That means renaming a user changes nothing but the label. Their entity IDs stay put. Their history stays attached. Every automation, script, dashboard card and blueprint that references them keeps working. You can rename Guest 1 to Sarah Chen on Friday and back to Guest 1 on Monday, forever, and nothing downstream notices.

Adding a user is the opposite. A new user gets new entity IDs, named after them — text.all_locks_sarah_chen_pin — so anything you want to automate has to be pointed at the new entities each time. Removing them takes those entities away again.

Neither is wrong. But if you find yourself re-editing the same automation every booking, you have chosen the wrong pattern.

---

Pattern 1: rotate a standing user (recommended for rentals)

For when the position is stable but the person is not. Set up once, then change two fields per booking.

Setup

1. Decide how many guests you can have at once — usually one per rental unit.
2. Add that many users, named for the position rather than the person: Guest 1, Guest 2. Leave them disabled, with no PIN. (Staff who come on a rhythm are not guests — give them their own permanent user per Pattern 0.)
3. Attach a condition entity to each so the code only works when it should. A calendar is the natural fit for a rental: the PIN is live during the booking and dead outside it, without anything having to remember to turn it off.

Per booking

Change the name to the guest, set a fresh PIN, and let the calendar handle activation:

action: text.set_value
target:
  entity_id: text.all_locks_guest_1_name
data:
  value: Sarah Chen

action: text.set_value
target:
  entity_id: text.all_locks_guest_1_pin
data:
  value: "{{ pin }}"

Generate the PIN rather than picking one — generate_pin draws from a cryptographic source and rejects sequences, repeats and the common-leak list:

action: lock_code_manager.generate_pin
data:
  length: 6
response_variable: generated

action: text.set_value
target:
  entity_id: text.all_locks_guest_1_pin
data:
  value: "{{ generated.pin }}"

Those entity IDs never change, so this automation is written once.

Fully automated from a calendar

If your booking platform publishes a calendar, the Calendar PIN Setter blueprint does the whole thing: extracts a PIN from the event, sets it when the booking starts, clears it when it ends. Pair it with the Slot Usage Notifier if you want to know when they first arrive.

---

Pattern 2: add and remove per guest

Better when the count varies — a contractor for one week, a house-sitter once a year — and you would otherwise be maintaining standing users who are empty most of the time. If they are coming back on a schedule, they are Pattern 0, not this.

action: lock_code_manager.add_user
data:
  config_entry_title: All Locks
  name: Sarah Chen
  pin: "{{ generated.pin }}"
  condition: calendar.bookings

and when they leave:

action: lock_code_manager.delete_user
data:
  config_entry_title: All Locks
  name: Sarah Chen

Removing a user clears their PIN from every lock in the entry. That is the point of removing them. If you want the opposite — hand the code over and stop tracking it here — pass clear_credentials: false, but understand that the code keeps working and the slot stays occupied.

You do not choose a slot number. Lock Code Manager reads what the locks hold and allocates a free one, so a slot freed by a departing guest is available to the next.

Both actions accept config_entry_title as well as config_entry_id, which makes hand-written automations readable.

---

Keeping guests apart from household codes

You can run two config entries against the same locks — one for permanent codes (you, family, staff) and one for guests — as long as they do not manage the same slot numbers on the same lock.

Worth doing when:

• You want the guest dashboard separate from the household one.
• You want to wipe every guest code at once, by clearing that entry.
• Different people administer them.

Not worth it for two or three codes; one entry is simpler.

---

Things that bite

Locks have a finite number of slots. Adding users fails once the lock is full. Standing users make the ceiling visible up front rather than at the worst moment.

A code left behind still opens the door. Before 5.0, removing a slot did not clear its PIN. If your locks predate that, the upgrade asks about every code it cannot account for — see [[Upgrading to 5.0#unmanaged-codes|Upgrading-to-5.0#unmanaged-codes]].

Do not reuse a PIN between guests. Generate a new one each time. A returning guest's old code should not still work, and the previous guest should not be able to guess the next one.

A condition entity is not the same as disabling. A disabled user's code is removed from the lock. A user gated by a condition still holds their slot; the code is only written while the condition is on. For a rental you almost always want the condition — it reverses itself.

Check the PIN actually landed. Each user has an in sync sensor per lock. If a lock was asleep or unreachable when you set the code, that sensor tells you before your guest does.