@CentralCommand can you please update your yaml config in the OP to fix the
The 'entity_id' option is deprecated, please remove it from your configuration
warnings? I´m not familiar enough with YAML yet. Just remove the entitiy_id lines as suggested by @tom_l won’t work, keeping the lines below (e. g. sensor.*updates) as is or with name: sensor.*updates) also doesn’t.
It’s not rocket science, e.g. this:
- platform: template
sensors:
updater_supervisor:
friendly_name: 'Updater - Supervisor'
device_class: problem
entity_id: ### <--------------- Remove this ###
- sensor.supervisor_updates ### and this ###
value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"
Becomes this:
- platform: template
sensors:
updater_supervisor:
friendly_name: 'Updater - Supervisor'
device_class: problem
value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"
Do the same for every template sensor.
Why aren’t you just using the package file, that is noted in the first post? It is up to date and runs just fine (removing the two indentation errors). The only thing you may need to change is the notifier.
Did not see it until now. But even that code still contains deprecated entity_id options.
That worked. Thought the entitiy_id is a reference for further attributes - but it´s just unnecessary part of yaml code. My deprecated warnings are gone now, thanks folks.
Huh, when did that slip in, I’m sorry about that, both indentation errors are fixed now. Thanks for pointing that out.
I updated the package to fix the indentation errors pointed out but there were no template sensors in the package which had entity_id, that had been fixed already. The package is mostly using threshold sensors now since I realized that was an easier way to get a binary sensor which is true when a number is greater then 0 (and those require the entity_id field). I updated the details post to do the same thing as the package for sensor.updater_hacs and sensor.updator_addons and fixed sensor.updater_supervisor to no longer have entity_id
It does? 
I can’t see any. 
You do realise, entity_id is only deprecated for a template sensor, not for all occurrences… 
I’d start “fresh” in your case. Remove your entries and copy the “new” package/version from the first post. Change the notofier, if necessary, and you are good to go. Another advantage is, whenever there is an update, you just need to copy it from here and are good to go.
Everything is fine and working for me even with the “old” template sensor based approach I will keep now, thanks. As you can see
CentralCommand even updated the OP meanwhile.
Any idea on how to work around such - okay, quite rare and not normal - situations?
I´m talking bout this section:
- platform: command_line
name: HASS OS Update
command: >
curl http://supervisor/os/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"
| jq '{"newest_version":.data.version_latest,"current_version":.data.version}'
value_template: >
{% if value_json.newest_version != value_json.current_version %}on
{% else %}off
{% endif %}
json_attributes:
- newest_version
- current_version
...
...
So the interesting part with actual numbers:
{% if 5.9 > 5.10 %} on
{% else %} off
{% endif %}
gives on cause 5.10 is taken as 5.1 so 5.9 is greater than 5.10. I thought “greater than” is better than “not equal” (!=) but… not at the finish line yet.
Scenario: update to an officially released version higher than currently provided for the majority.
Maybe it´s better to just go for the ‘update_available’ return?
I changed it, looking good now even for this rarely available scenario.
- platform: command_line
name: HASS OS Update
command: >
curl http://supervisor/os/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"
| jq '{"newest_version":.data.version_latest,"current_version":.data.version,"update_available":.data.update_available}'
value_template: >
{% if value_json.update_available == true %}on
{% else %}off
{% endif %}
json_attributes:
- newest_version
- current_version
- update_available
States are strings so you have to convert those values to actual numbers to do a mathematical comparison like that. You can do that like this:
{% if value_json.newest_version | float > value_json.current_version | float %}
Though actually I’m not sure if this is a good idea. I am blanking on the details but I feel like a month or two ago there was an issue where people were seeing an update message in their supervisor panel that was actually telling them to downgrade to the prior version of either HA OS or supervisor due to an issue. I’m failing to find a link but I’m pretty sure this happened and obviously this would be an issue with this comparator.
If there’s an update_available field now it is probably better to just rely on that. Not sure if that is new or just missed the first time. Can change the sensor to this in that case:
EDIT: removed. @e-raser has it right below. I forgot this was actually a sensor not a binary_sensor despite only have a value of on or off
Thanks for explanation. I already changed it for my HA instance, getting slowly used to that YAML stuff.
Not quite long on board so good point if there are cases like forced rollbacks (where an update actually is a downgrade) it´s probably even better to not use the greater than operator instead use your setting or rely on the update_available information. Would depend on what those states are in a “forced rollback/downgrade” scenario, for the moment I´m fine.
And once again: many many MANY thanks for this topic, this was exactly what I was missing out of the home assistant box and you served it, just perfect.
Hi Guys, I hope someone here can help me.
I’m trying to set up a sensor to show the current and latest version of an addon with the steps provided in this thread.
- platform: rest
resource: https://192.168.2.202:8123/api/hassio/addons/core_check_config/info
name: Check Home Assistant configuration
value_template: '{{ value_json.data.state }}'
scan_interval: 60
headers:
Authorization: !secret llt_addons
Content-Type: application/json
json_attributes_path: "$.data"
json_attributes:
- version
- version_latest
I’ve been trying to get this sensor to work for a few days now. But for some reason it just doesn’t create the sensor. Whenever I try to find it, it just doesnt show up.
I really hope someone can explain it to me.
Well to start you probably have to add verify_ssl: false to your sensor. Since that’s a local IP address whatever SSL certificate you are presenting is either self-signed or for a different domain entirely since CAs won’t issue SSL certificates for private IP addresses.
Also it looks like you’re providing Content-Type: application/json as a header which is weird since its a GET call and has no request body. Did you mean to put Accept: application/json to specify that you want JSON back? Not sure if that’s necessary or not but it makes more sense then providing Content-Type without a postbody.
Also only you can verify this but make sure your llt_addons secret is of the format Bearer <a valid token>.
I’m guessing it was blowing up on the SSL certificate since it looks correct other then that. Maybe the extraneous Content-Type header but most APIs just ignore that on a GET call.
Why didnt that occur to me before…
The verify_ssl did the trick. Big thanks!
Update notifications don´t work sometimes, sometimes they do. E. g. update to HA Core 2021.1.4 is shown in the UI, but did not fire my automation.
Any idea what to check?
Clearly available:
Automation with notification:
Last time fired: two days ago (for HA Core 2021.1.3)
alias: Notify_System_Update HA Core verfügbar
description: ''
trigger:
- platform: state
entity_id: binary_sensor.updater
to: 'on'
condition: []
action:
- service: notify.all_devices
data:
title: "Update available \U0001F7E2"
message: >-
HA Core {{ state_attr('binary_sensor.updater', 'newest_version') }} is
available.
data:
subtitle: ''
push:
thread-id: updates-notification-group
mode: single
Huh, that is really confusing. I’ve had issues with not receiving notifications before due to end device state but never with ha not firing an automation when it obviously should. If you go to developer tools you can manually set binary_sensor.updater to on and off to test it. Does it work when you do that at least?
Yes, this time it worked.
Really strange. Even HA reboots should not affect the automation trigger detection I guess. I have absolutely no idea… logs empty of course.
Will continue monitoring this a few more days/weeks.
Next occurence:
Supervisor shows HA Core update:
HA Core Updater (“binary_sensor.updater”) states:
This seems to not be related to the additional update sensors at all, but it´s very strange… did someone else discover this behaviour too?
That binary sensor only updates once a day so you cannot rely on it.