Why the heck is there no notify.persistent_notification service?

Month of "What the heck?!"
#1

I guess the real question here is why doesn’t persistent_notification leverage the notify platform like all other notification integrations? Seems like it would be great for consistency, usability and approachability to not have persistent_notifications be so strange, especially considering they are likely the first type of notification HA users encounter.

Also would like to be able to create alerts which create persistent notifications as their way of conveying their message. That won’t work right now since persistent notifications are not actually a notification integration and there is no notify.persistent_notification service.

#2

As a workaround you use the RESTful notification platform and the HA REST API, as in this post:

You do need to create a long-lived access token for it to work, but it works quite well.

3 Likes
#3

Nice! I didn’t think about that. Going to bookmark that for later.

#4

Thanks for advertising that useful tip. I just tried it and it works like a charm.

#5

This is also true for mobile notifications.

#6

persistent_notification.create is the service isn’t it?

1 Like
#7

There’s already a notify service for mobile notifications though. I have both IOS and Android apps hooked up to my HA and I see notify services for both types of devices.

#8

Yes this exists. My issue with it is that its not actually built on the notify platform which creates some issues. In addition to being confusing, challenges I have personally encountered with this are:

  1. Cannot create an alert which creates a persistent notification for its message
  2. Cannot create a notify group that also creates a persistent notification
  3. Cannot create an automation which takes in the name of a notification service to use and wants persistent notification to be an option since its service name and interface are different

There’s probably more. And fwiw that workaround @Steven_Rollason listed is a great solution to this and I will leverage it. But still I think its a WTH moment that persistent notifications (the only OOTB notification service available without configuring additional integrations) is not actually a notification service and behaves totally differently.

2 Likes
#9

Alerts and persistent notifications seem to me to have a lot of WTH issues. From my limited understanding @CentralCommand captures a number of them, but I think there are more.

I will try the work around above, but doesn’t it seem like a kludge to have an internal function like alerting/notification dependent on an http transaction within the same code? Of course there is the issue that the notification which could be critical is dependent on the access code working.

#10
1 Like
#11

This is great!
Now that it is implemented and released in 0.117, we can do this:

notify:
  - name: My Notifications Group
    platform: group
    services:
      - service: persistent_notification   # This is the new feature in 0.117!
      - service: mobile_app_oneplus   # Some other notification service

And starting with 0.117 we can also add a Text-to-Speech (TTS) notifications to groups and do this:

notify:
  - platform: tts
    name: say_in_the_living_room
    tts_service: tts.google_translate_say        # assuming you have tts defined (default)
    media_player: media_player.living_room_home_mini
  - name: My Notifications Group
    platform: group
    services:
      - service: persistent_notification
      - service: mobile_app_oneplus
      - service: say_in_the_living_room    #  Cool!
3 Likes
#12

Is it possible to clear a notification created from this notify service?

It looks like the implementation only added a title and message, but unlike the persistent_notification service it doesn’t provide an option for a notification_id, so you wouldn’t be able to do something like call persistent_notification.dismiss.

#13

No not really. You’d have to do something kind of gross like scanning all persistent notifications for the title you used in a template and pulling out the id it picked, something like this:

{{ states.persistent_notification
  | selectattr('attributes.title', 'eq', '<title  you used>') 
  | map(attribute='entity_id')
  | map('replace', 'persistent_notification.', '')
  | list | first }}

It would be nice if notify.persistent_notification used the same model as the mobile notifications and accepted a tag:

title: test
message: test
data:
  tag: persistent_notification_id
#14

Thanks @CentralCommand. That’s unfortunate. I wouldn’t even use a notification, but alerts only support them. Would be nice if they also supported calling a service.

Also while on this tangent, it seems like a design flaw of alerts to specify data at the top level of the alert. If there are multiple notifications on an alert and they all don’t accept the same data I would think that would be a problem.

#15

Yep, I know that pain. I really like alerts but the combination of these two features creates some serious challenges.

I’m guessing you also want to send your notifications to your phone and create them as persistent notifications and discovered data isn’t allowed for persistent notifications? I actually have a solution to that if you’re interested. What I do is I have a bunch of notification groups like this:

- name: 'home'
  platform: group
  services: []
- name: 'mike'
  platform: group
  services: []

Notice that services is completely empty. These do literally nothing by default but they are valid targets in alerts (and anywhere else that accepts a notification service). Critically they also don’t validate the service data so you can have anything you want in data.

Those services may do nothing by default but they still fire a call_service event just like any other service. So you can then make an automation which listens for those events and maps parts of the data to different services like so:

automation:
- id: fdbb59354977476e9f80b6099ed2a5aa_notify_to_script
  alias: Notify to script
  description: When specific notification groups are called translate their service data into a send_notification call
  mode: parallel
  max: 50
  trace:
    stored_traces: 15
  trigger:
    - id: home
      platform: event
      event_type: call_service
      event_data:
        domain: notify
        service: home
    - id: mike
      platform: event
      event_type: call_service
      event_data:
        domain: notify
        service: mike
  action:
    - service: notify.mobile_app_mikes_phone
      data:
        title: "{{ trigger.event.data.service_data.title }}"
        message: "{{ trigger.event.data.service_data.message }}"
        data: "{{ trigger.event.data.service_data.data }}"
    - condition: "{{ trigger.id == 'home' }}"
    - service: persistent_notification.create
      data:
        title: "{{ trigger.event.data.service_data.title }}"
        message: "{{ trigger.event.data.service_data.message }}"
        notification_id: "{{ trigger.event.data.service_data.data.tag }}"

I realize in this example notify.mike looks kind of silly since its basically the same thing as notify.mobile_app_mikes_phone. In my actual automation mike sends to both my android phone and my mac after normalizing the fields that are different for ios vs. android. Which I can share but its a lot more complicated so I didn’t want to distract more on here, figured this conveyed the idea well enough.

EDIT: If you’re trying to dismiss the notification when the alert is over you can do that too. Just set done_message to clear_notification. And then in this automation add a choose which calls persistent_notification.create or persistent_notification.dismiss based on the message.