Heads up: 2023.6 longer has persistent notifications in states: what to do?

Configuration
1

just as a heads up but also as an open question to the fellow HA users of persistent_notifications:

Persistent notifications are no longer stored in the state machine. This means that we no longer create an entity for each persistent notification.

see: Complete persistent notifications migration by bdraco · Pull Request #92828 · home-assistant/core · GitHub

as I have more than a few rather important notification automations in my system, I am puzzled how to proceed after this. Asked a few times in the #beta channel, but it remained silent on that, so here’s for a more open discussion on the matter.

I use the state of persistent_notifications in the frontend, to have conditionals like:

- type: conditional
  conditions:
    - entity: binary_sensor.trash_notification
      state: 'on'
  card: !include /config/dashboard/includes/button/include_button_trash_alert.yaml

based on:

  - binary_sensor:

      - unique_id: trash_notification
        state: >
          {{is_state('persistent_notification.trash_notification_today','notifying') or
            is_state('persistent_notification.trash_notification_tomorrow','notifying')}}

some more backend examples, like:

template:
  - binary_sensor:
      - unique_id: rss_feeds
        state: >
          {% set feed = states.persistent_notification|map(attribute='object_id')|join %}
          {{'rss_feed' in feed}}
        icon: >
          mdi:{{is_state(this.state,'on')|iif('rss','rss-off')}}
        attributes:
          count: >
            {% for state in states.persistent_notification if 'rss_feed' in state.object_id %}
              {% if loop.first %}{{loop.length}}{% endif %}
            {% endfor %}

and

           {% set feed = states.persistent_notification|map(attribute='attributes.message')
                          |list|join(',\n ') %}
            {{feed if feed and 'New Rss feed' in feed else 'No Rss feeds'}}

ofc, there’s more in automations to auto dismiss on existence:

    condition:
      - >
        {{states.persistent_notification.trash_notification_tomorrow is not none}}
      - condition: state
        entity_id: persistent_notification.trash_notification_tomorrow
        state: notifying
    action:
      service: persistent_notification.dismiss
      data:
        notification_id: trash-notification-tomorrow

or a bit more complex, templating the id:

      - service: persistent_notification.dismiss
        data:
          notification_id: >
            trash-notification-{{is_state('persistent_notification.trash_notification_today','notifying')
              |iif('today','tomorrow')}}

or

      - service: persistent_notification.create
        data:
          title: >
            Low ink ({{color}})
          message: >
            {{trigger.to_state.name}} is low
          notification_id: >
            low-printer-ink-level-alert-{{color}}

Id been keen to hear from other users how they will take care of this significant breaking change, and if we have tools at our disposal to replace these.
I did have a look at creating more input_booleans, but it will become very crowded in that regard, with nested booleans etc… not optimal

thanks for your ideas/suggestions

3 Likes
2

I never understood why they were called “persistent” notifications because they are not actually persistent.

You could use a triggered template sensor and local calendars for your trash schedules. Here’s one way:

I use this sensor in conditional cards and notification conditions.

3

I use this now for garbage.

1 Like
4

appreciate the feedback.
Ill revisit the schedules you both suggest, though Ive had reasons not to use those as the dats I get are from another integration, and at that time, I couldnt get a dynamically created calendar based on unapt from another integration.

However, it’s not only about schedules, but really about notifications with a dynamical id. check the print example I posted.

as said, I could maybe create extra input_booleans and then binary on the state of those…
they already are conditional based on some booleans, so it will be a nested boolean situation, and not very obvious.

admit I havent had a look yet how to implement trigger based templates here, that is a very useful suggestion too, thx!

leaves me with some observations on what we do still have:

create
dismiss
mark_read

how are we going to be able to use those, if we can not check/see which notifications are in fact available. (read the now deprecated ‘notifying’)

note: the mark_read service is no longer listed in the docs, but still available in the dev tools

Scherm­afbeelding 2023-06-05 om 22.22.04
Scherm­afbeelding 2023-06-05 om 22.22.04932×920 49.8 KB

1 Like
5

Hi there everyone,

I’ve been reading over the notes for the current upcoming release of Home Assistant in a few days and the persistent notification changes look like they’re going to take out 1/3rd of my automations and appear to have no work around, I suspect it won’t just be me either who handle notifications using these.

The way I currently have notifications set up is if I’m home and not in a do not disturb state such as in a work meeting, on a call, sleeping etc then the TTS detects which room I’m in and then plays the notification alert to that speaker. However, If I’m in a work meeting or call then I want the TTS to be held and then read out to me when those events end. Currently I use persistent notifications and another automation to handle this after counting how many notifications there are and using the correct choose option citing the correct number of persistent notification entity IDs and it works well but with persistent notification entity IDs being removed in the next release, this will no longer be possible.

Usually I don’t mind breaking changes, after all there’s normally an alternative way to get the job done but in this case which seems to me like a standard request to be able to hold TTS in this fashion, I don’t see an alternative. A wait for trigger option within a single notification would be an alternative but only on a singular basis, it would become quite problematic when multiple notifications start firing, for example whilst I’m asleep.

