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.
adding to the coat-reasoning, they are horrible imprecise… I had several other wind-chill templates, and they would differ more than a few degrees more than often. Coming to think of that, using several weather components on my location, all differ. Quit a bit.
So, it’s no more than a very rough indication. Best look at the wind, if its on, use a thicker coat. Or long thermo’s 
cheers!
what is it, 8, 7.5 or 6. Or feels like 1…
That reminds me of an old watch saying : -
“A Man with a watch is sure of the time … A Man with two watches is sure of nothing !” 
I agree
I just want to have them seperated all the time and not at times having the same temp. shown twice.
understand, like this:
Exactly