Home Assistant Notifications: The Complete Guide

Home Assistant notifications are the layer that turns a house full of sensors into a system that actually tells you something. In my setup they send a push to the right phone, speak a warning out loud, and — when it matters — override Do Not Disturb, all decided locally by my hub before the internet even gets a vote. Get this layer right and the house talks to you like a good assistant. Get it wrong and it nags you into muting it.

That last part is the trap almost everyone falls into. The first month I ran mobile notifications, every door contact, every motion event, and every automation “success” fired a push. Within a week my thumb had learned to swipe the app’s alerts away without reading them — which meant the one notification that mattered, a leak sensor going wet under the kitchen sink, got swiped away with the rest. I caught the puddle by smell, not by phone. That failure is what turned me from someone who sends notifications into someone who designs them.

This guide is the map for the whole cluster: the channels Home Assistant gives you, which one to reach for in which situation, and how the pieces — actionable buttons, critical alerts, per-person routing, spoken announcements, spam control, presence, and battery warnings — fit into one coherent alerting system instead of eight disconnected automations.

What Are the Notification Channels in Home Assistant?

Home Assistant has four practical delivery channels: mobile push through the companion app, spoken text-to-speech on media players, persistent in-dashboard notifications, and outbound bridges like email, Telegram, or ntfy. Each is a notify service, and the companion app is where 90% of real alerting lives because it runs locally over your LAN when it can.

The mobile channel is the workhorse. Install the official companion app on iOS or Android and it registers a notify.mobile_app_<device> service per phone — that service is what carries push, actionable buttons, and critical-alert flags. The Home Assistant companion app documentation spells out every field the payload accepts, and it is worth reading once end to end.

The second channel is spoken audio. Any media player HA can see — a smart speaker, an old tablet, a Chromecast — can be handed a tts.speak call and it will read your string aloud. It is the channel people underuse and the one that changes how a household experiences the smart home, because nobody has to look at a screen. I cover the full setup in the piece on making your speakers announce what just happened.

The third and fourth channels — persistent dashboard notifications and outbound bridges — are for state you want to see later rather than be interrupted by. A persistent notification sits in the HA sidebar until dismissed; it is perfect for “the vacuum finished” or “backup completed.” Bridges like Telegram or ntfy matter when you want a delivery path that does not depend on Apple’s or Google’s push servers at all.

How Do I Send My First Mobile Notification?

The minimum viable notification is three lines of YAML: call notify.mobile_app_yourphone with a message and a title. Trigger it from any automation and the push lands on your lock screen within a second or two over local Wi-Fi. Everything sophisticated is built on top of that same call.

Here is the shape I started with, wired to a door contact:

automation:
  - alias: "Front door opened"
    trigger:
      - platform: state
        entity_id: binary_sensor.front_door_contact
        to: "on"
    action:
      - service: notify.mobile_app_kenny_phone
        data:
          title: "Front door"
          message: "Opened at {{ now().strftime('%H:%M') }}"

The moment that worked, I did what everyone does: I wired a notification to everything. That is the mistake. A notification is an interruption, and an interruption you did not ask for is spam. Before you add the second automation, decide who the alert is for, whether it needs to interrupt or just inform, and whether it should be able to wake someone at 3 a.m. Those three questions are the entire discipline, and the rest of this cluster answers them one at a time.

One practical note from my own hub: name your notify targets deliberately. I renamed mobile_app_iphone_15 to a person-based alias early on, and it saved me a rewrite later when I swapped phones. Consistent entity naming is the boring habit that pays off across every automation you will ever write.

Which Notification Method Should I Use for What?

The right channel depends on urgency and whether the person needs to act. A leak needs to override silent mode; a “laundry done” nudge does not. Match the interruption level to the real-world stakes, not to how easy the automation is to write. The table below is the decision matrix I keep in my head.

Method	Best for	Interrupts silent/DND?	Needs the cloud?	Setup effort
Standard mobile push	Most alerts: doors, motion, status	No	Push server only (LAN-first)	Low
Critical alert (iOS) / high-priority channel (Android)	Leaks, smoke, security	Yes	Push server only	Medium
Actionable notification	“Do you want to do X?” one-tap responses	Inherits base level	Push server only	Medium
TTS announcement	Household-wide, hands-free events	N/A (audible)	No (local TTS engine)	Medium
Persistent dashboard notification	Non-urgent status to review later	No	No	Very low
Telegram / ntfy bridge	Backup path, non-Apple/Google delivery	Depends on app	Optional self-hosted	Medium

