Home Assistant + OpenClaw: Live Notifications Without Alert Spam

A good Home Assistant notification system is not an event firehose. It is a triage lane.

A recent r/homeassistant thread about “live notifications” is a useful demand signal: operators clearly want richer, more immediate notification flows, but the conversation also circles the same risk every mature setup hits sooner or later - repeated sounds, duplicated cards, and alerts that teach you to ignore your own house.

The fix is not “send fewer notifications” in the abstract. The fix is to give each class of event the right lane:

• live notification for something that needs attention now,
• digest or summary for noisy but meaningful activity,
• silence for everything that does not change a decision.

Home Assistant should stay in charge of detection, timing, and native device actions. OpenClaw adds value one layer above that: summarizing bursts, routing to the right channel, and helping the operator decide what to do next.

If you still need the integration boundary itself, start with /guides/home-assistant-openclaw-integration. If you are deciding which mobile surface should carry alerts or approvals, also read /blog/openclaw-mobile-access-landscape.

What this guide helps you finish

By the end of this guide, you should have one clean notification lane for Home Assistant events:

• urgent conditions reach your phone quickly,
• noisy bursts get grouped or summarized instead of stacked,
• operators can acknowledge or escalate events,
• OpenClaw only sees the traffic that benefits from summarization or routing,
• and you have a verification loop to prove the lane is timely without becoming background spam.

Who this is for and not for

This guide is for operators who already have Home Assistant detecting useful events and want a better human response path.

It is not a platform-comparison roundup, and it is not generic productivity advice about notifications. The job here is narrower: build a usable alert and triage workflow around Home Assistant with OpenClaw in the right place.

Step 1: classify events before you automate anything

Do this part on paper first. If you skip it, every automation looks reasonable by itself and terrible in aggregate.

Use this default classification:

A practical first pass looks like this:

Live now

• alarm armed/disarmed unexpectedly
• water leak detected
• freezer or fridge above threshold for a sustained window
• garage door left open after a meaningful timeout
• front-door activity while house mode is away

Digest or OpenClaw summary

• repeated motion near the same area
• several battery warnings arriving close together
• multiple doors, windows, or occupancy flips during a short period
• a cluster of device-unavailable events after a network wobble

Silence

• routine presence changes you are already expecting
• every motion event in occupied rooms
• rapid state chatter from flaky sensors unless it crosses a threshold
• any event that does not change what you would do

That last question is the filter that matters: would this notification change a human decision within the next few minutes? If not, it probably belongs in a digest or nowhere at all.

Step 2: separate state-based alerts from event-based bursts

This is the line that prevents most alert spam.

Use state-based notifications when the condition must remain bad

A state-based alert is about a condition that persists. Home Assistant’s state trigger supports waiting for a state to remain true for a period, which is exactly what you want for “still bad” problems.

Good examples:

• garage door remains open for 10 minutes
• freezer temperature remains above threshold for 15 minutes
• a door or window remains open after everyone has left

Minimal pattern:

alias: Garage door still open
triggers:
  - trigger: state
    entity_id: cover.garage_door
    to: "open"
    for: "00:10:00"
actions:
  - action: notify.mobile_app_pixel_9
    data:
      title: "Garage door still open"
      message: "Open for 10 minutes."
      data:
        tag: "garage-door"
        group: "entry-points"
        actions:
          - action: "ACK_GARAGE_DOOR"
            title: "Acknowledge"
          - action: "OPEN_HA"
            title: "Open Home Assistant"

Why this works:

• the for: window suppresses transient noise,
• the tag lets you replace or update the same notification instead of stacking copies,
• the group keeps related alerts visually bundled,
• and actionable buttons give you a real response path.

Use event-based notifications for rare, discrete events

An event-based alert is about something that happened, not something that stayed bad.

Good examples:

• a doorbell press
• an alarm trigger
• a critical automation failure
• a person-detected camera event while the house is in away mode

These should be rare and meaningful. If an event can happen ten times in five minutes, it is usually a bad candidate for raw live push. That is where OpenClaw should start earning its keep.

