Home Assistant Local Push Reliability: Verify Delivery Across Reconnects

You are on the same Wi-Fi as Home Assistant. You trigger a test automation that should ping your phone in two seconds. Nothing arrives.

That moment feels mysterious only if you think “local push” is a vague smart-home feature. It is not. It is a specific delivery path: the Companion app has to recognize the current network as home, use the right internal Home Assistant URL, stay registered to the right server, and keep the notification lane healthy enough to accept local delivery.

When any one of those assumptions drifts, the phone may still work sometimes, cloud push may still mask the problem, and actionable notifications may still fail in ways that look random.

This guide is for Home Assistant operators who want the local lane to stay trustworthy across reconnects, app changes, and internal URL transitions. The practical rule is simple: local push only works when the app is talking to the right Home Assistant over the right path, and you should prove that regularly.

If you are designing the broader notification architecture around this lane, pair this with /guides/home-assistant-openclaw-live-notifications-and-triage, /guides/home-assistant-openclaw-mode-aware-household-escalation, and /guides/home-assistant-openclaw-offline-fallback-control.

What this guide helps you finish

By the end of this guide, you should be able to:

• tell whether local push is actually active instead of merely assuming it is,
• recognize the common reconnect and re-registration breakpoints,
• prove local delivery and cloud fallback as two separate paths,
• keep actionable notifications and OpenClaw workflows anchored to the right Home Assistant server,
• run a short reliability drill after app, network, or URL changes.

What local push is and is not

Home Assistant’s mobile notification system is local-first when the app can maintain the right in-network connection. The official developer docs describe the path clearly: Home Assistant tries to deliver the notification locally over the app’s websocket path first, then falls back to platform push when local delivery is unavailable.

That leads to three useful operator conclusions:

• A delivered notification does not prove local push worked. Cloud push may have saved the alert.
• Local push is path-sensitive. The phone has to identify the current network correctly and reach the intended Home Assistant instance over the right internal route.
• Local push is transport, not notification design. It does not fix noisy automations, stale notify targets, or broken acknowledgement logic.

So what local push is not:

• not a generic “same Wi-Fi means it should work” promise,
• not a substitute for reviewing the current notify.mobile_app_* target,
• not a guarantee that an app reinstall or server move preserved the old registration state,
• not the same thing as “my phone got a notification somehow.”

The canonical path: make the local lane explicit first

The cleanest way to harden delivery is to verify one supported path in order and ignore every tempting side theory until that path is green.

1) Lock the app to the right home-network assumptions

In the Companion app server settings, verify these two values first:

• Home Network Wi-Fi SSID
• Internal URL

The app uses those settings to decide when it should treat the current connection as local and which Home Assistant address it should prefer on that network.

Practical guidance:

• Prefer a stable internal hostname or DNS name over a casual IP you may later change.
• If you changed your internal URL recently, assume local push is unproven until you re-check it on-device.
• If your supposed internal URL only works when your WAN, public DNS, or hairpin path is healthy, that is a warning sign. It may still function, but it is not the clean local lane most operators think they have.

This is why internal URL transitions break confidence so easily: the automation still says notify.mobile_app_phone, but the app may no longer classify the network or route the same way it did before.

2) Confirm the current app registration and notify target

Home Assistant creates device-specific notify services through the mobile app integration, typically in the form notify.mobile_app_<device_id>.

That means a reinstall, a device rename, a deleted app entry, or a “start fresh” cleanup can leave you with one of two quiet problems:

• the phone is registered again, but your automation still targets the old notify service,
• the phone now has duplicate or stale app registrations, and you are testing the wrong one.

The Companion FAQ and notifications docs both point to this family of issues. They document old app cleanup, duplicate device cleanup, and the need for unique device names so the right notify target gets created.

Operator rule: before you debug message formatting, actions, sound, or latency, verify that the automation points at the current device registration.

A fast check is to send a manual test from Developer Tools to the exact notify service you expect to own the device now:

action: notify.mobile_app_pixel_9
metadata: {}
data:
  title: "Local push drill"
  message: "Current device registration test"

If you recently reset the app or cleaned up an old app entry, treat the newest registered device and notify service as authoritative and update automations accordingly.

3) Check Local Push status before you test notification content

The Local Push troubleshooting screen in the Companion app is the most useful truth source in this workflow.

On the same trusted Wi-Fi where you expect local delivery, open the app and check whether Local Push is shown as Available.

If it is not available, stop there. Do not spend twenty minutes debugging tags, sounds, actionable buttons, or OpenClaw handoff logic yet. You still have a path problem.

The same screen also exposes local push status counters. That matters because it gives you a concrete verification hook: the lane should not just “feel okay”; it should show evidence of local availability and use.

The likely failure path: reconnects, app resets, and stale assumptions

The most common failure path is not dramatic. It usually looks like this:

1. you change the internal URL, replace a phone, reinstall the app, or clean up old app entries,
2. the phone reconnects and still appears broadly usable,
3. a few notifications arrive by cloud push, so everyone assumes the local lane is fine,
4. the first time you need a clean in-network alert or action round-trip, the drift shows up.

The docs do not call this “drift,” but they do document the ingredients: network classification, internal URL selection, device-specific notify services, old app cleanup, and action events that are tied to the server that sent the notification. The operational inference is straightforward: when those pieces move independently, reliability falls apart.

Symptoms that usually point to this path

