Do you mean that you have a group called ‘entities don’t care’, and the entities in that group are still triggering this sensor even though you haven’t listed them in the ‘ignored entities’ group?
If so, the sensor is working correctly. If you don’t want entities to trigger the sensor they need to be in the ‘ignored entities’ group.
@anon43302295 according to the definition of ignored_entities above it would seems to me to include:
- binary_sensor.updater
- group.entities_dont_care
Where group.entities_dont_care contains a bunch of sensors I want to ignore. So essentially it would like group.ignored_entities is a group of groups which I want to use to ignore from this sensor.
Groups are not recursive. That configuration is saying “don’t alert me if the state of the entity ‘group.entities_dont_care’ and the entity ‘binary_sensor.updater’ are unavailable, but do alert me for all other entity_ids”
Whether those entity_ids are in group.entities_dont_care is irrelevant.
I see, I understand what you mean now. Also did not realize that groups are not recursive.
Is there way to list like 30 sensors w/o cluttering up the package unavil_sensors.yaml file? That was my original intention.
something like:
group:
ignored_entities:
entities:
- binary_sensor.updater
- sensor.amazon_echo_*
Where I have like 10 sensors named sensor.amazon_echo_1, sensor.amazon_echo_2, sensor.amazon_echo_n
No, you can’t glob.
The only way you could keep it ‘somewhere else’ would be
group:
ignored_entities:
entities: !secret my_ignored_entities
And then in your secrets.yaml
my_ignored_enities:
- binary_sensor.updater
- sensor.amazon_echo_1
- sensor.amazon_echo_2
- sensor.amazon_echo_3
- [etc]
But I’d advise against it because it’s an added layer of complexity and it’s kinda misusing secrets.
The point of packages is to have everything that’s connected all in one file, so listing all the entities you want to ignore in the package is the ‘correct way’
Of course you could always put the whole group declaration in a different package to ‘keep it neat’, so long as the group is called ‘group.ignored_entities’ it doesn’t matter where it is configured.
I’ve posted an updated/alternate version of the Unavailable Entities sensor. The new version uses custom attributes to declare ignored entities. This allows for ignoring entities by domain and glob.
New version has issues. I guess actually unavailable entities don’t pick up any customize settings after a restart. Kinda defeats the purpose of this whole thing! I should have tested this more before posting. I had just changed the value in the developer states tool to test. Didn’t figure it out until I restarted with an integration disconnected.
I will leave up this as a marker of my shame and a warning to others 
The previous version which uses a group to declare ignored entities is still available at.
@anon43302295
This version supports your whitelist concept. Just set the attribute ignore_entity: false on any entities you want to whitelist in customize.
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!
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.
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.