Add monitoring of few entities based on their number state (unavailable --> critical)

[bcutter]

What would it need to monitor a few entities based on their value (which is a number)?

Real life example:
5 temperature sensor entities shall be monitored. If the temperature value drops to -100 ° (or sth. like "lower than -50 °") I want the unavailable entities sensor to react (as it normally does).

I think this could easily added with a selectattr similiar to the current one, right?

                |selectattr('state','in',['unavailable','unknown','none'])|map(attribute='entity_id')|list }}

Of course I need to specify those 5 entities somehow.

I think this way we could enhance or convert one unavailable entities sensor to an also powerful "critical" entities sensor.

Update: I managed to create a filter template to get those affected entities. How to integrate that into the unavailable sensor definition?

{{ states.sensor | selectattr('entity_id','match','sensor.multi') | selectattr('attributes.device_class','eq','temperature') | selectattr('state','in',['-100']) | list | length }}

2nd update: (slowly working to a solution... ;-))
This should work, right?

{{ states.sensor | selectattr('entity_id','match','sensor.multi') | selectattr('attributes.device_class','eq','temperature') | selectattr('state','in',['-100']) | map(attribute='entity_id') | list }}

---

So to summarize the remaining questions:

1. How to integrate that filter to the sensor definition?
2. How to bypass the |rejectattr('last_changed','ge',ignore_ts) part (the sensor values exist only for a few seconds so lower than the ignore_seconds variable)?

Update #345.391 😄
To my original section

              {{ states
                |rejectattr('domain','in',['group','button'])
                |rejectattr('entity_id','in',state_attr('group.problems_any_ignored','entity_id'))
                |rejectattr('last_changed','ge',ignore_ts)
                |selectattr('state','in',['unavailable','unknown','none'])|map(attribute='entity_id')|list }}

I added the additional entities to be monitored (based on number values) and summed both blocks up so the final sensor output (list of unavailable and critical entities) is the same. This way I can leave the original sensor definition untouched and at the same time bypass the ignore_seconds parameter for my critical entities section 🎉:

              {{ (states
                |rejectattr('domain','in',['group','button'])
                |rejectattr('entity_id','in',state_attr('group.problems_any_ignored','entity_id'))
                |rejectattr('last_changed','ge',ignore_ts)
                |selectattr('state','in',['unavailable','unknown','none'])|map(attribute='entity_id')|list)
                +
                (states
                |selectattr('entity_id','match','sensor.multi')
                |selectattr('attributes.device_class','eq','temperature')
                |selectattr('state','in',['-100.0']) | map(attribute='entity_id') | list) }}

Hope there will be no side effects, will test this for a while.

[bcutter]

Answered all my questions and finished my custom "critical entities" implementation. See lower section of original post.

Maybe this can act as a blueprint/proof of concept for enhancing this project from an "unavailable entities sensor" to a "critical entities sensor" (which is the way I use this sensor right from the beginning with a friendly_name "Problematic entities").

So: add some custom monitoring -> check ✔

[bcutter]

Temperature sensors had -100 degrees two times (only for a second).

The unavailable entities sensor did not trigger.

Error found: values are float, therefore instead of selectattr('state','in',['-100']) this is needed: selectattr('state','in',['-100.0']).

[jazzyisj]

I don't understand why you wouldn't want to just make an entirely different sensor/notification for your "critical" entities. It is telling you about an entirely different condition than "unavailable" entities. I would recommend doing this rather than complicating your unavailable entities sensor.

Also, your filter here would only catch sensors that are exactly equal to -100. A less than/equal test would be more robust.

selectattr('state','le',-100)

https://jinja.palletsprojects.com/en/3.0.x/templates/#list-of-builtin-tests

This would probably be your entire template for the entities attribute in a separate sensor.

            {{ states.sensor|selectattr('entity_id','match','sensor.multi')
                |selectattr('attributes.device_class','eq','temperature')
                |selectattr('state','le',-100)|map(attribute='entity_id')|list }}

BTW there is a newer simplified version of the original sensor I posted recently if you're interested in updating your implementation.

[bcutter]

It's working fine as stated, thanks.

I combine it because as written I originally named the sensor as "Problematic entities" sensor, not "unavailable entities" sensor. So I want everything that needs attention in one place without creating additional sensors. This way the whole process based on the problematic entities sensor (GUI visualization, automation/notification, ...) stays simple.

Yes the less equal is much more robust. In this case exactly -100.0 is what I'm looking for.

Thanks for that hint, didn't look at newer versions (never change a running system - it works just perfect 😄 👍 ).

[bcutter]

Catch-up @jazzyisj : how would you combine this today with your sensor (within ONE sensor)?