Sorry, I missed that one:
- platform: command_line
name: Supervisor updates
command: 'curl http://supervisor/supervisor/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"|jq ''{"newest_version":.data.version_latest,"current_version":.data.version,"addons":[.data.addons[]|select(.version != .installed)]}'''
value_template: "{{ value_json.addons|length }}"
json_attributes:
- newest_version
- current_version
- addons
haha, no worries 
can I do this in Hassio OS too?
'curl http://supervisor/supervisor/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"|jq ''{"newest_version":.data.version_latest,"current_version":.data.version,"addons":[.data.addons[]|select(.version != .installed)]}'''
thinking of the authorization here especially.
using a rest sensor myself with authorization like this:
- platform: rest
name: Hassio Rpi4 config
resource: !secret resource_hassio_rpi4_config
value_template: > #components|list|count}}
{{value_json.version}}
json_attributes:
- components
- unit_system
- config_dir
headers:
Content-Type: application/json
Authorization: !secret api_bearer_token
User-Agent: Home Assistant REST sensor
scan_interval: 3600
could that be done for the supervisor sensor too maybe? Trying this:
- platform: rest
name: Hassio Supervisor Updates
resource: http://supervisor/supervisor/info
value_template: >
{{value_json.addons|length}}
json_attributes:
- newest_version
- current_version
- addons
headers:
Content-Type: application/json
Authorization: !secret api_bearer_token
User-Agent: Home Assistant REST sensor
scan_interval: 3600
without success yet. Is the url correct? in the Config Rest sensor I need to point to https://mydomain.duckdns.org:port/api/config
when I enter http://supervisor/supervisor/info this seems incorrect?
Maybe the version platform can be modified to include an additional parameter to specify what info we want: Home Assistant, Supervisor, or Operating System.
WDYT?
Running on Home Assistant OS the following rest sensor works for me. The addons attribute gets fully populated.
platform: rest
name: addons
resource: http://127.0.0.1:8123/api/hassio/supervisor/info
value_template: '{{ value_json.data.addons|count }}'
scan_interval: 1800 # 60 seconds * 30 minutes = 1/2 hour worth of seconds
headers:
Authorization: !secret rest_token
Content-Type: application/json
json_attributes_path: "$.data"
json_attributes:
- addons
Then a template sensor I call sensor.addon_updates to count the number of addons with update_available == True. As a bonus this sensor also lists the
platform: template
sensors:
addon_updates:
friendly_name: Addon Updates
icon_template: mdi:counter
value_template: '{{ state_attr("sensor.addons","addons") | selectattr("update_available","eq",True) | map(attribute="name") | list | count }}'
attribute_templates:
addons: '{{ state_attr("sensor.addons","addons") | selectattr("update_available","eq",True) | map(attribute="name") | list }}'
Thanks for this, noticed that
Was slightly off and need pushing a few characters right to get the version number, so had a dig around and stumbled on this which serves up both current an latest version for the OS - however suspect this is constrained to the once a day update that you were trying to overcome!
- platform: command_line
name: os
command: 'curl http://supervisor/os/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''{"newest_version":.data.version_latest,"current_version":.data.version}'''
value_template: "{{ value_json.newest_version }}"
json_attributes:
- newest_version
- current_version
Anyway, thanks for the post - helpful!
Got my dashboard nearly to my liking 
I updated it here:
Hi,
I have been using this for some time to detected when an update is available. As of 2021.7 it has changed and the sensor.latest_available_version does not contain the point release therefore comparison not possible.
Does anybody know a better way to trigger an alert for an update notification?
sensor.latest_available_version = 2021.7
sensor.installed_version = 2021.7.1
update_available:
value_template: '{{ states.sensor.installed_version.state != states.sensor.latest_available_version.state }}'
The supervisor integration has binary sensors for that.
No, that integration only contains update sensors for Home Assistant OS and addons, not the core version.
Ups, my mistake, again 
Try this instead:
Thanks, worked a treat!
I’ve tried this (basically a copy of the code that @tom_l linked to above) and it didn’t trigger for me.
Can anyone see anything wrong that I’ve screwed up?
Putting the template into the developer tools tab correctly gave True when the update was available to be done. The sensors read correctly as 2021.7.1 and 2021.7.2 for current and latest (with appropriate attributes too).
alias: HASS Core Update
description: Notify if Core update is available
trigger:
- platform: template
value_template: >-
{{ states('sensor.latest_core_version') !=
states('sensor.current_core_version') }}
condition: []
action:
- service: notify.mobile_app_darrens_iphone_11
data:
message: >-
Core update from {{ states('sensor.current_core_version') }} to {{
states('sensor.latest_core-version') }} available
- service: mqtt.publish
data:
topic: scrollpi/messages
payload: s/Core update to {{ states('sensor.latest_core_version') }} available
- service: notify.persistent_notification
data:
message: >-
Core update from {{ states('sensor.current_core_version') }} to {{
states('sensor.latest_core_version') }} available
mode: single
The trigger needs to go from false to true. If it is already true after restarting it wont trigger. You’ll get it next time.
You could add a home assistant start event trigger as well, and a template condition, but that means you will get an alert every time you restart and there is an update available.
Just update and wait for the next one.
@tom_l - I don’t think there was any restart involved. This was for the update yesterday from core 7.1 to 7.2, and nothing fired. I understand what you mean though, so it may be that I didn’t notice or something.
I’ve now updated, so I’ll keep an eye on it for next time as you say and look to do something on restarts. I have an automation already that runs on restarts, so can look to just add it to that perhaps if I can localise the conditions (or a parallel specific automation if not).
You should have restarted after adding the sensors. Also reloading automations (if that is what you did instead of restarting) will have the same issue.
I meant that there was no restart coinciding with the new core update arriving (there was of course one after it installed). The sensors have been in place and functional for a while now, so all should have (to my mind) been fully available to trigger for yesterday’s update from 7.1 to 7.2.
Anyway I’ll add the conditional check on HA start-up anyway, and keep an eye on it for next time there’s a core update to see if it notifies or not.
Sorry I thought you only implemented this 17 hours ago (time of your post) where as the .2 release was before that (2 days ago).
No probs - my fault for not being clear.
The implementation is fairly new (sometime last week), but was a little surprised it didn’t fire off when 7.2 dropped.
I’ll add your suggestion about the check on start-up anyway, and will keep an eye on it when 7.3 (or 8.0) drops.
@tom_l - To close this one off for my earlier issue/question, just got the ping for the 7.3 update correctly and successfully. So looks like your assessment for the 7.1 → 7.2 update notification failure was on the money.
It’s even ahead of the game, as the update isn’t actually available in the supervisor yet