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

Configuration
41

yes and that is awesome indeed. But we can not 'go and have a look ’ in some system registry (I think) and check whether our automation templates would be correct.
on self made pers noti’s that is easy, as we just need to make sure we use the same in creating and dismissing.

the systems ones remain mysterious (on their id)

besides that, there s scenario where I have an animated frontend element on the condition the pers notify is ‘notifying’. clicking the notification away stops the animation (but does not change the triggering state for the notification). think garbage day, and garbage has been move out. no more animation, but it is still garbage day… etc etc

Ive added booleans for all of those scenarios, and that works ok, until now with the exception of not benig able to turn off the bollena when the pers notify is dismissed. The new Pr will fix that, so almost there!

just discovering the systems id’s (and hope some day an active state) left

and yes, the clear all. Isnt some nifty for loop possible in a script somehow, with the new trigger options?

script:

  dismiss_all_persistent_notifications:
    alias: Clear All Persistent Notifications
    sequence:
      repeat:
        for_each: |
          {{states.persistent_notification|map(attribute='object_id')|list}}
        sequence:
          service: persistent_notification.dismiss
          data:
            notification_id: >
              {{repeat.item}}
    mode: single

or the even nicer equivalent as python script:

for notif in hass.states.entity_ids('persistent_notification'):
    hass.services.call(
        'persistent_notification', 'dismiss',
        {'notification_id': notif.split('.', 1)[-1]})

and then adapt to the new situation?

1 Like
42

Doing the Lord’s work, you are…

One question (and I hesitate to even ask for fear of being greedy)… Somewhere along the way, there was mention of doing something similar for “Repairs”. Is there any possibility that this solution could be extended to pick those up at some point?

43

You’re assuming here. How would it be a mystery if you create an automation that gathers them.

From the trigger, you can see the notification_id, title, message, and created_at.

What else would you need? You can write templates that act upon all that information. You can even use that trigger in a trigger template sensor and store it when you need to.

There’s many options now that this is a valid trigger.

44

I’m not sure, I haven’t looked into that.

45

the idea here being an automation that keeps a registry of all triggered notifications data in some attribute?
must check if somewhere in those Pr’s a reason was found not to do that automatically in the core system. otherwise it might be a nice enhancement.

46

Did you fully read my post? I explained what to do using an input_select…

47

yes, we will require yet some extra helpers to do what we did before…
things aren’t getting easier with all of this. And still we can not identify a notifying notification. unless we truly are going to assume: there’s still an id stored inside template, so the notification must be notifying.

a lot of manual stuff required.

48

1 helper.

They are getting easier. Different does not mean harder, just because you have to learn a new process does not mean it’s harder. For some reason you want to store them and iterate them.

You can always just dismiss them at the time they come through with a simple automation. It would be no different than iterating the old states.persistent_notification domain. In fact, the template would be easier because you already have the notification information at your “finger tips”.

Not to mention, it would be ‘less resource’ heavy because nothing persists in the state machine and you don’t have to iterate a list to find the notification.

I understand you’re upset about not being able to traverse them, but you don’t need to. And if a new service “dismiss all” were to be implemented, there would be no reason to traverse a list of notifications.

49

I’d even argue that this method is better than the old method. We had to spend time finding the system generated persistent notifications before. You couldn’t even act the moment they appeared without a ridiculous template. Now you can simply trigger off any persistent notification, capturing exactly when it happens.

50

now you are assuming… :wink: and for starters, I am not upset, I’ve left that some years ago. Going with the flow.

its a bit much going into the specifics, but a desire to have a list of notifying notifications remains

well, of the many templates, that one was really simple… and finding the id too, since it was a mere attribute

but yes, I am very excited we get what we get now, that will hold some great improvements

51

This is what the frontend does right now to dismiss all the notifications

  private _dismissAll() {
    this._notifications.forEach((notification) => {
      this.hass.callService("persistent_notification", "dismiss", {
        notification_id: notification.notification_id,
      }); 
    }); 
    this.closeDialog();
  }

It would be reasonable to add a dismiss all service to core if someone wants to do it. We could replace the loop on the frontend

1 Like
52

I’ll look into it, I have some spare time today.

53

Given that 12 days have passed without a report, I’ll assume my suggestion (an independent message list) is no longer needed. Nevertheless, it was an interesting little templating exercise.

54

Yeah, I did mention that before looking into it :wink:
That’s not something that looks as trivial as the persistent notification was. But unless picked up by someone else I hope to get to it at some point.

1 Like
55

Don’t assume that.

And I apologize for not getting back to that as I had wanted.
It’s still on my to do list , my head was busy with the Kiosk mode and other pressing matters in real life…

Might be useful if we wait testing this trigger based template and incorporate the new Pers. Not. events.

56
2 Likes
57

And it’s merged. I would expect it in the Beta next Wednesday.

2 Likes
59

So is it also possible to receive failed logins as a push message again?

like this:

alias: Failed Login I Push Nachricht
trigger:
  - platform: state
    entity_id: persistent_notification.http_login
condition:
  - condition: template
    value_template: "{{ trigger.to_state.state != 'None' }}"
action:
  - service: notify.mobile_app_iphone_
    data_template:
      title: "{{ states.persistent_notification.http_login.attributes.message }}"
      message: >-
        url:
        https://whatismyipaddress.com/ip/{{states.persistent_notification.http_login.attributes.message.split("from
        ")[1]}}
  - service: persistent_notification.dismiss
    data:
      notification_id: http_login
initial_state: true
mode: single
60

In the next release you’ll be able to use the new trigger. Beta comes out Wednesday, full release comes out the 7th of July.

1 Like
61

I found it very useful @123 - waiting to see how this all plays out before implementing an alternative approach using your methodology (I had a lot of messaging and ui running from the notifications (both system and defined by myself) so keen to have a flexible solution in place).