Isn't this an int?

HI,
trying to set a light to a templated brightness setting I receive this error:

Invalid service data for light.turn_on: expected int for dictionary value @ data['brightness']. Got "{{state_attr('light.outside','brightness')|int}}"

on this actin:

action:
  service: light.turn_on
  data_template:
    entity_id: light.outside
    brightness: >
      {{state_attr('light.outside','brightness') |int }}

what would be wrong here?

–edit–
nevermind, it must have been an issue with the dev-service and dev-template where this exact template errored out.
I have it now in the actual automation, and it seems to do the job now. Still don’t truly understand why I need the |int when the template is of the exact same light, and its attribute…

You don’t need it.

First, the brightness attribute is an int already. But, the result of the template will be a string anyway. So even though it might be 255 (i.e., a number), it will get turned into '255' (i.e., a string) when the template is rendered. But that’s ok, because the light.turn_on service schema will “coerce” it back to an int.

yes, that’s exactly what I thought. Still the ha log errored out with the error above… And now that I have it in the real automation, (and not in the dev-template for testing) it works just fine, where it didnt without |int
puzzles me.

I can’t see how you would have gotten that error unless you had accidentally used data instead of data_template in the automation action service call. Or was that error from trying to make the service call on the dev-service page? If so, that doesn’t support templates, which would explain why you got that error.

In any case, you don’t need |int in that template, no matter where you’re using it, assuming you’re using it somewhere that accepts (and renders) templates.

I’ll retest (in the actual automation), and report back. It’s too strange to let go.
this is what’s in the log now:

2018-10-23 08:31:01 ERROR (MainThread) [homeassistant.core] Invalid service data for light.turn_on: expected int for dictionary value @ data['brightness']. Got 'None'

using this automation:

  - alias: "Tradfri outside light shows unavailable"
    id: "Tradfri outside light shows unavailable"
    # initial_state: 'on'
    trigger:
      platform: time
      minutes: '/1'
      seconds: 00
    condition: 
      condition: template
      value_template: >
        {{ states('light.outside') != 'unavailable'}}
    action:
      service: light.turn_on
      data_template:
        entity_id: light.outside
        brightness: >
          {{state_attr('light.outside','brightness') }}

the automation seems to work though. Displaying ‘unavailable’ when I cut off power externally. I suspect he issue to be that when I manually turn off the light in HA, and brightness effectively is 0, it doesn’t receive an int (0 isn’t an int?) and it errors out. Forcing the template to be an int by |int mitigates that?

So when using a template like this, and brightness is a possible 0 None, |int is needed to not have it error out.

    brightness: >
      {{state_attr('light.outside','brightness') |int }}

What’s happening is, when the light is off, light.outside has no brightness attribute. Therefore, in this scenario the state_attr() function is returning None, and None is not a valid value for brightness when calling the light.turn_on service. When you use the int filter in this case, it will return zero, because by default, it returns zero when its input isn’t a valid number, or a valid string representation of a number. And since None is not a valid number, int returns zero.

So, it has nothing to do with whether or not the brightness attribute is a number or a string, because in the scenario you describe, the brightness attribute doesn’t even exist. So int isn’t converting brightness to a number, it’s providing a default value of zero because there is no brightness value (which, as I said, causes state_attr to return None.)

I see. would it be better, more in line with syntax guidelines to write:

brightness: >
      {{state_attr('light.outside','brightness') | default(0) }}

then?

No. See jinja filters. E.g.:

The value None will pass through the default filter. This is not what you want.

a well, in that case I need the |int after all, if only to create an int out of None…Or would you know of anything else.
Theory is fine, but practice sometimes bends that a bit :wink:

instead of

So when using a template like this, and brightness is a possible 0, |int is needed to not have it error out.

I should have written:

So when using a template like this, and brightness is a possible None, |int is needed to not have it error out.

edited my post above to follow suit.

or?
see Input Number - Home Assistant for the |int on the brightness