What are the flaws of Node-RED? The areas that you plan (or hope) to give many, many necessary love somewhere in the future?
What is something people use the software for, where you would say they should not do this?
Node-RED seems so far optimized for IoT and online services. Is there any ability (or plans for them) to use it locally for desktop-automation, similiar to AppleScript & Automator on MacOS, shell & batch-scripts, Selenium for websites, Tasker on android, etc.?
How would you see the state of the project generally and feature-wise ? Is it still growing for the next decade? Or has it reached it's peak and will move to settle down at its optimum somewhere in the next years? Should it reinvent itself every some years and stay fresh and adapting?
(Node-RED project lead here) Some great questions, and not necessarily short answers.
> What are the flaws of Node-RED? The areas that you plan (or hope) to give many, many necessary love somewhere in the future?
It works really well as a single user system. One of the areas I really want to improve is the multi-user/collaborative features available in the editor.
You can certainly have >1 users editing the same flows in parallel, but you do end up having to merge back in each other's changes. That user experience isn't ideal.
I'm also keenly aware the documentation and getting started experience needs attention.
> What is something people use the software for, where you would say they should not do this?
I wouldn't tell someone not to use the project if they had found something that worked for them. As with any solution, you need to make sure it satisfies your needs and requirements.
I would say you need to acknowledge the limits of the system - partly born of the single-threaded nature of the underlying Node.js runtime.
> Is there any ability (or plans for them) to use it locally for desktop-automation, similiar to AppleScript & Automator on MacOS, shell & batch-scripts, Selenium for websites, Tasker on android, etc.?
It isn't something we're thinking about in the core of the project. But the project is designed so that this could all be done via 3rd party nodes created and shared by the community to integrate with those tools. In other words, this sort of integration could be done by anyone - it doesn't have to be the core project that does it.
> How would you see the state of the project generally and feature-wise ?
There's always more to be done.
> Should it reinvent itself every some years and stay fresh and adapting
There's a risk for all software projects that continually reinvent themselves that they sacrifice their existing community in search of something else.
A core principle we have is stability. That doesn't mean stagnation, but it means evolving in a considered way that brings the community with us and doesn't leave users stranded because they depend on something that has since been 'reinvented'.
I can on reply from the perspective of a multi-year user:
It is primarily functional programming. This means, you have an input, that is processed through blocks (functions) and does some things.
This is GREAT for things similar to IFTTT (If this then that) applications. E.g. you receive a datagramm via MQTT, and then format it, add some info, and upload it into influxdb.
You can also easily add a small dashboard with some buttons and labels for easy home automation.
What needs some working around with context store are side effects, or persistance. I have two examples that can be worked around, but are rather hacky:
1) Reading a list from a homepage, and only sending updates for new items. This is the prime example for context - you save a list of seen items in the context of the function node, so the next invocation can filter out the existing ones
2) Using a switch in the dashboard for selecting between automatic and manual mode. E.g. I want to have my rack fans controlled by the temperature, but with an override to set it manually. This needs a bit more hacking with context where you have two flows into one node, and you have to set the internal state of the context depending on the override button.
my use of it for hobbyist projects helped me get my foot in the door for my current employment in automation and controls.
I have multiple instances of it running to track various things, run my chicken coop door, send alerts, aggregate data... It's uses are endless and I enjoy the puzzle of using the new updates to the software to make my old flows better.
I'm a big Node-Red fan, been using it for years to automate and do lots of neat things. One problem I kept coming back to was trying to create dynamic urls for websockets. I'm curious if that might be on a future roadmap for Node-Red?
IOT guy here, I like node-red but never dare to run it on edge device to perform ops on critical infrastructure. what is the state of the project? prototype only or business ready?
(Node-RED project lead here) It is not at all limited to prototyping. There are an ever-growing number of companies incorporating Node-RED in their own products and services - you can see a list of some of them on the project homepage.
They span a wide range of industries and technology areas. Quite a few are industrial controller companies who include Node-RED on their commercially available edge devices.
How do you feel Node-RED stacks up against products like Boomi, MuleSoft, SnapLogic, etc., and is competing with those iPaaS vendors something you want to do?
(Node-RED project lead here) Node-RED is an open-source project and part of the OpenJS Foundation. We'd certainly aspire Node-RED to be comparable at a technical level with other offerings.
But as an OSS project, we aren't looking to create a hosted SaaS offering - the core project isn't trying to compete commercially with those vendors.
But there are companies looking to create commercial services around Node-RED that certainly want to be competitive. (My own company, FlowForge Inc, is one of them)
I want to thank you and the team for developing and improving this project. I used it early on to prototype a system based on Raspberry Pi's and AWS. It is very easy to build on and the library of integrations is great.
I’ve been looking at building an auto remediation system for server alerts, is Node-RED a decent system for this? It will probably start with just triggering some kind of ssh command to run a script.
I'm not an NR user yet but I've implemented my basic Home Assistant set up and plan to begin using NR extensively as I evolve my home automation beyond "Hello World".
(Node-RED project lead here) There are a few nodes for dealing with swagger in Node-RED - either generating Swagger doc for your HTTP end points, or on the client side to make it easy to interact with a Swagger documented API.
If you're looking for something that can take a Swagger/OpenAPI doc and generate a stubbed-out set of flows - that would be a neat idea. Sounds like a cool project to create as a pluing.
I use Node-RED in combination with home assistant, for automations.
It's sometimes overly complicated to follow the flows, or do something relatively simple, but otherwise it's a nice middle ground between built in YAML based automations, and something like AppDaemon which requires writing python scripts.
The new UI editor is a better experience than yaml, but still has limitations that make node-red valuable for more complex automations. In particular juggling timers, state, and Boolean conditions with HA automations can be kind of awkward as they require you to coordinate across multiple automations, but very easy in node-red.
All in all I use both. I use the native ones for simpler automations (exterior lights on at dusk, blinds up at sunrise, etc.j and node red for the complex stuff (bathroom fan on for 5 minutes unless if the door is closed or the humidity is above 65%, turn off two minutes after the door is opened and the humidity is below 60%j.
I find myself prototyping automations in Node Red before "productionising" the code in YAML. It's great for visualising flows but nothing beats automations running directly within HA. One fewer service to crash.
Even when you know how to script up automations, I still find Node Red invaluable for visualising and rapidly prototyping complex logic before you write a single line of code.
Plus, it is the perfect accompaniment to Home Assistant.
If you're interested in something more generic, check out if https://enso.org could be worth a look! Thanks to GraalVM, you might be able to import JS packages too, among others (Java, Python, & more...); OTOH with the caveat that the project is still in ways in-dev...
Hm, honestly, this was kinda precautiously overly-defensive statement from my side. I mean, I'm also following Luna/Enso with huge interest, but it's kinda on-and-off for me; it seemed to me to still have some rough edges in the GUI last time I checked, but also it was quite long ago already - somewhere right around their 2.0 public announcement, in January 2021. No slightest idea at what state the GUI is now, or the libraries; haven't had time to approach it again since. But I expect to do that quite soon.
My friend uses Node-RED to automate and run a lot of devices/things in his van (which he lives in). I'm not sure if it's better to not have a programming background, because it's one of the more difficult environments I've helped someone with and the debugging when something wasn't working was really poor, it all felt very un-intuitive.
Yeah node-red really rocks.
Maybe I am biased as a particularly visually oriented person but i really enjoy the ease of prototyping with nodes and flows. I cannot help but sense that they may become more commonplace- there are applications for embedded sensing and data pipelines where it helps to think less in packets and more in streams or currents... also great for mocking up a synthesizer which I did with Paul Stoffregen's super rad audio tool for teensy/ARM : - )
https://www.pjrc.com/teensy/gui/
I have just been going through a HELL of a time building a web-based app ("PWA" in progressive lingo) that needs to auto-discover certain devices on the user's LAN. This is a rebuild of an existing AIR-based app that's been in use in a corporate setting for 10 years and needs to be replaced because "death of flash". The AIR app I wrote back then handled discovering the local devices fantastically well. The problem now? Mixed-origin blockades. I can't get into all those devices and routers in each location to set up local DNS servers and maintain certificates. So the connection from the ultimate app to the local node has to be unencrypted. But this means the only answer to a web-based discovery app is to have it be served over HTTP as well.
Interesting thing google missed when trying to prevent people from doing this exact thing with PWAs: If you have a valid manifest and service worker, Chrome won't run the service worker if it's not served over SSL, but it WILL include the app name and icons and let you save it to the home screen on Android; it will even cache a good deal of what you intended.
For auto-discovery, I used a fuckton of hidden iframes loading asynchronously and waiting for any window.postMessage that matches what I want from a local device.
Seriously, Google has made my life fucking miserable as a solo dev. They don't want anyone to be able to write an IoT app without going through them.
There are fantastic reasons why it should not be allowed on random local devices, unless the local device is configured with some sort of authentication... but the problem now is that total ban on accessing local devices from a secure web app is a serious choke point for anyone trying to develop something to control appliances outside the walled garden.
Fascinating discussion here with a Plex dev expressing similar frustrations with the general direction of these context barriers... which in their case affects millions of users and threatens to pull down their entire platform. Their solution currently is bizarre; they actually have to hijack DNS resolution and issue SSL certs on the fly for each of their users' servers to allow their web app to connect to a local node. Not possible in my smaller corporate sphere.
Valid question. The devices are in shops all over the country and should be able to run autonomously. I don't want to get into the business of remotely managing those machines, setting up certificates and DNS on each one, especially since I have no control over the routers in the shops. Supporting the app is hairy enough without trying to do tech support for each shop's network issues.
We're a industrial-control company whose traditional UI has been standard win32 applications - we've slowing converting our stack over to a web interface but as our UI needs to talk to lots of local devices, we've hit the problems you described.
Our solution has been to basically mandate that the user install either a small embedded device (ie. RPI or equiv) or manually launch a container. These essentially just serve as a local websocket / api router so Chrome connects to some local "device/container" and then that connects to all the local devices.
Although this is a logistical hurdle, its actually simplified other aspects of development since now this device/container has a bit of intelligence and can act as real middleware to simplify what the UI needs to contemplate. Basically MVC-style development using hardware bits as Controller.
That's cool. I guess our problem could be described as allowing non-technical users to control the in-shop devices from an app on their phone (both android and iOS) without knowing the local IP at all. Like, how do we determine the shifting dynamic IP of our in local routing system from an app served from the cloud ...and the answer unfortunately is we can't. We have to serve the app locally in each facility.
* Local RPI / Container connects to message queue in cloud
* Web User inputs request to Web UI (cloud)
* Local RPI / Container retrieves request via queue and access final device
* Reports status back to queue which is then reported by Web UI
Basically the local device is your router using whatever message queue you want.
React Native and (maybe) Electron are nice if you need access to real networking but want to write webtech, and can afford to impose somewhat on your end user. Browsers (very much rightly, IMO) lack a lot of handy stuff for local device discovery, including, notably, all of UDP.
What do people automate at home? I genuinely have never thought to have the need to buy a home assistant but apparently lots of people in this thread do
Lights are the most obvious use case. Done right, you may almost never have to touch a light switch again.
In my house, the central lights turn themselves on when it becomes too dark (except after bedtime), and off when it becomes too bright. Lights turn on automatically when someone enters a room (when it is dark) and turn off when they leave.
When the last person leaves the house, all lights go out, except when I am on vacation, in which case the lights turn themselves on and off in a pattern that looks like I am at home.
After lights come extractor fans (keeping the humidity constant) and heat/air conditioning.
It is all about maintaining a comfortable home environment without having to manually turn things on and off all the time.
I wish I could figure out how to de-automate my bathroom light. It tends to wrongly notice that I've left the room leaving my in total darkness. My workaround is to leave the light on in the adjacent closet, which, for some reason has no such amenity. I doubt a lifetime of saved button pushes would ever make up for the inconvenience of troubleshooting this not-quite-smart-enough light system. But other people have different utility functions.
This is the thing that’s kept me from pursuing home automation: the advantage of automating lighting (or anything else) is completely negated the moment something goes wrong, because you’ll spend more time debugging than you ever did flicking the light switches in the first place.
I've been very conservative in uses of automations like that. A couple ancedotes:
The outside lights on the front of my house have a motion sensor. Alone, they turn on to about 50% at dusk, and off at 11:30. If there's any motion between dusk and dawn, they go to 100%, then eventually fade back to 50% or off depending on the time. They also come on (and stay on) at 100% if the garage is open. End result: they are at 100% when useful, and otherwise at 50% don't (annoyingly) shine as much into the front windows.
I also experimented with turning down the kitchen lights when there's no motion. The effective of this was described to me as "What did you do to the kitchen lights?! They just randomly turn off and it's driving me crazy!" -- even not in the room, the lights in an adjoining room turning off unexpectedly was bad. End result: Motion controls removed.
There's also some simple time-based controls. If no lights have been manually adjusted recently, at dawn a couple lights come on (to make it look like someone's home) and likewise turn off sometime later at night. There's also an absolute off at 3am, and again at very early dawn. These have the effect of never coming home to a dark house and never leaving lights on all night.
The best automations blend in so you don't even notice them. But absolutely make sure humans can still control things, and don't do things that interfere with that control or expectations.
The only thing that's tempted me when it comes to automation is whole-house light dimming past a certain hour. But AFAIK that would require buying a whole bunch of really expensive bulbs (or, otherwise, re-wiring a bunch of stuff), so I've passed on it for now.
If you get used to candle or other low-power nighttime lighting, typical house lighting seems obnoxiously bright. I'm convinced it's a major contributor to the sleep troubles that, it seems, nearly everyone in the modern "West" has. It's way more light than you need to get around, play board games, play or listen to music, read, et c. It's like we're trying to make our houses as bright as they are in daytime, which seems like it'd have to be really bad for sleep.
I'd just put dimmer bulbs in all around and forget about automation, but I kinda do want the daytime-like brightness for at least 2-3 hours after sundown, in Winter, or the option to turn it back to full brightness if I've got people visiting and they don't like it (it's not that way so you like it, it's that way so you get sleepy when you're supposed to—but whatever)
There was a similar use case I read about here on HN that interested me: using color-changing bulbs to shift the color tone of all lights in the house from cool during the day to warm at night. But, as you mentioned, it would be pretty expensive to replace every bulb in my house, so I haven't considered it. Maybe when I start running out of spare bulbs I'll think about implementing this.
It's not completely negated, depending on the case.
The kitchen in the place I rent has this island (its more like a peninsula) that just barely makes the light switch for the kitchen out of reach, so instead we have to walk around the way around.
Obviously a manageable situation, but automating things has been a covid hobby. So I automated the lights, obviously, via replacing the light switch and added a motion sensor to the kitchen wall. There's also an echo dot for voice control.
Walk into the kitchen, lights turn on, eventually they go off. If they don't go on, just say "alexa turn on kitchen" and they go on, motion detector eventually picks up and turns them back off.
Use the light switch, and it disables the motion sensor for an hour and just leaves the lights on, or off, whichever direction was pressed.
Time saved for everyone not walking back and forth, also at night, has definitely been greater than time spent for me debugging.
I am working on having my phone alarm slowly open my curtains in the morning.
Unfortunately automating normal curtain opening is pretty tricky mechanically. It was easy to get as far as "Ok Google, open the curtains" -> stepper motor moves. But connecting the stepper motor to the curtains is tricky. I think that's why smart blinds are way more common.
Recently discovered that you can build simple api style end points with it.
Eg built one that tries resolving an ad domain to check if ad blocking is functioning correctly and publishes that as a end point that is suitable for an uptime dashboard
Is anyone using the node-RED ecosystem to deliver end-user customization of their not-home-automation product/service?
I’m looking for ways to offer practical/accessible low-code (or not considered scary code) composition for our internal users who are running light industry factory production lines, but open to learning about commercial applications in any field to draw inspiration from.
We're (extremely early days into) looking to use NodeRed to provide customised configurations for a fleet of telegraf agents.
Telegraf has the ability to phone home and ask for its telegraf.conf as it starts up, but the server-side of that equation is frustratingly left as an exercise for the reader.
There's not many ways to skin that particular cat, which is odd and unsettling in its own way.
I am personally not a huge fan because my brain is not wired to do visual programming.
I have Node-RED installed and running alongside HomeAssistant, but I never use it because automations that are easy to do in NR are just as simple to create directly in HA. Automations that are complex enough to need NR are easier (for me) to code and debug in Python.
I think NR is great for non-programmers and maybe for quick prototyping, so I am not disparaging it in any way. The functionality and implementation is excellent; it's just not for everyone.
I didn't dislike node red, but it didn't really fit my use case well. I wanted to use it as a REST service to write APIs for clients to use to generate reports from our various databases. Basically a low-code data pipeline from cassandra, mongo, sql, etc. It worked...but things like switching git branches while keeping things running, updating the service, aggregating results, etc, were difficult. More difficult than just writing the code.
I wrote one then never used it again opting for node instances inside of our Kubernetes cluster instead.
It does (everything is saved as json), but it's a bit of a hassle. Scripts are saved to a single line, so you really need a plugin that breaks them up. It's really pretty silly that isn't the default.
The other huge PITA is that touching a node in the UI causes the json to update even if you didn't do anything, and changes will often cause nodes in the json to reorder. That makes git commits very cluttered.
Merging is also very hit-or-miss and duplicate nodes are common. You can mostly fix this with another plugin that saves flows to individual files instead of one big file (default). As long as you split your flows and subflows up enough, team members will usually not step on each others toes.
I used this at work. Not a fan. If you only touched the system once every 4 months I can see the usefulness- It's easier to see the overall structure than wading through code, particularly if you're a visual person. It makes it relatively easy to pick something up that you have mostly forgotten.
It is a huge PITA if you are trying to build API features quickly with a team. Especially if there's nobody to tell you to use the plugins.
It originated in that space, but the ecosystem has taken it in very different directions. It has lower-level abstractions than n8n (which focuses on automating third-party SaaS), but can arguably do the same.
I've used it for an insane amount of things, starting with home automation and telemetry but also fairly sophisticated uses, including:
- Sniffing for multicast streams on a LAN and exposing IPTV set top boxes as HomeKit devices
- Automating image conversion and video transcoding
- Building an RSS aggregation and transformation pipeline that does translations, scraping, etc.
- Building a simple GUI for managing backup snapshots and batch file copies
- Monitoring Azure deployments (and exposing the data as simple dashboards).
- Doing App store price checks and sending Pushover notifications when an interesting app goes on sale (backed by SQLite).
- An embarrassing number of Slack and Telegram bots for various user groups/events/etc.
As a general rule of thumb, Node-RED can do pretty much any kind of automation you can get a REST API for, and quite often someone out there has already built a module for it.
I think of n8n more along the lines of a graphical workflow/BPM tool for SaaS, but with much less flexibility/ability to go "low level".
> - Building an RSS aggregation and transformation pipeline that does translations, scraping, etc.
About how many feeds are we talking here? One per hour? Ten? Some hundred? I've thought at some point doing similar, but was not sure whether node-red or similar tools would perform well enough with this kinds of jobs.
thanks for listing all of these examples... i really like node-RED, and wrote up a tutorial on it a few years back, but have never actually reached for it to solve a real problem. you've given me some ideas!
Essentially you can use Node-RED to either act as another HomeKit bridge or to handle MQTT events from homebridge itself (I chose the latter).
You can easily "fake" and inject new accessories into homebridge via the homebridge-mqtt plugin (which allows you to dynamically add accessories and "see" them in MQTT).
I use node-red for Escape Room game high level automation. Gathering data from all the puzzles (over CANbus and mqtt), displaying game state for game masters, fallback control, audio+light sequences, etc
Erm. You can't run Node-RED on those, the NodeJS runtime alone would eat three times the flash storage. You can _talk_ to them, though, from a more powerful system.
Sorry I meant in concert with. I run node red on a raspberry pi and then send it stuff from the esps. My brain was thinking the right thing and my fingers didn't type it. You're absolutely correct.
Huge fan of huginn, I've started running n8n and huginn on the same box recently. Some of the huginn modules are a little more work to use with common SaaS offerings. I'm hoping together they can cover basically everything I want, although I don't do any home automation.
