I have been running HA for more than 5years. I have Node Red installed with no flows.
I have yet to discover a use case for Node Red
3 Likes
You and me both.
I’ve never used Node Red but I have made extensive use of LabView, which is also a visual programming language. It gets very easy to lose overview very quickly with that. For simple things, and for people with no coding experience, it works well though. I’ve done some scratch programming with my kids, the visual programming is much better for them than text-based. Never used NR
I actually like the UI-based programming as we have it now, no worries about typos, syntax and indenting, and you can go to Yaml when you need it. I do really like the idea of having the ‘traces’ flow view available in the editor and being able to drag and drop into that.
Another thing that would solve a lot of beginner’s problems I think, is to include a set of 30 or so example blueprints for the most common tasks with the core. Blueprints, when well written, are so easy to use. And with the new ‘take control’ feature they are even better, you can change small things if you need to.
Some users are fine with the current UI, some users will find a flow editor of some kind easier to grasp. People are different.
I find it rather strange how religious this discussion is. There is no “better way” for all end everybody.
4 Likes
I’m with you on that one, masitito. It’s weird that people are so convinced that a feature is useless to them, that they believe nobody must have that feature. It’s a bit self-centered, if I’m honest.
If I may add my personal experience: I find the current automations UI a bit difficult to get into my head. A simple on/off scenario I have managed to create pretty well. However, once you’ve got a scenario where a set of lamps can have 5 different scenes, and a motion sensor, and it’s dependent on daylight, it get VERY complex VERY quickly. It feels like every “line” of related automations has to take into account every possible state from the other automations.
A flow would visualise such complex scenarios.
But, I guess another approach would be what Hue does: dumb it down to a single screen of input values that covers an entire flow - a switch, one or more participating lamps, different scenes, motion detection, a timer, whatever. Blueprint may be good for that, but then HA will need a lot more baked in blueprints, because I don’t see a novice user sifting through a billion and a half posts on the blueprint exchange (that’s probably a slight overstatement, but still). Just a few decent ones for an average person in an average situation.
2 Likes
Seconding. A graphical flow editor would have avoided me going into Node-RED, which is too low level for most HA automation work.Although, to be quite honest, I have to say that Home Assistance Automation Editor has improved enormously since I first picked it up back in 2022.
4 Likes
As someone that is IT smart but developer dumb, visual automation setups through Node Red have allowed me to actually make automations that work for my home. I can make them pretty quickly now, they are fairly easy for me to troubleshoot and keep up to date, and they work consistently if not as fast as a native automation. However the learning curve on Node Red is weird because it makes layout and connections easy but then requires you to know some of the underlying concepts (like service calls, properties, messages, etc.) which required me at least to spend a long time reading documentation. While the built-in automation editor is easy enough for very simple automatons, I am a visual person and trying to build anything more than “if this then that” simple automations I just can’t get to work well and I find them frustrating to troubleshoot then.
If the overall goal is to make Home Assistant more friendly for non-developers, the answer cannot be “go learn YAML”. My wife isn’t going to go learn YAML, nor are my parents, most of my co-workers, friends, etc. While I am comfortable enough following a guide to edit my config file to add specific functionality, and I can usually figure out what the edits are doing, the average user needs something simple and intuitive (always ask “can my SO or parents do this without help?”). Its why there has been such a focus on making integrations configurable from the UI and I see this WTH as a logical extension of that concept. Developers simply cannot assume that all of the various Home Assistant users out there think like developers or naturally grasp the fully text based automation editor that we have right now. Just because long time users are happy to configure their complex automations by hand in YAML doesn’t mean that is the right way to point “normal” users.
5 Likes
Who said that they believe nobody must have that feature? I think what most here are saying is: we don’t think this is the most useful thing to spend the precious time of the paid developers on, since there’s already an addon that does most of this pretty well, and they are already working on improving the current automation UI. On top of that, there is a lot more that those developers have on their plate which many of us find more important.
I don’t think anyone here has said ‘if some volunteer makes a PR with a fully finished flow automation editor that doesn’t break anything we currently have, it should be shot down because flow editors are evil’
That’s exactly what I’m saying.
I’m already annoyed with the PR process as it is. I will always disagree with any new feature that extends the time it takes to add features that I want, features that I contribute to the code base. Most of the areas that I contribute to are part of main HA core functionality. This means my PRs wait for a review from the core developers. Less time they have, the longer it takes to get PRs through to fix things.
It may sound selfish, but a feature like this is massive. It also really goes against the core meaning behind WTH. Typically WTH is meant for small quality of life changes. Not “Hey lets add a completely new automation system that will likely take years to complete”.
2 Likes
Nearing the beginning of this thread I saw people defending their take on absolutely NOT having this feature because they don’t need or like it, some in favour of Node Red. Sure, nobody literally “this is a bad idea”, but it’s wait I read between the lines.
But hey, I can’t help that a discussion feels like that to me, right? Maybe I’m a bit more outspoken about it, so I just wanted to say nobody should condemn new ideas right out of the gate just because whatever reason. And that was definitely happening the way I’ve read this discussion in its early stages.
Yeah, it does sound pretty selfish!
Even if a feature is “massive” it doesn’t automatically have to impact anything as long as it’s maintained as a separate project. This feels more like a political stunt because you don’t like the overall idea.
Says who?
It might not impact anything immediately, but once it’s been developed and tested on the Home Assistant instance of the person that works on it, it will have to be submitted as a Pull Request (PR). At that point, it WILL be competing for the time of those that have full access to the Home Assistant repository on GitHub to approve it.
I don’t think Petro is saying nobody should try and do it. He does seem to be saying to temper your expectations and be patient.
Says the description of what the WTHs are, you should read the pinned topic sometime 
Okay, where exactly is that? I can’t find anything mentioned in Month of "What the heck?!" - Home Assistant Community.
That’s your interpretation, definitely not mine, as you might see from my response.
Yeah, except Frenck did write this too:
And in the blog post literally one example is “HA voice hardware”. Don’t tell me that is a small quality of life change 
2 Likes
Given that the Home Assistant development team already laid the groundwork for Access Control years ago, I would expect Frenck to encourage people to give feedback on what they would like to see included. I also believe that they’d started doing that before the first year they had a Month of What The Heck, but I could be mistaken.
Right, is this shut down? No. That doesn’t mean it fits into WTH. Anyways, I can see y’all want to argue my standpoint and I simply don’t want to. Just take my comments at face value and discuss amongst yourselves. I’m not interested in debating, I’m just sharing my opinion. Especially seeing that some of you don’t know how to have a discussion without going into attack mode.
This will likely be my final post about this WTH.
I’d rather have:
- Access Control
- Template blueprints in the UI
- Automatically generated helpers inside automations.
All of those require core decisions and adding this wth will take away from those. I see no reason to add a graphical flow UI when you can use NodeRed. There is no alternative to what I listed above, and the work-arounds require alot of overhead to get done. Access control is has no work around aside from coding your own dashboard outside HA using websockets.
Just curious - who’s this development ‘team’?
So, is there a reason NodeRed can’t be the official graphical flow UI supported by HA?