Does anyone know of a work around where TTS, especially multiple can be held, otherwise I’ll be stuck on the current release and will need to put through a feature request.

Apologies if configuration isn’t the correct place for this, I’m unsure whether to put it in here or uncategorized.

Cheers,

6

word has it that Nick Koston, the author of the Pr, will check to see if persistent_notifications cant be enumerated. We had some discussion in #beta, and also Mike Degatano felt this could be a good idea. see Discord for some more on this chat

2 Likes
7

I’m more worried about some persistent notifications such as HTTP login attempt or IP ban I was intercepting to get some messages pushed to my phone through the Telegram bot and so be notified on the fly (otherwise they stay silent until you open the HA interface)… I have to see in practice how it will work after the update but I have some concerns :frowning:

3 Likes
8

Looks like no alternative has been made available in the release. Do you think this is something that could be a feature request or is Nick able to get them back? “If you used these entities in, for example, automations, scripts, or templates, you won’t be able to use these anymore” is simply not an option with no viable work around.

9

I was shocked when I saw that they removed it from the state machine. I was using them in many different ways.
Examples:

  • when someone ring on doorbell but nobody was home it created a persistent notification with a snapshot
  • when missed some critical events in my home
  • etc.

Basically it was one of the integrations which was extremely important and has NO simple alternatives. Why do they remove things that do work? And most importantly has no easy and simple alternative!

2 Likes
10

Not sure, I also just noticed I was using it on the frontend to with my dashboard saying the notification or if there was more than one saying “You have multiple notifications”

I feel like this part of the release should have been held off until a viable alternative or a fix was established.

1 Like
11

I totally agree with you. I don’t know why this rush it was for. Now I’m trying to add mqtt sensors with publish in place of persistent notifications. Until now without success :pensive:

12

This is quite a shame… With SSD Pi users stuck on HAOS 9.5 and now this. As it is I already spent a week in the past 2 months resolving SQL changes (due to the entity_id’s moving tables), seems like with this one there is no way forward for now though

13

Please update us if you have any success

14

Quite funny reading the PR actually. Apparently we’ve all been exploiting a bug which has now been fixed. HASS, now with AntiCheat.

2 Likes
15

for the sake of reference, here is the link to the PR, which would add a new persistent_notification() template

btw, a workaround I use now is:

      - service: persistent_notification.create
        data:
          notification_id: trash_tomorrow_notificatie
          title: >
            {{now().strftime('%d %B')}}: Afvalmelding morgen
          message: >
            {{states('sensor.afvalwijzer_tomorrow')|title}} wordt morgen opgehaald!
      - service: input_boolean.turn_on
        entity_id: input_boolean.trash_tomorrow_notificatie

and

      - service: persistent_notification.dismiss
        data:
          notification_id: >
            trash_{{is_state('input_boolean.trash_today_notificatie','on')
              |iif('today','tomorrow')}}_notificatie
      - service: input_boolean.turn_off
        data:
          entity_id: >
            input_boolean.trash_{{is_state('input_boolean.trash_today_notificatie','on')
                |iif('today','tomorrow')}}_notificatie

can even enumerate them now via the boolean (search on keyword ‘notificatie’)

not the same, I know, but a way forward for now

1 Like
16

why was it removed when so many people are using it?And why was no alternative created before?

17

see the PR (that is listed in the breaking changes) for those reason listed.

apparently the issue was not raised during the process of taking it out, other than the ‘enumerating’ suggestion

I raised the issue during beta, but only during the last couple of moments in the beta cycle did awareness grow…

so, all I can say is: join the beta cycle and help testing these changes

18

This doesn’t appear to be a full work around though if I’m not mistaken. Before with default IDs you could do just persistent notification and any more would just add a +1 for each one, making it very easy to reference consistently in an automation IE if 2 persistent notifications which you could easily monitor via like a counter service then your automation could check the counter to see which TTS to read then do a TTS automation with {{ states (‘persistent_notification’) }} and {{ states (‘persistent_notification_2’) }} so it reads both

I don’t think using custom IDs would work unless we can manage to get it automatically going like +1 like the default ones did.

2 Likes
19

For me unfortunately is not usable because I’ve listed all the persistent notifications in a feed card based on their entity_id. They were dismissables and very flexible.

20

sure, it’s not a perfect copy of persistent notifications, it does work however, in combination as I posted. requires some changes, maybe some extra templates, ys.

the way I see this is: keep banging against the wall stating things dont work anymore. Or, try to adapt, go with the flow, and make things work again for you own use case.

for all details on those notifications in attributes, we might hope and wait for the new template to arrive. Most other things can be replaced using the technique I demonstrated above.

most pressing wish personally is a dismiss-all script. both my yaml, or python scripts that did that relied o the hass.states, so are no longer functional…

we can use the button in the UI drawer ofc, and maybe that isnt too bad.
go with the flow…