Update notifications! Core, HACS, Supervisor and Addons (now a blueprint!)

[felipecrs (Felipe Santos)]

By the way, there is now entities made just for updates. Good days we live!

Introducing the update entity | Home Assistant Developer Docs

[CentralCommand (Mike)]

Yep! I’m expecting over time that likely will make this package a thing of the past. Or maybe it will just become a single automation that pops a notification any time an entity of type update turns on (but no longer need to be the one creating those entities). Not sure yet, will re-evaluate when it comes out.

[felipecrs (Felipe Santos)]

Yeah. For example, HACS will have to provide their own update entity for each plugin installed and so.

[DavidFW1960 (David)]

They already do.

[felipecrs (Felipe Santos)]

What do you mean? It was just announced and I haven’t seem any new release from HACS yet.

[DavidFW1960 (David)]

What do you mean? HACS has always had a sensor showing how many updates are available and each available update as an attribute.

[CentralCommand (Mike)]

Add update entities

[paulius2k]

@CentralCommand, this command:

curl http://supervisor/addons/core_check_config/logs -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"

kills my IOWait performance for some 10 minutes: IOWait goes up to 70-90%.

I guess it does not find any logs to read from.

I put in curl params --connect-timeout 2 --max-time 4, but this doesn’t help: the timeout comes faster, but the IOWait remains high for ~10 mins.

What would be the best way to solve it?

Thank you!

[CentralCommand (Mike)]

Tbh I’d just say remove it. The reality is that particular piece is a nice idea but kind of useless in practice. The core check config addon has returned a false positive error for me every release for quite a while. They’re always about impossible python dependency errors. Impossible because if the error was real there would be no release since the build would’ve failed. The addon needs some fixes to be useful again.

So I would say just do this:

1. Remove the offending sensor from the package
2. Change the core_has_update sensor to this:

    # True if there's an update available and the config check has completed or its been 20 minutes
    - name: core_has_update
      unique_id: '9108f22a9aac4ef6b167f20da7c476ec'
      device_class: problem
      state: "{{ is_state('sensor.updater_core', 'on') }}"

3. Change the message of the ha_core_update_available alert to just this:

      New version is {{ state_attr('sensor.updater_core', 'newest_version') }}.
      Currently on {{ state_attr('sensor.updater_core', 'current_version') }}.

With this you’ll still get a notification when core has an update that tells you the current and newest version. Plus the automation will still have started the core check config addon and the notification will still have a link to it in actions so you can check it if you want. The only difference is the text won’t tell you if the check succeeded or failed, you’ll have to check it manually if you want.

If there is a next version (give or take what these new update features bring us in the upcoming release) I’ll probably do that in the package too. It’s a pretty fragile piece since it relies both on that addon working correctly and uses a regex to parse the log for a specific line, not ideal.

[CentralCommand (Mike)]

On the beta now taking a look at it, this has become a lot easier, I think all the command line entities can go. Update entities look like this:

Which has everything I could want. I basically want the following, every time an update is becomes available send a notification with the following:

1. Name of what updated
2. Current and new version in details
3. Link to the changelog
4. Update action that when pressed installs the update

#2 and #3 are in there so that’s easy. #1 isn’t but is obtainable from the entity via template since its the device name ({{ device_attr('update.auto_entities_update', 'name') }}). And #4 is trivial since all update entities have an update.install service.

Addons are a little more troublesome. An update entity for an addon looks like this:

This one has #1 and #2 but is missing #3. Which is a more significant issue since I can’t use a template to figure that out, its not in the device data either. I have a partial release summary but that won’t fit in a notification (and its cut off). So that will require a bit of thought or I’ll just have to lose the changelog link for now. Though on the plus side its a lot easier to set the notification icon since entity_picture is set for me instead of picking through addon metadata to see if it has a logo or an icon set.

The harder part is how to make an automation that triggers any time an entity with domain update turns on so I know to send a notification with its details. There’s not really an easy way to do that other then manually listing every update entity by ID in a state type trigger. You can use a template type trigger like this:

{{ states.update | selectattr('state', 'eq', 'on') | list | count > 0 }}

But that’s not great. That will only trigger when an update entity turns on for the first time. If you have multiple updates pending you’ll only get one notification.

Adding a time-pattern check like so might work:

{{ states.update | selectattr('state', 'eq', 'on') | list | count > 0 and now().minute is odd }}

and then in the automation collect the ones that have turned on in the past two minutes like so:

{{ states.update
    | selectattr('state', 'eq', 'on') 
    | selectattr('last_changed', 'gt', today_at('%s:%s' % (now().hour, now().minute)) - timedelta(minutes=2))
    | list | count > 0 }}

Only cons I see are your notifications will be up to 2 minutes delayed (annoying but fine), you’ll get notified for every pending update after a restart since last_changed resets (again annoying but probably fine), and tracing will be difficult if something goes wrong since you’ll get a new trace every 2 minutes (by the time you realize something went wrong your trace has probably rotated out).

If those cons aren’t good enough then the only other OOTB option I can see is listening for all of state_changed events on binary things and filtering like so:

mode: parallel
max: 1000
trigger:
  platform: event
  event_type: state_changed
  event_data:
    new_state:
      state: 'on'
