I am prefering not to have another sensor, so I am using it only direct in my automation.
If someone is interested, here is the code:
" - alias: ‘Remind for unavailable device’"
I am a bit curious what your reasoning for not wanting another sensor is?
I’m even more curious about why that trigger works though, and it does. I did a little test.
- id: test_automation
alias: test automation
trigger:
- platform: template
value_template: "{{ states('input_number.radio_volume')|int }}"
action:
- service: system_log.write
data:
message: It worked!
Template triggers work by evaluating a template on every state change for all of the recognized entities. The trigger will fire if the state change caused the template to render ‘true’. This is achieved by having the template result in a true boolean expression ({{ is_state(‘device_tracker.paulus’, ‘home’) }}) or by having the template render ‘true’ (example below). Being a boolean expression the template must evaluate to false (or anything other than true) before the trigger will fire again.
So reading that, very carefully, many times - I really don’t understand why that test fires in the first place. I would get it if HA considered 0 to be false and anything else to be true, but I don’t think that is the case. It would mean that in my test the automation should only trigger again if the input_number was set to 0 and then above 0 again. But it triggers every time I move the slider, even if I never return to 0!!
Someone’s got some 'splainin to do here!
2 Likes
I think my method definitly is not perfect. So far it worked fine. I only had to exlude being notified when it switched back to a 0 count:
The reason I am prefering not to have another sensor is, that I would need that sensor only for this one automation. I prefer keeping my homeassistant clean, this would be another sensor that I would have to “maintain” in my config (excluding from the DB history, excluding from being published to other sources and so on)
while you’re at it:
- alias: Remind for unavailable device
variables:
watched: >
{{states|selectattr('state','in',['unavailable','unknown','none'])
|rejectattr('domain','eq','group')
|rejectattr('entity_id','in',state_attr('group.entity_blacklist','entity_id'))
|map(attribute='entity_id')
|list}}
trigger:
platform: template
value_template: >
{{watched|count|int > 0}}
for:
minutes: 1
action:
service: notify.me
data:
message: >
{{watched|count}} entities unavailable, please check:
{{watched|join(',\n')}}
note I changed the service and blacklist group to have it work locally 
also, ‘unlisted’ the list for presentation purposes a bit. Still a bit hesitant how this will impact performance, blew the system before, and now only triggers 1nc a minute… Even when used as template trigger?
you might consider adding a core issue against this. Considering the input_numbers here will be floats (volume between 0 and 1) the value template will ever only be 0 (for all decimals up to 1, got to remember the |int returns anything into 0 even a string.) or 1. But even with that said, the value template simply returns a number, and not a true/false.
triggering shouldn’t happen because of that, so thats a bug…
The fact that works is perplexing because, as you pointed out, it contradicts how a Template Trigger has traditionally worked (requires a binary true/false result).
You’re saying a variable works in a Template Trigger? That hasn’t worked in the past (and I even created a Feature Request to add this functionality).
Based on what you both have observed, the Template Trigger’s behavior must have changed (recently). The question is was the change by design (and we all missed it in the Release Notes) or by accident (an unforeseen by-product of some other change).
FWIW, I’ll be experimenting with this shortly (using the latest release version) and will report my results.
1 Like
not really sure, but I tested this automation by triggering it manually, and it notified me correctly. That would indicate it at least sees the variable and templates it correctly.
Havent seen a real life notification yet, since I always have a few unavailables
my post was more of a yaml code cut intention tbh…
I recall this is how it worked in the past; the variable is initially interpreted correctly by the Template Trigger. The issue is that when the variable changes state, it fails to update the Template Trigger. My wild guess is that there’s no listener assigned to the variable within the Template Trigger.
@Mariusthvdb I don’t think variables can be used in a trigger. My understanding is the variables are evaluated at the moment of the trigger evaluating to true (please correct me if I’m wrong). That is why you must reset the variables in the action block if the values have changed and the new value is of consequence. They aren’t constantly re-evaluated. I think that would add an incredible amount of overhead if you’ve got a significant amount of variables.
I think this little test can confirms this. Moving the slider to and from zero, this automation never fires.
id: test_automation
alias: test automation
variables:
test: "{{ states('input_number.radio_volume')|int == 0 }}"
trigger:
- platform: template
value_template: "{{ test }}"
action:
- service: system_log.write
data:
message: It worked!
Having learned my lesson a few messages earlier about not testing thoroughly enough before opening my mouth, I did verify the value!
Thank you both for confirming I’m not crazy though. If this indeed is a little bug it will be the first one I’ve noticed that didn’t turn out to be me being a blockhead! 
Exactly. The example in the Feature Request uses a variable to report which input_booleans are on. Regardless of how many input_booleans are turned on/off/on, the Template Trigger fails to detect the state-changes.
I’m not so certain about that. The variable’s template would be the same one you would normally use in the Template Trigger. Here’s your example without a variable:
trigger:
- platform: template
value_template: "{{ states('input_number.radio_volume')|int == 0 }}"
Same template but not in the variable; overhead is the same.
As for the concern about the overhead of multiple variables, only the variable(s) used in the Template Trigger needs to be monitored for state-changes.
Anyway, short story is variables aren’t assigned listeners when used in a Template Trigger … so if you want it, please cast your vote for the Feature Request (i.e. throw a virtual coin in the fountain and hope the wish comes true). 
I used this to test a few types of entities:
- alias: Funky Template Trigger
trigger:
- platform: template
value_template: "{{ states('input_number.test') }}"
action:
- service: persistent_notification.create
data:
title: Funky Stuff
message: "{{ now().timestamp()|timestamp_local }}"
These can trigger the automation:
value_template: "{{ states('input_number.test') }}"
value_template: "{{ states('counter.test') }}"
value_template: "{{ states('light.test') }}"
The first two trigger regardless of the reported numeric value. However, when using light it triggers only when state changes to on but not to off.
These do not trigger the automation:
value_template: "{{ now() }}"
value_template: "{{ states('sensor.time') }}"
At first I thought this behavior might be due to the fact that templates now support native types. Maybe the template’s result is (somehow) converted into a binary true/false value … but that now seems like a stretch.
Anyway, this doesn’t behave consistently nor does it comply with the documentation. You should definitely report it as an Issue in the Core repo.
You should slide it to and from 1 to trigger it. This is always true unless the slider is on 1…
But maybe you did that too?
My test with an input_number involved changing its value from 5 to 6 to 7 and then back to 5. It triggered on each state-change.
Done.
2 Likes
yeah, nice test set up, and clear for the issue in core.
maybe we should add this Use new template 'expand' functionality in automation trigger? to it, now we’re talking triggering templates, and the dust on the expand() functionality has settled down, maybe try to expand using expand in a trigger template once more…
1 Like
This would eliminate half my groups!
I don’t understand how you expect that to work.
Your example creates a list of entities in a Template Trigger. You’re expecting the Template Trigger to behave like a State Trigger. However it has never worked that way. A simple state-change is what a State Trigger considers sufficient to trigger but that’s just enough for a Template Trigger to evaluate its template (and trigger only if the computer template’s result changes).
Perhaps what you are looking for is the ability to template a State Trigger’s entity_id. The expand function would be a good fit for that.
That is what I was looking for 
Well apparently we’re wrong. No explanation there that makes much sense to this blockhead, but whatevs.
but also this: https://github.com/home-assistant/core/pull/46423
which at least would suggest the Bug to be recognized and being worked on