The rule of thumb

• State-based: page when the condition remains true long enough to matter.
• Event-based: page only when the event itself is rare and decision-changing.
• Bursting events: do not live-push each one; group them and route the bundle to OpenClaw.

Step 3: add grouping, suppression, acknowledgement, and escalation

This is the part that turns notifications into a system instead of a pile.

Grouping and replacement

Home Assistant Companion notifications support tag and group, which are the first controls you should reach for before adding any fancy logic.

Use them like this:

• tag: keep one ongoing issue in one slot, updating it instead of creating a new card
• group: visually cluster a family of related alerts such as doors, cameras, or climate

On Android, the Companion docs also support alert_once, which is especially useful when you are updating an existing notification and want the card to refresh without vibrating or sounding each time.

Practical policy:

• one open issue = one tagged notification
• one subsystem = one group
• repeated updates to the same issue should refresh the card, not re-page the operator

Acknowledgement

Actionable notifications let the mobile app emit events back into Home Assistant. That gives you a clean acknowledgement loop.

Typical pattern:

1. Send the alert with an ACK_* action.
2. Listen for the mobile_app_notification_action event.
3. Flip a helper such as input_boolean.garage_door_acknowledged.
4. Suppress further escalation while that acknowledgement is active.

Example acknowledgement handler:

alias: Garage door alert acknowledged
triggers:
  - trigger: event
    event_type: mobile_app_notification_action
    event_data:
      action: "ACK_GARAGE_DOOR"
actions:
  - action: input_boolean.turn_on
    target:
      entity_id: input_boolean.garage_door_acknowledged

This gives the operator a way to say “I saw it” without pretending the condition is resolved.

Escalation

Escalate when the condition remains unresolved after a second window, not when the first notification exists.

A sane escalation chain looks like this:

1. first live push to the primary mobile device,
2. if still unresolved after N minutes, update the same tagged notification,
3. if still unresolved after another window, send a richer OpenClaw summary to Telegram or another triage channel,
4. only then consider paging a second person or a louder channel.

If you want to react when a notification is dismissed rather than acknowledged, Android Companion can emit mobile_app_notification_cleared. Treat that as a channel-specific enhancement, not a universal rule, because the official cleared-notification event is Android-specific.

Step 4: put OpenClaw in the right place

Home Assistant already does native detection and native mobile push well. OpenClaw should not sit in the path of every raw event.

The better pattern is:

• Home Assistant detects the event or condition.
• Home Assistant decides whether it belongs in live, digest, or silence.
• Only the events that benefit from interpretation or cross-signal context go to OpenClaw.
• OpenClaw summarizes, routes, or escalates them into the best operator channel.

That is consistent with the boundary in /guides/home-assistant-openclaw-integration: Home Assistant owns device truth and deterministic rules; OpenClaw owns interpretation and bounded orchestration.

Where OpenClaw adds value above native Home Assistant notifications

Home Assistant native notifications are enough when:

• one event maps cleanly to one action,
• a short title and message are all you need,
• you want immediate local/mobile delivery.

OpenClaw adds value when the operator needs one or more of these:

• a burst summary: “Front entry saw 7 motion events and 2 door state changes in 4 minutes while the house was Away”
• cross-signal explanation: “These device-unavailable alerts started right after a Wi-Fi AP reboot”
• routing by severity or context: push urgent issues to the phone, send medium-priority clusters to Telegram, leave low-priority items for a digest
• triage help: “This looks like noise from one flaky sensor, not a house-wide incident”

A useful payload to send into OpenClaw is not every raw state change. It is a bounded event bundle with context, for example:

{
  "lane": "triage",
  "kind": "entryway_activity_cluster",
  "window": "5m",
  "count": 9,
  "entities": [
    "binary_sensor.front_door_motion",
    "binary_sensor.doorbell_person_detected",
    "lock.front_door"
  ],
  "house_mode": "away",
  "severity": "review"
}

That structure gives OpenClaw something worth summarizing.

