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
I saw that after I commented on the git. So this behaviour was known, and known to be counter intuitive. They agree itās a ābugā hence the ābugfixā, but at the same time is āworking as intendedā and ānot a bugā. Cool beans. Anyway, sounds they know about and are working on it.
The behavior weāre talking about doesnāt affect me, none of my templates are structure like that. However the PR you mentioned just might!
I have an issue where for some reason or another, if any of my zwave motion sensors are dead the motion boolean is in the on state. This means on a restart, my house alarm triggers if any of those zwave nodes are dead. Problem was discovered at 4:00am burning the midnight oil playing with my config. Wife wasnāt very impressed. Problem reoccurred again a week later when the power flickered at - you guessed it - 4:00 am! Wife was even less impressed.
My ābugfixā for this was if the alarm triggers after a restart, it disarms and then rearms itself, thus saving me from my wifeās wrath. I also finally bought a UPS for the RPi.
Curious if that PR will prevent me from getting tied up by my 'nads again? 
I read the responses to your Issue and adminiugaās reply is notable:
A non zero values are evaluated as True.
This leads me to believe that the unexpected behavior (i.e. it differs from the documentationās description) is a side-effect of supporting native types. As long as the template generates a result that is a non-zero value, it is interpreted as True (and will trigger). Thatās definitely not how it used to work as is described in the documentation which predates the introduction of native types.
It also explains why I observed that it would trigger only when a light changes state to on but not when it changed to off. The on state is equivalent to boolean True or a value of 1 whereas off is boolean False or 0.
When Frenck replied it is āthe correct behavior and thus not a bugā thatās 'technically the truth` now. However, itās not how it used to work (ostensibly prior to support for native types) because you, I, Marius and others have never known it to work like this and our Template Triggers were never written to work that way. This is new behavior.
1 Like
Thank you. The false if 0 else true isnāt what threw me off here. Thatās a pretty common convention and honestly what I would have expected. It was the triggering on state changes to and from non-zero values.
I had basically wrapped my head around the essence of the issue after reading PR#46423 a couple times. Your reply helps solidify it for me. At least I know Iām not crazy now. The initial āthatās the way itās supposed to beā response without further explanation really threw me off because it clearly was not the documented behaviour to my understanding.
I have received a few of those and it can leave one a bit frustrated. In one case, the individual confirmed they didnāt even try to replicate the bug. 
Anyway, thatās not the norm and most replies are helpful.
Where and how do you add this?
Recent migrator to HASS, I assume I copy the package_unavailable_entities.yaml to the config folder and then reference it in configuration.yaml somehow?
Iās like to implement it as I have random disconnects on some Tasmota devices which I think is related to my WiFi but need to track them.
You can either copy the code from the gist and place it in your configuration.yaml or add it as a package. I recommend using the package method.
- Create a folder named āpackagesā in your config directory.
- Add this to the homeassistant section of your configuration.yaml
homeassistant:
packages: !include_dir_named packages
- Create a new file named package_unavailable_entities.yaml in this directory.
- Copy the RAW contents from the gist file into your new file. Save it.
- Add any entities you want to ignore to the group section in your new file.
group:
ignored_entities:
entities:
- binary_sensor.updater
- sensor.temperature etc. etc.
- Restart HA.
You should be good to go!
There are some pretty good hints in the gist comments.
2 Likes
Thanks got it up and running in seconds.
āPackagesā is another thing I have to learn about now 
Thanks, exactly what I was looking for. Great job.
Is there any way to ignore all entities of a certain type? Etc media_player.?
Add the domains you wish to ignore to the filter which excludes groups.
Change this
|rejectattr('domain','eq','group')
to
|rejectattr('domain','in',['group','media_player'])
building on this, I now try to find any attribute in the state machine with an undefined value. I have to because I see
Unhandled Promise Rejection: TypeError: undefined is not an object (evaluating 'JSON.stringify(s).toLowerCase')
and Bram explained to me:
You have an entity with an attribute that has the value
undefined.
Now Bram has added a guard against that, but I want to find the culprits, and see if I can prevent that from my side of things.
So, how to rebuild the templates above so it finds states with an undefined attribute, and lists that attributeā¦
something like this:
{% for s in states
if s.entity_id.attribute is undefined %}
Entity: {{- s.entity_id -}} - Undefined attribute:{{s.entity_id.attribute}}{{',' if not loop.last else ''}}
{% endfor %}
which of course isnāt correct, but merely to show what I am trying to doā¦
Great setup! Iāve tweaked this as I prefer to define which entities to monitor rather than which to exclude - very simple change, but works great. Thanks!
1 Like
WOW, that is some clean code. Thanks. Looks much better than mine.
The old code from me wasnt even working anymore since the last HA Updates, letās see if this one works
I donāt know if you read the posts after that one, but the example makes an incorrect assumption about using variables in a Template Trigger (they fail to update). In other words, there are no listeners assigned to any entities in the template.
A new concept was introduced (later) called a trigger_variable but it only supports limited templates (so it still wonāt work for this application).
If you are interested, there is a Feature Request to allow the use of variables (or the new trigger_variables in a Template Trigger with full templating abilities.