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

Blueprints Exchange
1

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 experimental features if you want update notifications for HACS components. Will update when this feature is pushed to HACS stable.

Features

  1. Receive a notification on up to two devices every time a listed update entity becomes on.
  2. Notifications all include the following features:
    • New version
    • Current version
    • Link to open item
    • Update action
    • Skip action
    • Entity picture as icon (if available in entity)
    • Release summary (if available and as much as fits)
    • Changelog link (if available)
  3. Notification switches to “updating…” when update is in progress to let you know
  4. Notification is automatically dismissed when update is complete
  5. IOS and android supported (normalized to look and work as identically as I can get them on each)
  6. Can create a persistent notification as well. Text is identical to others and dismissed on complete. Includes open and (if available) changelog links
  7. Choose whether update action takes a partial backup or not
  8. Can optionally start the config check addon when an update for core is available. If so notification text will be updated to let you know when that addon finished running so you can check it.
  9. Can send reminders about all available updates every X hours (configurable)
  10. Option to provide changelog links for update entities which don’t have them (addons) so your notifications can still include them.
  11. Can limit when notifications are sent to mobile devices with a time window (still sent to HA at all hours if you choose to make a persistent notification as well)

Improvements

Definitely room for improvement still. The biggest things in my mind are these:

1. Don’t make users list update entities to watch, just watch them all.
2. Allow users to provide a list of devices to send notifications too instead of supporting a specific number

EDIT: After talking through it with @Sir_Goodenough below I think we’re good on #1. I forgot the polling loop I added (reminder_hours) will send you a notification about any available update, not just the ones you listed in update_entities. So update_entities is just for the updates you want to know about immediately. And core if you want to use the “run config check when a core update is available” feature. All others this will inform you about every x hours (whatever you put in reminder_hours) :+1:

Date of last update - 5/6/2022

Changelog

Update 5/6/2022

:rocket: Enhancements

  • Emulating android’s sticky notification feature for ios notifications by recreating the notification when the changelog action is selected (per request here)

Update 5/5/2022

:bug: Bug fixes

  • Existence check in template was causing a warning, no more warning

Update 5/2/2022

:bug: Bug fixes

  • Reminder hours set to None does not cause error

Update 4/14/2022

:bug: Bug fixes

  • Using a proper if statement to prevent errors on install/skip actions in android. Note to self: default doesn’t shortcircuit :confused:

Update 4/13/2022

:rocket: Enhancements

  • Added new input for status_bar_icon to allow users to choose one besides mdi:package-up

:bug: Bug fixes

  • Fixed install action not working on IOS, action no longer coming in as trigger.event.data.actionName
  • Core and OS updates breaking if other entities besides update one enabled after removing filter in earlier fix. Now properly finding the update entity for these no matter what is enabled.

Update 4/11/2022

:rocket: Enhancements

  • Added notification_channel option so users can set the channel (android) and group (ios) used for update notifications. Defaults to Updates

:bug: Bug fixes

  • Updates channel used for android notifications by default (user-overridable)
  • No skip action on supervisor updates since its not skippable
  • When installing an update from a notification action for something other then an addon or core always set backup: false regardless of the value of the take_backup input since its not supported.

Update 4/9/2022

:rocket: Enhancements

  • Added only_before and only_after options. When used notifications will only be sent to specified mobile devices in the specified time window

:bug: Bug fixes

  • OS and Core notifications were only being dismissed on startup if you had listed those entities in update_entities. Since that’s not required to get notifications for them, always dismissing for these entities on startup when they are off.
  • Core update notification doesn’t switch back to saying “core check has started” on next reminder after check completed for users of the run_core_check feature
42 Likes
2

You may want to add this so that people that don’t have these options available won’t come back and complain that this doesn’t work. It just goes in the top like name, description. domain, etc in the blueprint…

  homeassistant:
    min_version: 2022.4.0

I don’t have an answer, but a concept to find all the “update available” things
I use this in a blueprint to drop some data on the event buss and then pull it off later.
May be a way to go…

- variables:
    event: '{{ trigger.to_state.attributes.action }}'
    sub_event: '{{ trigger.to_state.attributes.side }}'
    entity_id: !input 'remote'
    friendly_name: '{{ trigger.to_state.attributes.friendly_name }}'
- alias: Fire Last Action event
  event: cube_last_action
  event_data:
    event: '{{ event }}'
    side: '{{ sub_event }}'
    entity_id: '{{ entity_id }}'
    friendly_name: '{{ friendly_name }}'

yours would look different, of course.
You could do a for loop and generate a list to drop on the event buss, then just pull it out later, maybe…

1 Like
3

