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

[Vasco]

@CentralCommand

I am running in Docker so I don’t know if it varies in other deployments.

I am running docker too! So it’ll work

@CentralCommand

One other added bonus for anyone interested. I realized that the same technique I used for sending out a notification when an addon updates could also be used to send out a notification when a new addon gets listed.

Now this is cool too! Is there an automation you have for this? I dont use nodered.

Or is node red required to run any of this? Planning to remove old sensors i’ve built. And adding this as a package. Amazing!

[CentralCommand (Mike)]

Nope, Node RED not required for most of it. That’s why I separated the top post into two. The first post is all things you can do (almost) entirely within HA. The only addon dependency the packages in the first post have is on the Check Home Assistant configuration addon. There’s an automation in there that automatically starts that addon when there’s an update to core available. The second post is additions for people that use Node RED.

Without Node RED you’ll still get a notification any time there’s an update to core, supervisor, any add-on you have installed or any HACS component you have installed. You’ll also get a notification any time there’s an update to DNS, CLI or Audio if you use the second package instead (added that later).

The things I added that do depend on Node RED are whenever a HACS component or add-on you have installed updates instead of getting a generic message that says “you have this many HACS/Addon updates available” the notification says specifically which one updated. And now I added the “new addon” notification that depends on Node RED.

But it definitely doesn’t require Node RED, you can still get notifications for updates without it!

[noodlemctwoodle]

@CentralCommand Thanks for this awesome post!!! I’ve integrated this into my dashboard so thank you very much for sharing

[dorremez (Dor Remez-Guy)]

Hi, want to try using your sensors…

But have a quick question… the ‘“SUPERVISOR TOKEN”’… This will be what I’ve entered? (Bearer fdDGSg…) OR, what I get in result after that which is way longer…?

Thanks a lot

[CentralCommand (Mike)]

If you scroll up a few posts here’s my description on how the SUPERVISOR_TOKEN bit works:

@CentralCommand

When running in Docker the supervisor token HA uses is made available via an environmental variable called SUPERVISOR_TOKEN . So the $(printenv SUPERVISOR_TOKEN) part is literally going to run the command to print out the value of the environmental variable SUPERVISOR_TOKEN and insert it into the command at that spot. Since the commandline sensors run their command as HA that should work as is.

So basically if you’re running in Docker you should just be able to use that sensor as is. If you’re not running in Docker I’m not sure if it will work as is but it can’t hurt to try it anyway, worse that happens is you’ll get an unauthenticated error in the log. If you do have to or want to generate your own token for this sensor then you can just swap it in and remove the $(printenv SUPERVISOR_TOKEN) part

[drmilos (drdre)]

Where you put this?

I am trying to grt notification on Telegram and not sure in which file I shall store code

# Update is available - un-acknowledgeble, auto-dismiss, me only
# Wait 5 minutes before first to give core config check time to run
ha_update_available:
  name: HA has an update
  entity_id: binary_sensor.updater
  state: 'on'
  can_acknowledge: false
  repeat: 
  - 5
  - 360
  skip_first: true
  title: 'Update for HA available'
  message: "New version is {{ state_attr('binary_sensor.updater', 'newest_version') }}. Currently on {{ states('sensor.current_version') }}"
  notifiers:
  - 'me'
  data:
    tag: 'ha-update-available'
    url: 'http://hassio.local/hassio/addon/core_check_config'
    ttl: 21600

# Supervisor update is available - un-acknowledgeable, auto-dismiss, me only
supervisor_update_available:
  name: Supervisor has an update
  entity_id: binary_sensor.updater_supervisor
  state: 'on'
  can_acknowledge: false
  repeat: 360
  title: 'Update for HA Supervisor available'
  message: "New version is {{ state_attr('sensor.supervisor_updates', 'newest_version') }}. Currently on {{ state_attr('sensor.supervisor_updates', 'current_version') }}"
  notifiers:
  - 'me'
  data:
    tag: 'supervisor-update-available'
    url: 'http://hassio.local/hassio/dashboard'
    ttl: 21600

