Home Assistant Presence Confidence Before Away Mode: Build One Truth Lane

The ugly version of presence automation is easy to recognize: the alarm arms away while someone is still upstairs, or a critical alert gets suppressed because one phone briefly looked like it was home.

That is usually not an alarm problem. It is a truth problem.

Home Assistant already gives you raw location signals, person entities, zone triggers, and the companion app. The mistake is treating any one of those as final household truth. This guide takes the calmer path: raw presence is input, not truth, and away mode should only read one verified household lane.

If your higher-level routing already depends on mode, alerts, or OpenClaw summaries, keep /guides/home-assistant-openclaw-mode-aware-household-escalation, /guides/home-assistant-openclaw-offline-fallback-control, /guides/home-assistant-openclaw-integration, and /guides/home-assistant-automation-failure-isolation nearby. This page sits underneath those: it makes the occupancy layer trustworthy first.

What this guide helps you finish

By the end, you should have a first-edition presence lane that:

• keeps device_tracker entities as raw inputs,
• lets person entities represent individual people instead of household truth,
• adds a pending-away hold window before the house flips state,
• verifies absence with one more household check,
• and gives every away-dependent automation one canonical entity to trust.

Who this is for and not for

Use this guide if you already run Home Assistant, already have presence entities, and now need a calmer way to decide when the house is actually away.

This is not a catalog of every presence technology, nor a full Home Assistant beginner guide. The job here is narrower: build one dependable occupancy lane before you let away mode, alerts, or OpenClaw consume it.

Start by separating three layers that often get blurred together

The fastest way to calm presence drift is to stop asking one layer to do three jobs.

Official Home Assistant docs support this split cleanly.

• Presence detection creates device_tracker entities from the companion app or network-based methods.
• The person integration merges multiple trackers and gives stationary home trackers priority over GPS while you are home.
• Automation state triggers support hold windows with for, which is useful for candidate states before flipping away.

That means the right design is not “pick the best tracker.” It is “build the layers so no noisy tracker gets to flip the house by itself.”

Step 1: Repair the raw layer before you automate on top of it

Do not write a smarter away automation on top of broken inputs.

The official docs and companion FAQ point to the same preflight checks:

• keep only travel devices attached to a person; remove old phones, tablets that stay home, and shared wall dashboards,
• make sure the companion app still has always-on location permission, background access, and the needed sensors enabled,
• check the home-zone radius if it is unrealistically tight,
• and if you mix stationary trackers with GPS, keep consider_home low enough that stale home signals do not pin a person at home forever.

The recent operator complaints are predictable here too: tiny home zones, drifting phone accuracy, or an extra device still attached to a person can make home and away flap for no real household reason.

A practical preflight list is:

1. Open each person and remove devices that do not actually travel with that person.
2. Review one or two recent device_tracker histories for skipped updates, drift, or long stale periods.
3. Check the companion-app location logs if Android trackers are inconsistent.
4. Sanity-check your home-zone radius against the location accuracy circle you actually see on the map.
5. Decide which trackers are just inputs and which entities will be allowed into the truth lane.

If this preflight already feels messy, stop there and clean it first. A better inference layer will not save a misconfigured person.

Step 2: Create one canonical household-truth lane

This is the move that makes the rest of the guide work.

Do not let alarm automations, notification suppression, quiet-hours logic, or OpenClaw read device_tracker.alex_phone directly. Do not even let them read person.alex directly if the action affects the whole house.

Instead, create one explicit household lane. The simplest reliable first edition is three states:

• home: somebody is believed to be home,
• verifying_away: raw presence says everyone may be away, but the house has not committed yet,
• away: the absence check held long enough and passed verification.

A minimal helper shape looks like this:

input_select:
  occupancy_truth:
    name: Occupancy truth
    options:
      - home
      - verifying_away
      - away

template:
  - binary_sensor:
      - name: Household someone home raw
        device_class: presence
        state: >
          {{
            is_state('person.alex', 'home') or
            is_state('person.sam', 'home')
          }}

That template sensor is still not truth. It is just the raw household candidate built from person entities instead of from individual trackers.

The important rule is architectural: every automation that changes house mode, alarming, or notification suppression should read input_select.occupancy_truth, not the raw sensor.

Step 3: Add hold windows before you let the house become away

The official automation docs give you the right primitive here: use a state trigger with for so raw absence has to persist before anything important happens.

That creates breathing room for exactly the failure you care about: one phone wobbling to not_home for a minute while the person is still upstairs.

A first-edition pattern looks like this:

automation:
  - alias: Presence lane - start away verification
    triggers:
      - trigger: state
        entity_id: binary_sensor.household_someone_home_raw
        to: "off"
        for: "00:03:00"
    actions:
      - action: input_select.select_option
        target:
          entity_id: input_select.occupancy_truth
        data:
          option: "verifying_away"

Three minutes is not magic. It is just a sane starting hold window for “everyone looks gone.” Use longer if your phones drift badly. Use shorter only after you have logs that support it.