Huh, I had no idea this was an option, thanks! I guess blueprint schema needs an update.

Not really sure I understand the concept here. I get that I can find all update entities in a template, loop through and fire an event for each but I’m not sure how that helps me. How does that get me to where I have an automation that triggers any time any update type entity becomes on?

1 Like
4

My thought was some kind of for loop to find them all, put them in a list. I guess once you have the list an event isn’t needed… But use the list to loop thru the updates further down.
I don’t know.
It’s a concept to spark other ideas…

I had a thought of doing this kind of Blueprint but this templating outclasses what I had in mind for sure.

I don’t think you can get it to trigger on anything except a schedule. An external automation that the user adds to call it every X hours would be fine.

5

So you can collect and loop for sure. The problem is you’re switching to a polling model. Let’s say you did a simple time pattern trigger of 1 hour with that. It’ll work fine but you may not see a notification about an update for up to one hour.

In fact I know it works fine because I accidently did that lol. The reminder_hours input I added actually does that, I forgot to filter the list to the ones you put in update_entities. See here:

    - alias: Send reminders if enabled
      conditions: "{{ reminder_hours > 0 }}"
      sequence:
        - alias: Get all pending, unstarted updates
          variables:
            updates: >-
              {{ states.update
                  | selectattr('state', 'eq', 'on')
                  | rejectattr('attributes.in_progress', 'true')
                  | map(attribute='entity_id') | list }}
        - alias: Loop over updates and send reminder
          repeat:
            count: "{{ updates | count }}"
            sequence:
              - variables:
                  entity_id: "{{ updates[repeat.index - 1] }}"
              - *update-variables
              - *send-to-mobile-devices
              - *send-to-ha

So I guess in that case I’ll just keep this and mention that in the description. I could also add some lower times like 1 and 2 hour if people want, currently the min I added was 3 hours.

6

I would think immediate notification of updates has no value unless you have something broke and are drooling for the update.
I wouldn’t want it more often than every 6 hours, probably longer.

7

You’re probably right. I’m very spoiled though, I’ve had instant notifications about updates ever since I made that package. But if I’m honest that’s really not that necessary.

I think the only one they really have to list in update_entities is core. And then only if they want to use the option to start the check config addon when the update becomes available. I don’t start that addon in the polling loop, only when it first turns on. So they should list the core entity for that feature and any others they really want instant notifications about. Others can just be picked up in the poll loop.

8

Small update - The mobile device selectors are now optional. So if you want to just receive update notifications as a persistent notification, you can do that. Just leave them blank and set “Send to HA” to true.

9

Hey. Thanks for making this Blueprint.

Any chance you can enhance it with two fields, from time and to time (notification time interval)?
If the notification is triggered outside the interval make it wait for the interval time.
Just don’t want update-notifications on my phone in the middle of the night.

10

Awesome job :+1:t2:

11

Thanks for your blueprint.

Is it possible to automaticly add all update.* devices? I mean that the blueprint use alle updatateable devices automatic.

1 Like
12

No, it’s not possible. I tried I promise, you can see some of my research into it here.

That being said, note this in the top post:

So you will get update notifications about all the update entities as long as you don’t put none in reminder_hours. They just will be a little delayed. So you only have to put the ones you really want to know about immediately in update_entities. And core if you want to use the “start config check on core update” feature.

1 Like
13

That’s a good idea, yea I can add that :+1: I don’t have time right now but I should be able to get to it at some point this weekend.

EDIT: Btw in the meantime, the way reminder hours actually works is it sends out a reminder when the hour is evenly divisible by the number. So if you pick like 8 and put essentially no entities in update_entities it will only send out notifications at midnight, 8:00, and 16:00.

I should just make update_entities optional but I had some difficulties. The default value has to be a string and when update_entities is filled in then its an array. Which I guess is handlable but weird.

14

Added only_before and only_after options to the blueprint. If provided, notifications will only be sent to mobile devices within that window. They will always be sent as persistent notifications regardless of the hour if the send_to_ha feature is enabled since I figured that’s not waking anyone up.

1 Like
15

Something that I would also suggest is to support notifying to HTML5. In most cases it supports everything as the mobile app notifications.

Perhaps even to notification groups?

16

So unfortunately that is actually quite difficult. There’s a couple reasons for this:

1 - There is no way to make a selector for a notification service. The only two options are to use a generic action selector or a generic text selector. Both work very poorly though.

With the action selector you’re literally just asking the user to fill in all the details. You can’t even be sure the action they’re giving you is going to send a notification, you don’t know what its going to do. And there’s no way for the blueprint author to make the messages or the actions or all the stuff this blueprint is doing. It would basically become a blueprint to “do a thing when an update is available” with you (the user) deciding what thing to do. Except without being able to use information like which thing has an update? What version is available? At what URL can I view info about this new version? Essentially all the stuff you’d want out of this blueprint.