# HACS repos have updates available - unacknowledgeable, auto-dismiss, me only
hacs_update_available:
  name: HACS repos have updates
  entity_id: binary_sensor.updater_hacs
  state: 'on'
  can_acknowledge: false
  repeat: 360
  title: "Updates available in {{ states('sensor.hacs') }} HACS repo{% if states('sensor.hacs') | int > 1 %}s{% endif %}"
  message: ""
  notifiers:
    - 'me'
  data:
    tag: 'hacs-update-available'
    url: 'http://hassio.local/hacs/installed'
    ttl: 21600

# Addons have updates available - unacknowledgeable, auto-dismiss, me only
addon_update_available:
  name: Addons have updates
  entity_id: binary_sensor.updater_addons
  state: 'on'
  can_acknowledge: false
  repeat: 360
  title: "Updates available for {{ states('sensor.supervisor_updates') }} HA addon{% if states('sensor.supervisor_updates') | int > 1 %}s{% endif %}"
  message: ""
  notifiers:
  - 'me'
  data:
    tag: 'addon-update-available'
    url: 'http://hassio.local/hassio/dashboard'
    ttl: 21600

[CentralCommand (Mike)]

Those are alerts, see here for more info: https://www.home-assistant.io/integrations/alert/

There’s no default file to put alerts in like with automations, scripts, scenes, etc. They can either go into your configuration.yaml under alert: like it shows in that help link or you can use one of the options in splitting up the configuration to move them to a separate file. Using a package like I linked in my top post is one such option for splitting up the configuration.

I’m not super familiar with telegram but as long as you can make a notifier with platform: telegram (which it looks like you can) it should work. You can either make a telegram notifier called me or adjust this section above in all the alerts to the name you choose:

notifiers:
  - 'me'

I don’t know what kinds of options telegram notifiers accept for data but you’ll also probably need some adjustment there for each alert as that is specific to each type of notifier.

[drmilos (drdre)]

Will deal with it in following days.

Thank you for the prompt reply

[Tomahawk]

Useful code, - thanks for sharing!

Any chance you know how to code a “new version” sensor for the System HassOS X.YZ…?

Cheers.

[CentralCommand (Mike)]

Haha yea I thought about that one too. So there is a /supervisor/host/info API but this is what I get back from it:

{
  "result": "ok",
  "data": {
    "chassis": "",
    "cpe": "",
    "features": [
      "reboot",
      "shutdown",
      "services",
      "hostname"
    ],
    "hostname": "hassio",
    "operating_system": "Raspbian GNU/Linux 10 (buster)",
    "deployment": "",
    "kernel": "4.19.66-v7l+"
  }
}

The problem here of course is that it doesn’t include anything about the version so there’s no way to tell from this API call if I need an update. This doesn’t make it impossible it just means I think I’d have to have something running on the host basically telling HA when its host has an update.

This was enough of a roadblock that it deterred me for now but I will probably revisit it at some point. Something like that would clearly be dependent on the host OS though so it would need to be modified per host type that HA can be deployed on.

That being said, you might actually want to try the API call for your own system first since I notice you have more info under Host System on yours then I do and it actually does list some version info (HassOS 3.13). From the HA CLI when you execute ha host info what do you see? Does the response include info on current version and newest version for you? If so that’s all you need to make a sensor like the ones above.

[EDIT] Wow, ok, you have identified a flaw in my plan my friend. I realized after you said this that I didn’t actually know how to update raspbian since I haven’t actually had it that long. Appears the answer is run apt update and now that I did it appears I have 280 upgradeable packages LOL

However I think this does make it scriptable as long as you can ssh into the host from HA so I’m going to dig into this. I think I can figure this out

[paddy0174 (Patrick)]

The correct command would be:
sudo apt update && sudo apt upgrade -y

Update reads the package list and updates the ressources. Upgrade actually does the real process of upgrading software. The -y confirms all changes upfront (no interaction).

But, you have to be careful, this has some pitfalls in general. What you wouldn’t do with this, is a dist-upgrade (upgrading to a higher version of the OS). In theory you could do that as well, but I wouldn’t recommend that. Then it would be:
sudo apt update && sudo apt upgrade -y && sudo dist-upgrade -y

Oh, and there are a few more package managers out there, so apt is on some systems the way to go, others would need apt-get or aptitude.

[CentralCommand (Mike)]

