I’m not aware of any solution that can auto-populate Markdown Cards, since they have no entity.
on the quotes in that other post; I can see it is merely anecdotal there, and they’re obviously in to another business.
Their HA posts are a mere nicety, almost feel like personal notes.
My ‘take credit’ might have been a bit strong. Personally I would have credited/positioned this thread and community more prominently, because it found the issue in the first place, then iterated to a technical solution, and even presented a dashboard to round it all up… heck even keeps being relevant because HA changed into breaking it (will soon be fixed hopefully)
I explicitly refrained from naming, other than that business name, because it shouldn’t be relevant.
I am sorry you took offence to my notes about the message processing routine. The notes are hosted on my Photography site and as Petro says I did refer back to this post and credited Petro for the easy-time macros as well. I write my posts to condense information from the threads as it can be long winded to work through many screens of information on a single thread to find the gold in there.
It also helps me to learn how they work as I write the documentation.
2 Likes
sure, appreciate that, and your post now, thanks for that… I hope to have taken out the possible poise that could have been read in my sarcastic post above.
Think moving forward this will be the template i use by default even though the issue got resolved to rule out any duplications, thanks Taras.
don’t think this was mentioned earlier but now that things have settled down on the subject of persistent notification migration, I just would like to post this little automation that toggles an input_boolean.{{notification_id}}_notificatie for me on creation and dismissal
- id: sync_boolean_when_persistent_notifications_updated
trigger:
platform: persistent_notification
update_type:
- added
- removed
action:
- variables:
pnid: >
{{trigger.notification.notification_id}}
service: >
{{'on' if trigger.update_type == 'added' else 'off'}}
- condition: >
{% set id = 'input_boolean.' ~ pnid ~ '_notificatie' %}
{{has_value(id) }}
- service: >
input_boolean.turn_{{service}}
data:
entity_id: >
input_boolean.{{pnid}}_notificatie
with these booleans, I set several other frontend considerations, and it replaces the former state ‘notifying’ really nicely.
All in all this completes the Persistent notification package for me, and all I have to do is create that helper in the UI for the cases I need it. If I dont care to track a notification, I simply dont create that helper, and the condition prevents further action.
Guess I could simply add this to the trigger template now we have the action block there, not sure yet?
Keeping it as an automation allows for easy tracing, so that would be an advantage over the trigger template?
the way for me to sync easily when cresting these persistent notification ids is to use:
action:
- variables:
oid: >
{{trigger.to_state.object_id}}
id: >
{{trigger.to_state.attributes.id}}
- service: persistent_notification.dismiss
data:
notification_id: >
{{oid}}
that way I am always 100% what to use in the boolean sync automation, and it makes for easy creation of the booleans…
For the dumb user who just wants the count of active persistent notifications and doesn’t want to read through this 146 messages… what should this user copy paste please? I would really appreciate
For those interested in a Node Red solution, just do this:
[{"id":"e849d43f62cfc58c","type":"ha-api","z":"878e74c2.7f39c8","name":"get","server":"9405c3fe.d0a6c","version":1,"debugenabled":false,"protocol":"websocket","method":"get","path":"","data":"{\"type\": \"persistent_notification/get\"}","dataType":"jsonata","responseType":"json","outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"results"}],"x":390,"y":360,"wires":[["cced63c483c3f4b8"]]},{"id":"9405c3fe.d0a6c","type":"server","name":"Home Assistant","version":5,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true,"heartbeat":false,"heartbeatInterval":30,"areaSelector":"friendlyName","deviceSelector":"friendlyName","entitySelector":"friendlyName","statusSeparator":"at: ","statusYear":"hidden","statusMonth":"short","statusDay":"numeric","statusHourCycle":"h23","statusTimeFormat":"h:m","enableGlobalContextStore":true}]
With that node you get an array of all existing active notifications.
5 minutes to solve this in NR, LOL.
1 Like
Firstly let me say I am relatively new to HA having moved across from smartthings and I have got the template sensor to operate in the developers tools event and I see the messages I manually create in the array however how do I cause them to be created when the persistent-notifications are generated or deleted.
1 Like
seems I have found a related challenge:
create a sensor that counts and lists the updates/repairs in the config notification tray. Ive moved that completely out of the users area (left side menu) and have that info on a dedicated dev view.
we can count updates in Jinja, but not yet directly the repairs, for which I now use custom integration. Spook, resulting in a jinja template:
{% set issues =
states('sensor.active_issues')|int(default=0) %}
{% set updates =
states.update
| selectattr('state','eq','on')
| list | count %}
{{issues + updates}}
the sidebar does this
and you cant see there probably but it does Not count all update entities in the states. The other day my Synology needed an update, and an update entity turned ‘on’, but the notification tray didnt show the update.
Repairs do his in states:
manually creating a next repair using Spook causes another event, and the previous is no longer available (so we cant count it nor list it)
since this seems to seem somewhat consistent (…) with what persistent notifications now do, I was hoping for some help here to make our pers. not. trigger based template into a repairs template
this was my final version:
- trigger:
- platform: homeassistant
event: start
id: start
- platform: persistent_notification
update_type:
- added
- removed
sensor:
- unique_id: persistent_notifications_overview
device_class: timestamp
state: >
{{now()}}
attributes:
notifications: >
{% set msgs = this.attributes.get('notifications',[]) %}
{% if trigger.id == 'start' %}
{{[]}}
{% elif trigger.update_type == 'added' %}
{% set new =
[ {"id": trigger.notification.notification_id,
"title": trigger.notification.title,
"message": trigger.notification.message,
"created_at": trigger.notification.created_at.isoformat()} ]%}
{{msgs + new}}
{% else %}
{{msgs|rejectattr('id','eq',trigger.notification.notification_id)|list}}
{% endif %}
# unique: https://community.home-assistant.io/t/heads-up-2023-6-longer-has-persistent-notifications-in-states-what-to-do/578654/135
history: >
{%- set previous = this.attributes.history|default([]) %}
{% if trigger.update_type == 'added' %}
{% set new = [{
"id": trigger.notification.notification_id,
"title": trigger.notification.title,
"message": trigger.notification.message,
"created_at": trigger.notification.created_at.isoformat()}] %}
{{previous[-3:] + new}}
{% else %} {{previous[-4:]}}
{% endif %}
and Id appreciate some help rebuilding that.
So we can create a counter like this based on that:
{% set msgs =
state_attr('sensor.persistent_notifications','notifications') or [] %}
{{msgs|count}}
listening to these events:
event_type: repairs_issue_registry_updated
data:
action: remove
domain: spook
issue_id: user_3467327y
origin: LOCAL
time_fired: "2024-01-10T08:29:52.085411+00:00"
context:
id: 01HKS7VZ2NSB0CSQVTGXN6XG7S
parent_id: null
user_id: null
required for the trigger based template
Please have a look?
this seems to work:
template:
- trigger:
- platform: homeassistant
event: start
id: start
- platform: event
event_type: repairs_issue_registry_updated
id: update
# event_data:
# - create
# - remove
# - update
sensor:
- unique_id: repairs_overview
device_class: timestamp
state: >
{{now()}}
attributes:
repairs: >
{% set rprs = this.attributes.get('repairs',[]) %}
{% if trigger.id == 'start' %}
{{[]}}
{% elif trigger.event.data.action == 'create' %}
{% set new =
[ {"issue_id": trigger.event.data.issue_id,
"action": trigger.event.data.action,
"domain": trigger.event.data.domain,
"created_at": trigger.event.time_fired.isoformat()} ]%}
{{rprs + new}}
{% else %}
{{rprs|rejectattr('issue_id','eq',trigger.event.data.issue_id)|list}}
{% endif %}
# unique: https://community.home-assistant.io/t/heads-up-2023-6-longer-has-persistent-notifications-in-states-what-to-do/578654/135
history: >
{%- set previous = this.attributes.history|default([]) %}
{% if trigger.id == 'update' trigger.event.data.action == 'create' %}
{% set new = [{
"issue_id": trigger.event.data.issue_id,
"action": trigger.event.data.action,
"domain": trigger.event.data.domain,
"created_at": trigger.event.time_fired.isoformat()}] %}
{{previous[-3:] + new}}
{% else %} {{previous[-4:]}}
{% endif %}
and counting those with
{% set repairs =
state_attr('sensor.repairs_overview','repairs') or [] %}
{{repairs|count}}
is easy…
only thing not showing is the severity of the repair, and not sure if the domain is propagated correctly, as it always shows spook now, and not Hue, or Homeassistant…
update
at restart this does throw an error…
2024-01-10 13:58:46.589 ERROR (MainThread) [homeassistant.helpers.template] Template variable error: 'homeassistant.util.yaml.objects.NodeStrClass object' has no attribute 'data' when rendering '{%- set previous = this.attributes.history|default([]) %} {% if trigger.event.data.action == 'create' %} {% set new = [{
"issue_id": trigger.event.data.issue_id,
"action": trigger.event.data.action,
"domain": trigger.event.data.domain,
"created_at": trigger.event.time_fired.isoformat()}] %}
{{previous[-3:] + new}} {% else %} {{previous[-4:]}} {% endif %}'
2024-01-10 13:58:46.590 ERROR (MainThread) [homeassistant.helpers.sensor] Error rendering state template for sensor.repairs_overview: UndefinedError: 'homeassistant.util.yaml.objects.NodeStrClass object' has no attribute 'data'
update2
needs a check on startup, so adding trigger.id == 'update' and that id to the trigger solves that. (edited that in the post above)
or, as suggested in Discord: mimic the {% if trigger.id == 'start' %} in the history attribute.
2 Likes