WTH: NodeRed as native automation platform

Archive Month of "What the heck?!" (2020)
1

Let’s face the truth: yaml sucks.
Saying that I’m not trying to convince anybody that it doesn’t work. Of course it works. I expect users with years of experience will postulate for it.
But the truth is it is not easy to use, not easy to read, not easy to debug, is scattered across templates and automations and finally is pretty limited (we can saw it recently when new feature, basic for other languages met yaml).
I would forget: It has editing support if you can install VS plugin. But this plugin works only on HA 64bit which still remains to be not recommended build. LOL.

Long story short: yaml IS NOT programming language. But HA offers it to program automations.

What about idea, to make NodeRed official, native automation platform?
It’s easy to use, has embedded ‘normal’ programming language (Javascript) it can even spawn/remove sensors without need of HA restart (which is not achievable by HA itself).
It has native support for MQTT which allows to listen/send to MQTT changes without need of creating sensors.

Are there any arguments against?

2

You think node-red is easy :rofl:.

But, fair point, I love node red too.

3

Biggest argument against nodered: flowchart programming.

1 Like
4

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.

5

That is your opinion, not truth.

10 Likes
6

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.

1 Like
7

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

8

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.

4 Likes
9

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)

10

I forgot nothing. You configure the trigger, conditions and actions of an automation.

11

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.

2 Likes
12

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.

2 Likes
13

I have almost the opposite impression :slight_smile:
I started using node-red soon after I have started with HA (almost two years ago now) for two reasons:

  • I never really managed a proper way to debug automation in yaml. Whatever programming language you use, the first trial usually fails and then you start adding “printf” or the vernacular version of it to debug. There is no printf in yaml. So, why this f… automation is not working as it is supposed to :slight_smile: How to debug? I could post for help on the forum, but, I am more on the DIY side.
  • I am an old linux user and I can’t live without cron. Repeating something on Tuesdays and Thursday every 30 minutes of odd hours from 9 to 23, is a one liner in cron. How many in yaml? And yes, I have almost this kind of usecase for some ventilation inside my house.
14

I use a service call to persistent_notification.create (or to the log). Works for me.

1 Like
15

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) }}"
2 Likes
16

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.

4 Likes
17

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 :wink:

1 Like
18

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:

  1. There’s a steep learning curve to Node RED. There’s so many tools available and each one is filled with features and settings. Plus to a non-programmer many of the terms and names are unfamiliar. People generally do a decent job with documentation on those nodes but they’re still complicated and theres not nearly enough relevant cookbook examples for home automation. NR doc itself is also quite large.
  2. Node RED is often just programming. It’s tough to find examples without either JSONata or function nodes. Function nodes are literally a box to put Javascript. And JSONata is just weird, I’ve gotten used to it but I will never like it. It’s not even templating either, its just like another programming language for some reason. EDIT: Oh right and they also have mustache templates in places, almost forgot about that. They really need to make up their mind on that front.
  3. As mentioned several times now, HA team has no control over the design/dev/roadmap of Node RED. So integrating it further then it is and making it an intuitive part of the experience is difficult or impossible. The target audiences of HA and Node RED overlap a lot but aren’t the same and HA team can’t do anything to change NR to better target their audience.
19

Node red is no easier than Yaml. Not a fan of the “Replace YAML with NodeRed for Automations” idea.

20

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.