Right now if people want to use templates, they have to remember data_template and service_template. Sure, it’s in the docs, but it’s yet another question that’s asked about at least daily, if not multiple times a day.
Lets just have templates supported, and add tags to enable a “raw” mode for those few times when people don’t want a template parsed.
Indeed, I’ve never understood why data: can’t just deal with a template too. Is there really that much overhead that we need a different key for templates?
Theres no reason for the data and data_template separation functionally speaking. You can use data_template without using data so why bother with data at that point. I have plenty of automations setup with data_template that don’t use a template. Its just confusing when you think of it like that.
Where is the vote button? I couldn’t are more.
Oh, found the vote button 
Gotta save those ms, you’ll never get that precious time back. I wonder what costs more time, the time spent on the forum correcting data to data_template or all the saved ms for going through a separate code path. 
And you cannot see data_template in GUI which is annoying.
This is the major issue IMO.
Perfect adjective for this operation: “magic”!
If you overlook to add the incantation “_template” to “data”, you win a trip to the community forum to ask “Why doesn’t this work?”
Perhaps as an interrum measure we could have a warning in the config checker if a (potential) template was detected under a data key?
Got this locally implemented in a backward compatible fashion.
I’ll still need to write up some tests though.
PR is up!
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.
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 
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.