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

[FrancYescO (Francesco)]

Is there a service to call to start the updates (have/supervisor/hassio) from telegram?

[CentralCommand (Mike)]

For updating an addon you have this:

service: hassio.addon_update
data:
  addon: <addon slug>

For updating core & supervisor there isn’t but you can make them like this:

shell_command:
  update_core: 'curl -X POST "http://supervisor/core/update" -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" 2> /dev/null'
  update_supervisor: 'curl -X POST "http://supervisor/supervisor/update" -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" 2> /dev/null'

Although for supervisor you could also just wait since it auto-updates.

[FrancYescO (Francesco)]

Thanks, Any other suggestion for HACS integrations?

[CentralCommand (Mike)]

Well the package at the top includes an alert which sends a notification sensor.hacs_updates has a value greater then 0. The notification just has the count of hacs packages requiring updates though.

If you want a notification as an update to a HACS component becomes available with the details of what HACS component needs an update you can do that but its a bit trickier. I did that in Node RED since I find that easier, the export of my flows for that is in the second post. You can do it in pure HA though with something like this:

automation:
  trigger:
    platform: state
    entity_id: sensor.hacs_updates
  action:
    - choose:
        - alias: Update count went up
          conditions: "{{ trigger.to_state.state | number > trigger.from_state.state | number }}"
          sequence:
            - variables:
                component: >-
                  {% set old_ids = trigger.from_state.attributes.repositories | map(attribute='name') %}
                  {{ trigger.to_state.attributes.repositories | rejectattr('name', 'in', old_ids) | first }}
            - service: notify.me
              data:
                title: "HACS Update - {{ component.display_name }}"
                message: "Newest version of {{component.name}} is {{component.available_version}}, installed version is {{component.installed_version}}"
                data:
                  tag: "{{ component.name }}"
      default:
        - variables:
            component: >-
              {% set new_ids = trigger.to_state.attributes.repositories | map(attribute='name') %}
              {{ trigger.from_state.attributes.repositories | rejectattr('name', 'in', new_ids) | first }}
        - service: notify.me
          data:
            message: clear_notification
            data:
              tag: "{{ component.name }}"

Just an FYI I have not tested this code. My automation around this is in Node RED so I’m just trying to translate what I have to HA YAML. It’s kind of complicated so it may need some adjustment but hopefully you can see what’s going on and take it from there if it does.

Also if you don’t use the HA mobile app or HTML5 notifications then you can drop the clear_notification bit. That automatically clears the notification after you’ve done the update but those integrations are the only two that support removing notifications. If you use telegram or something for example then dismissing after update isn’t an option.

[FrancYescO (Francesco)]

Thanks for this, actually i was using the solution that alexkrupin posted some post above, that basically notify for update of everything, but the thing i miss is to just avoid opening HA to let the updates start but i want to use a telegram command, you solved the problem with Core (Supervisor and Addons have autoupdates Activated) i just miss something for update HACS components where i still need to open HA, start the update of outdated component(s), restart core. sometime pretty boring

[e-raser]

…and sometimes pretty important to e. g. read the change log/release notes. For me personally that’s a bit too much of automation.

[FrancYescO (Francesco)]

Starting the update from telegram, at least for me does not mean that i’ll skip looking at the changelog/release note (infact direct link to these are in notification message)

[CentralCommand (Mike)]

This is what I do as well. My notifications about updates for a specific component always include the following:

1. The new and old version numbers (to see if its patch, minor or major)
2. A link to the changelog notes
3. A link to open to the thing’s page in the HA UI (if necessary)
4. An action which starts the update from the notification without needing to open HA UI (if possible, can’t do that with HACS sadly)

With core updates I took it even further. My notification also includes whether the config check has passed or failed and a link to the logs of that add-on. So I know whether its safe to click that update action or whether I have to go look at the logs to see what happened.

This way I can completely manage my updates without touching the HA UI but still be safe about it.

[Hansie9999 (Hans Jambé)]

Hello,

I installed the full package,

for starters I wanted just a simple line where icons show up if there are any updates, like this (currently is it showing a HA update)

However, I know there are also addon updates but they are not showing (I simply want an extra icon to show up if there is anything with an update for now, ill work from there to get more details )