And a text selector basically is no selector. You’d be asking users to copy and paste a string like notify.my_notification_service and just kind of hoping they get it. You can use a regex to validate that it looks right but you can’t actually guarantee that the notification service exists because there’s no help for the user.

2 - When it comes to notification services there is exactly one field you can count on - message. That’s it. Some notification services support title, some don’t. Even fewer have options besides title and message. And I can’t just create a notification that works for the companion app and send it to any random notification service, it won’t work. To see what I mean, try making a notify group like this:

notify:
  - name: Test group
    platform: group
    services:
      - persistent_notification
      - mobile_app_my_phone

And then call it with something simple like this:

title: Test
message: Test
data:
  notification_icon: mdi:alert

What you’d probably expect is for the phone to receive a notification with that title, message and icon. And for a persistent notification to be created that has just the title and message (since persistent notifications don’t support icons). What actually happens is the call fails. The persistent notification service only supports title and message so it won’t accept data and throws an exception. The call fails, an error is logged and no notification is sent anywhere.

For this reason accepting a notification group or any random notification service is impossible. Unless I want to remove everything from the notifications besides message. That means no actions to install or skip, no url to the configuration panel, no action/link to open the changelog, not even a title. Everything besides the message has to go. That drops a ton of the value of this blueprint. I know I would personally never use it if I did that, I doubt many others would either.

3 - HTML5 notifications specifically are supportable but it’s a lot of work. These 3 problems come up:

  1. There’s no selector for HTML5 notifications. With the mobile app I can cheat by asking for a mobile app device knowing that the Send Notification device action exists. I have no option like that for HTML5 notifications. So I’m stuck with the two options above - Action selector or Text Selector.
  2. I need to add new inputs specifically for HTML5 notification services. And since I have no selectors for it that doesn’t seem appetizing.
  3. There was an effort to normalize the schema for notifications for Android and IOS notifications here. HTML5 notifications were left out of this. Their schema and featureset doesn’t match the other two at all so I would have to do a lot of resarch and add a lot of code to handle normalizing to that notification service. There would have to be a lot of demand for me to consider that.

I know that’s a long response and I’m sorry. The TL;DR is that it’s really far more work then it sounds. I would maybe be willing to handle HTML5 notifications if there was a lot of demand for it. Although really if there is a lot of demand for it those that use it should push up a feature request to get it better supported and caught up with notifications on the companion apps as it appears to have been left behind. And perhaps consider turning on analytics so the HA team knows it is more used, right now analytics says that its only used in 1.3% of installations. Compare that with the 99.3% of installations that use mobile_app.

It is not possible to do notification groups or any random notifier at this time for the reasons above.

1 Like
17

Thanks a lot for the elaborated answer. I understand and agree with all you said.

Just to mention, there is another blueprint (Frigate Mobile App Notifications) which accepts both a selector for mobile apps (like yours) and a text box which you can use to fill a notification group.

I have a notification group with two mobile apps and one HTML5 browser, and surprisingly, I receive the notifications simply fine in my browser (even though the blueprint claims to be compatible with only mobile apps).

Anyway, you already mentioned the reasons why it would not be the nicest thing to have a non-validated text input, so, all good.

Thank you for such a nice blueprint!

1 Like
18

@CentralCommand Hey man, just came today to see if any changes have been made to this to accomodate the new update entities, and surprise surprise, it is even more complex than expected haha :slight_smile:

Something epic for you to consider adding, and that should not be hard to achieve is notification channels, with the option for the user to define it (e.g. “Updates”). What this basically allows to do is to configure how the notification behaves on the device, particularly (or most importantly for me) “Do not disturb”. Here is the link to the documentation: Introduction | Home Assistant Companion Docs

I am not entirely sure if they are supported on iOS and I do not have a device to test this first-hand.

Anyhow, good work on your project, I have to admit that i have “forked” from your first integration iteration and did my own thing, but I am now coming back to get a flavour of what you have achieved and provide constructive feedback. Thanks for your commitment!

19

Ah crap, good catch. In my system I have this script that normalizes the notification fields for iOS and Android so I don’t have to remember all the differences. One of the other things it does is set channel from the value for group because I always want those two to be the same. But I forgot that’s obviously not standard.

Will definitely add that, did not mean to send channel-less notifications :man_facepalming:

1 Like
20

Fixed. Uses Updates by default for channel (android) and group (ios). Also a new input to allow users to change that if they want.

1 Like