Good Notifications: When, To Whom, and What to Say
In Lesson 7 you confirmed that a notification from Home Assistant reaches your phone. Now you'll learn to design alerts so they're useful rather than annoying. This lesson is about thinking, not about building an automation.
The notify channel works. That's only the beginning. Most household notification problems don't come from technical failures to arrive, they come from arriving too often, to the wrong people, about the wrong things, at the wrong moment. This lesson will help you avoid that before you start automating alerts.
Plan on about forty-five to fifty minutes. By the end you'll design a few sample notifications on paper: when they should arrive, to whom, with what content, and what you're deliberately not sending. No buttons in the notification and no complicated automations.
This lesson's core rule
Not every event deserves a notification.
An alert should mean something you genuinely want to know right now.
A notification isn't an event log
Home Assistant sees hundreds of changes a day: temperature, a light's state, presence, battery, a window opening. Most of them are the home's normal operation, not a reason to pull your phone out of your pocket. A notification is a signal: something needs your attention or a reaction. Everything else should stay in the entity's history, on a dashboard, or in the logbook.
Worth notifying about: something needs a reaction now or soon, otherwise something happens or gets missed.
Not worth notifying about: a state change that's normal and doesn't need anything from you.
Before you add an alert to an automation, ask yourself: if I hadn't gotten this notification, would something have actually gone wrong? If the answer is "no, I'd just not know about a minor detail," it's probably not a good candidate for a push.
Push, dashboard, or history
Not every piece of information needs to reach the phone. Some things are better shown on a dashboard, and some belong only in history. A notification should interrupt your day only when it genuinely makes sense. A dashboard is good for a calm check of the home's state, and history is for later diagnostics.
| Place | What it's for | Example |
|---|---|---|
| Notification | Something needs attention now or soon. | A water leak, a window left open after everyone's left. |
| Dashboard | Information you want to see when you check on the home yourself. | Temperatures, sensor batteries, light states. |
| History / logbook | Diagnostics and checking what happened earlier. | When a sensor changed state, or when a phone was home. |
Priorities: not everything carries the same weight
Not every alert deserves the same weight. In practice it's worth thinking in three tiers. You don't need to configure technical channels or priorities yet. The point is knowing what's urgent and what can wait.
| Tier | Example | Note |
|---|---|---|
| Information | The washer finished a load. | Useful, but not urgent. Could be a push only during the day and only to someone home, or just a note on the dashboard. |
| Heads-up | The living room window has been open longer than expected and no one's home. | Worth knowing, but doesn't need to wake anyone at 3am if you're home. |
| Urgent | A water leak was detected in the bathroom. | Rare, but serious. Alerts like this should be the exception, not the everyday. |
If everything is urgent, nothing is urgent
When you treat every alert as critical, after a week you stop reacting to any of them. Urgent notifications should be rare.
Who to send it to
Technically a notification goes to a device. Practically it should reach the person it concerns, or who can act on it. Sending everything to every household member is a fast route to spam and to everyone annoying each other.
Good: the washer alert goes to whoever can realistically act on it, say, they're home or they're handling the laundry.
Bad: the same alert goes to every household member, including someone at work who can't do anything about it anyway.
Presence from Lesson 5 can help here, but remember its limits. Don't build logic like "only send when Marek is home" if presence isn't behaving reliably yet. For now, it's enough to plan the recipient on paper and ask: who should really get this alert?
Time of day matters
The same alert at 3am and at 3pm are two different experiences. A note that the washer finished in the middle of the night is a bad idea. A note about an open window when everyone left for work in the morning might make sense.
Daytime: informational and comfort alerts, say, the washer, a package, an open-window reminder.
Nighttime: only genuinely urgent things. Everything else can wait until morning.
You don't need to build time conditions into an automation yet. At this stage it's enough to write down, for each planned alert, whether it should arrive at any hour or only within set hours.
When not to send a notification
Good notifications aren't just about deciding when to send. They're also about deciding when to stay quiet. A system's silence matters, because it's what makes a user take an alert seriously when one finally shows up.
Don't send if the user can't do anything about it.
Don't send if the information is just a curiosity.
Don't send if the same problem has already been reported and nothing's changed.
Don't send if the alert would cause more disruption than it's worth, say, at night for a comfort matter.
Presence as context, not as the only truth
Presence can help decide who to alert and whether it's even worth sending an alert at all. For instance, an open-window reminder makes sense once everyone's left the house. A washer alert makes sense when someone's home. But presence from a phone can be delayed and imprecise, so don't base critical alerts on it alone.
Presence for comfort, not for security
The same rule from Lessons 5 and 6 comes back here. Presence can help you avoid sending an alert to someone who's away, but it doesn't replace a sensor, a lock, or an alarm.
Anti-spam: don't repeat yourself
One problem, one alert. If a sensor flickers or a state bounces around, and an automation sends a notification on every change, your phone turns into a spam generator. It's better to send one reminder, and maybe a second one after a longer stretch of time, than ten within an hour.
In automations you'll later run into the idea of a cooldown, a gap between successive alerts of the same type. For now the rule is enough: if you've already said something once, don't say it again every moment, until the situation genuinely changes.
Good: one reminder about the open window, then silence until it closes or a set time passes.
Bad: an alert every minute while the window's open, even though you already know about the problem.
Repeating versus escalating
If a problem persists, sending the same notification every minute isn't always the best fix. It's better to think in terms of escalation: the first note is calm, a second one after a longer stretch can be clearer, and only truly serious matters get their own rules in the lesson on critical notifications.
Better: one notification, then a second after 30 minutes if the problem's still there.
Worse: the same push every minute until the user turns off notifications entirely.
Wording that helps, not just informs
A good notification answers three questions: what happened, does it concern me, and do I need to do anything. The title says what it's about. The body says what's worth knowing or doing. No entity identifiers, no jargon, no sentence that adds nothing.
Good: title "Living room window open," body "No one's been home for 20 minutes. Check whether you left the window cracked on purpose."
Bad: title "binary_sensor.living_room_window changed," body "state: on."
A notification should lead to a decision
After reading a good notification, you know what to do next. You can act, check, ignore, or set the matter aside. If a message only says "something changed" without helping you decide, it's probably poorly designed.
| Type of decision | Example wording |
|---|---|
| Go check | Water was detected in the bathroom. Check under the sink. |
| Handle it later | The bedroom sensor's battery is at 12 percent. Replace it next time you're nearby. |
| Act at your convenience | The washer finished. You can hang the wash up next time you're in the laundry room. |
Grouping and summaries
Sometimes it's better to send one summary than five separate alerts. Instead of three notifications about three low-battery devices, one: "Three sensors have low battery: living room, hallway, bedroom." Instead of a stream of alerts about every small evening event, one evening summary, if it's even needed at all.
Fewer alerts, more sense
Grouping isn't a technical requirement at the start. It's a way of thinking: does the user need five separate pushes, or one readable message.
Examples of good and bad alerts
| Situation | Good | Bad |
|---|---|---|
| The washer finished | One daytime notification to whoever can realistically act on it. | An alert to every household member at any hour. |
| An open window | A reminder once everyone's left and a few minutes have passed. | An alert every minute while the window's open. |
| Low sensor battery | One summary a week, or once it drops below a threshold. | A push for every single percent of battery. |
| A presence change | No notification, just watch the history. | "Marek left home" every few moments while the GPS flickers. |
How to technically implement anti-spam
The principles from this lesson can be backed by specific Home Assistant mechanisms.
| Problem | Mechanism |
|---|---|
| A brief sensor flicker | for: |
| A repeating alert | a tag or a cooldown |
| Several runs at once | mode: single / restart / queued |
| The problem cleared | clear or update the notification |
| Android alert types | notification channels |
Sent ≠ received ≠ a human confirming
Home Assistant can send a push. The phone can receive it. A human can tap a button. Those are three different things. Sending alone doesn't prove anyone saw the alert.
What can go wrong
You notify about everything: every entity change turns into a push.
You send to everyone: household members get alerts they can't act on.
You wake people at night for no reason: a comfort alert fires at any hour.
You repeat the same alert: no gap between successive notifications about the same thing.
The wording says nothing: you see the push, but don't know what to do with it.
You rely on presence alone: a critical alert built entirely on a phone's signal.
You think only technically: because a push can be sent, you assume it's worth sending. That's a design mistake.
You don't distinguish a dashboard from an alert: calm information ends up on the phone instead of staying on a technical view or in history.
You don't give the user a decision: the notification says something happened, but not whether to react.
No escalation: instead of sensibly repeating an important alert after a delay, you send the same message every moment.
Assignment: design three notifications on paper
To do
☐ List three household situations you'd want to know about from your phone.
☐ For each one, write down: who should get the alert, at what time, and what priority it has.
☐ Write a human title and body for each notification.
☐ For one of them, plan whether and how presence should affect sending it.
☐ For each situation, decide whether it should be a push, a dashboard item, or just history.
☐ For each notification, write down what decision the recipient should make after reading it.
☐ For one alert, plan whether it should repeat after a delay or only be sent once.
☐ For each alert, note when the system should stay silent.
☐ List three events you deliberately don't want pushes about.
☐ Mark which of your three planned alerts could be grouped into a single summary.
Key takeaways
Not every event is an alert, a notification should mean something important right now, not every change in the home.
Priorities matter, if everything is urgent, nothing is urgent.
Send to the right person, not to every household member without a plan.
Time of day and presence are context, the same alert can make sense in the morning and none at night.
Anti-spam and good wording, one readable notification beats five technical pushes.
Push, dashboard, or history, not everything needs the phone, and a good alert leads to a decision.
What's next
In Lesson 9 we'll move on to actionable notifications: buttons inside a notification that let you do something without opening the app. That's powerful, but it also calls for caution, because a button in an alert is a fast, one-tap decision.
For now you have a design for good notifications: you know when to send, to whom, with what wording, and what not to send. That's the foundation worth having before you build automations and buttons on top of it.
