New HACS update, no sensor, but any alternative?!

Configuration
1

Hi, all!

Till the new HACS version, I was using an automation, in order to get notified of new updates for HACS addons:

alias: Notify - New HACS Updates (Persistent Notification)
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.hacs
condition: []
action:
  - if:
      - condition: template
        value_template: "{{ states(\"sensor.hacs\") | int != 0 }}"
    then:
      - data:
          message: >
            {% set ns = namespace(value="New HACS Updates - " ~
            now().strftime('%-d %b, %H:%M') ~ "\n") %} {% for rep in
            state_attr('sensor.hacs','repositories') %} 
              {% set ns.value = ns.value + "\n- " ~ rep.display_name | title %}
              {% set ns.value = ns.value + "\n    Current: " ~ rep.installed_version %}
              {% set ns.value = ns.value + "\n    Latest: " ~ rep.available_version %}
              {% set ns.value = ns.value + "\n" %}
            {% endfor %} {{ ns.value }}
          notification_id: "0001"
        action: persistent_notification.create
      - data:
          attributes:
            updates_list: >
              {% set ns = namespace(value="New HACS Updates - " ~
              now().strftime('%-d %b, %H:%M') ~ "\n") %} {% for rep in
              state_attr('sensor.hacs','repositories') %} 
                {% set ns.value = ns.value + "\n   - " ~ rep.display_name %}
                {% set ns.value = ns.value + "\n       Current: " ~ rep.installed_version %}
                {% set ns.value = ns.value + "\n       Latest: " ~ rep.available_version %}
                {% set ns.value = ns.value + "\n" %}
              {% endfor %}
                {% set ns.value = ns.value + "\n--------------------------------\n\n" %}

                {% set ns.value = ns.value + state_attr("sensor.variable_history_hacs_updates","updates_list") %}
                {% set text = ns.value.split('\n--------------------------------\n\n') %}
              {{ (text[:6]) | join("\n--------------------------------\n\n") }}
          replace_attributes: true
        target:
          entity_id: sensor.variable_history_hacs_updates
        action: variable.update_sensor
    else:
      - data:
          notification_id: "0001"
        action: persistent_notification.dismiss
mode: single

Now, with the new HACS version, there is no sensor for this. Any alternative to achieve this?

Thanks in advance.

2

There are separate update sensors now

afbeelding
afbeelding1252×588 21.3 KB

2 Likes
3

Auch… I understand… Sooo, all the sensors need to be checked, in order to receive a notification. Gotcha. Thanks!

1 Like
4

Theoretically you could create a template sensor doing just that (all update sensors from integration== HACS) and output a binary sensor with the old entity name.

If any of xyz are true == true.

In sure Taras could gen up such an animal in 40 seconds…

5

If you want to mimic the former functionality (which I think provided a count of updates available) …

{{- integration_entities('hacs')
    | select('match', '^update\.')
    | expand
    | selectattr('state','eq', 'on')
    | list 
    | count
    -}}
2 Likes
6

Oh, but wait, they did the update very good, there is no need for notification. Seems that it will show an update notification in settings, like a normal addon update. Which is perfect.

3 Likes
7

Yes, certainly has some polish on it - very happy that the updates come in as repairs (been using the new version for months now in the pre-release version)

However, some people are probably still going to want a binary sensor or count to show on their dashboards so I hope my example can help those who do want something like that.

1 Like
8

Thanks for this! I still like to have a binary sensor for triggering notifications outside Home Assistant (email, Pushover, etc.).

1 Like
9

I needed to change the examples in the custom-sidebar repo because the examples to get the HACS updates in JavaScript and Jinja templates got outdated with the removal of the HACS sensor.

@teskanoo example works perfect, posting my alternative here just as another way to retrieve that number:

{{-
    expand(states.update)
    | selectattr('state', 'eq', 'on')
    | map(attribute='entity_id')
    | map('device_attr', 'identifiers')
    | map('contains', 'hacs')
    | list
    | count
-}}
10

Thank you!
This works but it includes all updates on the system, not only the HACS ones (it shows me 12 updates).
The initial example of @teskanoo works and shows me the correct HACS updates available and that is 1 only at this point.

Question, is there a way to exclude certain integrations from the counter?

For example integration_entities not == unifi or integration_entities != unifi

Thank you

11

Did you check @teskanoo’s post?
That code is precisely to filter out only the HACS updates.

Edit: I am seeing that you already checked the post.

You can use the same approach with select match to exclude some of the updates from the final result.

12

Thank you, I will have two sensors, one for HACS updates and one for the rest but I want to exclude updates from certain integrations, here is my example to exclude HACS and also the Unifi integration.

{{-
    expand(states.update)
    | selectattr('state', 'eq', 'on')
    | rejectattr('entity_id', 'in', integration_entities('unifi'))
    | rejectattr('entity_id', 'in', integration_entities('hacs'))
    | list
    | count
-}}
1 Like
13

I’m trying to narrowing down the HACS update sensor to distinguish if it is a dashboard or an integration update. The attribute seems to be available as shown on the screenshot below, but I cannot find an info on how to access it. Does somebody have an idea? So the goal would be to have two sensors, one for available HACS Dashboard updates and one for available HACS integration updates.

grafik
grafik1413×272 18 KB

Edit: its the “Repository Type”, does anyone know how to access this info/attribute via a template? Repository types - HACS

14

