WTH we dont have a is_available filter?

[Soloam]

Just to add this note, I pushed a PR to this some time ago… in the end it was rejected because no one agreed with any naming.

[ehendrix (Erik Hendrix)]

Now I see, that would then be separate change since it is different portion. Note that you should be able to do this with current solution by using template trigger and condition:

automation:
  - alias: Some Automation
    trigger:
      - platform: template
        value_template: "{{ is_nominal('sensor.sensor1') }}
    conditions: "{{ is_nominal('sensor.sensor2') }}
    action:
      - service: notify.mobile_app
        data:
          message: "{{ 'Test ok' if is_nominal('sensor.sensor3') else 'Test bad' }}"

[ehendrix (Erik Hendrix)]

I like that one.

[Soloam]

This was my original PR! Add template filter default_na: Default Not Assigned Filter by soloam · Pull Request #65384 · home-assistant/core · GitHub

Hope this one gets approved!

[ThomDietrich]

Absolutely. No beginner would know/use this though

[Soloam]

I was going to a default like behavior! But the filter option is better, we can use it in conditions directly.

[ThomDietrich]

With prefix though? I would agree with has_valid_state

[Soloam]

In the end, if the name says something that is clear, and if it’s in the documentation… any name is good to me!

[123 (Taras)]

@Soloam

valid_state

This promotes the misconception that unavailable and unknown are not valid states. The terms valid/invalid usually indicate conformance/non-conformance to known and accepted rules. However unavailable and unknown are members of a group of accepted states (like on or off). The distinction is that they represent non-nominal states; they convey information that there’s a problem with the entity (it’s not performing nominally).

It’s a subtle but important distinction, used in engineering, to improve descriptive accuracy.

An example of an invalid state would be an integration that produces a binary_sensor reporting down instead of off. That would be truly invalid because it fails to conform to Home Assistant’s rules for a binary_sensor’s acceptable states.

[finity]

I really doubt that the target audience would likely know what “nominal” means and would probably understand that unknown or unavailable means something isn’t right.

I think that subtlety would be lost on most users.

I would like some variation of the “invalid” term myself.

[CentralCommand (Mike)]

Fwiw if this is to be added it should be a jinja test, not a filter and should probably just be called nominal. That way you can do this:

automation:
  - alias: Some Automation
    trigger:
      - platform: template
        value_template: "{{ 'sensor.sensor1' is nominal }}"
    conditions: "{{ 'sensor.sensor2' is nominal }}"
    action:
      - service: notify.mobile_app
        data:
          message: "{{ 'Test ok' if 'sensor.sensor3' is nominal else 'Test bad' }}"

And more importantly, if its a jinja test you can do this:

{% set sensors_to_test = ['sensor.sensor1', 'sensor.sensor2', 'sensor.sensor3', ...] %}
{{ sensors_to_test | select('nominal') | list }}

If its not a test then it can’t be used in a select filter to reduce a list of sensors to only the nominal ones.

[123 (Taras)]

Nominal

[ehendrix (Erik Hendrix)]

@petro

is_nominal, is_actual, is_measured, is_active makes sense to me. I’m good with any of them.

@ehendrix

non-entity-id string would

I’m referring to the None object, unknown string and unavailable string.

Essentially making it useful for attributes as well.

So providing a state object itself, something like: is_nominal(sensor.test) or is_nominal(sensor.test.attributes.attr)?
Issue with that would be that one would get an error if the state object does not exist.

[finity]

well, yeah I know that and you know that but I’d venture a guess that most people don’t.

[petro]

@ehendrix

So providing a state object itself, something like: is_nominal(sensor.test) or is_nominal(sensor.test.attributes.attr)?

State object (simple test):

{{ is_nominal(states.sensor.test) }}
{{ states.sensor.test is is_nominal }}

State object, for the intended use case in a generator as a test. I can help you set this up in your PR if you need me to. EDIT: Looked at your PR, looks like you got this part figured out so these following test cases should work. You have to use at least 1 select or selectattr in your test case because that doesn’t work without pass_eval_context and if someone changes that it’ll break select, selectattr, reject and rejectattr

{{ states | select('is_nominal') | list }}
{{ states | selectattr('state', 'is_nominal') | list }}
{{ states | selectattr('attributes.attr', 'is_nominal') | list }}

Entity_id

{{ is_nominal('sensor.test') }}

Attribute or string

{{ is_nominal(states.sensor.test.attributes.attr) }}
{{ is_nominal(state_attr('sensor.test', 'attr')) }}

[petro]

I was thinking something simple like is_good I’m sure that will be a point of contention in the PR.

[Soloam]

The main use case that I was thinking was to use in if similar to the is_defined, but with the state, like:

{% if states('sensor.test')|is_good %}
   do this
{% else %}
  do that
{% endif %}

[petro]

Yes, that would work if he incorporates strings instead of just entity_id’s and state objects.

[123 (Taras)]

@finity

that most people don’t

I’ll include myself in that group of “don’t know” when it came to understanding the meaning of the word ‘slug’. Entity_ids are slugs. It took a quick googling to learn what that means in the context of software terminology.

There’s a filter available to convert a string to a slug and it goes by the amusing name slugify.

[Soloam]

I kinda think that should be the way to go, it should receive a string and return false if that string is on the ones that are considered “not good”