One important caveat from the official trigger docs: for timers do not survive a Home Assistant restart or automation reload. If your house restarts often, move the pending-away deadline into an input_datetime instead of trusting an in-memory hold timer.

Step 4: Verify absence with one more household check

Hold windows reduce noise. They do not prove the house is empty.

Before you promote verifying_away to away, check one more thing that makes household sense. The cleanest first check is usually one of these:

• the front or garage door has been closed for a short window,
• interior motion near the exit path has stayed quiet,
• or your arrival buffer zone has stayed clear if you use one.

This is the moment where confidence becomes design instead of wishful thinking.

A simple verified-away promotion can look like this:

automation:
  - alias: Presence lane - confirm away
    triggers:
      - trigger: state
        entity_id: input_select.occupancy_truth
        to: "verifying_away"
    conditions:
      - condition: state
        entity_id: binary_sensor.front_door_contact
        state: "off"
        for: "00:00:30"
      - condition: state
        entity_id: binary_sensor.downstairs_motion
        state: "off"
        for: "00:05:00"
    actions:
      - action: input_select.select_option
        target:
          entity_id: input_select.occupancy_truth
        data:
          option: "away"
      - action: input_select.select_option
        target:
          entity_id: input_select.house_mode
        data:
          option: "Away"

Then add the matching cancel path:

automation:
  - alias: Presence lane - cancel false away
    triggers:
      - trigger: state
        entity_id: binary_sensor.household_someone_home_raw
        to: "on"
    actions:
      - action: input_select.select_option
        target:
          entity_id: input_select.occupancy_truth
        data:
          option: "home"

This is the canonical lane the rest of the house should consume.

• raw trackers feed people,
• people feed a raw household candidate,
• candidate absence starts verifying_away,
• verification promotes to away,
• and any return-to-home signal cancels the candidate quickly.

If you have no door or motion signal to verify against, use a longer hold window and accept that the confidence level is lower. That is still safer than letting one raw tracker arm the whole house directly.

One likely failure path to contain on purpose

The classic failure is not dramatic. It is boring.

Someone is still home. Their phone drifts out of the home zone, or a GPS update lands outside a too-small radius, or the person entity briefly goes not_home. A direct away automation sees that flip and arms the house.

The containment rule is simple:

• raw trackers never change house mode directly,
• person still does not change house mode directly,
• only the verified household lane can do that,
• and the lane must spend time in verifying_away first.

That one structural choice contains a lot of bad days.

Recent operator reports about zone drift and home-zone oscillation are exactly why this matters. The docs tell you what the supported tracking pieces do. Community reports remind you that those pieces still wobble in real homes. Your job is not to pretend the wobble does not exist. Your job is to keep the wobble from becoming household truth.

Wire everything else to the truth lane, not the inputs

Once the lane exists, use it everywhere that matters.

Good consumers of input_select.occupancy_truth == away include:

• alarm arming,
• away-mode helper changes,
• notification suppression that only makes sense when no one is home,
• camera or entry escalation rules that should behave differently in home versus away,
• and any OpenClaw summary or routing logic that depends on occupancy context.

If an automation is still watching device_tracker.* or person.* directly for whole-house decisions, the system is only half-finished.

This is also where OpenClaw sits cleanly. OpenClaw should consume the verified lane and add context above it. It should not be the thing that tries to repair noisy raw presence. Build the trustworthy occupancy layer in Home Assistant first, then let /guides/home-assistant-openclaw-mode-aware-household-escalation and /guides/home-assistant-openclaw-integration sit above it.

Run a practical verification drill before trusting it

Do not call this finished until you force one false-away scenario and one real departure.

False-away drill

1. Leave one tracked person physically at home.
2. Put that phone into a noisy state for a few minutes: disable Wi-Fi, close the app if that is part of your usual failure pattern, or use whatever condition has caused drift before.
3. Confirm the raw tracker or person may wobble, but input_select.occupancy_truth does not reach away.
4. Confirm the house mode, alert suppression, and away-only automations stay in their home behavior.

Real-departure drill

1. Have everyone actually leave.
2. Confirm the raw household sensor goes off first.
3. Confirm the truth lane enters verifying_away before away.
4. Confirm the verification checks pass and only then does input_select.house_mode become Away.
5. Return home and confirm the lane snaps back to home promptly enough that away-only suppression stops.

Restart caveat drill

If you rely on for timers, do one extra test: restart Home Assistant during the pending-away window and make sure your logic still lands safely. If it does not, move the deadline into a helper-based timestamp instead of trusting the in-memory hold.

The repeatable rule to keep

The right sentence to keep after this page is not “my phone says I am home” or “my person entity is correct most of the time.”

It is this:

Raw presence signals are inputs, not truth. Build one verified household lane before you let away mode, alerts, or OpenClaw depend on absence.

If your next problem is brittle action flow after the mode flips, use /guides/home-assistant-automation-failure-isolation. If your next problem is what should happen when the occupancy layer says away, use /guides/home-assistant-openclaw-mode-aware-household-escalation. If you need degraded-control planning once the house is away, use /guides/home-assistant-openclaw-offline-fallback-control.