Designing a Housesitter Mode: Paused Automations, Temporary Access, and Controls a Stranger Can Operate

Housesitter Mode is not a feature you install. It is a small set of Home Assistant helpers that give a visitor one switch to flip, one bounded number to adjust, and one lock button to press — while the automations behind them read the same state. The goal is not to impress the sitter. It is to make the house behave predictably for someone who has never seen your dashboard and will not read your YAML.

The failure mode this prevents is mundane: you leave for a week, the sitter triggers the motion lighting at 2 a.m., the vacuum starts during dinner, and the thermostat drops to 16°C because your “away” routine assumed an empty house. A second failure mode is worse: you hand-edit automations before a trip, forget to revert one, and come home to a house that no longer responds to you. A helper-based mode avoids both by keeping the mode flag in one place that both the dashboard and every automation can read.

Why a helper, not a hand-edited automation

A toggle helper is a virtual entity that stores an on or off state you set yourself. It is not backed by a physical device, so it survives restarts and can be shared between the dashboard and any automation that needs it. Home Assistant’s documentation describes it as usable “as an adjustable switch for your automations, scripts, and dashboards” and gives “mark guest mode as active” as an example use. That is exactly the shape of Housesitter Mode: one state, many readers.

The alternative — editing each automation’s trigger or condition before a trip — has no single source of truth. If you miss one, the sitter gets a surprise. If you forget to revert one, you get a surprise. A helper makes the mode a state you can inspect, log, and test.

Create the mode toggle

In Home Assistant, go to Settings > Devices & services > Helpers, select Create helper, and choose Toggle. Name it something the sitter will recognize, such as “Housesitter Mode.” The toggle appears on a dashboard as a switch.

The start-up behavior is a safety decision, not a default to accept. By default, a toggle helper restores the state it had before Home Assistant stopped, and if there is no state to restore it starts as off. You can instead force it to always start on or always start off.

Which is right depends on which failure you fear more:

Restore previous state (default): a power cut during the trip re-enters Housesitter Mode when Home Assistant comes back. The sitter arrives to a house that is already paused. The risk is that the mode is still on after the sitter leaves and you return to a house that ignores you.
Always off: any restart returns the house to normal automations. The sitter may arrive to motion lights and a vacuum schedule. The risk is the opposite: the mode silently ends and the sitter gets the full routine.

I have not seen a case where “always on” is the right choice for a mode that pauses automations. It means a restart during your absence silently re-pauses the house, and you may not notice until you are home. Pick restore or always-off, and write down which you picked and why.

Add a number helper for the access window

The sitter needs to set one value — how long the guest Wi-Fi stays on, or how long the temporary access window lasts. That belongs in a number helper, not in a text note on the fridge.

A number helper stores a numeric value you set yourself and appears on a dashboard as a slider or a numeric input box. Its min and max are required, step defaults to 1 with a smallest value of 0.001, and mode can be box or slider. A slider with a sane range is harder to misuse than a free-text instruction, because the sitter cannot type 900 hours by accident.

Create it the same way: Settings > Devices & services > Helpers > Create helper > Number. Set a range that matches your actual policy — for example, 1 to 12 hours in 1-hour steps — and give it a unit of measurement so the dashboard reads clearly. The value is readable by any automation that needs it, so the same number can drive a guest network schedule, a lock code window, or a notification reminder.

Add a schedule helper for the away routine

A schedule helper creates a weekly schedule from time blocks with defined start and end times. The schedule is active when a block starts and inactive when it ends, so it can be used as a trigger or condition in automations and scripts. For Housesitter Mode, the schedule is the away routine: the lights that should still cycle, the times the house should look occupied.

Two rules matter before you rely on it:

Overlapping time blocks on the same day are not allowed and are rejected during configuration validation.
A time block cannot cross midnight. To keep a schedule active across midnight, create two touching blocks on consecutive days — for example, 22:00 to 24:00 on the first day and 00:00 to 05:00 on the following day.

Block boundaries are inclusive at the start and exclusive at the end. A block from 09:00 to 12:00 is active from 09:00:00.000 up to but not including 12:00:00.000. When two blocks touch — one from 07:00 to 10:00 and another from 10:00 to 12:00 — the schedule stays on across the boundary and does not briefly flip to off. That has a practical consequence: an automation triggering on the state changing to off does not fire at a boundary between two touching blocks. If your handover depends on an event at that moment, use the schedule block started trigger instead.

If the away routine does not fit inside a week, or needs to cross midnight in a way that is awkward to split, a schedule helper may be the wrong tool. A plain mechanical timer or a simple switch is sometimes the smarter choice for a single recurring window. The schedule helper earns its place when the routine is weekly, the blocks are within single days, and you want the same state readable by multiple automations.

Gate the paused automations with a condition

A condition checks whether something is true right now. When a trigger starts an automation, Home Assistant checks the conditions. If they are met, the automation runs its actions. If not, the automation stops. The condition is checked once at that moment; if the state changes afterward, it is not re-checked.

That is the mechanism for pausing automations. Add a condition to each automation you want paused:

condition:
  - condition: state
    entity_id: input_boolean.housesitter_mode
    state: "off"

When the toggle is on, the condition fails and the automation stops before its actions run. When the toggle is off, the automation behaves normally. The same pattern works for scripts.