• Local Push does not show Available while you are on the expected home Wi-Fi.
• A notification arrives externally, but the same alert is inconsistent on the LAN.
• An automation still targets an older notify.mobile_app_* service after reinstall or rename.
• You have duplicate app/device entries and are no longer sure which one is current.
• Actionable notification events land on the wrong Home Assistant server in a multi-server app setup.

Recovery sequence that usually gets you back to clean state

1. On the phone, confirm the active server entry, Home Network Wi-Fi SSID, and Internal URL.
2. Send a manual notification to the current notify.mobile_app_* target.
3. Check Local Push status again on the same Wi-Fi.
4. If the device was recently reinstalled or reset, remove stale app registrations and old app data per the Companion cleanup guidance.
5. Update automations, scripts, and helpers that still point at an obsolete notify service.

Under the hood, the app registration is a specific device identity inside Home Assistant. You do not need the internal implementation details to fix the problem, but you do need to treat a fresh registration as a real state change, not as a cosmetic reinstall.

The verification path: prove local and cloud separately

The shortest reliable drill is a three-part test.

Test A: prove the local lane

While on the trusted home Wi-Fi:

1. Open the Companion app and confirm Local Push is Available.
2. Send a manual notification to the current device notify service.
3. Confirm the notification arrives.
4. Confirm the Local Push status counters reflect activity.

Use a boring test first. Do not start with cameras, attachments, or branching automations.

action: notify.mobile_app_pixel_9
metadata: {}
data:
  title: "LAN delivery test"
  message: "If this arrived while Local Push was available, the local lane is alive."
  data:
    tag: "lan-delivery-test"

Test B: prove the action round-trip

Now verify that the response path is also healthy. Actionable notifications are only useful if the tap comes back to the intended Home Assistant server.

action: notify.mobile_app_pixel_9
metadata: {}
data:
  title: "Action path test"
  message: "Tap acknowledge so Home Assistant can confirm the return event."
  data:
    tag: "action-path-test"
    actions:
      - action: "ACK_LOCAL_PUSH_TEST"
        title: "Acknowledge"

Then watch for the mobile_app_notification_action event in Home Assistant.

This matters even more if you use OpenClaw for downstream triage. Let Home Assistant own the delivery and acknowledgement proof first. Once the action event is returning correctly, OpenClaw can safely summarize, escalate, or open the next workflow on top of that foundation.

Test C: prove the fallback path on purpose

Now leave the trusted Wi-Fi, or otherwise move into a state where local delivery should not be the primary path anymore.

Send the same simple notification again.

If it still arrives, good: that is your fallback path working. But log it correctly. You have now proven cloud or external push fallback, not local reliability.

That distinction is the whole point of the drill. A healthy operator posture separates:

• local delivery is working,
• fallback delivery is working,
• both are working,
• I only tested one and assumed the other.

How this interacts with actionable notifications and OpenClaw workflows

Actionable notifications do not change the transport rules. They add a response loop on top of the existing Companion connection.

That means:

• if the app is registered to the wrong server, actions can return to the wrong place,
• if the notify target is stale, your automation may be testing the wrong device entirely,
• if local push is broken, an alert may still arrive externally while the operator assumes the whole local workflow is trustworthy.

For OpenClaw-aware operations, the clean split is:

• Home Assistant + Companion app own detection, direct mobile delivery, and deterministic action events.
• OpenClaw owns incident shaping after the alert exists: summarizing a burst, opening an investigation, routing a follow-up, or linking the operator into a richer workflow.

That is the right layering for the three related guides already on this site:

• Use /guides/home-assistant-openclaw-live-notifications-and-triage when you are deciding what belongs in the live lane versus digest or silence.
• Use /guides/home-assistant-openclaw-mode-aware-household-escalation when the same alert should route differently by mode, occupancy, or quiet hours.
• Use /guides/home-assistant-openclaw-offline-fallback-control when you need a degraded-path control lane that survives bigger failures than a stale app connection.

The operator mistake to avoid is using OpenClaw or a secondary channel to paper over an unverified local lane. First prove direct Home Assistant to Companion behavior. Then add higher-level workflow logic.

A short reliability drill you can actually repeat

Run this after any of these changes:

• app reinstall or device replacement,
• internal URL change,
• Home Network Wi-Fi SSID change,
• Home Assistant migration or server rename,
• notification service rename or cleanup.

Five-minute drill:

1. Join the trusted home Wi-Fi.
2. Confirm Local Push is Available.
3. Send one simple local test to the current notify.mobile_app_* service.
4. Send one actionable test and confirm the return event reaches the intended server.
5. Leave the Wi-Fi and send one fallback test.
6. If anything feels ambiguous, audit duplicate app registrations before you trust the lane again.

If local push is not healthy yet, keep your urgent notifications on the regular fallback path and keep your control surface narrow until you restore confidence. For households that need true degraded-operation planning, that is where the offline fallback guide becomes the next move instead of one more round of guesswork.

The repeatable rule

Local push becomes reliable when four things stay aligned:

• the app recognizes the right network as home,
• the internal URL still points at the right Home Assistant,
• the current app registration still owns the notify service you are using,
• and you keep proving local and fallback delivery as separate paths.

That is the standard worth repeating after every reconnect, every phone change, and every internal URL transition: do not trust local push because it worked once. Trust it because you can prove which path delivered the alert today.