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) 
1 Like
This is what I do as well. My notifications about updates for a specific component always include the following:
- The new and old version numbers (to see if its patch, minor or major)
- A link to the changelog notes
- A link to open to the thing’s page in the HA UI (if necessary)
- 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.
1 Like
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.
1 Like
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:
- I rebooted the faulty host #2
and now sensors are notAfter next HA restart againunavailableanymore. BUT instead it shows 0 updates (there are 4).unknown. - And ALL sensors don´t get updated.
scan_intervalis 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
8 Likes
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)?
I do actually. In fact I wrote a community guide on the topic haha
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
Its possible to know the supervisor last boot too?
Thanks
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.
Hello, it’s possibile to add an auto-dismiss of the update available notification?
As add-on are autoupdating, and when upgrading core HASS will be restarted so the issue is not present, i still have the problem with HACS, that after i have started all the upgrades sometime i forgot to dismiss the notification, so i’ll come back after few hours and i still have the old update available notification.
Another good thing that i love to have is the upgrade to version x.xx complete notification, is there any service that can help me in that?
This is actually pretty easy as it turns out. One of the options in the alert integration is done_message. This is the message that gets sent to the notifier when the alert was on and is now off because its alerting condition has become false. In your case that would mean an upgrade was available and now it is complete.
So in your alerts just set the done_message to something like so:
done_message: "Upgrade to version {{ state_attr('<ID of the matching upgrade sensor for this alert', 'newest_version') }} complete"
So this one is easy if you use mobile notifications although it kind of rules out your ability to do the “upgrade complete” notification because it uses the same field. When you send a notification with the message clear_notification then it dismisses any existing notifications with the same tag (see here for info on notification commands like this). So to get an alert which creates a mobile notification and then automatically dismisses it when the condition becomes false you can simply do this:
alert:
my_alert:
name: My example alert
entity_id: binary_sensor.problem_found
state: 'on'
title: "There's a problem!"
message: "It's bad, go check it out!"
done_message: 'clear_notification'
notifier: my_ios_or_android_phone
repeat: 30
data:
tag: REQUIRED_FIELD
With this when the alert turns on it will create a mobile notification with the tag REQUIRED_FIELD and that message. But then when the alert turns back off it will send the message clear_notification to the same tag, causing the mobile app to auto-dismiss this notification it created.
This trick works with any alert, including the upgrade notification ones shown here. It does however require that you use the mobile app for notifications. If you use some other notification service then you’ll need to look up if that service supports dismissing notifications and how/if you can leverage it from an alert.
Now I’m going to take a stab in the dark here and say that what you actually want here is not auto-dismiss but rather you want the “Upgrade complete” notification to replace the “Update available” notification once it is done. In that case, we use the first technique but now add a tag so the new notification replaces the old one. So your alert looks like this:
alert:
my_alert:
name: My example alert
entity_id: binary_sensor.problem_found
state: 'on'
title: "There's a problem!"
message: "It's bad, go check it out!"
done_message: 'The problem has been resolved!'
notifier: my_ios_or_android_phone
repeat: 30
data:
tag: REQUIRED_FIELD
What will happen here is each notification created by this alert will replace the previous notification on your phone/mac/ipad/etc. since they all have the same tag. So when the problem is resolved the “It’s bad, go theck it out!” notification becomes the “The problem has been resolved!” notification, you never see both.
Again though this technique only works if you use the mobile app. If you have a different notifier you’ll have to see if/how it supports notification replacement.
1 Like
Hello,
what is the size of your image /local/homeassistant/homeassistant.png in pixel please?
my result is like this :
1200x630 px
1 Like
After the update, everyone has this problem:
-
sensor.home_assistant_operating_system_version
-
sensor.home_assistant_operating_system_newest_version
Yes.
Looks like someone forgot to update the status page:
1 Like