Automation Syntax, again

[timka]

For something so simple, an old school PLC automation and HMI guy such as me continues to have problems with Ninja and scripting specifics, all the while amazed at the generalities of the language.

Case in point, the following automation:

- id: 'conditional max temp'
  alias: 'conditional test max temp'
  description: ''
  trigger:
    platform: numeric_state
    entity_id: input_number.test_number
    above: "{{ states('input_number.test_max_temp')|int }}"
  condition: []
  action:
  - service: input_number.set_value
    data:
      value: "{{ states('input_number.test_number')|int }}"
    entity_id: input_number.test_max_temp
  mode: single 

The code passes config check but fails with a log entry:

“Invalid config for [automation]: expected float for dictionary value @ data[‘above’]. Got None. (See /config/configuration.yaml, line 2)”

I have tried any number of versions of the ‘above’ expression but without luck.

What am I missing?

Thanks.

[rccoleman (Rob Coleman)]

There’s no evidence in the docs that a template is allowed in the above: or below: portions of a numeric_state trigger, and that’s likely causing the error. You could use a template trigger for that, though.

Automation Trigger

[CentralCommand (Mike)]

Not every field allows templates or has a way to use the state of an entity unfortunately. As stated above, the doc does not say that field supports templates so therefore I would assume it doesn’t. I remember a push during the WTH month with posts like this one to allow more places to use the value of an entity/helper instead of a hard-coded value. Seems like you’re going to have to add a feature request to enable template/entity support here.

[tom_l]

I believe this is on the list of things to do. It was requested during the WTH month. However only templates for numeric conditions and time triggers were implemented.

[timka]

Indeed, fumbling with the expression in a template trigger yields a functioning automation. Thanks all for the comments.

Working script follows. Interesting to note that without the | float filters in the comparison expression, the automation does not fire though it passes config check and is error free when reloading automations.

- id: 'conditional max temp'
  alias: 'conditional test max temp'
  description: ''
  trigger:
    platform: template
    value_template: "{{ states('input_number.test_number')|float > states('input_number.test_max_temp')|float }}"
  condition: []
  action:
  - service: input_number.set_value
    data:
      value: "{{ states('input_number.test_number') }}"
    entity_id: input_number.test_max_temp
  mode: single 

[123 (Taras)]

@timka

Interesting to note that without the | float filters in the comparison expression, the automation does not fire though it passes config check and is error free when reloading

“Check Configuration” identifies syntax errors, not logic errors.

Leaving out the float filter isn’t a syntax error. However it is a logic error because, without the conversion from string to float, it’s checking if one string is greater than another; it’s a non-numeric comparison.

[timka]

Yes, I keep forgetting that ALL templates resolve to strings.

I find it interesting, sometimes, that code can pass the config check but then flags a logbook error entry when I reload automations. Are there two levels of checking? The logbook error is where I find statements pointing to “expected float . . .” when the expression is not valid.

[123 (Taras)]

@timka

ALL templates resolve to strings.

This situation has nothing to do with that (and 0.118 supports native types other than just string).

@timka

Are there two levels of checking?

Yes. One checks basic syntax. The other reports a completely different class of errors encountered during the execution of your code.