I don’t see it as a mistake. I found YAML to be very logical and easy to pick up. Way more human readable than some other markup languages.
Jinja took a little more effort but the simple concepts (e.g. how to retrieve a state) were relatively easy to pick up. I’m still learning.
As a pure markup format, it’s okay’ish. I mean, there are not many alternatives anyway if you want human readable. I absolutely hate languages with syntactical significant whitespace, but that’s mostly personal preference.
But config is not code, code is not config. Or at least, it shouldn’t be. That’s what separate scripts are for. The way Jinja2 mashes all this together is horrible. Of course you can learn anything. But learning Jinja2 looks about as fun as trying to pick up COBOL or something from the days of yore. It just doesn’t look and feel like a modern language.
Pyscript is much better and cleaner. It’s still Python (which I don’t like), but subjectivity aside, that is the way HA should go, IMO.
Like you, I have very few function nodes in my Node-Red setup. The few I do have were more about me learning how the function node worked than an actual need to do whatever in code. I’m a professional programmer but I prefer keeping my flows visual. That way it’s easier for me to tweak and tune the logic as various edge-cases present themselves.
That’s quite an advanced automation no one should say this
We’re getting to the point.
It’s just save=state.light[N]; for i in (1, N): state.light[i]=save.state[i-i]; state.light[0]=not(save)
Pseudocode is easy, but in YAML+Jinjia it’s very complicated (I’ve done it in python_script, I’ll post it ASAP).
Another easy automation for me is: turn_off(light.any, climate.any except light.porch_lamp).
[I know it’s close to doable with YAML alone if it wasn’t for the “except”, so I added it - not an uncommon need]
A complicated automation for me is:
I’ve endeavored making my whole home smart, so I’d like to play smart things with it!
Templating YAML with Jinja2 started as a big trend a few years back.
Actually, I have nothing against Jinja di per se; but the user base of Ansible and an home automation system are very different: the former work with it everyday, the latter do it from time to time, maybe months apart. That’s why a structured language, with an overload of possibilities, especially with a scattered documentation, becomes a stopgap.
Moreover, an home automation has to be reliable and robust to exceptions and errors (how many people writing templates ask themself when they will be evaluated and if they’ll always yield meaningful results?).
If I had to bet, in such a situation I’d first consider a visual language, like Node-Red or Blocky. However it has to be well integrated; if you have to write hard-to-remember function calls inside graphic items, its usefulness is lost.
I repeat: I’m not pushing for it, I know it would be a though work; I’m just suggesting not to take YAML+Jinja for granted as the best decision.
Could you elaborate a little bit? I don’t get it…
Now I got it, but that’s more of a physics or statistics problem than a code problem… Depending on the information you are counting with it might just be a rule of three… once you get the formulas figured out it will be irrelevant whether you use NR or jinja or whatever…
Anyways, I’m not sure this way of achieving this is worth the extra effort vs simpler solutions.
I’m not sure too, it heavily depends on how difficult is to implement it. If it is simple, it’s free energy saving, small or big.
Anyway it’s only an idea - I’d like to work on it soon, if you like it too, we can work on it on a separate thread.
What about automatically selecting furnace or HVAC depending on what is more efficient at a certain temperature? Possibly using an efficiency curve calculated from real data? Measure its degradation to understand when filters are clogged or there is some circuit leak? Develop a strategy to automatically disconnect less important loads to reduce maximum consumption and have a smaller electrical contract?
For me, having brought electrical devices under computer control means playing with ideas like that, not struggling to learn simple boring automation…
If you are aiming to achieve a real advantatge vs simpler things I suspect it will become difficult to implement. I mean, with simpler conditions like “is somebody home?”, “is everybody sleeping?”, “is the room empty?”, etc, you achieve, let’s say, a 90+% efficiency effortlessly, it’s bread and butter. It’s really up to you whether that remaining 10% is worth the effort. It sounds to me like you are trying to apply rocket science to design a pencil, but hey, if you are really willing to go this route I’ll be pleased to see how far you get. You’ll need at lest some basic knownledge, if not advanced, of Thermodynamics and of course statistics to figure out the real scenario your house is in order to get some extra %'s of efficiency.
I tend to agree. I avoid crazy automations for my smart thermostat because it’s already smarter than me with it’s setpoints and target temperatures. Then again, my house is newer and energy efficient. Takes 4-6 hours to drop 3 degrees 
. I have to turn off the heat at 6pm so that it’s cold for sleeping.
If there is one thing from this thread which I think could be realistically implemented would be a common, recognizable badge to be added to all the text inputs that supports templates.
Pyscript unstable? Running fine here and reliable.
I know this is an old post, but I think a very good point and opportunity was missed here. I found this post because I ran into the exact problem described by @mumon66 - the lack of any mention of the .split function in the Jinja2 template documentation page linked on the Template tab of the Developer Tools. As @petro correctly points out, the .split function (and many other very useful details) are documented with Python. I think it would be very helpful (and easy) to include some of the points that @petro made on the Template tab with a third link to this documentation.
Question tho, would it ever be possible to add Lua support in place of Jinja?
I mean we could still have Jinja, but having Lua as a native alternative is more intuitive for anyone who can code (more so than Jinja).
Coming from someone who likes to write blueprints - but really hate Jinja with a passion.
*Without resorting to pyscript, node-red, etc etc
You can add any language you want if you have your mind set on it. HA is open source after all. That’s how things like pyscript started.
This thread is a case-study in why open source projects often have such low quality. Someone provides legitimate feedback, and is immediately shot down with:
Then finally, the ultimate classic, “it’s open source, do it yourself”.
Fortunately this doesn’t apply to HA! 
One of the benches in the park had a nail sticking out of it. Someone who loved the park, but was busy or didn’t have the skills to fix the bench, suggested “hey, this nail could injure the kids; could you fix it?”
Instead of saying “sure, we don’t have time right now, but it’s a valid concern, and we’ll get to it as we can”, the volunteers got defensive. They took the suggestion as a complaint; as criticism. They felt indignant: why was this lazy person, who hadn’t contributed anything, questioning their work?
They responded with things like “well, don’t sit on the nail, then”, or “it’s a pretty obvious nail; why can’t you see it?”, or “it’s a free park; go somewhere else if you don’t like it”, or “this park is run by volunteers, so just fix it yourself instead of whining”.
The person who had made the suggestion was sad, because they wanted to see something good get better, and that seemed increasingly unlikely to happen.
There’s a bulletin board for reporting protruding nails and problems like that get fixed.
What we have here is someone asking WTF we don’t replace the existing, functional slide with one they would prefer.
If the idea inspires no one to do it, it doesn’t get done. Explaining why their wish is unlikely to be fulfilled is all part of the discussion.
The irony is that little parable was written 5 years ago in response to users who were bitter that no one appeared to be listening to their complaints. They made dire predictions about Home Assistant’s future unless their suggestions were followed.
When informed they’re free to contribute in many ways, like enhance the documentation or report bugs in the appropriate Github repo or participate in beta testing, they balked at the very idea. Their concept of open-source was “free software for me, someone else does what I want”.
It’s a perfect WTH suggestion: something that isn’t actually broken (the bench is still usable), but can cause a lot of pain to first-timers who don’t know about the nail. If few people feel that it’s worth working on, that’s fine; there’s no need to forcibly reject the suggestion. Maybe over time others will find it, like I did, and upvote.
I was going to just click the button and move on, but I have a visceral dislike for condescending “just send a PR” style responses, and made the mistake of reacting to that.