Two things in that table drive every decision in my house. First, the “needs the cloud” column: standard and critical push both still traverse Apple’s APNs or Google’s FCM servers, so if you want an alert path that works when those are unreachable, TTS on a local speaker and a self-hosted ntfy bridge are your two truly local options. Second, the interrupt column is a privilege you ration — if everything can override Do Not Disturb, nothing does, because you will disable the lot.

How Do Actionable Notifications Work?

An actionable notification is a push with buttons. You attach an actions list to the payload, HA fires a mobile_app_notification_action event when the user taps one, and an automation listens for that event to run something. It turns a notification from a read-only alert into a remote control on your lock screen.

The pattern I lean on hardest is “garage left open — close it?” When my tilt sensor reports the garage open past a threshold, I get a push with a Close button; tapping it runs the cover-close automation without unlocking my phone or opening the app. The same shape works for “unknown motion at 2 a.m. — arm cameras?” and “dishwasher done — start the drying fan?” Anything you would otherwise walk to a dashboard to do is a candidate.

The one gotcha that cost me an evening: the action event has no memory of which notification sent it unless you tag it. Give every actionable push an action identifier and, if you send them per person, include the person in the payload so the handling automation knows who tapped. I walk through the full event-listener pattern, including how to clear a notification after it is answered, in the deep dive on tapping the alert to run the automation.

When Should an Alert Override Do Not Disturb?

Almost never — and that is exactly why the few that do matter. On iOS a Critical Alert bypasses the ringer switch, silent mode, and Do Not Disturb, and it requires an explicit flag in the payload plus a one-time permission grant. Reserve it for water, smoke/CO, and genuine security events. Everything else can wait for morning.

In my setup exactly three things are allowed to wake me: a leak sensor going wet, the smoke/CO detector integration tripping, and a door opening while the house is armed-away and nobody is home. That is the entire whitelist. I built it after the opposite failure — a “freezer door ajar” alert I had set to high priority woke the whole house at 4 a.m. over a sensor that had simply drifted out of calibration. Now non-emergencies physically cannot reach critical priority in my notification wrapper.

The mechanics differ by platform: iOS uses a dedicated critical flag with a volume field, while Android routes urgency through notification channels you configure once. The official critical-notifications documentation is the source of truth, and I unpack the iPhone side — including how to keep the permission from silently resetting after an app update — in waking me for leaks, not for lights.

How Do I Send Different Alerts to Different People?

Route by person, not by device. Home Assistant’s person entities each map to one or more device trackers and, through them, to a phone’s notify service. Build a script that takes a person and a message and looks up the right notify.mobile_app_* target, and every automation can address a human instead of hardcoding a phone.

This matters more than it sounds. In a two-adult house, “the back gate opened” should reach whoever is home, not both phones buzzing in the same room, and definitely not the person on a flight. A “kid’s bedtime routine finished” belongs on the parents’ phones only. Once notifications are addressed to people, you can layer presence on top — send to whoever is actually home — and the household stops getting alerts that are none of their business.

The building block is a reusable notify_person script that maps a person entity to their device’s notify service, with a sensible fallback to a whole-house TTS announcement if the target phone is unreachable. I show the full script, including how to fan a single alert out to a dynamic group of “everyone currently home,” in routing the right alert to the right phone.

Can My Speakers Announce Events Out Loud?

Yes, and it is the channel that changes the feel of the whole house. A tts.speak call sends synthesized speech to any media player HA controls, so “the washing machine finished” or “someone is at the front door” is spoken in the room instead of buried in a phone. Local TTS engines mean it works with the internet down.

The trick that makes TTS livable rather than annoying is context. I do not announce everything everywhere — I announce the right thing in the right room at the right volume, and I suppress announcements entirely during quiet hours or when a media player is already mid-song. A speaker blurting “garage door closed” over a dinner-table conversation is exactly the kind of gimmick that gets a smart home unplugged.

For a genuinely local pipeline I run a self-hosted TTS engine so no announcement string leaves the house, and I target announcements to the room where presence sensors say a person actually is. The full walkthrough — engine choice, per-room targeting, volume ducking, and the quiet-hours guard — is in making your speakers say what just happened.

Why Am I Getting Too Many Notifications?

