Ah yea, I need to update that. It used to be sensor.hacs_updates but this was originally made a while ago. I believe it changed to sensor.hacs when v1.0 came out since a lot changed at that point.
I still have it as sensor.hacs_updates in my system since I just clicked and changed the entity ID. But I should update it to use the default name as most people will have that.
Just to note: HA Core v2021.4 brings some enhancements for Supervisor:
The Supervisor is now also in the integrations dashboard, and provides entities for all kinds of things! These entities are disabled by default, so head over to the integration and see if there anything in there you could use. Thanks @raman325!
So this way you can now - out of the box - use entities for current version and available updates for addons including for Home Assistant OS.
sensor.home_assistant_operating_system_version
sensor.home_assistant_operating_system_newest_version
binary_sensor.home_assistant_operating_system_update_available
Downside: 3 single entities where @CentralCommand’s command line sensor definition only needs one entity with three attributes. For this reason I´ll not switch to the Supervisor integration provided version and update information. Never change a running system 
, might be of interest for people starting from scratch with update notifications though.
It is fantastic! 
However, in this way there are many more entities, while with a single sensor you have news on more addons for example (update available, current version, new version)
uhmmm, and you don’t know if an addon is working or not. 
Yea I’ve been looking into this. I had a long chat about this in #beta in discord during the beta to see if I could convert over to using those sensors for info on whether the update is available instead of hitting the supervisor API with curl.
Unfortunately its pretty tricky to just update the package to those because there’s really no easy way to find them. The sensors created by the integration don’t have a common pattern in their entity ID that would make them easily findable by for loop to quickly see if any addons have updates. It also doesn’t look like they have an attribute or anything that makes them easily identifiable. They do all come from the same integration but that info can’t be leveraged in a template currently.
However blueprints do have selectors around integrations so I’m revisiting that in light of this. But I really don’t want to make a blueprint that requires people make one per addon as that just seems like a lot of grunt work and then a lot of automations clogging their list. One in total would be ideal, trying to see if that’s possible.
Anyway I’m still looking into it (and if anyone has any good ideas please share!). For now though I’m going to leave the package as is.
Is there a service to call to start the updates (have/supervisor/hassio) from telegram?
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.
Thanks, Any other suggestion for HACS integrations?
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.
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
…and sometimes pretty important to e. g. read the change log/release notes. For me personally that’s a bit too much of automation.
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) 
This is what I do as well. My notifications about updates for a specific component always include the following:
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.
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
Shell command seems to be missing the -o UserKnownHostsFile=/config/.ssh/known_hosts option.
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:
unavailable anymore. BUT instead it shows 0 updates (there are 4).unknown.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.
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
Nice, do you have that display as a love lace card? Can you share that also?
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.
Thanks a lot for sharing it Rod. I added a Telegram notification right after the persistent one.
@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)?
