Home Assistant Occupancy Automation Rental

It is 11:42 on a Tuesday and you are looking at your dashboard from the couch, two states away from your cabin. The cleaner left at 1:14 this afternoon. The next guest is not due until Friday. The thermostat is sitting at 71, the porch light has been on since dusk, and the bedroom lamp you put on a smart plug is glowing because your previous guest tapped it on the way out and never tapped it off. You are paying for empty. This is the exact problem a thoughtful home assistant occupancy automation rental setup solves — not by guessing, but by combining the booking calendar, door sensors, motion data, and energy use into one signal that says “someone is here” or “the place is empty.” Once Home Assistant knows that reliably, every other automation gets easier and cheaper to run.

Who this guide is written for

This is for the host who already runs Home Assistant on a Raspberry Pi 4, an Intel NUC, or an old laptop in the closet, and who has at least a Schlage Encode or Yale Assure smart lock, an Ecobee Premium or Nest Learning Thermostat, and a couple of TP-Link Kasa KP125 or Lutron Caséta smart plugs paired up. You do not need to be a developer. You do need to be comfortable editing a YAML file and clicking around the Settings panel without panic. If you are still on Alexa-only routines, save this for later and start with simpler workflows — the basics in our Home Assistant short-term rental starter setup are a better first stop. If you have outgrown the Alexa app and want one place that knows whether the property is occupied, this is your next move.

What occupancy actually means in a short-term rental

Occupancy in a normal home is simple: someone is in the house or they are not. In a rental it has at least four states you actually care about, and confusing them is why most automations misbehave.

Vacant between bookings — nobody should be inside, HVAC can drift to a setback, lights stay off.
Cleaner on site — someone is inside, but not a paying guest. Different lighting and HVAC rules apply, which is why a separate cleaner notification flow is worth wiring up.
Booked but not yet checked in — calendar says occupied, sensors say empty. The house is in “welcome prep” mode.
Guest physically present — doors have opened from outside, motion is detected, the lock has been used with the guest code. This is when your guest mode profile takes over and locks down admin features.

Treating these as one boolean is what causes lights to snap off while a guest is in the bathroom or HVAC to fully recover for nobody. Build the model first, then the automations.

The signals you should combine

You do not need indoor cameras or microphones — both are off-limits for guest spaces anyway. You can build a confident occupancy signal entirely from privacy-respecting hardware that hosts already buy.

Smart lock events — Schlage Encode, Yale Assure, or August Wi-Fi Smart Lock all expose “unlocked by code X” events. Tag each guest code with the booking it belongs to. Our Home Assistant smart lock for Airbnb walkthrough covers code rotation in detail.
Door and contact sensors — Aqara MCCGQ11LM or SmartThings multipurpose sensors on the front door and any patio doors give you open/close timestamps.
Motion sensors in shared areas — hallway, living room, kitchen. Aqara P1 or Hue Motion devices are fine. No motion sensors in bedrooms or bathrooms.
Energy use on key plugs — Kasa KP125 or Aqara T1 plugs report wattage. A coffee maker drawing 800 watts at 8 a.m. is a great occupancy hint.
Booking calendar — pull your iCal export from Airbnb or VRBO into Home Assistant’s calendar integration so the system knows the booking window.
Thermostat schedules — Ecobee Premium or Nest Learning Thermostat already know when comfort is supposed to be active; pair their schedule with calendar windows for a tight Home Assistant rental thermostat plan.

Step-by-step setup in Home Assistant

Here is the setup path that has held up across dozens of rental builds. Do these in order; do not skip the testing phase.

Add your booking calendar via the Calendar integration. Use the iCal URL from your booking platform’s host dashboard.
Pair your smart lock and create separate user codes for guests, cleaners, and yourself. Name them clearly: “guest_current,” “cleaner_lead,” “owner.”
Create an input_select called “Property State” with the four values: vacant, cleaner_present, awaiting_guest, guest_present.
Build a template binary_sensor called “Property Occupied.” It returns true when motion has fired in any common area in the last 20 minutes, OR a door opened in the last 5, OR a high-wattage plug is currently drawing power.
Write three automations: lock-code-used promotes state to guest_present; calendar event start sets it to awaiting_guest; calendar event end plus 4 hours of zero occupancy sets it back to vacant.
Run a one-week shadow test: log state transitions to a notify channel but do not let any automation actually change devices yet. Verify the model matches reality.
Once the model looks right, wire actions to it: thermostat setbacks when vacant, porch light disable when guest present (so it does not blast on the bedroom window), water heater plug off when vacant for more than 24 hours.

