1st issue:
Using the device_class: problem does not work for me, therefore in lovelace UI the state_color: true does not work unfortunately.
I get errors in config check:
Invalid config for [sensor.template]: value is not allowed for dictionary value @ data['sensors']['updater_addons']['device_class']. Got 'problem'
value is not allowed for dictionary value @ data['sensors']['updater_hacs']['device_class']. Got 'problem'
value is not allowed for dictionary value @ data['sensors']['updater_supervisor']['device_class']. Got 'problem'. (See ?, line ?).
What I use instead: icon_template: 'mdi:update'
The config check errors still appear even if those icon_template lines are removed.
Probably a syntactical problem. Anyway, also automations are shown with state_color: true in lovelace UI. Tried to change the device class using the customize options, but that only gives me
@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.
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.
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.
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.
Latest HASS OS available in UI: 5.9
Latest available HASS OS I upgraded to: 5.10
Maybe it´s better to just go for the ‘update_available’ return?
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.
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.
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.
I can’t see any. 
You do realise, 
