WTH we dont have a is_available filter?

Month of "What the heck?!"
3

I agree with he naming problem… Basically this it, something that is not ‘unknown’,‘undefined’,‘unavailable’, that are values that will make most templates fail. The naming
is_nominal is a good name as any other, if the documentation explains its result, but I kinda like that

4

I was confused by this too as its not a state I’ve ever seen.

@Soloam does undefined here really mean “does not exist”? Like you want a test that passes if an entity exists with that ID and its state is something other then unknown or unavailable and fails otherwise?

If you actually have entities which have state undefined I’d report that as a bug on the integration personally. I would not expect any special handling for that state as its not a common or known one and is integration specific. The integration should probably use unknown or unavailable instead.

5

It’s normal to test if a entity is different from ['unknown','undefined','unavailable'] because if it’s any of them we can’t for example treat it as a number, it would make the template fail

6

Actually, it’s not normal to test for undefined because that’s not a common state value. That’s why we’re asking which one of your entities reports this value?

2 Likes
7

I think you’re confusing the undefined and defined tests in jinja with 'unknown' and 'unavailable' states.

8

I like the nominal terminology, I was struggling for that in a somewhat related post

9

probably the undefined is never used, but unknown and unavailable is very common, and a filter to check both at the same time would be of great use.

10

I remember people testing for null as well. Agree that this would be a bug by the integration generating it, not to be considered here.

I would argue that there are big differences between unknown, unavailable, and others. Still, in many places we want to simply filter for “everything is good”. Therefore, I would welcome the addition of this concept. An example to illustrate some potential further places for this:

automation:
  - alias: Some Automation
    trigger:
      - platform: nominal_state
        entity_id: sensor.sensor1
        to: "on"
    condition:
      - condition: nominal_state
        entity_id: sensor.sensor2
        state: "on"
    action:
      - service: notify.mobile_app
        data:
          message: "{{ 'Test ok' if is_nominal('sensor.sensor3') else 'Test bad' }}"
11

I also found a integration that returned null! This is a error in the integration. Having unknown and unavailable in a filter would solve a lot of problems.

12

This isn’t possible. States will never have that value. Attributes can be null and it’s not a bug.

13

FYI, really liked this idea. Created PR #79550 for this and based on initial review looks like the idea is accepted.

2 Likes
14

Had a quick review, looks great!

Any chance you would be willing to follow-up with trigger and condition platforms?

15

Oh man, I was gonna do this this weekend with the following plan in mind:

  1. Works with just 'entity_id'
  2. Works with strings 'unavailable', 'unknown' and None
  3. Works with state objects

Looks like you did that accept for the non-entity-id strings

EDIT: I was also going to name it has_state

16

Not sure what you mean with this, can you elaborate.

17

The yaml example I gave above.
Admittedly, not sure whether its significant but I could imagine especially starters would appreciate it.

@petro I like your has_state. Not sure which is ultimately better but I have to admit, I would need to read the documentation for “nominal”

18

I would say naming of it not really determined. has_state to me kinda means it has some kind of state which could be ‘unavailable’. Maybe has_valid_state? First had is_available, then changed it to is_nominal. Changing is not hard, just need to come up with right name for it. :slight_smile:

A non-entity-id string would return false unless you mean something else. :slight_smile:

19

Just to give my 2 cents on the naming, valid_state

1 Like
20

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

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

Essentially making it useful for attributes as well.

21

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. :sweat_smile: :rofl:

2 Likes
22

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' }}"