(Yet another) ignore previous "unavailable" state

Ok, how can this you posted:

  - {{ 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: ""
  - platform: state
      - sensor.home_assistant_os_agent_latest_release
    attribute: tag
  - condition: template
    value_template: >-
      {{ trigger.from_state.attributes.tag != "unavailable" and
      trigger.from_state.attributes.tag != "unknown"  }}
  - condition: not
      - 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
  - service: notify.persistent_notification
      message: There is an update in Os-Agent!
      title: Update message
mode: single
1 Like

Yeah, that’s what I proposed originally.


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).

  - "{{ 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: 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:

  - "{{ 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
  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
    }}/os-agent_1.4.0_linux_x86_64.deb<br></br> sudo dpkg -i os-agent_{{


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.

{{ 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.

    - 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 


  - 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
      Authorization: !secret rest_bearer
      User-Agent: Home Assistant
      Content-Type: application/json


  - 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 }}"
      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


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
  - platform: sun
    event: sunrise
    offset: "0:59:00"
    enabled: true
condition: []
  - service: homeassistant.update_entity
    data: {}
      entity_id: sensor.os_agent_version
  - service: homeassistant.update_entity
    data: {}
      entity_id: sensor.os_agent_version_github
  - if:
      - condition: state
        state: "\"True\""       #### caution " " omitted on template sensor
          hours: 0
          minutes: 0
          seconds: 0
        entity_id: sensor.os_agent_updater
      - service: persistent_notification.create
          notification_id: os-agent
          message: >-
            OS_Agent {{ states('sensor.os_agent_version_github') }} is
            wget https://github.com/home-assistant/os-agent/releases/download/{{
            states('sensor.os_agent_version_github') }}/os-agent_{{
            }}_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
          message: SBFspot "{{ states('sensor.sbfspot_latest_release') }}" is available
              - action: URI
                title: Mod History
                uri: https://github.com/SBFspot/SBFspot/wiki/Modification-History
        enabled: false
      - service: notify.mobile_app_alp_l29
          message: OS_Agent {{ states('sensor.os_agent_version_github') }} is available
            clickAction: https://github.com/home-assistant/os-agent/releases/latest
      - service: persistent_notification.create
          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: 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: 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

So these examples work great as the trigger, but how would you go about it in a wait template?

e.g. I use the following:

  {{ is_state('binary_sensor.office_door_motion', 'on') or (
  is_state('binary_sensor.office_door_motion', 'off') and (now() -
  states.binary_sensor.office_door_motion.last_changed).total_seconds() < 1.5 )) }}

to see if a motion sensor is on, or was on in the past 1.5 seconds (to account for the varied delay in when motion sensors turn off)
This works great, unless that sensor goes unavailable, because then when it comes back it shows as off, and a recent last change, when in reality I only care about that last change if it was from a state of ‘on’ to a state of ‘off’, I don’t care about an ‘unavailable’ to ‘off’ transition.