@petro knew it - thank you! :slight_smile:

Examples (according to the documentation Templating - Home Assistant):
{{ device_attr('update.apexcharts_card_update', 'model') == 'plugin'}}
{{ is_device_attr('update.apexcharts_card_update', 'model', 'plugin') }}

I was trying to implement this in the final template with is_device_attr:

  {{-
    expand(states.update)
    | selectattr('state', 'eq', 'on')
    | is_device_attr('entity_id', 'model', 'plugin')
    | rejectattr('entity_id', 'in', integration_entities('unifi'))
    | rejectattr('entity_id', 'in', integration_entities('hacs'))
    | list
    | count
-}}

But that throws this error: TemplateAssertionError: No filter named 'is_device_attr'

And my other try with a device_attr test

 {{-
    expand(states.update)
    | selectattr('state', 'eq', 'on')
    | device_attr('entity_id', 'model') == 'plugin'
    | rejectattr('entity_id', 'in', integration_entities('unifi'))
    | rejectattr('entity_id', 'in', integration_entities('hacs'))
    | list
    | count
-}}

Throws another error: TypeError: device_attr() takes 3 positional arguments but 4 were given

I was also trying different things with 'eq' etc, but I’m not skilled enough to get it working - can someone help me? I’m not sure if I can use device_attr or is_device_attr in an expand…?

Thank you

15

Hmm, that should be added to filters. You’ll have to iterate the list with a for loop unfortunately.

16

Checked the docs, is_device_attr is a test, the device_attr is a filter. So I was trying to loop through the filter device_attr, but it fails big-time with the error TypeError: 'NoneType' object is not iterable.

{% for plugin in device_attr('entity_id', 'model') %}
  {{ 
      expand(states.update)
      | selectattr('state', 'eq', 'on')
      | rejectattr('entity_id', 'in', integration_entities('unifi'))
      | rejectattr('entity_id', 'in', integration_entities('hacs'))
      | list
      | count
  }}
{% endfor %}

I believe instead of

device_attr('entity_id'

something like

device_attr(expand

is required, but it fails when I try to pack the whole expand section into the device_attr brackets

Can you point me in the right direction?

17 
{{ states.update | map(attribute='entity_id') | select('is_state', 'on') | select('in', integration_entities('unifi')) | select('in', integration_entities('hacs')) | select('is_device_attr', 'plugin') | list | count }}
18

Beautiful, thank you! FYI, the attr_name was missing in is_device_attr

I now created two sensors. One will show me a count of all System & Intregration Updates (excluding Unifi Firmware Updates in my case). This includes Home-Assistant and Supervisor updates. The other sensor will show me a count of all Frontend-Updates.

template:
  - sensor:
      - name: "System Updates"
        state: >
          {{
            expand(states.update)
            | selectattr('state', 'eq', 'on')
            | rejectattr('entity_id', 'in', integration_entities('unifi'))
            | list
            | count
            -
            states.update | map(attribute='entity_id') | select('is_state', 'on') | select('is_device_attr', 'model', 'plugin') | list | count
            }}

  - sensor:
      - name: "Dashboard Updates"
        state: >
          {{ states.update | map(attribute='entity_id') | select('is_state', 'on') | select('is_device_attr', 'model', 'plugin') | list | count }}
19

Nice job!

i made a small addition. The sensor now also shows which variable to update and version number:

      - name: "System Updates"
        unique_id: System_Updates
        state: >
          {{
            expand(states.update)
            | selectattr('state', 'eq', 'on')
            | map(attribute='entity_id')
            | rejectattr('entity_id', 'in', integration_entities('unifi'))
            | list
            | count
            -
            states.update
            | selectattr('state', 'eq', 'on')
            | selectattr('attributes.model', 'eq', 'plugin')
            | map(attribute='entity_id')
            | list
            | count
          }}
        attributes:
          updates: >
            {{
              expand(states.update)
              | selectattr('state', 'eq', 'on')
              | rejectattr('entity_id', 'in', integration_entities('unifi'))
              | map(attribute='attributes.friendly_name')
              | list
            }}
          versions: >
            {{
              expand(states.update)
              | selectattr('state', 'eq', 'on')
              | rejectattr('entity_id', 'in', integration_entities('unifi'))
              | map(attribute='attributes.latest_version')
              | list
            }}

      - name: "Dashboard Updates"
        unique_id: Dashboard_Updates
        state: >
          {{
            states.update
            | selectattr('state', 'eq', 'on')
            | selectattr('attributes.model', 'eq', 'plugin')
            | map(attribute='entity_id')
            | list
            | count
          }}
        attributes:
          updates: >
            {{
              states.update
              | selectattr('state', 'eq', 'on')
              | selectattr('attributes.model', 'eq', 'plugin')
              | map(attribute='attributes.friendly_name')
              | list
            }}
          versions: >
            {{
              states.update
              | selectattr('state', 'eq', 'on')
              | selectattr('attributes.model', 'eq', 'plugin')
              | map(attribute='attributes.latest_version')
              | list
            }}

the outcome of the sensor

template:
  - sensor:
      - name: "System Updates"
        state: >
          2
        attributes:
          updates: >
            ['remote-badkamer', 'WLED Firmware']
          versions: >
            ['604241926', '0.15.0-b5']
  - sensor:
      - name: "Dashboard Updates"
        state: >
          0
        attributes:
          updates: >
            []
          versions: >
            []
2 Likes