Home Assistant + OpenClaw: Build a Mode-Aware Household Escalation Ladder

At 2:03 a.m., a person-detected camera event is not one event. It is several possible incidents wearing the same label.

If the house is in away, that push may deserve an immediate snapshot, an acknowledgement timer, and a second escalation if nobody responds.

If the house is in sleep, the same event may deserve a quiet but still urgent push to one adult phone, not a whole-house blast.

If the house is in normal evening occupancy, it may deserve nothing more than a logged snapshot and a morning summary.

That is the point of this guide: the same event should not escalate the same way in every household mode.

Home Assistant already gives you the local truth you need for this - helpers, person entities, automations, conditions, and mobile notifications. OpenClaw belongs one layer above that. It should add context, summarization, and incident shaping when the raw Home Assistant route is too noisy or too flat.

If your baseline notification lane is still messy, read /guides/home-assistant-openclaw-live-notifications-and-triage first. If you are designing the camera side of this pattern, keep /guides/openclaw-home-assistant-camera-and-snapshot-triage nearby. If you still need the integration boundary itself, start with /guides/home-assistant-openclaw-integration. If you also care about degraded-control paths, pair this with /guides/home-assistant-openclaw-offline-fallback-control.

What this guide helps you finish

By the end, you should have a first-edition household escalation policy that:

• changes route by mode, occupancy, quiet hours, and risk context,
• treats acknowledgement as ownership instead of just a button,
• handles camera, entry, leak, power, and device-health events differently,
• keeps Home Assistant as the detector and OpenClaw as the context layer,
• and survives a false-positive drill without waking everybody twice.

Who this is for and not for

Use this guide if you already run Home Assistant, already trust its entities and automations, and now want a cleaner escalation policy instead of one more pile of notifications.

This is not a generic tour of smart-home modes. The job here is narrower: design an escalation ladder that changes human interruption level when the household context changes.

Start with four context inputs, not twenty

A mode-aware system gets worse, not better, when you keep adding states that never change a decision. Use only inputs that actually alter the route.

For most households, the useful set is:

• house mode: home, away, sleep, guest
• occupancy truth: who Home Assistant currently believes is home, usually via person entities and zones
• quiet-hours state: a time-based condition or helper that says “avoid unnecessary wake-ups now”
• risk overlay: a separate high-risk flag for moments when you want a more aggressive ladder than the base mode would normally allow

In practice, many operators model home, away, sleep, and guest with an input_select helper, then keep high-risk as a separate boolean or binary sensor. That shape is usually better than forcing every situation into one giant mode list because risk often acts like an overlay: the house is still asleep, but the escalation policy is temporarily hotter than normal.

A minimal first pass can look like this:

input_select:
  house_mode:
    name: House mode
    options:
      - home
      - away
      - sleep
      - guest

input_boolean:
  high_risk_mode:
    name: High risk mode

You can create those helpers in the UI instead of YAML if that matches how you already manage Home Assistant. The important part is not the storage method. The important part is that every automation can read the same mode and risk truth.

Write the ladder before you write the automation

Do not begin with YAML. Begin with a policy sheet.

If an event family does not behave differently by mode on paper, it will not behave differently in automation either. The clean move is to write one household escalation ladder with event families on the left and modes across the top.

Here is a practical first-edition version:

That table does three things most alerting setups skip:

• it separates inconvenience from consequence,
• it makes quiet-hours exceptions explicit instead of emotional,
• and it forces you to say which classes really deserve late-night interruption.

The table is also where you decide acknowledgement rules. Example: a leak alert can stop repeating after one adult acknowledges it, but it should re-open if the leak remains active for another ten minutes or spreads to a second zone.

The canonical build path in Home Assistant

Once the paper ladder feels right, the Home Assistant side becomes much calmer. The supported building blocks are simple:

1. detect the event with a state or event trigger,
2. read house_mode, occupancy, quiet-hours, and risk state,
3. branch with choose conditions,
4. send a notification with a stable tag so later updates replace it,
5. capture acknowledgement back into Home Assistant,
6. escalate only if the incident remains unowned or worsens.

A stripped-down branch pattern looks like this:

alias: Front porch person escalation
triggers:
  - trigger: state
    entity_id: binary_sensor.front_porch_person
    to: "on"
