WTH is it this complicated to send a notification?

Month of "What the heck?!"
,
1

Trying to send a notification from an automation is a nightmare.

Less technical

Searching for “notif” (to match both “notify” and “notification”) shows, among others:

  1. Persistent Notification: Create
  2. Notifications: Send a notification message
  3. Notifications: Send a notification
  4. Notifications: Send a persistent notification
  5. Notifications: Send a notification via <my_device>

This gives rise to a lot of questions, like:

  1. Why are there 2 different ways (1 and 4) to make a persistent notification, and what’s the difference, if any, between them?
  2. What’s the difference between sending a “notification” (3) and sending a “notification message” (2)?
  3. Can I send a notification to my device with the generic actions (2 and 3) or only with the specific one (5)?
  4. What is a “persistent notification”, and why is Home Assistant concerned with this? As far as I know, it’s actually me (an iOS user) who can control whether the notification I receive is persistent (Banner Style: Persistent) or not (Banner Style: Temporary).

I would greatly simplify this by reducing this list to only 3 options:

  1. Send a notification inside Home Assistant
  2. Send a notification to
  3. Send a notification via
  • Option 1 sends a notification to the notifications section from Home Assistant.
  • Option 2 sends a notification to the currently active device of a person. This is in line with modern approaches of apps like Telegram and Slack, which are only notifying you once.
  • Option 3 sends a notification via a specific device of a person.

More technical

Searching “Home Assistant send notification” on Google yields the “Notifications” page (Notifications - Home Assistant), which looks like the one and only official documentation regarding all notifications, but based on the URL, it looks like it should be named “Notify integration”.

It then mentions a “notify platform” (I have no idea what a platform is in this context, because it surely doesn’t refer to platforms like iOS, Android, which most of us are accustomed with) which is legacy, but fails to mention its newer alternative that we should be using instead of it.

And then continues by mentioning a “notify action”, which adds to all this “notify” confusion.

Then there’s “notify.notify” :exploding_head: which, aside it’s confusing name, looks like it shouldn’t be used, but is not marked as legacy.

2

Great Topic!
Great Suggestions!

Maybe we would need to think more about Option (e.g. send to a persons’ all devices, current active device. High Priority).

But totally agree - it is really not intuitive to set up.

1 Like
3

One important concept that it seems you may be missing is that “notifications” does not just mean the ones you get on your phone. There are currently almost 70 core integrations, as well as a number of custom integrations.

For this and many of the following questions the answer is mostly “History” or “Maintaining backward compatibility”… Legacy actions and integrations that don’t pose direct conflicts or require significant updates to remain functional are rarely removed completely, they just go into development hibernation.

One reason for there being two similar actions related to Persistent Notifications is that Notify groups can only be targeted at services in the notify domain not at the persistent_notification service domain. #4 allows persistent notifications to be included in those groups. Either #1 or #4 can be used interchangeably anywhere else.

#3 is the action notify.notify. Personally, I think its continued existence probably causes more problems than getting rid of it would.

#2 is the new notify.send_message action (see below).

If you want the notification to be sent reliably to the same endpoint… currently only #5… or #6 :wink: (“Send a notification with” is used for Notify Groups)

This has nothing to do with notifications to your mobile device, persistent notifications is a distinct integration that posts notification to the HA dashboard. See link above.

The docs include a Glossary…

That page is for the Notify integration, which, as it states, is a building block upon which other notification integrations are built. The purpose of the page is to provide an overview, not specific instructions for every integration that provide notifications.

Part of the reason the docs are confusing right now is that notifications are undergoing changes to move away from being platform/service-based to being entity-based. When completed, most notifications should use the same action, notify.send_message. That action will be able to be targeted at one or more entities.

Currently these changes have only been made for a subset of the more basic notification integrations, so none of the actions can be deprecated as they are all still in use. It is also possible that some older notification integrations will not be converted. These legacy integrations will still require individual services/actions, so I wouldn’t bet on the dropdown clearing out significantly any time soon.

5 Likes
4

Agree on this one. Should be more easy especially for new users.

The biggest pain I have with them, is the way of ‘actionable notifications’. Why isn’t there a option to just ‘add’ an action to the notification + to set which action will be triggered once it’s pushed.

8 Likes
5

I’m not sure if notify.notify deserves it own WTH.

I agree, if you read the docs it sounds like it should be deprecated and removed.

However, it would be much more useful and sane if notify.notify could be configured to send to your chosen notification target.

That way people just starting out, blue prints, etc. could avoid using a hard coded notification entity at least until they figure out ntofication groups.

6

Personally I’d fine it intuitive to have the ability to target a person entity for a notification and then have that lead to being able to send the notification to all (or even better, some selection) of the device_trackers attached to that person.

I’m currently doing this in a bit of a hack way by making absolutely sure the entity name that can be pulled from the device_trackers attribute matches the name assigned to it for the notify integration but it’s never felt particularly future proof.

notify.mobile_app_{{ state_attr(person.me, 'device_trackers')[0].split(".")[1] }}

It’d make a lot more sense if I could just target the person I want the notification to go to.

2 Likes
7

Just for reference not saying this is a solution or even fully relates to the topic.

On iPhone or iOS devices I have the Home Assistant app and the Apple Homekit app. I am using the home kit bridge integration on Home Assistant. This setup works for me the best so far with the way my phone will connect while on my wifi network or when on the internet how it connects. Originally I had a lot of issues with the Home Assistant app connecting while I was on wifi, with the latest iOS Home Kit and Home Assistant app seem to work flawlessly together, Home Kit has even pulled all of my Home Assistant stuff(even my hacs dual thermostat works perfectly on my iPhone control center).

Currently, Sending a notification via mobile_app works best for me as a single person.
With multiple people and targeting the notifications or if for some reason you need a notification to communicate with some project I’ll say good luck.

8

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.”)

3 Likes
9

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?

3 Likes
10

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.

1 Like
11

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:

  • List every applicable device to be notified.
    • Some of those are owned by a person, while others are communal (e.g., TV).
  • Call a service for each of these devices.
    • Using a slightly different action interface for each device.
  • Wrap around conditional logic for every device you don’t want to receive the notification when a person isn’t home.
    • You might have to do this several times depending, on how many people you’re tracking.
  • Hope you don’t have to change the automation for a long time.

The current way is clunky and time consuming. I think there is a better way.

:rainbow: Let’s rethink notifications! :tada:

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).

Where does the notification go?

1. Notify person/people

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.

2. Notify area(s)

Any notification device that is associated with an area (room/floor/etc.) will receive the notification.

3. Notify zone(s)

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.

4. Notify device(s)

Any notification device that is selected will receive the notification.

5. Mix and match

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.

How will the notifications be built?

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.

14 Likes
12

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.

2 Likes
13

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.

14

Voting here but @stefanlod has amazing suggestion

15

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.

1 Like