yes, thanks, Ive thought about that, and my reasoning was the sensorâ state is a string (everything is a string unless you explicitly state it isnât ) and the quoted â1.0â is a string⌠so, no need to create floats or ints because of that?
if needed, maybe I would be better of using an intâed value_template?
well, im stuck really, I can test various formats in the dev-template and they all show the correct mdi icon, and when in frontend it keeps showing the mdi:helpâŚ
maybe @petro would you understand whatâs going on here?
Sorry I didnât get to this earlier. I think youâre drawing the wrong conclusion here. The issue is operator precedence. is number is a test, and it takes precedence over divide. So it basically did 3600 is number first, then used that in the denominator of the division. Thatâs why you got an unexpected result when you tried that in the template editor. In that particular case you do need to use parentheses to get the divide to happen first, and then apply the is number test to the result of the divide.
But == has lower precedence than divide, so you donât need the parentheses. This:
now().utcoffset().total_seconds()/3600 == 1.0
produces the same result as:
(now().utcoffset().total_seconds()/3600) == 1.0
I suspect your original problem had more to do with trying to use the result of the value_template in the icon_template. If you look back, all your non-working template sensor examples used the state of the sensor in the icon_template. It didnât work until you used now() instead. But thatâs just a guess since I really donât use icom_template.
HI!
Thanks for this, much appreciated, and very informative. Didnât realize the precedence issue indeed. Will take note of that and be careful.
HoweverâŚ
this is the only template up to now, where I must use the value template itself and canât use the state of the sensor for templating. And, donât want to be stubborn, I do need the parentheses for the icon_template to work. If I read correctly, this canât be explained by what youâve just tought me. It might even be a bug, and I will see if posting an issue on this could be helpful.
Im using regular icon_template here, builtin HA, so no custom-ui.
you can copy and try for yourself. take out the parenthesis in the {% set offset = (now().utcoffset().total_seconds()/3600) %} line and it will fail.
Not in dev-template, like all the others that showed correctly there, but in actual HA .
I adjusted your template sensor for my time zone and tested it with and without the parentheses and it worked in both cases (using version 0.89 in docker).
So now that I look at your OP again, your issue is that there are no entities to get it to be re-evaluated. Itâs only evaluated once at startup. Do you see this warning in your log:
Log Details (WARNING)
Sun Mar 10 2019 07:36:34 GMT-0500 (Central Daylight Time)
Template sensor utc_offset has no entity ids configured to track nor were we able to extract the entities to track from the value template(s). This entity will only be able to be updated manually.
When the sensor is updated at restart, it has no state in the state machine yet. So when it evaluates value_template and icon_template, states.sensor.utc_offset does not exist yet. This results in the icon_template being evaluated as mdi:help.
To solve your original problem, and to solve the problem you didnât realize you had â namely that when there is a utcoffset switch, like today, the sensor isnât updated until the next restart â add entity_id. So something like:
Came back to report exactly what Phil did: No entity_id to track.
2019-03-10 09:00:43 WARNING (MainThread) [homeassistant.components.sensor.template] Template sensor utc_offset has no entity ids configured to track nor were we able to extract the entities to track from the value, icon template(s). This entity will only be able to be updated manually.
I was seeing it âworkâ only because I restarted my test system (docker-based) after I added the template sensor to the config file. Only reason the template sensor worked again this morning (showing correct offset for DST) was because, yet again, I started the test system which is normally off.
BTW, if you watch closely, youâll see that right after restart the icon is mdi:numeric-0 until the sensor updates again. Thatâs because at first the state doesnât exist, so the int filter returns 0. Then on the next update it changes to the expected value. This is going to happen all the time. I.e., the icon will always be one update behind the state. But since thatâs only for one minute, and only will be an issue for one minute twice a year, and probably while youâre sleeping, might not be worth changing.
For example, if itâs for indicating time-changes as a result of Daylight Saving Time, then that only happens twice a year (and the sensor need not check for it every clock-tick).
in short: I needed an automated way to set my python scripts on the correct timeDifference. I am on CET +1, but daylights savings times are not synchronous.
our Summertime starts on march 21st, while I think even today Daylight savings changes in the python time
so, its not always +1âŚ
Hope to have it covered thanks to @pnbruckners help with the utc offset template.