having used
binary_sensor:
- platform: template
sensors:
ha_update_available:
friendly_name: 'Ha update available'
value_template: >
{% set latest = states('sensor.ha_current_version') %}
{{ latest != 'unavailable' and
latest != states('sensor.ha_local_version')
and 'b' not in latest}}
for ages, with underlying sensors:
- platform: rest
name: Ha current version
resource: https://www.home-assistant.io/version.json
value_template: >
{{ value_json.current_version }}
json_attributes:
# - current_version
- release_date
- release_notes
- release_notes_path
- release_title
- release_description
- patch_version_notes
- root_url
- semantic_version
and
- platform: version
name: Ha local version
I now have a positive flag an update is available while I have 103.2 installed and the current version still shows 103.1 (which is of course incorrect)
Not sure if I can do this so let me ask if we need to change the
latest != states('sensor.ha_local_version')
in the template to
latest >= states('sensor.ha_local_version')
it would still give an erroneous outcome if the latest points to in incorrect version, as it does at the moment. It would however be more to the point, and not simply check if the available and installed version are equal or not…
I know we shouldn’t treat strings as numbers but in this case I wouldn’t know how else to proceed, without stripping, splitting and |int’ing the lot…
Your version sensors name implies that you want it to return the version of homeassistant you currently have installed, but you’ve configured it to return the latest default version…
Surely a better option would be to delete everything you’ve got and just configure the version sensor to return the newest version for your platform, and notify when the sensor updates (which is exactly what I do and it works fine)
A yes, I now see I’ve misread the instruction on source completely! Its the other way round, should have set it to local as it now defaults to available… (which is incorrect at the moment, but thats besides the issue)
in my current ‘default’ setup, it is configured to return the newest version…
you mean an automation upon state change?
Will do so, but have already made an automation based on updater.
Since I need the state of the available updates as condition for other templates and settings based on that, I need a binary_sensor that is right there upon start. (updater is at least half an hour behind after restarts…)
So I made these template sensors for update available…Need something to compare the installed version with the available version.
this is why:
and they’re flashing for attention…
edit
wait, above is incorrect… default, so without further settings, is local: Version - Home Assistant
which means my template and naming is correct… I’m comparing the local version with the available version correctly.
If local < available the binary should be ‘on’.
I’ve made an extra sensor based on version, and that reports fine. Does take quite som time after startup to be initialized unfortunately
this: https://www.home-assistant.io/version.json: the base of my rest sensor, is wrong!
If you need both the local version and the latest available version, why not just use two version sensors, one for each?
yes, as I was crossposting above 
that’s what I’ve done now, see my screen above.
let me ask please, is it expected to see all details in the available sensor more info,
and see none of that in the local version sensor:
could you have a quick glance at your version sensor please?
also, getting back to my binary template sensor:
how do I compare the 2 to see if the local version is < then then available version…
Looks right to me. I would guess the local one is right too as its only reporting the version you’re on. Maybe if you need those attributes for the local version it needs a feature request? But this is my version sensor which I think is identical to yours…
yep, the same
the notification you mentioned, is it based on platform: state? So when any update in the sensor takes place, you get notified?
Yeah, I have a condition that prevents it firing if to_state != from_state for it too, but basically yeah, trigger on any state change, run the ‘configuration checker’ addon, wait 10 minutes, notify me.
I then have a quick look at the addon logs to make sure I’ve not hit a breaking change and update.
cool, thanks for your support and ideas.
with each and every step, question, discussion here, rethinking the setup, the config smoothes out… very nice indeed.
about that, dont you use the breaking changes sensor, which lists these if they exist (they mostly do 
)
1 Like
Yeah, I do, it’s a ‘belt and braces’ approach 