For automations where only part of the sequence should be skipped, use the Condition building block between actions under Then do. That stops the remaining actions when the condition is not met, without preventing the earlier actions from running. This is useful for a routine that should still log or notify but should not turn on lights.

Do not put the mode toggle in the trigger. A condition is the right tool because it does not start the automation when it becomes true; it only gates an automation that a trigger already started. If you want the mode itself to cause something — for example, to send a notification when the sitter arrives — use a separate automation triggered by the toggle’s state change.

Give the sitter a lock they can operate

The lock building block in Home Assistant exposes states and actions that are enough for lock-up without exposing the rest of the system. A lock entity can report locked, locking, unlocked, unlocking, open, opening, jammed, unavailable, and unknown. The actions are lock.lock, lock.unlock, and lock.open. The open action only works on locks that support opening.

On the sitter’s dashboard, a single lock control is usually enough. Keep the rest of the dashboard read-only: a status card showing whether the front door is locked, and a button that locks it. The jammed state is worth surfacing, because a sitter who sees “jammed” knows to check the door rather than assume it locked.

I am not naming a specific lock model here. The building-block documentation describes the generic states and actions, not any particular device’s features. Check your lock’s integration page for what it actually supports before promising the sitter a button that does something.

Notify on the states that matter

Notifications are how you find out that the mode was turned on, that the door was left unlocked, or that the access window is about to expire. Use notify.send_message with a specific notify entity when the destination matters. Avoid notify.notify, which is shorthand for the first notify action Home Assistant can find; the destination is not explicitly selected and the message might not be sent where you expect.

A useful pattern is a persistent notification for the sitter and a phone notification for you. The persistent notification appears in the Home Assistant notifications panel, so the sitter sees it on the dashboard. The phone notification reaches you. Both can be sent from the same automation.

Test the notification action before the sitter arrives. Go to Settings > Tools > Actions, choose the action you want to test, select one or more targets, enter the message text, and select Perform action. A notification path that has never been exercised is not a notification path.

Test the mode before the sitter arrives

A mode that has never been exercised in both states is not a mode, it is an assumption. The test procedure is short and worth doing the day before you leave:

Turn the mode toggle on. Walk through each automation you intended to pause and confirm it does not run when its trigger fires. If you can, trigger it manually from the automation editor.
Turn the mode toggle off. Confirm the same automations run normally. This catches a condition that was written with the wrong polarity.
Check the schedule’s next_event attribute. It should match the next intended window. If it does not, the blocks are wrong or the time zone is off.
Test the notification action from Settings > Tools > Actions. Confirm it arrives on the device you expect.
Test the lock control. Lock and unlock from the dashboard, and confirm the state updates. If the lock reports jammed, resolve that before the sitter arrives.
Restart Home Assistant and confirm the mode toggle returns to the state you chose. This is the step that catches a start-up behavior you did not intend.

If any step fails, fix it before the sitter arrives. The point of the test is to find the failure while you are still there to fix it.

What to leave the sitter

The handover is one dashboard and one written note. The dashboard has the mode toggle, the access-window number, and the lock control. Nothing else needs to be interactive. The note says what the toggle pauses, what the number controls, and what to do if something looks wrong.

Include a fallback for when the mode is left on after the sitter leaves. The simplest is a reminder automation that notifies you if the mode has been on for more than a set number of days. The number helper can hold that duration, so the reminder is adjustable without editing YAML.

If the sitter is not comfortable with a dashboard, a mechanical timer or a plain switch is the smarter choice for the lights. Housesitter Mode is for the parts of the system that genuinely need coordination — the lock, the access window, the paused routines — not for every device in the house.

FAQ

Can I use one toggle to pause all automations at once?

Not directly. Home Assistant does not have a global “pause all automations” switch that respects a helper. You add the condition to each automation you want paused. That is more work up front, but it is also more precise: you choose which routines pause and which keep running, such as smoke alarms or leak sensors.

What happens to the mode if Home Assistant restarts during the trip?

It depends on the toggle’s start-up behavior. By default, the toggle restores the state it had before Home Assistant stopped. If there is no state to restore, it starts as off. You can change this to always on or always off in the helper’s settings. Choose deliberately and test it with a restart.

Why did my schedule not turn off at midnight?

A time block cannot cross midnight. If you created a block from 22:00 to 05:00, it is invalid. Split it into two touching blocks on consecutive days: 22:00 to 24:00 on the first day, and 00:00 to 05:00 on the following day. The schedule stays on across the boundary when the blocks touch.

Why did my automation not fire at the end of a schedule block?

If two blocks touch, the schedule stays on across the boundary and does not briefly flip to off. An automation triggering on the state changing to off does not fire at that boundary. Use the schedule block started trigger if you need an event at the transition.

Should I use notify.notify or a specific notify entity?

Use a specific notify entity when the destination matters. notify.notify is shorthand for the first notify action Home Assistant can find, so the message might not be sent where you expect. If you want the sitter to see a persistent notification and yourself to get a phone notification, send both explicitly.

Is Housesitter Mode a security feature?

No. It is a coordination feature. It pauses routines and gives the sitter bounded controls. It does not verify who the sitter is, and it does not prevent a determined person from using the controls you gave them. Treat it as convenience and clarity, not as a security boundary.

For a broader look at the small systems that run a household, see How to Audit the Small Systems That Quietly Run Your Week. The same audit habit — one state, one place to change it, one test before you rely on it — is what makes Housesitter Mode work.