Step 5: choose the right channel for each decision

Do not force one mobile surface to do every job.

Home Assistant Companion app

Best for:

• fastest native push
• lock-screen visibility
• actionable notifications
• local push when your device and Home Assistant can use the internal URL on the same network

Tradeoff:

• great for urgent alerts and single-tap actions
• weaker as a conversational triage surface once several related events need explanation

Telegram with OpenClaw

Best for:

• shared operator channels
• richer summaries
• back-and-forth triage
• handling noisy event bundles without turning the phone lock screen into a scrollback log

Tradeoff:

• usually not the first channel you want for wake-you-up urgency
• better as the second lane for grouped or escalated review

If you want this path, use /guides/telegram-setup.

Control UI or remote dashboard

Best for:

• deeper context after the alert
• reviewing state, logs, or the broader situation
• approvals that need more than a notification button

Tradeoff:

• not a primary paging surface
• strongest as the place the operator lands after receiving a high-signal alert

For that handoff, use /guides/control-ui-auth-and-pairing.

The broader mobile role tradeoffs are covered in /blog/openclaw-mobile-access-landscape.

A simple lane that works for most operators

If you want one sane first edition, use this:

Lane 1: urgent mobile push

Use Home Assistant Companion for:

• leaks
• alarm state changes
• persistent open-entry states
• person/camera events only when away mode makes them meaningful

Rules:

• every live alert gets a tag
• every subsystem gets a group
• anything that updates repeatedly uses alert_once where supported
• every alert has either an acknowledge action or a direct jump into HA

Lane 2: OpenClaw triage channel

Send grouped event bundles to OpenClaw for:

• repeated motion clusters
• several battery or offline events inside a short window
• multiple related state flips that mean more together than alone

Route these to Telegram or another chat/control surface where a short summary is more useful than a phone buzz every 20 seconds.

Lane 3: digest or report

Send low-priority noise into a scheduled summary:

• battery cleanup
• device reliability drift
• overnight environment changes that do not require immediate action

This is the lane most people forget to create. Without it, they keep trying to decide between live push and silence, and the result is usually spam.

Verification: prove the lane is timely but not noisy

Do not stop at “the notification arrived once.” A good notification lane needs an evidence week.

For seven days, track these five checks:

1. Latency: how long from event to first live push?
2. Duplicate rate: how many repeated notifications represented the same unresolved issue?
3. Action rate: how often did an operator use acknowledge, open HA, or escalate?
4. False urgency: how many live pushes should really have been digest items?
5. Missed context: how many triage cases required opening more context because the first message was too thin?

Success looks like this:

• urgent events arrive within the window you intended,
• one unresolved issue usually occupies one notification card,
• repeated motion or activity bursts appear as summaries, not a dozen pings,
• operators can tell the difference between “seen,” “resolved,” and “needs escalation.”

If you fail any of those checks, tune the lane in this order:

1. lengthen the hold window for state-based alerts,
2. move bursty event streams out of live push and into OpenClaw summaries,
3. improve acknowledgement handling,
4. only then add more channels or more rules.

Common failure modes

You are paging on every event instead of every decision

This is the classic mistake. Fix it by reclassifying the event into live, digest, or silence before touching YAML.

OpenClaw is seeing too much raw noise

If OpenClaw is trying to interpret every motion blip, the problem is not the model. The problem is routing. Feed it grouped bundles and persistent-condition summaries instead.

Your notification channel is doing the wrong job

If the operator has to think through context, a lock-screen push may be the wrong final destination. Push urgently, then hand off into Telegram or Control UI for actual triage.

Acknowledged is being treated as resolved

These are different states. An acknowledgement should usually suppress escalation, not clear the underlying condition.

The operating model to keep

The clean model is simple:

• Home Assistant detects and times the event.
• Home Assistant decides whether it is live, digest, or silence.
• OpenClaw summarizes clusters, adds context, and routes the operator to the right surface.
• The operator gets one clean path to action instead of a storm of pings.

That is what “live notifications” should mean in a mature setup.