condition: 
  condition: and
  conditions:
    - "{{ trigger.event.data.entity_id is search('^update[.]') }}"
    - "{{ not not trigger.event.data.old_state }}"
    - "{{ trigger.event.data.old_state.state not in ['unknown', 'unavailable', 'on'] }}"

Which is instantaneous and won’t re-trigger after a restart but is even less traceable in case of an issue and also might be a performance problem. You’re literally triggering any time any binary entity changes at all (attribute or state), hence the max: 1000. Seems like it might put a lot of stress on some systems.

I do have a solution in my system. I basically came up with a way to trigger off a state change to any entity who’s ID matches a pattern by using an automation to watch patterns and write out files with a list of entity IDs when what matches a watched pattern changes. And then !include ing those files elsewhere (like in the entity_id field of the state trigger). Which I was planning to publish but was hoping not to make this dependent on. Will play around a bit, I really wanted to make this just a blueprint

[CentralCommand (Mike)]

So I made a blueprint

Update notifications (Core, OS, Addons, HACS, etc)

[Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.] Now that 2022.4.0 has come out with its update entities I decided to see if I could convert my update notifications package into a single blueprint. Turns out the answer is yes! Notifications about all your updates, and install them right from the notifications! Dependencies HA version >= 2022.4.0. Otherwise you won’t have any update entities. HACS version >= 1.24.1 and enable exper…

2022.4 required since its entirely based on update entities. It’s pretty cool. The notifications look great, you get one per addon/HACS component with an update (instead of a generic one), it can replicate them to HA persistent notifications, and it includes update, skip and changelog actions on each one.

I’m not ready to replace the package at the top with it though because of one big problem - you have to list all the update entities you want to watch. I really couldn’t figure out any good way to send a notification any time any update entity turns on without requiring you list them. My ideas in the reply right above didn’t really work. The only way I was able to get it to work was like this:

mode: parallel
max: 1000
trigger:
  platform: event
  event_type: state_changed
condition: "{{ trigger.event.data.entity_id is search('^update[.]') }}"

But this literally triggers on every state changed event. Like all of them, it’s awful. Trying to filter the trigger based on new_state and old_state would be better but it didn’t work. Even my example above just never triggered, seems you can’t put new_state and old_state filters in event_data like that.

I think what I’ll need is for the package to include the blueprint and an automation which writes out a file with a list of all update entities and keeps it up to date. This way the file can be used in a state trigger with !include. Fortunately I have such an automation, I just need to clean things up and make it publishable. Then I’ll update the top post.

EDIT: Actually I forgot that the blueprint’s polling loop for reminder_hours will inform you about every update, not just the ones you manually listed in update_entities. So I think that alleviates my concerns. You don’t have to list every update entity out manually, you only have to list out the ones you want to be notified about immediately. All others you’ll get notified about in 1-24 hours (whatever you set reminder_hours to). Which seems good enough.

So I suppose I will update the top post then. This has become just a blueprint!

[clipse (Marco)]

Just briefly again for understanding, I now no longer need all the command line sensors?
Only your Blueprint?

Btw: Before I forget it, mega work! I think this should be firmly integrated into HA.

[CentralCommand (Mike)]

Yep, that’s it! The blueprint is now doing all the work this package did and more (since it gives you an notification per update instead of one for any update).

[Snuffy2]

Came back to this thread after previously installing what is now a rather old version of this package (now blueprint). I was looking to update to the new blueprint, but I’m not sure I understand the new settings. I’m hoping to set it up to only get persistent notifications within Home Assistant when there are updates. I’m personally not interested in getting push notices to my phone when there is an update. Is this possible with the blueprint?

[CentralCommand (Mike)]

So I wanted it to be but I can’t seem to figure out how to make an optional input in a blueprint. I think I’d have to take away the selector and just make it a text input so I can say “enter '' to ignore” which is really frustrating.

Another alternative is to have a separate boolean input that is basially “don’t send a mobile notification”. It would still unfortunately make you pick a mobile device because of blueprint limitations but it wouldn’t use it.

EDIT: @Snuffy2 ok I think I figured it out. Going to do some updates to support a default so its optional

[Kethlak (Cassandra Gelvin)]

The alternative core update will be useful here since apparently binary_sensor.updater is no longer used.

[mousawm (Mousa)]

Hi,
Does this automation support HACS updates?

[CentralCommand (Mike)]

Yes. Both the original package and the new blueprint do. For the blueprint you do have to enable experimental features in HACS though as the update entities aren’t available in stable. See the blueprint thread for more details

[BigBlackBear (Mike)]

I’ve been using this blueprint for a week or two now and I love it. I just have a single suggestion. When choosing the Changelog option for an update, the notification is dismissed and I can no longer use it to trigger or skip the update. To solve for that, would it be possible to simply re-trigger the notification if the Changelog option is chosen?

[CentralCommand (Mike)]

So I guess first question is android or iphone? For android this is trivial, I’ll add an option for sticky. Sticky notifications don’t dismiss when an action is selected, only when swiped away or dismissed by automation. Actually I may just set that by default as that makes sense.

For ios I’m not sure if I can. I’ll see but I’m not sure if I get an event when a URL action is clicked on. If I don’t then there’s no way for me to tell when to recreate the notification.

I would suggest making a feature request for the sticky option on ios if that’s what you use. It’s really handy.

EDIT: Looks like I do get an event even for URI actions. I’ll see what I can do in that case. But seriously, the sticky option is great.