Because most sensors are chatty and most automations fire on every state change. A motion sensor can flip on and off a dozen times an hour; a power-monitoring plug can cross a threshold repeatedly as an appliance cycles. Without debounce, throttle, and quiet-hours logic, each of those becomes a push, and the volume trains you to ignore the channel.

The fix is three techniques layered together. Debounce collapses a burst of state changes into one alert by waiting a beat before firing. Throttle enforces a minimum gap between repeat notifications of the same type — I will get “back door open” once, not every time the sensor re-triggers while the door stays open. Quiet hours simply route non-critical notifications to a persistent dashboard entry overnight instead of a buzz.

This is the single highest-leverage thing you can do to a notification system, and it is why I treat “reduce the noise” as a design goal equal to “send the alert.” My leak sensor caught fire — figuratively — precisely because real alerts were drowning in trivial ones. The complete pattern, with the exact for: durations and template throttles I run, is in debounce, throttle, and quiet hours.

How Do I Trigger Alerts on Who’s Home?

Use real presence, not just “phone joined the Wi-Fi.” Wi-Fi presence flaps — phones sleep their radios, roam between access points, and drop off the network while you are still sitting on the couch. Combining device trackers with a router integration, GPS zones, and Bluetooth or mmWave room sensors gives arrive/leave events you can actually build alerts on.

The classic failure is the “welcome home” light that triggers three times an evening because a phone’s Wi-Fi dropped and rejoined. I hit exactly that, and the fix was to stop trusting any single presence signal. My arrival logic now requires a GPS zone transition plus the phone reconnecting, and departure waits for the zone to actually clear — no more phantom “everyone left” events firing while I am in the garden.

Presence is also what makes per-person routing and TTS targeting smart: alerts follow people to the room they are in, and “everyone left, arm the house” only fires when presence genuinely says the house is empty. The reliable arrive/leave recipe — combining device trackers with mmWave for true room presence — is in notifications that use real presence, not just Wi-Fi.

How Do I Get Warned Before a Sensor Battery Dies?

With one automation that watches every battery in the house at once. Instead of a rule per device, use a template that loops over all entities exposing a battery device class, filters for anything under a threshold, and sends a single digest naming each low sensor. It is the difference between finding out proactively and finding out because a door sensor went silent.

This one is personal. A Zigbee door contact on my back door died quietly, and because a dead battery reports nothing rather than “I’m dead,” the sensor just stopped updating. I did not notice until I checked the logbook a week later and saw the last event was stale. Now a nightly automation walks every battery entity, and any device under 20% lands in one tidy list on my phone — no per-device rules to maintain as I add hardware.

The template approach scales automatically: a sensor added next year is covered the day it joins the mesh, with no automation edit. I share the exact Jinja template, the threshold logic, and how to catch the “reports nothing when dead” sensors separately in low-battery alerts for every sensor in one automation.

What Does a Real Notification Architecture Look Like?

One wrapper, not scattered notify calls. In my hub every alert goes through a single notify_dispatch script that takes a message, a priority, and a target person, then decides the channel: persistent for informational, standard push for normal, critical flag for emergencies, TTS to the occupied room in parallel. Automations never call the mobile app directly.

The payoff is that policy lives in one place. When I decided non-emergencies should never override Do Not Disturb, I changed one script, not forty automations. When I added quiet hours, one guard covered everything. This is the same discipline I apply everywhere in the house — the same rule engine that runs my grow-light schedules and the sauna pre-heat also owns notification policy, because one brain making consistent decisions beats forty automations each reinventing the rules.

If you build nothing else from this guide, build the wrapper first and route your existing automations through it. Then add the pieces — actionable buttons, critical alerts, per-person routing, spoken announcements, spam control, presence, and battery warnings — as policies inside that one dispatcher. That is how eight separate tutorials become one system that survives an internet outage and still tells you what you actually need to know.

Frequently Asked Questions

Keep Building

• Actionable Notifications: Tap the Alert to Run the Automation
• Critical Alerts on iPhone: Wake Me for Leaks, Not for Lights
• Per-Person Notifications: Route the Right Alert to the Right Phone
• TTS Announcements: Make Your Speakers Say What Just Happened
• Cut Notification Spam: Debounce, Throttle, and Quiet Hours
• Arrive/Leave Notifications That Use Real Presence, Not Just Wi-Fi
• Low-Battery Alerts for Every Sensor in One Automation