aha, yes the HassOS version is present, here is output 
➜ ~ ha host info --raw-json
{"result": "ok", "data": {"chassis": "vm", "cpe": "cpe:2.3:o:home_assistant:hassos:3.12:*:production:*:*:*:ova:*", "features": ["reboot", "shutdown", "services", "hostname", "hassos"], "hostname": "hassio", "operating_system": "HassOS 3.12", "deployment": "production", "kernel": ➜ ~
is it possibe for me to retrieve it with the same curl command line?
i already have the current version, so thats fine
Yep. If you change the command to curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" everything you need should be in that response.
When you copied from the command line it looks like it got cut short since it stops after "kernel":. But since it says HassOS 3.12 I think I can figure it out from that. If the only thing you want is the version number then I think something like this would work:
sensor:
# Sensor to version of HassOS
- platform: command_line
name: HassOS Version
command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" '
value_template: "{{ value_json.data.operating_system[7:] }}"
json_attributes:
- data
I believe this will give you a sensor where the value is the current version of HassOS and the attributes contain the other details you have.
It doesn’t look like the next version is in there so I don’t think you can use this to alert on updates, just the current version you have installed. Unless the next version information is after kernel in the response since that’s as far as I can see.
Thxn for that, gonna test tomorrow!! I already have a sensor for next version, so I can manage my notification 
Oh nice! Care to share? I know @Tomahawk was looking for that info earlier and I didn’t know how to get it. Probably others would find that handy as well.
for current HassOS version, i use this one :
- platform: rest
resource: https://version.home-assistant.io/stable.json
name: HassOS Version
value_template: "{{ value_json.hassos.ova }}"
scan_interval: 3600
Hmm, this one gives me a “unknown” state
something wrong with it …
# Sensor to version of HassOS
- platform: command_line
name: HassOS Version current
command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" '
value_template: "{{ value_json.data.operating_system[7:] }}"
json_attributes:
- data
edit: i see this in my log;
2020-04-21 09:49:11 ERROR (SyncWorker_3) [homeassistant.components.command_line.sensor] Command failed: curl http://supervisor/host/info -H Authorization: Bearer $(printenv SUPERVISOR_TOKEN)
2020-04-21 09:49:11 WARNING (SyncWorker_3) [homeassistant.components.command_line.sensor] Empty reply found when expecting JSON data
changed to code, below, that works
- platform: command_line
name: HassOS Version current
command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''{"hassos":.data.operating_system}'''
value_template: "{{ value_json.hassos[7:] }}"
Nice! Strange, I wouldn’t have expected jq would be required there since the output of the API call should already be JSON. Anyway glad you got it working 
FYI for everyone that is making use of my “does my host have updates” alert, I noticed today that it was silently failing. The reason appears to be that on update of HA it overwrites the folder I had my SSH keys stored in (/root/.ssh by default)!
To counter this I re-ran ssh-keygen and generated the keys into /config/.ssh since the config folder is preserved from release to release. I then updated my sensor and shell command to include -i /config/.ssh/id_ed25519 to tell it where to look for the identity file since its not in the default location. This got it back working again so anyone using those should do a similar update. I edited the post to include these details already.
I don’t know if /config is the correct place for ssh key files from an architecture standpoint. But it seemed more appropriate then /ssl and /share which are the only other two folders I know are for sure preserved through updates. Plus there’s already .token files in /config for all integrations using oauth, not to mention all the auth information in .storage so it made sense to me.
This is great, and I’m starting to implement all the sensors. But I’m trying to find a workaround for the addons, and here’s why. I’m not updating ESPHome to the latest because I want to stay on 1.13.6 which is stable for me. So my addon updater would always be on. But I do want to know if any other addons need to be updated. I thought if I could make a list of the addon names in a Lovelace card along with the other sensor information, I would at least have one place where I could see all the information about updates. Or maybe someone has a better idea. I’ve been messing around with templates for a couple of hours, but I’m new at this, and despite much reading of documentation and messing about in the template editor, I’m not getting anywhere. Anyone have any ideas? TIA!
If you want to specifically ignore one addon the way I would probably do it personally is by just modifying the jq to exclude that one.
Now I don’t use the ESPHome add-on and I don’t see it in my list so I’m just going to use the adguard add-on as an example. To tweak this for yours, just open up the ESPHome addon in HA and at the top in the URL bar it should look like this: ‘{HA Base URL}/hassio/addon/a0d7b954_adguard’. That last part in bold is the addon slug, replace the one for ESPHome where it says a0d7b954_adguard below.
Sensor will look like this instead:
# Sensor to track available updates for supervisor & addons
- 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 and .slug != "a0d7b954_adguard")]}'''
value_template: "{{ value_json.addons | length }}"
json_attributes:
- newest_version
- current_version
- addons
With this when building its list of addons that need updates it will exclude that one.
Alternatively, if you want to be able to present UI showing all addons that are out of date but simply not get notifications for the one you know is out if date you can modify the value_template instead of the command like so:
# Sensor to track available updates for supervisor & addons
- 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 | selectattr('slug', 'ne', 'a0d7b954_adguard') | list | length }}"
json_attributes:
- newest_version
- current_version
- addons
What this will do is it will still capture the full list of out of date addons and their current version in the addon attribute so you can show that list somewhere. But the state of the sensor will only increase if an addon other then the one you are excluding was updated. This way the alerts will only send you notifications when an addon you are tracking is updated.
Thank you so much for your help, Mike - very much appreciated!!! The first sensor works as advertised, and I am happy to use that one. The other one does not work for me - I get the following error:
2020-04-28 16:53:04 ERROR (MainThread) [homeassistant.components.sensor] command_line: Error on device update!
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 324, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 476, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/command_line/sensor.py", line 126, in update
value, STATE_UNKNOWN
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 251, in render_with_possible_json_value
error_value,
File "/usr/local/lib/python3.7/concurrent/futures/_base.py", line 435, in result
return self.__get_result()
File "/usr/local/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
raise self._exception
File "/usr/src/homeassistant/homeassistant/util/async_.py", line 49, in run_callback
future.set_result(callback(*args))
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 276, in async_render_with_possible_json_value
return self._compiled.render(variables).strip()
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 1090, in render
self.environment.handle_exception()
File "/usr/local/lib/python3.7/site-packages/jinja2/environment.py", line 832, in handle_exception
reraise(*rewrite_traceback_stack(source=source))
File "/usr/local/lib/python3.7/site-packages/jinja2/_compat.py", line 28, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
TypeError: object of type 'generator' has no len()
Right sorry, I missed a | list in haste, modified it if you want to give the second one another shot.
Thanks so much, it works now! 
Could I be so bold as to ask another question? I’m trying to pull the addon names out of the sensor, but they are “one level down” in the attributes in the addon list/array, and I don’t know how to format a template sensor to pull them out. I’ve been trying various things, but haven’t been successful so far. Is that something you could help me with? If not, no problem, I really appreciate the help you’ve already given me.
Hm ok so I’m not entirely sure what you mean by template sensor in this context but going back a post to this:
It sounds like you’re trying to make a single string showing info about the addons including their names, is that correct? If so something like this should do the trick, could throw this in a markdown card:
{% for addon in states.sensor.supervisor_updates.attributes.addons %}
{{ addon.name }} ({{ addon.installed }} -> {{ addon.version }})
{% endfor %}
Does that help? If not you might have to clarify a bit more of what you’re trying to do.
Also just an FYI when I personally find the flex table card HACS component useful in situations like this. Obviously a markdown card with a template would give you much greater control over the UI if you want that but if you do just want a simple table showing what needs updates that card should do the trick.
Thanks so much, that looks like where I was trying to go. Sorry I’m not being clear, I think I’m not entirely clear in my own head exactly what I want yet 
My first try was with the attributes entity card, but I couldn’t get the addon names to work. I will look at the flex table card, which is new to me. I’ll work on this more tomorrow, because now it’s bedtime…
Thanks again for your help and your quick responses!
Just to follow up: I now have a very functional markdown card with all the information I want - shows how many add-ons need to be updated with a list of which ones, how many HACS updates are available with a list of which ones, and the current/latest information for supervisor, audio, cli, and DNS. It’s great to have at-a-glance information all in one spot. Thank you, @CentralCommand for all your help - I’ve learned a lot by implementing this. I may use a different kind of card to make it prettier in the future, but right now it’s function over form, and function is what counts 
these little f**kers are breeding like rabbits…
another one… multicast now.
Haha I didn’t even notice. Well, updated to include multicast support now.
Would you mind sharing your code?
The first post includes packages with all the code. There’s two at the bottom, the original base one and an updated one that includes additional sensors/alerts for audio, dns, cli, multicast and core. I updated that second one with multicast support.
If you want just the new multicast bit though here it is:
sensor:
- platform: command_line
name: Updater Multicast
command: 'curl http://supervisor/multicast/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
alert:
# Multicast update is available - un-acknowledgeable, auto-dismiss, me only
multicast_update_available:
name: Multicast has an update
entity_id: sensor.updater_multicast
state: 'on'
can_acknowledge: false
repeat: 360
title: 'Update for HA Multicast available'
message: "New version is {{ state_attr('sensor.updater_multicast', 'newest_version') }}. Currently on {{ state_attr('sensor.updater_multicast', 'current_version') }}"
notifiers:
- 'me'
data:
tag: 'multicast_update_available'
url: 'http://hassio.local/hassio/dashboard'
Of course pasting it out here just made me realize I accidently added an extra ’ when updating the first post so now I will fix that haha.