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)?
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.
Hello,
what is the size of your image /local/homeassistant/homeassistant.png
in pixel please?
my result is like this :
1200x630 px
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:
@CentralCommand I have a basic syntax issue here.
How to handle '
which are part of the command in the command_line sensor definition? (also in HA Terminal addon first)
I need to run this command on a foreign SSH host:
pihole -v | head -1 | grep -oP '(?<=\is v)(\d*\.)+(\d*)'
As you can see it already contains '
twice for the RegEx definition. I already tried few combinations in Terminal addon prior to defining the sensor but I can´t make it syntactially work.
You got an idea? What´s a working escape sequence for this?
Update 1: on SSH/Terminal addon using "
around the actual command works
(ssh username@IP -i /config/.ssh/id_rsa -o UserKnownHostsFile=/config/.ssh/known_hosts "pihole -v | head -1 | grep -oP '(?<=\is v)(\d*\.)+(\d*)'"
) but not in the sensor definition, YAML seems to be a bit special here…
Update 2: I believe some part of the actual RegEx (some characters are probably used as escape sequence by YAML/HA) is the problem. No idea how to work around this though…
Yea if your command has both single and double quotes in it then you have to escape one of them. What I usually do is wrap the command in single quotes and then escape the single quotes inside, you do this by using a double single quote (''
). There’s actually an example of this in the package at the top, here’s the command line sensor for the new addons one:
# Sensor to track details on new addons
- platform: command_line
name: New addons
command: 'curl http://supervisor/addons -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" 2> /dev/null | jq --slurpfile slugs /config/common/found_addon_slugs.txt ''{"addons":[.data.addons[] | select(.slug as $slug | $slugs | index($slug) | not)], "repositories":.data.repositories}'''
scan_interval: 900
unit_of_measurement: new release(s)
value_template: "{{ value_json.addons | length }}"
json_attributes:
- addons
- repositories
- addon_slugs
Notice the command has both single and double quotes in it so the single quotes are escaped inside.
The problem seems to be the RegEx part. As soon as I have at least one \
in the command_line sensor command, Visual Studio Code complains unknown escape sequence
I try to avoid adding even more complexity to this by using an external script (Command Line - Home Assistant)…
Oh I see what you mean. Maybe try replacing all the single backslashes with \\
? So that way the first interpreter sees the escape sequence for backslash and then passes on a backslash to the command itself.
Simple but probably genius. VSC stopped complaining; I will continue with sensor definition and give it a try. Thanks for the moment!