–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…
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'
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.
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.)
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
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.