Privacy, safety, and the guest experience

Two non-negotiables. First, disclose every smart device your rental setup uses on your listing. “Smart lock, smart thermostat, motion sensors in living room and hallway only, no cameras inside, doorbell camera at front entry” is plenty. Hosts who hide sensors get reported, even when those sensors are doing nothing wrong. Second, never put motion sensors in bedrooms, bathrooms, or any space where a guest expects privacy. Occupancy can be inferred plenty well from common areas alone. If your model is “wrong” because a guest spent two hours napping — that is fine. The system will catch back up when they walk to the kitchen for water. You are not running a security operation, you are saving on utility bills and avoiding mistakes. For the wider take on what to disclose and where, our guest disclosure guide walks through exact wording.

Common mistakes hosts make

Treating “door opened” as “guest arrived.” A delivery driver or a cleaner stopping back for a forgotten phone will trigger this. Always combine door events with which lock code was used.
Setting motion timeouts too aggressively. A 5-minute timeout in a living room will trip during a movie. 20 to 30 minutes is more honest.
Letting calendar alone drive HVAC. If a guest cancels last minute and your checkout automation never fired, the house heats or cools for nobody. Always require sensor confirmation, not just a calendar gap.
Hard-killing devices the moment occupancy goes false. Use a delay. Nothing makes a guest more angry than the lights snapping off while they are mid-shower because they did not trip a hallway sensor for 21 minutes.

A practical AI lab note

This is exactly the kind of YAML you can sketch in plain English and have Claude Code or Codex translate into a working template binary_sensor or automation. Describe what you want — “true if any of these motion sensors fired in the last 20 minutes or this door opened in the last 5,” paste in your entity IDs, ask for the YAML. Then drop it into a test instance, not your live one. Test for at least 48 hours with logging only. AI-generated automations are great drafts. They are not great fire-and-forget production code. Treat the LLM as a junior engineer whose work you review.

Host checklist before going live

Calendar imported and visible in the Calendar panel.
Each lock code mapped to a person type (guest, cleaner, owner).
Property State input_select created and visible on a dashboard.
Occupied binary_sensor template tested in Developer Tools.
Notify channel logging every state change for at least one full booking cycle.
Fallback: a manual override switch on the dashboard so you can force vacant or guest_present from your phone.
Listing disclosure updated to mention every device contributing to occupancy detection.

Frequently asked questions

How accurate does the occupancy model need to be?

Aim for “correct within 10 minutes,” not instant. A rental does not need security-grade detection. As long as your model figures out within 10 minutes that the place is empty after a checkout, you save almost all the energy you would otherwise. Guests do not notice a 10-minute warm-up at arrival, especially if the house was at a setback rather than fully off. Over-precision creates flaky automations and confused guests.

Can I do this without motion sensors?

Yes, but accuracy drops. With just a Schlage Encode and an Aqara door sensor you can detect arrivals and major comings and goings, but you will miss the “guest is in the living room watching TV” signal. If you skip motion, lean harder on energy monitoring — a TV plug pulling 60 watts and a Breville coffee maker pulling 800 are great occupancy proxies. Just be careful that an always-on appliance does not give you a false-positive forever.

What happens if Home Assistant goes offline mid-stay?

Your locks, thermostat, and lights all keep working in their last commanded state. Set safe defaults: Ecobee at a moderate occupied setpoint, lights returning to manual control. Pair this with an uptime monitor so you get a text if your Raspberry Pi or NUC stops responding. Do not build automations that assume the hub is always online — assume it goes down once a quarter and design accordingly.

Should I share the dashboard with guests?

No. Build a separate, stripped-down guest dashboard with only the controls they need: thermostat, a few light scenes, maybe a doorbell view. Do not expose occupancy state, lock codes, or sensor data to a guest URL. Use Home Assistant’s user roles to keep your full admin dashboard for yourself only.

Where to go next

Build slow, test for a week, and let the system earn your trust before you let it touch a guest’s thermostat. Once the occupancy model is solid, layer the rest of your stack on top of it — checkout automation, dashboard, thermostat schedules — and use the Related reading above to pick the next piece to wire in.