Perhaps as an interrum measure we could have a warning in the config checker if a (potential) template was detected under a data key?
3 Likes
Got this locally implemented in a backward compatible fashion.
I’ll still need to write up some tests though.
5 Likes
PR is up!
21 Likes
wow, that is so cool. Worth the whole WTH month on its own! Thanks.
imagine building/expanding on this, we lose the need for template sensors, binaries, switches ea completely too? ‘Simply’ let the backend handle templates if and where they are used in the config.
Well, have any field except templates. Just today found another fine option:
logger:
default: >
{{states('input_select.log_level')}}
The possibilities are endless and HA yaml is going to be so much simpler in a few 
Hope this gets some momentum indeed, and for now, again, thanks!
Wow yea this is awesome, I thought this would be harder, this is fantastic. Plus now we can use templates in keys which is another long standing hassle. Man what a great month, can’t wait for next release! 
So I’ve closed my PR listed above. While is worked perfectly for the use case described here. It caused issues on other parts of the system.
This change is complex. I’m not giving up the fight, but at this point, I don’t see the above listed PR to have a future. Going to try / take some different approaches.
3 Likes
Frenck,
Would I be right in assuming that the ultimate goal would be ‘whereever’ we used anything with a *_template we would be able to replace that with just the * ???
If so this would be truly awesome but I can see why this would take several “coats of looking at” as this touches a lot of integrations/components etc.
And to be able to drop a template in ‘virtually anywhere’ would be fantastically flexible.
Tinkerer, thanks for proposing this 
1 Like
This would be changes in every place that would accept the template. Not something small. That means every component, every yaml field would need to change from a static on startup grab to dynamically updating. It’s a good goal, but it won’t be done anytime soon.
Can’t say I follow they entire rationale, but is it a possibility to deprecate the ‘old’ method but just keep it enabled for a long time? That way at least everything new will be implemented correctly while you buy time to work on a more robust solution and give custom component developers ample time to fix their own code.
That is what I tried to do, however, in the end, it changes the behavior of “data”.
There are more paths, it is simply going to be more complicated that initially set out.
Lets say this is implemented in the future.
Can we have them live along side each other in a peaceful manner?
If data_template is “removed” then lot’s of people automations and scens will need to be updated.
As said above, the goal is to have it backwards compatible. The above PR (now closed) did exactly that. it accepted both data and data_template. Of course we are not going to break all automations.
1 Like
[font style=“text-decoration: sarcastic”]
THIS is why I LOVE these forums. The amount of time spent fighting for noble causes that go against the ‘if it ain’t broke don’t fix it’ rule of thumb.
Why can’t we all just use data_template everywhere - update the docs wherever data is mentioned (CTL+H find & replace!), etc. Just get used to using data_template (I won’t say anything, but you can still use data if you’re not templating [power user move!]). Tell everyone to use data_template always and everywhere and there’s no longer confusion. Just give it a chance and I’m sure everyone can adjust to the new normal - data_template!
To me, this entire thread is akin to spending 2 hours to reduce two automations into one, when the two work just fine. Which is ironic, because it takes a data_template to do this a lot of the time anyhow - data_template everywhere, always and forever!!
I love this place, such infotainment!
[/font]
3 Likes
Petro, I agree completely.
The scope is (probably) pervasive, but with a goal in mind and everyone aware of that then every change from now on should be with that in mind.
This is just the way it works with messages, which is obviously quite a small garden to be cultivated. The rest of HA is a ‘bit’ more extensive.
But implicit in the title (OP) would be that it apply everywhere.
I quite like @Markus99 's idea but it feels like a compromise.
I Agree with @frenck that it should be backwards compatible (I fully realise that loading your yaml into an editor and search replace “_template” with “” (empty string) is a doddle for even a modest user, but some newbies will not be happy.
It is a worthy goal and one that (understandably) may take a bit more time than 'next release’
Attempt 2 (based on the first attempt):
edit: This has been merged
As of 0.115, this WTH has been resolved.
25 Likes
Does this mean that I can du stuff like
condition: time
before: "{{ input_datetime.foo }}"
from 0.115?
1 Like
No @Olen. This applies to data_template, event_data_template and service_template, which now are obsolete.
Thanks.
Should I add another WTH (or feature request) for enabling templates also in other places (like conditions)?
2 Likes
Sure, we should not stack different things in a single topic. The original WTH of this topic has been resolved.