Update notifications! Core, HACS, Supervisor and Addons (now a blueprint!)

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 :slight_smile:

  - 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:] }}"
3 Likes

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 :+1:

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.

1 Like

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.

1 Like

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.

1 Like

Thanks so much, it works now! :slightly_smiling_face:

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 :blush: 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!

1 Like

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 :grin:

1 Like

these little f**kers are breeding like rabbits…
image
another one… multicast now.

1 Like

Haha I didn’t even notice. Well, updated to include multicast support now.

1 Like

Would you mind sharing your code? :slight_smile:

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.

Patrick, did you mean my markdown card? Remember, functional first, pretty later…this is functional :grin: I intend to do something nicer in the future, but this gets me started.

It looks like this:

markdowncard

I have semitransparent cards with a starry sky background, in case you’re wondering why it looks spotty :joy: Also, please note that I’m not including ESPHome in the number of addons that need updating, that is why it shows two addons in the list, but says only one needs updating. I haven’t added the new multicast sensor yet. I have button cards for the HA Core update information (already had that previously) so those aren’t included here; they sit just above this card.

This is the code for the markdown card in Lovelace:

    - type: markdown
      content: |
        ## Update Information

        **Add-ons: {{ states.sensor.supervisor_updates.state }} addon(s) need updating.**

        > {% for addon in states.sensor.supervisor_updates.attributes.addons %}
        > {{ addon.name }} ({{ addon.installed }} -> {{ addon.version }})
        > {% endfor %}

        **HACS:  {{ states.sensor.hacs.state }} updates available.**

        > {% for repo in states.sensor.hacs.attributes.repositories %}
        >    **{{ repo.display_name }}** _{{ repo["installed version"] }}_ -> _{{ repo["available version"] }}_
        > {% endfor %}

        **Supervisor:**  current: {{ states.sensor.supervisor_updates.attributes.current_version }}  -  latest: {{ states.sensor.supervisor_updates.attributes.newest_version }}
        **Audio:**  current: {{ states.sensor.updater_audio.attributes.current_version }}  -  latest: {{ states.sensor.updater_audio.attributes.newest_version }}
        **CLI:**  current: {{ states.sensor.updater_cli.attributes.current_version }}  -  latest: {{ states.sensor.updater_cli.attributes.newest_version }}
        **DNS:**  current: {{ states.sensor.updater_dns.attributes.current_version }}  -  latest: {{ states.sensor.updater_dns.attributes.newest_version }}

Hope that’s helpful.

3 Likes

@Anwen Yep, thanks a lot, that was, what I was looking for. It’s always interesting to see, how others solve these things. I for one love the idea to name the addon and afterwards only write the old and new version. :slight_smile:

@CentralCommand Sorry, should have quoted the post I meant, and not only reply to it. I’m already using your package for a few days now, it works really great. I found a neat little trick, as I want the alerts mostly only as a persistent notification. I use different notification streams together in home-feed-card.

Thanks a lot for your work, it’s really appreciated! :slight_smile:

2 Likes

Thanks for the inspiration!

2 Likes

Glad you liked it…yours looks good! And now you’ve inspired me - I’ve learned how to include icons and tables :slight_smile: This is my new version, which also shows my button cards above (and I have a new background–decided it was time for a change!)

Now, if I could just make those icons blue… :grin:

2 Likes

Looks like I need another update to my “does my host have updates” alert. I forgot that the known_hosts file is also in the /root/.ssh folder which means it is also wiped out every update. And without it you get this warning when you try to SSH. Since we aren’t doing this interactively there’s no way to accept that warning and thus the SSH command silently fails.

To counter this, add a known_hosts file to your /config/.ssh folder and add the following to your command: -o UserKnownHostsFile=/config/.ssh/known_hosts. Then run the command once in portainer so it updates your new known_hosts file and it should be good after that.

I’ll update the config in the post as well. Sorry about that, hopefully people didn’t build up too many updates :slightly_frowning_face: