WTH we dont have a is_available filter?

[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”

[Soloam]

using the slugify example:

{{ "Hello World"|slugify(separator="_") }}

It receives a string and handles it. This, in my point of view, should do the same, receive a string and return true or false

[petro]

It should do all of them. The goal is to shorten syntax in all the use cases where ‘unknown’ and ‘unavailable’ need to be checked, which is selectors and if statements.

[Soloam]

I’m good with that… so if its a string handles as a string, if its a dict it handles that dictionary and process accordingly.

[ehendrix (Erik Hendrix)]

Just pushed update for PR. It will now do state objects and strings. This means following works:

{{ is_nominal('sensor.test') }}
{{ is_nominal(states.sensor.test) }}
{% if 'sensor.test' is is_nominal %} ...
{% if states.sensor.test is is_nominal %} ...
{{ states.sensor.test is is_nominal }}
{{ states | select('is_nominal') | list }}
{{ states | selectattr('state', 'is_nominal') | list }}
{{ is_nominal(states.sensor.test.attributes.attr) }}
{{ is_nominal(state_attr('sensor.test', 'attr')) }}
{{ 'sensor.test' | is_nominal }}
{{ states.sensor.test | is_nominal }}

what also works is providing a list:

{{ is_nominal(['sensor.test1', 'states.sensor.test2']) }}
{{ is_nominal([states.sensor.test1, states.sensor.test2]) }}
{{ is_nominal([states.sensor.test1, 'states.sensor.test2']) }}
{{ ['sensor.test1', 'states.sensor.test2'] | is_nominal() }}
{{ [states.sensor.test1, states.sensor.test2] | is_nominal() }}
{{ [states.sensor.test1, 'states.sensor.test2'] | is_nominal() }}

What does not really work is:

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

If the attribute does not exist for an entity then it fails in rendering the template itself resulting in also those without the attribute being added to the list. Does not even get to the is_nominal function.

[petro]

Yeah, that’s expected. You’d have to check if the attribute is defined before checking it’s value.

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

[petro]

I’m looking at your code and I think you’re getting false positives and assuming it’s correct. I’ll comment on the PR

EDIT: nevermind, I must have been loooking at the first version of your PR…

[ehendrix (Erik Hendrix)]

Testing includes both positive and negative, so shouldn’t be. But please review and comment.

[petro]

Yeah, I was looking… Not sure, but I refreshed the page and saw your current changes and made my comments.

[TheFes]

This WTH is solved some time ago when the has_value function/filter was introduced.

Templating