(Yet another) ignore previous "unavailable" state

Ok, how can this you posted:

condition:
  - {{ trigger.from_state.attributes.tag != "unavailable" }}
  - {{ trigger.from_state.attributes.tag != "unknown" }}

be written in a single line? Using for example an “and” expression?

I just edited my post.

Ok, let me try the single line. I felt something like {{ trigger.from_state.attributes.tag != "unavailable", "unknown" }} could bu valid.

Ok just putting
{{ trigger.from_state.attributes.tag != "unavailable" and trigger.from_state.attributes.tag != "unknown" }}
in the visual editor resolves in

condition: template
value_template: >-
  {{ trigger.from_state.attributes.tag != "unavailable" and
  trigger.from_state.attributes.tag != "unknown"  }}

in yaml and seems to work.
So a single condition can be used that way.
Thanks a lot!

1 Like

And just in case someone is interested, the full yaml automation to properly notify in case an Os-Agent update exists is the following:

alias: Os-Agent Update
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.home_assistant_os_agent_latest_release
    attribute: tag
condition:
  - condition: template
    value_template: >-
      {{ trigger.from_state.attributes.tag != "unavailable" and
      trigger.from_state.attributes.tag != "unknown"  }}
  - condition: not
    conditions:
      - condition: state
        entity_id: sensor.home_assistant_os_agent_latest_release
        attribute: tag
        state: unavailable
      - condition: state
        entity_id: sensor.home_assistant_os_agent_latest_release
        attribute: tag
        state: unknown
action:
  - service: notify.persistent_notification
    data:
      message: There is an update in Os-Agent!
      title: Update message
mode: single
1 Like

Yeah, that’s what I proposed originally.

:man_shrugging:

Yeah, your right.

I skimmed over your answers when the OP said things didn’t work.

If the nominal value of the tag attribute is numeric then you can use the following Template Condition to reject non-numeric values (like unavailable and unknown).

condition:
  - "{{ trigger.from_state.attributes.tag | is_numeric and trigger.to_state.attributes.tag | is_numeric }}"

If you’re uncomfortable with Template Conditions written in shorthand notation, here’s the traditional way to express it:

condition:
  - condition: template
    value_template: "{{ trigger.from_state.attributes.tag | is_numeric and trigger.to_state.attributes.tag | is_numeric }}"
1 Like

Never tried this syntax, just wanted to use the != oner.

Haven’t tried it but seems even better than the proposed syntax.

I don’t know what the value of tag normally looks like but if it’s an integer (1, 2, 3, …) or floating point number (1.3, 2.1, 12.45, …) then the is_number filter will work correctly. However if it’s something like 2022.9.3 then the filter won’t produce the desired result because, although it’s numeric, it’s not a proper number.

Os-agent versions follow the x.x.x pattern, currently on 1.3.0, so this should NOT work, if things are as you say. :sleepy:

^Post 25 has the notify automation, I didn’t feel the need to relink it.

Is this working for you Tryfos? Am I missing something as to where you set the value of the tag, because I am not seeing it in the automation from post 25, and I wasn’t sure if your first quote meant you also have a separate automation following the version change.

sensor.home_assistant_os_agent_latest_release: 1.4.0
sensor.home_assistant_os_agent_latest_tag: 1.4.0

Both update at the same time I believe

Yes it’s working.
As a matter of fact and out of pure chance Os-Agent was updated a couple of hours ago (to 1.4.0) and everything worked as it should. :grinning: I initially thought something was wrong after I messed with it earlier.
You don’t set the value, it gets retrieved by the sensor.
I use the value of attribute “tag” from sensor “sensor.home_assistant_os_agent_latest_release”.

Hmm must be just because I was doing it after 1.4.0 then. I couldn’t get it fire from dev tools. Nevermind user error lol. I was trying to set release instead of the tag.

In the next version of Home Assistant there will be a new templating filter/function called version. It will allow you to perform comparisons like this:

