Thanks, I’ll try this!
No one else getting this error after restart?
I guess there has to be an error in the following, but it works fine.
windchill:
value_template: >
{% if states('sensor.out_temp') | float < 10 and states('sensor.yr_wind_speed') | float > 1.34 %}
{{(13.12 + 0.6215*float(states.sensor.out_temp.state) - 11.37*(float(states.sensor.yr_wind_speed.state)*3.6)**0.16 + 0.3965*float(states.sensor.out_temp.state)*(float(states.sensor.yr_wind_speed.state)*3.6)**0.16) | round(1) }}
{% else %}
N/A
{% endif %}
unit_of_measurement: '°C'
friendly_name: Wind chill
What error.? You don’t specify ?
Though looking at the template and you specifying that it only happens at restart would lead me to think that it’s the use of " states. " rather than " states ()" the former can give errors if the sensor is unavailable.
Sorry. The error i refer to is the one mentioned earlier in this discussion, This one:
ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.windchill fails
TypeError: can’t multiply sequence by non-int of type ‘float’
I’m not sure, will have to try this in my template editor, but I’d be willing to bet this is a result of (‘unavailable’ * 9 / 5) | float or some such.
Try reconfiguring the template to use states()
Use finity’s example given above, it uses the correct syntax to avoid these errors, just convert it to the entities you use.
Would this be more correct?
windchill:
value_template: >
{% if states('sensor.out_temp') | float < 10 and states('sensor.yr_wind_speed') | float > 1.34 %}
{{(13.12 + (0.6215 * (states('sensor.out_temp') | float)) - (11.37 * (states('sensor.yr_wind_speed') | float * 3.6)**0.16)
+ (0.3965 * (states('sensor.out_temp') | float) * (states('sensor.yr_wind_speed') | float *3.6)**0.16)) | round(1) }}
{% else %}
N/A
{% endif %}
unit_of_measurement: '°C'
friendly_name: Wind chill
1 Like
Well it certainly looks more robust and it matches finity’s syntax so I’d say you were good to go.
I assume you’ve put it through the template editor and it returns your desired result.
So all you can do now is implement it and monitor it over time to see if always stays valid
It actually DID work but just returned the error when restarting. Not even every time.
I will try it out and see if the behaves better.
Thanks 
Yeah, the ‘old’ syntax does still work, but there were issues about transient states whilst establishing connection with the sensors, that’s why they changed it and why finity specifically used that syntax.
I have now used the “updated” syntax for a week and have had no error since after restart
So I guess I now have to modify all the rest of my templates to match the new way.
So this thread is still unsolved, why is that ?
Surely finity solved this for you ???
I just wanted to observe the result over some days but I have now marked the updated template as solution.
Yes finity solved it.
as a fyi,
Ive created this template a rather long time ago, based on the Jagti calculation algorithm. You might find it useful:
jagti_windchill:
value_template: >
{% set temp = states('sensor.temp_current')|float %}
{% set wind = states('sensor.windspeed')|float %}
{{(13.12 +0.6215*temp + 0.3965*(temp - 28.676)*(wind**0.16)) | round(2) }}
unit_of_measurement: '°C'
device_class: temperature
friendly_name: Jag/Ti Wchill
easily encapsulated with the conditions you need.
He wanted limits on the input variables as the calc is only valid within certain ranges
yes, I understand that, thats why I said
windchill:
value_template: >
{% if states('sensor.out_temp') | float < 10 and
states('sensor.yr_wind_speed') | float > 1.34 %}
{{ states('sensor.jagti_windchill') }}
{% else %} {{states('sensor.out_temp')}}
{% endif %}
unit_of_measurement: '°C'
friendly_name: Wind chill
…
btw, there are several Windchill sensors available natively currently (when I made mine, I dont think I had seen those before)
At least Darksky (apparent_temperature) and Buienradar (feeltemperature) now offer these?
Also, why use N/A. As if there is no apparent temp outside these conditions 
Ive added the current temp in the else clause
Yeah, those are what I use 
I see your point in using the current temp. in the else clause, but I always want to see the current temp. and if within the conditions also the windchill
No, Marius is saying that there is an “apparent temperature” value.
This is real temperature with wind chill applied (if applicable) else it just displays the current temperature.
I have it to view, but don’t actually use it for anything other than to see if I need a thicker coat.
It does not affect heating at all (in fact neither does outside temp)
But with this only one temp. is visible, either the current temp. with windchill or current temp. without windchill or…?
I don’t know what you mean ?
Regardless, this is my display : -
When outside the limits they just display the same. This is a standard component sensor, no templates involved.