I can agree on this one but want to take is one step further,
I arranged all my notifications and it took me some work but it works.
What I would like to see is a notification center.
I create notifications via automations
and then users can subscribe on which devices they want to receive it and when(timeslot, only when at home, etc…)
and then maybe still have prio messages which you always receive(“Cat is stuck in the dryer and the house is on fire.”)
It would be neat if we could set a specific notify service and defaults for a person entity, then when we want to notify that person, we can just call a notify to that person entity, and use the same defaults.
Maybe each end-user could change their person notify settings?
This WTH should get a Documentation label too.
The OP lists a number of problems with the documentation.
However, there is a lot of room for improving, generalizing, and rationalizing the notification implementation(s)
The companion(mobile) app documentation page is a maze of twisty passages. It isn’t easy to get an overview of what functionality is available and how it would be implemented.
Clearly a lot of the notification functionality evolved through iterations but doesn’t really have a design.
Picture this. You’re writing a notification to notify people in the house that the washing machine is finished.
Specifically, you don’t want people who aren’t in the house to be notified because it’s not relevant to them at all.
Under HA today, you have to:
The current way is clunky and time consuming. I think there is a better way.
Let’s rethink notifications! 
I’m hoping to communicate how I imagine automations could behave under a reimagined automation engine. I’ve written about this in the past, but this is a good chance to rehash.
When we use the (say) notify.notify action, here’s how it could work.
Importantly, when the topology of notification devices changes, actions do not need to be revised by the user to get the same result as before (except for notifying specific devices).
Alongside tracking devices associated with person entities, we can also have notification devices associated with them.
When a notification is sent to a person entity, every device listed as a notification device will receive the notification.
Any notification device that is associated with an area (room/floor/etc.) will receive the notification.
Any notification device listed in a zone (work/school/home) will receive the notification. Presumably, any device that isn’t tracked on the map will be assumed to be zone.home.
Any notification device that is selected will receive the notification.
The user would have the choice of being able to select different criteria. For example, notification devices belonging to a person that are also at home; or devices that are at home or at the office.
The user would have the option of sending the notification that meet all or any of the criteria.
Currently, the notification engine provides a different service for each device. This is messy because there is a slightly different interface depending on whether it’s a TV, iOS, Android, etc.
The notify.notify action will contain a generalised interface where the Title and Message fields will be common across all devices.
Any settings relevant to a specific platform can be enumerated underneath, perhaps responding to the devices that are due to be targeted.
Settings that have to be written out in YAML now (such as critical iOS notifications or groupings) will be brought into the UI.
While the inconsistencies regarding the notify action is something to be solved, an important premise in your post is location/presence tracking. Keep in mind that many users and their significant others don’t want to be tracked. Making a behaviour a default that relies on something that’s optional is perhaps something to think about more.
I think what would help is if more of the notify action’s fields could be templated, since it would be easier to write a single, generic script for what you describe.
I agree that location tracking here is optional. By default, a person is at home unless they have location tracking turned on.
In that case, the need to target a zone would be unnecessary.
Expanding on my previous comment, your exact scenario is what I wanted to solve without going through the complicated setup you described.
I have a generic (but fragile) script to notify all people that are in a targeted zone:
alias: Notify mobile devices for everyone in a zone
mode: queued
icon: mdi:home-alert
description: Sends a notification to all mobile devices for persons in specified zone
fields:
notification_zone:
name: Zone
description: Zone to check for persons
required: true
example: zone.home
selector:
entity:
filter:
integration: zone
notification_message:
name: Message
description: Message to send in notification to the mobile devices
required: true
example: Hello World - Message
selector:
text:
type: text
notification_title:
name: Title
description: Title for the notification to use
required: false
example: Hello World - Title
selector:
text:
type: text
sequence:
- repeat:
for_each: "{{ state_attr(notification_zone,'persons') | list }}"
sequence:
- action: >-
notify.mobile_app_{{ state_attr(repeat.item,
'device_trackers')[0].split(".")[1] }}
data:
message: "{{ notification_message }}"
title: "{{ notification_title }}"
max: 10
I then call that script when the washer or dryer is done (this is the dryer, but the washer automation is the same setup)
alias: Notifications - Notify for dryer done
description: ""
triggers:
- type: turned_on
trigger: device
device_id: DRYERDEVICEIDHERE
entity_id: binary_sensor.dryer_dry_completed
domain: binary_sensor
id: DryerDone
conditions: []
actions:
- action: script.notify_mobile_all_at_home
data:
notification_zone: zone.home
notification_title: Dryer is done
notification_message: Please unload the clothes in the dryer!
mode: single
However this required me to be absolutely sure during device setup to name mobile devices consistently. Specifically, in the companion app under the “Servers & Devices” section where the configuration for my server is, the device name is “NamePhone” for each member of the household. Then the various notify services are named “notify.mobile_app_namephone” (you can check this in the developer tools>actions tab by typing “notify.mobile_app” into the field and see what pops up) and the script to notify everyone in a zone is able to correctly call the various service names.
I could not find a way to script pulling the notify service attached to a device, so that’s the most fragile part of this process. That’s the magic this filter is doing notify.mobile_app_{{ state_attr(repeat.item, 'device_trackers')[0].split(".")[1] }}, pulling the device trackers listed as attached to a person entity and then using the name of the first device tracker as the end of the name of the notify service. This means the name of your device in the companion app MUST match the name of the notify service. I’m saying that again in case anyone tries to replicate this setup.
I strongly suggest allowing People to be in groups that can also be notified instead of having to name individuals only and align this with access control users and groups (so we don’t have multiple sets of groups with differing functionality). E.g. notify all “Admin” users for a system failure, then I can add/remove people into/out of that group for access rights for Admin and receiving notifications for Admins (or create different groups if you need slightly unaligned groups of people).
Also annoying is the fact that the companion apps too often use different configuration for the same functionality (eg images). As a HA user I do not care about the API of iOS or Android.
What about WhatsApp vs Telegram? Or WhatsApp vs an iOS push notification?
What you ask for would be ideal, but can only work for common features. There are always platform differences.
They did some word to standardise and simplify actionable notifications, which was good.
The same principle applies. If multiple platforms allow the same feature I want a unified API.
Currently the notification integration expects (according to the docs) a title and only tells you that target and data may or may not be supported by an implementation. Does WhatApp let’s you set a title?
So IMHO the notification integration could provide an image attribute. Or why not even a critical? This way I can send the same notification to different implemenatations and each would do the best to match my intention.
BTW, when I asked that Android and iOS to standardize my post got shot shot down with a not-planned. Nice to see that I got for attachments what I wanted, though not for critical.
@masitito I totally agree! Differences in underlying APIs and platforms shouldn’t be exposed, unless there is absolutely no other possibility. E.g. with things like title, this could be implemented everywhere. If the underlying platform doesn’t have a separate title field, HA could simply prepend the title to the main message. I can imagine similar solutions are possible for other areas where platforms differ.
I much rather prefer the freedom to do this or not.
Sure. Who said “title” (or whatever) should be a mandatory field?
Well, it’s not right now, only message is
Aha, so it’s not only me. This nags me every time I add a notify action. Often the drop down simply refuses to give me the right suggestion because of so many close hits, and I have to go hunting for it on another automation.
You made a suggestion, which I rejected. I responded to what you said. Nothing else.
Yes, the order of events is crystal clear to me. What’s the reason for pointing that out? FYI: I was just taking part in the discussion and did not feel emotional about it, let alone offended or anything. Totally fine that you disagree with my idea, I just thought you might not have realized that the “title” field doesn’t need to be mandatory.
That all said: no matter how it’s solved, I still think the differences between platforms should be hidden from the user, at least for the most common use cases. My suggestion might not be the best solution, but it should be possible to achieve this. (I’m not against keeping the options open to use platform-specific features. I just think that we need to make the simple cases as easy as possible. )
I actually just spent the last few weeks creating a script to make notifications easier. It’s not perfect, but a lot less painful than the current way of sending notifications. Here’s the script in case anyone else wants to try it: Script for easier notifications on mobile and web - Share your Projects! / Scripts - Home Assistant Community.
I’d love to see better notification support in HA too. 