{{ version(trigger.to_state.attributes.tag) > version('1.3.0') }}

I don’t know what version reports if it is given a value like unknown or unavailable. Perhaps it reports none. If it does then, in the future, your Template Condition can be reduced to something like this:

condition:
  - "{{ version(trigger.from_state.attributes.tag) is not none and version(trigger.to_state.attributes.tag) is not none }}"
1 Like

I know this is marked as solved. I get why it works with the attribute(it’s that sneaky attribute trigger thing) Sorry it’s long I wanted to leave as much details for future peoples.

This threw me and OS agent actually upgrading from 1.3.0(my systems is still 1.3.0) to 1.4.0 threw me.

I have a couple of technical questions.

  • @Tryfos version is a one-shot basically… Once you dismiss the notification, It isn’t going to come back on the next restart unless OS agent upgraded again in github… Is that correct?

  • I didn’t have the github integration installed… I have never previously had a need or desire for it. It’s cool. I wonder how much extra database data (multiplied by fields of data and repos) it is going to create compared to how I had planned to do this.
    Lots of sensors from github vs my couple of sensors, I also use this for my addon so its 4 sensors vs 20 or so from git

One thing I would add.
persistent_notification.create should be used over notify.persistent_notification
because you can add notification_id: os-agent This forces all messages into a single overwritten message instead of multiple message notifications (I didn’t know that).

So I did my message like this.

service: persistent_notification.create
data:
  notification_id: os-agent            ## <<< this can be whatever 12343232
  title: "There is an update in Os-Agent! "
  message: >-
    OS_Agent {{ states('sensor.home_assistant_os_agent_latest_tag') }} is
    available<br></br> [os-agent](https://github.com/home-assistant/os-agent)
    <br></br> wget
    https://github.com/home-assistant/os-agent/releases/download/{{
    states('sensor.home_assistant_os_agent_latest_tag')
    }}/os-agent_1.4.0_linux_x86_64.deb<br></br> sudo dpkg -i os-agent_{{
    states('sensor.home_assistant_os_agent_latest_tag')
    }}_linux_x86_64.deb<br></br>

msgCapture

Hopefully someone finds that useful for their own message. I suck at linux, so a reminder of those console commands is handy for me. I couldn’t find a sensor for cpu_arch natively x86_64. I can do it from a rest sensor… but I also know which arch types I have so it wasn’t a big deal for me.
eg

{{ states('sensor.cpu_archtype') }} I just hand typed it between my machines.

I have a nice msg I can cut and copy the commands from and pop them in host console. I also have go the latest release page. I don’t have to fiddle with wget, between version or my x86_64 or aarch64 builds.

So prior to this question coming up I was in the middle of something similar. This is how I planned on doin this … I suck at templates, I know this.



The way I did this.

This is “True” when git version is higher than machine version. That’s all I want to know.

      
template:
    - sensor:
        - name: OS_agent Updater
          unique_id: os_agent_updater_version8123
          icon: mdi:memory
          state: >
            "{{ states('sensor.os_agent_version_github' ) > states('sensor.os_agent_version_installed' ) }}"
           #### caution " " will show up in True result. I omiited " " here 
   




’sensor.os_agent_version_installed’

  - platform: rest
    unique_id: os_agent_rest_installed8123
    name: OS Agent Version Installed
    resource: http://localhost:8123/api/hassio/host/info
    value_template: "{{ value_json.data.agent_version }}"
    scan_interval: 604800
    headers:
      Authorization: !secret rest_bearer
      User-Agent: Home Assistant
      Content-Type: application/json




’sensor.os_agent_version_github’

  - platform: rest
    name: OS Agent Version github
    unique_id: os_agent_rest_github8123
    resource: https://api.github.com/repos/home-assistant/os-agent/releases/latest
    username: !secret GITHUB_USERNAME
    password: !secret GITHUB_BEARER_TOKEN
    authentication: basic
    scan_interval: 604800     ## 1 week of seconds using Home Assistant Core Integration: Update entity
    value_template: "{{ value_json.tag_name }}"
    headers:
      Accept: application/vnd.github.v3+json
      Content-Type: application/json
      User-Agent: Home Assistant REST sensor      