actions:
  - variables:
      house_mode: "{{ states('input_select.house_mode') }}"
      high_risk: "{{ is_state('input_boolean.high_risk_mode', 'on') }}"
      quiet_hours: "{{ is_state('binary_sensor.quiet_hours', 'on') }}"
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ high_risk or house_mode == 'away' }}"
        sequence:
          - action: notify.mobile_app_primary_phone
            data:
              title: "Front porch person"
              message: "Away/high-risk route. Review now."
              data:
                tag: "front-porch-person"
                group: "security"
                actions:
                  - action: "ACK_FRONT_PORCH"
                    title: "Acknowledge"
      - conditions:
          - condition: template
            value_template: "{{ house_mode == 'sleep' }}"
        sequence:
          - action: notify.mobile_app_primary_phone
            data:
              title: "Front porch person"
              message: "Sleep route. Quiet review."
              data:
                tag: "front-porch-person"
                interruption-level: time-sensitive
      - conditions:
          - condition: template
            value_template: "{{ house_mode == 'guest' and quiet_hours }}"
        sequence:
          - action: persistent_notification.create
            data:
              title: "Front porch person"
              message: "Guest/quiet-hours route. Log for review."
    default:
      - action: persistent_notification.create
        data:
          title: "Front porch person"
          message: "Home mode route. Add to review queue."

The exact actions will vary by your notification surfaces. The important design choice is this: branch once on context, then keep each branch simple. Do not clone five nearly identical automations when one readable policy automation will do.

Where OpenClaw should enter the flow

Home Assistant should remain the authority for detection, presence, helper state, and deterministic mobile actions. OpenClaw helps after that layer, not instead of it.

The clean uses for OpenClaw in a mode-aware escalation design are:

• summarizing bursts: “three exterior camera events in eight minutes while the house is away”
• adding cross-signal context: “front porch person plus side gate open plus no known people home”
• routing by role: sending one explanation to the operator who is on point and a softer FYI to everyone else
• turning repeated weak signals into one incident object instead of five separate pushes
• keeping acknowledgement state legible with a short incident summary or handoff note

What OpenClaw should not do first is become the raw event router for every sensor flip. If Home Assistant already knows the route deterministically, let it route. Use OpenClaw when extra context changes the human decision.

A practical rule is:

• if one event plus one mode is enough to choose the route, keep it in Home Assistant;
• if several weak signals together decide whether a human should care, let OpenClaw shape the incident.

Five event families, written the way a real house feels them

This is where the ladder stops being abstract.

Camera events

For cameras, the routing question is almost never “did motion happen?” It is “does this image change what a human should do right now?”

• In home, most exterior person detections should log or summarize unless paired with an entry sensor or an unusual time window.
• In away, a person-detected event can justify a snapshot push immediately, especially if no known person is home.
• In sleep, the same camera event may be urgent, but the delivery should still be narrow: one phone first, not every tablet and speaker.
• In guest, avoid interior camera or guest-area noise unless you have a clearly documented security exception.
• In high-risk periods, let OpenClaw add a richer summary: recent camera activity, door state, and whether anyone acknowledged the event.

If you want the visual design for this lane, use /guides/openclaw-home-assistant-camera-and-snapshot-triage.

Entry events

Doors, locks, gates, and garage openings deserve a stronger mode split than most households give them.

• home: one push may be enough for an unexpected late-night open state.
• away: immediate alert plus a follow-up if the state persists.
• sleep: treat unexpected entry as urgent, but still route to the smallest waking audience that can act.
• guest: suppress expected guest-room or guest-entry churn, but never suppress perimeter exceptions just because guests exist.
• high-risk: shorten the acknowledgement timer and add cross-check context from occupancy and cameras.

This is also where stable notification tags matter. A door that remains open should update one incident, not create six separate pushes.

Leak events

Leak logic should be boring and aggressive.

Water risk is one of the clearest examples of a condition that deserves state-based escalation rather than endless event spam. Use Home Assistant hold windows where needed for noisy sensors, but once a leak is believed to be real, quiet hours should not hide it.

The better split is not whether to notify. The split is how broadly and how often:

• home: push the nearest responsible operator first.
• away: push all relevant operators because response latency matters.
• sleep: override quiet hours; do not wait until morning.
• guest: same as normal; guest mode should never downgrade water safety.
• high-risk: shorten repeat intervals or escalate to a backup person faster.

Power events

Power incidents are where operators often over-page themselves.

A brief mains flicker at dinner time should not look like a break-in. A sustained outage while the house is away may deserve a calmer first message but a stronger follow-up if climate control, refrigeration, or security coverage is now degraded.