this is my code in the ui-lovelace.yaml

      - type: entity-filter
        entities:
          - entity: alert.ha_update_available
            name: "HA"
            show_state: false
          - entity: alert.supervisor_update_available
            name: "Supervisor"
            show_state: false
          - entity: alert.addon_update_available
            name: "Addons"
            show_state: false
          - entity: alert.hacs_update_available
            name: "HACS"
            show_state: false
          - entity: alert.audio_update_available
            name: "Audio"
            show_state: false
          - entity: alert.cli_update_available
            name: "CLI"
            show_state: false
          - entity: alert.dns_update_available
            name: "DNS"
            show_state: false
          - entity: alert.multicast_update_available
            name: "Multicast"
            show_state: false
          - entity: alert.observer_update_available
            name: "Observer"
            show_state: false
        state_filter:
          - "on"  
        card:
          type: glance  
          title: Beschikbare updates  

these are my entities, I think there is something fundamentaly wrong, because the addons update warning is showing “idle” , should that not show “on” ? or a number of the amount of updates available ?

Can anyone point me in the direction to where I probably am going wrong ??

Thank you,

Hans

[e-raser]

@CentralCommand

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_

Shell command seems to be missing the -o UserKnownHostsFile=/config/.ssh/known_hosts option.

[e-raser]

I have one strange behaviour when trying to adopt this for two hosts: while it´s working great for host #1, the command_line sensor for host #2 just gives “Unavailable” (and therefore the binary_sensor of host #2 is unavailable too).

I checked the whole SSH passwordless part - same for both hosts, works great.
I checked the command in Portainer first - same for both hosts, works great.
I checked the /config/.ssh/known_hosts file and it contains lines for both hosts.

No idea why it works in Portainer but the command_line sensor fails. Any idea @CentralCommand No idea what else to check

Update:

1. I rebooted the faulty host #2 and now sensors are not unavailable anymore. BUT instead it shows 0 updates (there are 4). After next HA restart again unknown.
2. And ALL sensors don´t get updated. scan_interval is 5 minutes but last change has been only once when HA has been restarted last time. Those ssh command_line sensors are the first and only one behaving like that. Strange… what the?

Update 10 days later: seems to work now, somehow.

[rodpayne]

Thanks everyone for the great info! I made a package that takes all of the notifications and puts them into one persistent_notification. On GitHub: packages/update_notifications.yaml

[sleeepy2]

Nice, do you have that display as a love lace card? Can you share that also?

[rodpayne]

No, it is only this persistent notification. My goal was to have everything come to me when there is something to see, rather than remembering to go look for it. It probably wouldn’t be too hard to direct the markdown to two places. I’ll look at that the next update.

[alexdelprete (Alessandro Del Prete)]

Thanks a lot for sharing it Rod. I added a Telegram notification right after the persistent one.

[e-raser]

@CentralCommand
Related to your Update notifications! Core, HACS, Supervisor and Addons - #32 by CentralCommand I came across the SSH thing when trying to get folder size information from within the InfluxDB container (Unreliable InfluxDB size sensor - #34 by e-raser).

Do you know / have any experience with HA container being able to (password-less) SSH to another docker container (which is probably only possible for root so workflow would look like: HA container → SSH to host → login to another docker container → get information → done)?

[CentralCommand (Mike)]

I do actually. In fact I wrote a community guide on the topic haha

SSH'ing from a command line sensor or shell command

I’ve noticed there’s a significant number of posts looking for help on this topic and the posters all seem to struggle with a few common issues. I realized I’ve been almost copying and pasting my responses on these topics so it seemed like a good case for a community guide. What will this cover This guide will walk through the process of getting a command which ssh’s into another machine to get some simple data ready to be included in a command line sensor. To keep it simple I’ll use the same …

[e-raser]

I know that guide as I used it for creating sensors and scripts for checking APT updates of other servers via SSH. This time my use-case is a bit different… I´ll follow up in that topic as it has nothing to do with update notifications

[txespirito]

Its possible to know the supervisor last boot too?
Thanks

[CentralCommand (Mike)]

Not a good way from what I can see. Neither the ha supervisor info or ha supervisor stats commands have it so not seeing anyway to get it from the api. You could get it via the docker cli by using docker inspect <Id of supervisor container> but that’ll take a good bit of setup work.

If you really need it I’d recommend putting in a feature request to get an uptime sensor for supervisor. Or a pr if your comfortable in code.