You need to make a long term token on your profile.
You need a git token too. !secret GITHUB_BEARER_TOKEN

tokenCapture

then I saved it to secrets as !secret rest_bearer
rest_bearer: Bearer eyJ0eXAiOi… dont forget to add Bearer in front of the token in your secrets file.
same for the git one. Bearer is hard to troubleshoot being missing.





This checks once per day at around sunrise and notifies me again If I dmissed the notification without actually updating os-agent. which I would potentionally do and then forget to come back to… I have kids lol

alias: os_agent version check
description: Check if the installed and released os_agent versions match
trigger:
  - platform: sun
    event: sunrise
    offset: "0:59:00"
    enabled: true
condition: []
action:
  - service: homeassistant.update_entity
    data: {}
    target:
      entity_id: sensor.os_agent_version
  - service: homeassistant.update_entity
    data: {}
    target:
      entity_id: sensor.os_agent_version_github
  - if:
      - condition: state
        state: "\"True\""       #### caution " " omitted on template sensor
        for:
          hours: 0
          minutes: 0
          seconds: 0
        entity_id: sensor.os_agent_updater
    then:
      - service: persistent_notification.create
        data:
          notification_id: os-agent
          message: >-
            OS_Agent {{ states('sensor.os_agent_version_github') }} is
            available<br></br>
            [Latest](https://github.com/home-assistant/os-agent/releases/latest)<br></br>
            wget https://github.com/home-assistant/os-agent/releases/download/{{
            states('sensor.os_agent_version_github') }}/os-agent_{{
            states('sensor.os_agent_version_github')
            }}_linux_aarch64.deb<br></br> sudo dpkg -i os-agent_{{
            states('sensor.os_agent_version_github') }}_linux_aarch64.deb
          title: OS_Agent New Version
      - service: notify.mobile_app_alp_l29
        data:
          message: SBFspot "{{ states('sensor.sbfspot_latest_release') }}" is available
          data:
            actions:
              - action: URI
                title: Mod History
                uri: https://github.com/SBFspot/SBFspot/wiki/Modification-History
        enabled: false
      - service: notify.mobile_app_alp_l29
        data:
          message: OS_Agent {{ states('sensor.os_agent_version_github') }} is available
          data:
            clickAction: https://github.com/home-assistant/os-agent/releases/latest
    else:
      - service: persistent_notification.create
        data:
          notification_id: os-agent
          title: OS_Agent was version checked
          message: "{{ now().timestamp() | timestamp_custom('%H:%M:%S %D') }}"
mode: single

I think you overcomplicate things :grinning: Anyway, these are way above my knowledge…
The automation -as I posted it- works fine and indeed worked when Agent was updated to 1.4.0. Yes, if you dismiss the notification, it does not show up again. But it’s fine enough for me, usually I update right away.
Did you say that this actually worked?

condition:
  - condition: template
    value_template: "{{ trigger.from_state.attributes.tag | is_numeric and trigger.to_state.attributes.tag | is_numeric }}"

It was a little tricky to set up honestly. I had some difficulty trying to find examples for the rest sensors. Which was part of my motivation of posting it all so it was somewhere neat for someone else.

I used your post 25 automation only. So no idea if the below template works.

condition:
  - condition: template
    value_template: "{{ trigger.from_state.attributes.tag | is_numeric and trigger.to_state.attributes.tag | is_numeric }}"

I finished setting mine up when I realised I actually wanted an annoying persistent notification that would bug me If I didn’t actually install this or my addon update. Even if it was a few days later…

So yeah I agree your way is quite neat and simple, but I wanted to be annoyed at the notifications for my particular use cases. I would use yours for say tasmota, that isn’t critical.

1 Like