I was working on adding manual sensors, but it turns out that the Supervisor Integration actually has binary sensors for updates being available now for each addon installed as well as the operating system, but they are disabled by default. Enabling these was a fair bit easier than trying to setup the command_line sensors.
1 Like
where can you enable them?
edit: nm, found it
Yea I had tried those a bit ago but the problem before was that I wanted one sensor that told me “is there an add-on with an update?” and getting that was painful. There’s an update_available sensor per add-on but there was no real way to collect all those sensors to answer my question. And no easy way to get the current version, latest version and other information about the add-on from that sensor to craft notifications with all the information I wanted.
However I realized since I initially looked at that integration this problem has been solved thanks to the great device template functions that raman325 added. Now I can answer my question in a sensor with this one template:
{{ expand(
integration_entities("hassio")
| select('search', '_update_available(_\d+)?$')
| reject('search', '_operating_system_')
) | selectattr('state', 'eq', 'on')
| list | count }}
And starting from that update_available entity I can figure out the slug of an addon and then any other information I want using this template:
{% set entity_id = "<id of entity created by hassio integration>" %>
{{ (device_attr("entity_id", "identifiers") | first)[1] }}
Which means I can reduce this package’s reliance on the command line integration a bit. Well at least for tracking add-on and os updates, commandline sensors are still needed for all the others to my knowledge. I’ve been updating my config and will publish an updates once I get things to a good state.
Although I’ll probably publish it as a separate package. The benefit of the package as it is now is people can just drop it in and it basically starts working. If it depends on the hassio integration then its not that simple anymore. I have to instruct people to enable that integration (which can only be done in the UI not in the package’s YAML), enable all the sensors it creates and ensure they maintain the proper naming convention for their entities (i.e. entity IDs of the update available sensors contain the string _update_available). It would be nice if there was a better way to publish dependencies and find those particular entities within the integration.
3 Likes
Hello,
great news, i search for a while for addon only,
could you share your complet sensor code please?
Thanks!
Like you just want me to turn my template into a template sensor for you? I haven’t made the new package yet. If you just want the one sensor then here I suppose it would be like this:
template:
- sensor:
- unique_id: 8b6338db01224a878c9eb22db4ef1d9c_addons_have_updates
state: >-
{{ expand(
integration_entities("hassio")
| select('search', '_update_available(_\d+)?$')
| reject('search', '_operating_system_')
) | selectattr('state', 'eq', 'on')
| list | count }}
2 Likes
Just wanted to say thank you (again) and make a short review what I’ve built based on this.
I can strongly recommend this topic (Update notifications! Core, HACS, Supervisor and Addons).
I‘ve built everything based on this topic. HA, HASS OS, Supervisor, Supervisor Addons, HACS, deCONZ, router, Shelly devices, … created my own for Pi-Hole, Nextcloud (apps and server), … afterwards. And I even remotely update APT packages of other servers - everything from Home Assistant.
Process is always the same:
- Get current version info
- Get latest version info
- Compare current to latest, create update switch
- Visualize it in the UI
- Create notification automation
- Optional: Create update switch
In my case I have a dedicated update section for all HA stuff and integrated systems, where only updates are shown. If there are no updates, the section is invisible.
Took me quite some time but I‘m very happy with that setup.
Example screenshots taken from the mobile app:
As you can see I need to spend half an hour or so on the weekend to do some updates 
For notifications part: I send them to mobile devices using HA Companion app (once) as I personally don’t like the persistent notifications. My persistent notification is the whole update section in the UI.
6 Likes
Maybe a stupid question.
Pasted config from the firs post to packages/updater.yaml
Check config says:
expected a dictionary for dictionary value @ data[‘packages’][‘sensor’]
What am I missing?
How are you including packages in your configuration? Like somewhere in your config there should be something like:
homeassistant:
packages: <what is here?>
Yes I have
homeassistant:
packages: !include_dir_merge_named packages
And I have working package. So I created a new yaml file and pasted the package config there
If you are using include_dir_merge_named then you will need to modify the YAML you pasted in. The way include_dir_merge_named works is detailed here.
The file’s name is not taken into account with that include mechanism, its basically just taking the content of the file and putting it directly under packages. Which is why HA is confused why your package called sensor appears to be a list, not a dictionary. Adjust updater.yaml like this:
update_notifications:
<paste package details here, indent everything one extra>
1 Like
Hi, I have the same problem.
When i trying to put my “supervisor_updates.yaml” package to packages folder
packages: !include_dir_named includes/conf
like this
update_notifications:
sensor:
# Sensor to track available updates for supervisor & addons
- platform: command_line
I have an error:
Package supervisor_updates setup failed. Component update_notifications Integration ‘update_notifications’ not found.
Thanks for your effort and great package in the first post.
Just wanted to ask if you did finish creating the new package in the meantime?
Hi @CentralCommand,
great work! May I suggest that you add a hint in your initial posting that meanwhile Supervisor provides out-of-the-box entities for versions, newest versions, and updates available that only need to be turned on? I understand that your method creates less entities with more attributes and thus has advantages. But for some users the Supervisor entities will be the low hanging fruit that is extremely easy to reach and use. You would spare them to read through about 250 postings to discover that meanwhile there is an alternative method.
2 Likes
Just posted it. As noted in the details its unfortunately not just import and go anymore since there’s manual “enable the sensors” steps. But does involve a lot less curling supervisor. Let me know if you have any issues.
3 Likes
Turning them on doesn’t give any notifications though? It just enables some sensors. The point of this post was to provide an easy to import package that then gives you notifications for updates to any of your stuff. And besides the original package still worked without issue even on latest builds.
I did update it to use the supervisor integration just now if you want to try that out. That being said as I did note there’s a cost in that the package isn’t quite as easy to use now. Previously the only manual step was to make sure you had a notify.me service defined (or else replace the notifier in the alerts with the notifier of your choice). Now you have to open up the UI and enable a lot of sensors too.
Would you like to change the new updated package between </>? 😉
Btw; great work!
1 Like
Sorry I’m not sure what the question is. Is that an error you’re seeing or are you asking me to update something in the post?
The code formatting in your first post is broken.
1 Like
Fixed. Thanks!
hey dude,
i have a question:
Would it be possible that I get with your updated notifications, when an update still the current version and the new version as a message? So be it HACS or Addon?
That would be mega