Thanks! Yea I agree, auto-updating the host in the background seems a bit dangerous, I wouldn’t want to put that on a command_line sensor. I choose to put the actual update command onto a shell_command that I run when I know there are updates. Although just now when I did it it took down home assistant, I assume because a package it was using was updated. So yea, I definitely wouldn’t want to run that command automatically.

That being said @Tomahawk I did figure it out I’ll share it below but I’m not going to add this one to the package because of a few important caveats:

1. This is completely OS dependent. It looks specifically at the output of apt to see if there’s updates so if apt is the package manager your host uses it will need to be adjusted
2. apt pops out this lovely warning message when you use it in this way WARNING: apt does not have a stable CLI interface. Use with caution in scripts. So yea, it appears they don’t really encourage this kind of usage and it may break in the future and require fixing. Just FYI
3. It relies on being able to ssh into the host. To do this you’ll need to replace parts of the sensor with the username and address of your particular host, it won’t just work out of the box like the others above
4. I set up my HA to be able to SSH into the host without a password. For anyone that doesn’t know how to do this, here’s a quick guide. Alternatively you can include your password but password-less SSH is the best practice for security.

With that out of the way, here it is. So like the others, first we need a sensor to tell us when there’s updates. And in this case since we’re using apt our sensor is going to return us a count of packages that need updates so I added a binary_sensor to go with it and then obviously an alert. Here’s those three:

sensor:
  # Sensor to track info on updates available for host
  # Warning: apt returns a message that its CLI is not stable enough for scripting. So be warned, this could break
  - platform: command_line
    name: Host updates
    scan_interval: 900
    command: 'ssh -o UserKnownHostsFile=/config/.ssh/known_hosts <INSERT HOST USERNAME>@<INSERT HOST ADDRESS> -i /config/.ssh/id_ed25519 ''sudo apt update > /dev/null && sudo apt list --upgradeable'' | jq --raw-input --slurp ''{ "packages": split("\n") | del(.[] | select(. == "" or . == "Listing...")) }'''
    value_template: '{{ value_json.packages | length }}'
    json_attributes:
    - packages

binary_sensor:
  - platform: template
    sensors:  
      # True if there's updates available for the host
      updater_host:
        friendly_name: 'Updater - Host'
        device_class: problem
        value_template: "{{ states('sensor.host_updates') | int > 0 }}"
        availability_template: "{{ (states('sensor.host_updates') | int(-1)) > -1 }}"

alert:
  # Host update is available - un-acknowledgeable, auto-dismiss, me only
  host_updates_available:
    name: Host has updates
    entity_id: binary_sensor.updater_host
    state: 'on'
    can_acknowledge: false
    repeat: 360
    title: "Update{% if states('sensor.host_updates') | int > 1 %}s{% endif %} for HA Host available"
    message: "Updates available for {{ states('sensor.host_updates') }} package{% if states('sensor.host_updates') | int > 1 %}s{% endif %} on host"
    notifiers:
    - 'me'
    data:
      tag: 'host_updates_available'
      ttl: 21600

NOTE: Run the ssh command in the host updates sensor once manually in the portainer add-on to get your known_hosts file updated, otherwise it won’t work. Or alternatively copy the necessary line into /config/.ssh/known_hosts file manually from some other machine so its set up. Otherwise the SSH command will fail behind the scenes.

So, what does this sensor do? It’s going to

1. SSH into the host
2. Run sudo apt update first to update the package list (ignoring any stdout of that command)
3. If that went successfully, run sudo apt list --upgradeable to get the list of packages to update
4. Use jq to create a JSON array out of that output and stick it in a field called packages ignoring rows that just say “Listing…” or are blank (since apt does that, remember, it doesn’t like being scripted)
5. Set the value of the sensor to the length of that JSON array and store the list of packages into the packages attribute

Note that I set the scan_interval to 15 minutes since this one is doing a lot more work then the others.

But of course there is one difference with this one from the others, unlike the others we have no UI to send this to. There’s no place in Home Assistant that allows you to update the host. So let’s make one. With shell command we can make a service that tells our host to update all packages needing updates like so:

shell_command:
  # Updates packages on host
  update_host: 'ssh <INSERT HOST USERNAME>@<INSERT HOST ADDRESS> -i /config/.ssh/id_ed25519 ''sudo apt upgrade -y'''

