Could you elaborate more please?
What is wrong in flow-chart programming in regard of use-cases valid for home automation?
What about programming using data-serialization language then (yaml)? It shouldn’t be even considered as programming language.
That is your opinion, not truth.
Lol I feel like that would be my biggest argument for node RED. But I get that not everyone has the same preferences.
That being said I’m not sure I agree with this one. I definitely like Node RED and I’m glad the integration makes it so smooth that it basically feels like a part of HA right now. But Node RED has a pretty steep learning curve as well, I’m not sure its more approachable then YAML. And the HA team has no control over its direction, design and development so I think it would be tough to make it more integrated then it already is.
I think the HA team is on the right track with the automation editor UI. Automating via YAML is basically coding, automating via AppDaemon is literally coding and Node RED may be UI driven but still requires a ton of technical knowledge to get the hang of it. If the success of IFTTT and SmartThings tells us anything its that most people are really just looking for very simple automations and optimizations. I think for people looking to do that the automation editor UI has the least learning curve. For people looking for more complicated automation they can grab one of those other approaches for now while the editor expands its capabilities over time.
But it will never be sufficient enough because yaml is not a programming language. It’s wrong tool for the task it’s used for.
The point is that yaml automation is the first method suggested in documentation. Therefore a lot of users might stuck here wasting their time, just because they have no idea about alternatives.
BTW I don’t think NodRed has steeper learning curve than yaml. For sure is less error-prone
We’re not after a programming language in home assistant though. We’re after a way to configure platforms and integrations. For which yaml+jinja is perfectly sufficient.
If you want to program use a shell or python script.
I don’t need or want Node Red, but you are quite welcome to use it if you prefer it. Just don’t force me to.
You forget about “automation”. Configuring is different thing. Actually HA are stepping off yaml for configuration by moving towards GUI.
But we are talking about automation which IS programming. And you are offering non-programming language for that. And likely this is the reason why it is so weak feature-wise and hard to learn (or unfriendly syntax-wise)
I forgot nothing. You configure the trigger, conditions and actions of an automation.
I tried to get into Node-Red. I really thought I was going to enjoy the visual nature of it. I moved most of my automatons over to it.
However, I began to feel like things that were trivially simple in YAML were exceedingly complex to recreate in Node-Red. So I slowly migrated everything back to YAML and have been much more productive ever since.
In my opinion, it’s not all that hard to learn how to write a YAML-based automation. It’s a simple, straightforward approach (trigger, condition, action) and usually it’s the need for proper indenting that trips people up.
However, what is challenging is Jinja2. That’s really the ‘programming’ part where decisions are made about which services to call, which entities to include, option parameters to set, etc. Learning Jinja2 is challenging because its documentation is not written for home automation audiences, especially not for someone just starting out.
Would it have been a better a decision to use python as the primary means of writing automations? Maybe. Python is well documented and there’s no shortage of tutorials available for all skill levels. The other home automation system I use employs VBScript. It was easy to learn and the language contains so many functions (plus bespoke functions provided by the product itself) that you rarely need to invent anything new (date math is trivial compared to what we do in Jinja2).
Nonetheless, that ship has sailed. It’s unlikely automations will be standardized on python. Currently, if you want to use python for creating automation logic, you do have that option via the python_script integration, AppDaemon, or the recently introduced pyscript (custom component).
From what I’ve seen, I think pyscript comes closest to being the easiest to learn and use. It does a good job of making the hard things easy. However, it’s still python and learning python is non-trivial for someone who has little exposure to programming.
I have almost the opposite impression 
I started using node-red soon after I have started with HA (almost two years ago now) for two reasons:
How to debug? I could post for help on the forum, but, I am more on the DIY side.I use a service call to persistent_notification.create (or to the log). Works for me.
I do a log of debug logging style testing early when I create a new automation/script. I use persistent_notification.create. I can output any values to the web UI this way.
- service: persistent_notification.create
data_template:
title: "automation.hot_water_pump_timeout"
message: "Start - {{ as_timestamp(now()) | timestamp_custom('%I:%M:%S %p %d%b%Y', true) }}"
Several home automation systems offer tight integration with Node-Red (openHAB and Hubitat come to mind). What all have in common is that they offer a native means of creating automation logic. If they didn’t, they wouldn’t natively provide much in the way of “automation” for home automation.
Making Node-Red the default automation engine is not without risk. It’s an entirely separate, independently-run, open-source project (and based on different technologies). Being independent, its roadmap isn’t tied to Home Assistant, openHAB, Hubitat, etc. Hitch your wagon to theirs and you may go in an unexpected direction.
Gutting Home Assistant’s existing automation engine and becoming fully dependent on Node-Red for that task would be a strategic mistake.
Agreed. But, when your template doesn’t work? How many {{ should I put? Your “printf” is “I was here at this moment”. What is useful too, is what is the value of this variable. And this one, maybe I am wrong it difficult to get…
I am not saying that NR should replace the native yaml automation.
For me, yaml, nodered and appdaemon should be the three official method for automation. Each one has its pros and cons. If I am being honest though, I can’t find cons in NR 
I am a heavy user of NR, in fact I do all of my automation there, and I definitely can think of some cons. Node RED should do a WTH month, I would have a lot to say lol.
But to me the biggest cons from HA’s perspective are these:
Node red is no easier than Yaml. Not a fan of the “Replace YAML with NodeRed for Automations” idea.
Almost forgot this, I completely agree about the missing debug however. Node RED’s Inject and Debug nodes as well as very clear definition of what is state in these flows is incredibly helpful, easily one of the main reasons I do my automation there. I made a WTH post specifically on adding an equivalent of the debug node to HA for that reason.
Talking of weirdness it is a close fight between JSONata and jinja2 
The WTH is about Home Assistant, not Node-RED.
Node-RED can be used with Home Assistant, but that is all third-party.
Nevertheless, thanks for suggesting, but closing this down for the above reasoning.