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