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

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.

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.

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.

Awesome job :+1:t2:

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

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

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.

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

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?

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

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

@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!

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

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

Hm ok, I guess looking at the doc you’re right. It is close enough to android that sending the same thing to both does probably work. I’ll think about it but I really don’t like the lack of selector for it. I worry it just introduces a lot of potential for bugs where the blueprint now accepts a notification service that doesn’t work because it has a far different feature set then mobile application.

I think for now I’m going to leave it off. But I would definitely suggest making or pushing up a feature request to get a selector specficially for notification services. Or to have core create a device with a “Send Notification” device action when you subscribe for HTML5 notifications like how the mobile app works. Either one allows me to create a selector that I can be sure only shows users options that have been tested and work.

Thanks Mike for implementing it.

Any idea how HACS is currently tracked, I don’t think they added the update entity as of now, so i guess that will be their next step right?

Actually they do already. But only if you enable experimental features, hasn’t been pushed to stable yet. I should probably mention that at the top though :+1:

But yea if you turn that on then you get update entities for all those too. I have it enabled and tested, has all been working great.

Off topic but relevant, is there a way to get an update notification if your Blueprint (or other Blueprints) is changed?

If I understand correctly, I have to copy new (version) code from GitHub and reload the Blueprint to get the latest version(?)

I’m not really aware of one unfortunately, I wish it was less of a hassle. There’s a feature request to make it easier but no current solutions I’m aware of.

That being said, poking around a bit, a call to https://api.github.com/gists/13d91bc293e8b98cba2c9ee932527dea gets everything needed to do this for my particular blueprint. There’s a version ID and date of last update in there you could use to notify about an update to the blueprint. Even the raw blueprint data is in there if you wanted to make a shell_command or command_line.notify which pulls that in and uses it to update the file.

The bummer is you’d have to make the senors and services per each blueprint you use. And only for blueprints which are hosted as gists, don’t really think there’s a solution for blueprints where the code is just embedded in the top post of a forum thread. But at least for this one I think something could be built out of a command_line.sensor and a shell_command.

PLEASE go to and vote up that feature request if you can.
This is a blueprint creator and user sore point and people complain it doesn’t exist, but then don’t poke the bear to get the feature worked on…
Feature Request

I moved my 8 blueprints from a gist to a repo and am (hoping) that a solution like HACS has or like Luma proposed in the FR would come to pass. The repo is easier when you have 8 of them than individual gists were… I then have a markdown file in the repo that is also the Blueprint Exchange post here, so edit it in VSCode, overwrite the top post here, and all documentation is up to date and matching…