A good first edition is:

• one immediate notification when power state changes materially,
• no duplicate pushes for every dependent device that goes unavailable right after,
• one OpenClaw summary if the outage crosses your “this is now an incident” threshold,
• and a different branch if the house is in high-risk or weather-watch mode.

Device-health events

Routine low battery and temporary offline churn are the classic sleep destroyers in badly tuned systems.

Most device-health events should route to digest by default. Escalate only when one of these is true:

• the device is safety-critical,
• the device is part of your away-mode detection path,
• the device is the only sensor covering a meaningful risk,
• or several device-health failures together imply a larger outage.

This is one of the best places for OpenClaw to help. Five low batteries in one afternoon are usually not five urgent interruptions. They are one maintenance note.

Quiet hours, guest mode, and acknowledgement are policy features, not polish

Most mode-aware systems fail here. They make mode branching look sophisticated, then forget the rules that actually determine whether the system feels humane.

Quiet hours

Quiet hours should change the delivery shape, not erase real risk.

Good quiet-hours behavior:

• suppresses routine device-health noise,
• narrows who gets the first push,
• prefers replacement over repeated sound,
• keeps true safety or security events able to break through.

Bad quiet-hours behavior:

• silences leak and entry incidents until morning,
• lets every low-value event become “time-sensitive”,
• treats sleep mode as a blanket mute.

Guest mode

Guest mode is not a softer copy of home mode. It exists because social context changes what counts as normal household noise.

Use it to suppress or downgrade:

• expected guest entry and exit churn,
• motion in guest-designated areas,
• routine late-night activity that would otherwise look unusual.

Do not use it to suppress:

• perimeter breaches,
• leak or smoke-adjacent problems,
• power incidents that remove safety or comfort in occupied areas.

Acknowledgement

Acknowledgement should mean “a human owns this now,” not “the phone made a sound.”

Home Assistant Companion actionable notifications are the easiest clean path here because the acknowledgement button can fire an event back into Home Assistant. A minimal handler looks like this:

alias: Front porch acknowledgement
triggers:
  - trigger: event
    event_type: mobile_app_notification_action
    event_data:
      action: ACK_FRONT_PORCH
actions:
  - action: input_boolean.turn_on
    target:
      entity_id: input_boolean.front_porch_acknowledged

The policy rule that should sit next to that automation is even more important:

• acknowledgement suppresses repeats for the current incident,
• dismissal is not always the same as acknowledgement,
• unresolved incidents can re-open after a timeout or worsening condition,
• and high-risk or away-mode incidents can escalate to a second operator if nobody takes ownership.

That is how you stop the house from waking two people about the same already-owned problem.

Run a verification drill that includes one false alarm and one bad hour

Do not call this guide finished until you test it under two conditions: a false positive and a late-night interruption.

Use a simple drill sheet:

1. Camera false positive at normal evening occupancy
   • Confirm it does not page the whole household.
   • Confirm it becomes a digest or low-friction review item.
2. The same camera event in away mode
   • Confirm it becomes an immediate push.
   • Confirm the notification carries enough context to decide quickly.
3. The same camera event in sleep mode at 2 a.m.
   • Confirm it wakes the smallest useful audience.
   • Confirm repeat pushes stop after acknowledgement.
4. Guest-mode entry test
   • Confirm expected guest churn is quieter.
   • Confirm perimeter exceptions still break through.
5. Leak or water test
   • Confirm quiet hours do not suppress it.
   • Confirm re-open behavior works if the state persists.
6. Power or device-health cluster
   • Confirm you get one incident, not a storm of dependent failures.
   • Confirm OpenClaw adds summary context instead of multiplying noise.

After each drill, ask one brutally useful question: would I want to receive this exact interruption again at 2 a.m.?

If the answer is no, either the route is wrong, the acknowledgement rule is weak, or the event family belongs in digest instead of live escalation.

What to fix first when the ladder still feels noisy

If your first edition still feels bad, the usual failure is not that you need more AI. It is one of these:

• you created too many modes that never change an action,
• you are routing raw events instead of event families,
• quiet hours are an afterthought,
• acknowledgement does not actually suppress repeats,
• or OpenClaw is being asked to compensate for noisy Home Assistant triggers that should have been filtered earlier.

Fix those in that order.

The reusable rule to keep is simple:

Escalate on consequence, not on event count. The same event should not climb the same ladder in every household mode.