Then you can include UI showing what needs updates with an update button up top. Here’s what I made for anyone interested. Note that it does depend on two HACS packages though, vertical stack in card and flex table. You’ll need to install them to use this as is. Or make a different UI, there’s lots of options

cards:
  - cards:
      - entity: sensor.host_updates
        name: Host packages with updates
        type: entity
      - icon: 'mdi:update'
        icon_height: 30px
        name: Update all
        tap_action:
          action: call-service
          service: notify.update_host
          service_data:
            message: Ignore
        type: button
    horizontal: true
    type: 'custom:vertical-stack-in-card'
  - columns:
      - attr_as_list: packages
        id: name
        modify: 'x.replace(/^(\S+)(\s.*)$/, ''$1'')'
        name: Name
      - attr_as_list: packages
        modify: 'x.replace(/^(\S+)(\s.*)$/, ''$2'')'
        name: Details
    entities:
      include: sensor.host_updates
    sort_by: name-
    strict: true
    type: 'custom:flex-table-card'
title: Host packages with updates
type: 'custom:vertical-stack-in-card'

And there we go! Now hopefully I’ll never build up that many host updates again haha.

[pergola.fabio]

can anyone tell me how to retrieve the current HassOS version thats running?
i am still running 3.12 , buw how can i get that in a sensor?

[paddy0174 (Patrick)]

Take the first sensor out of this package:

sensor:
  # Sensor to track available updates for supervisor & addons
  - platform: command_line
    name: Supervisor updates
    command: 'curl http://supervisor/supervisor/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''{"newest_version":.data.version_latest,"current_version":.data.version,"addons":[.data.addons[] | select(.version != .installed)]}'''
    value_template: "{{ value_json.addons | length }}"
    json_attributes:
    - newest_version
    - current_version
    - addons

But why not taking this package? That is exactly what you want, and someone else has already taken care of avoiding all the cliffs…

[CentralCommand (Mike)]

I’m not using HassOS so I can’t really try out the APIs on HassOS to see what’s available. But I think it might be available in the /supervisor/host/info API, I just can’t confirm that.

Do you have a way to use the home assistant CLI? If so could you run this command for me and let me know what the output is:
ha host info --raw-json

If anything in that response is something you don’t want to share feel free to replace those values with placeholders. I just need to see what the fields are that come back for you and if it includes info on HassOS current version and next version to know if a sensor is possible. Mine doesn’t when I run that command but I have a suspicion it behaves differently on HassOS since your developer tools page has more host info then mine.

[pergola.fabio]

aha, yes the HassOS version is present, here is output

➜  ~ ha host info --raw-json
{"result": "ok", "data": {"chassis": "vm", "cpe": "cpe:2.3:o:home_assistant:hassos:3.12:*:production:*:*:*:ova:*", "features": ["reboot", "shutdown", "services", "hostname", "hassos"], "hostname": "hassio", "operating_system": "HassOS 3.12", "deployment": "production", "kernel": ➜  ~

is it possibe for me to retrieve it with the same curl command line?
i already have the current version, so thats fine

[CentralCommand (Mike)]

Yep. If you change the command to curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" everything you need should be in that response.

When you copied from the command line it looks like it got cut short since it stops after "kernel":. But since it says HassOS 3.12 I think I can figure it out from that. If the only thing you want is the version number then I think something like this would work:

sensor:
  # Sensor to version of HassOS
  - platform: command_line
    name: HassOS Version
    command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" '
    value_template: "{{ value_json.data.operating_system[7:] }}"
    json_attributes:
    - data

I believe this will give you a sensor where the value is the current version of HassOS and the attributes contain the other details you have.

It doesn’t look like the next version is in there so I don’t think you can use this to alert on updates, just the current version you have installed. Unless the next version information is after kernel in the response since that’s as far as I can see.

[pergola.fabio]

Thxn for that, gonna test tomorrow!! I already have a sensor for next version, so I can manage my notification

[CentralCommand (Mike)]

Oh nice! Care to share? I know @Tomahawk was looking for that info earlier and I didn’t know how to get it. Probably others would find that handy as well.

[pergola.fabio]

for current HassOS version, i use this one :

  - platform: rest
    resource: https://version.home-assistant.io/stable.json
    name: HassOS Version
    value_template: "{{ value_json.hassos.ova }}"
    scan_interval: 3600