StackStorm VS Node RED

Stackstorm

What differentiates this from things like n8n, node red, and stackstorm? (which sort of occupy a zapier replacement, IoT automation, and infra automation niche, respectively)

Network Automation is interesting topic, something like event driven automation would be cool. StackStorm is what comes to mind for a tool/resource.

StackStorm: Event-driven automation\ (17 comments)

StackStorm -- "IFTTT For Ops" I am investigating the different integrations to see if it can help automate some things.

GitHub: github.com/node-red/node-red

Ahh, you didn't create Node-RED editor. That's an external project.

https://nodered.org/

Node Red is a unique application that provides a graphical programming environment. With this, you can define input to output transformation with any level of complexity, including reading, parsing, formatting, and output with optional conditionals. For example, here is a flow definition that parses MQTT JSON messages that communicate if a node is alive, and then store this information in InfluxDB:

For a simple test, I created this Node Red flow that listens to homeassistant/status messages. HA itself will send messages that communicate when its started or when it is about to shutdown. These messages, and a custom message I send from within HA, could be seen:

Also check out https://nodered.org/ and https://github.com/huginn/huginn if you're interested in free and open-source software you can run yourself.

Node-RED (e-RT3) Flow-based, low code development tool

GitHub https://github.com/node-red/node-red GitHub Stars 19.1k Most Recent Update on GitHub 2 weeks ago Open Source License Apache 2.0 Number of Active Contributors This Year 13 Acceptance of External PRs Yes Official Website https://nodered.org/ Documentation https://nodered.org/docs/

Want a low code application for event-driven applications? Then Node-RED is your go to. The new update brings a breaking change, with Node-RED now requiring Node 18.x or later. The team have added new features and updated dependencies to the editor, and there are lots of fixes within the editor. Check out the release notes for all the details.

During a college project in the field of IoT, I came across a simple and powerful solution for wiring together hardware devices called NODE-RED developed originally by IBM. The project was very simple as it only involved controlling electrical appliances and sensing room temperature using a temperature sensor. The whole hardware system was connected to the network using the MQTT Protocol, and using Node-Red, it was just a few minutes of work to connect all sensors and respond accordingly.

Good question.

I expect that we're moving into a phase of AIs talking to AIs, and initially it'll be wasteful (because it'll be mostly English), but eventually, they'll derive their own language and seamlessly upgrade protocols when they determine they're talking to an AI. No clue how that will come about or what that language will look like, but honestly, it's kind of exciting.

Really interesting to think about how they might handle context, as well. Even though we have much bigger context windows (and they'll only get larger), context management is still a resource-management issue, which we'll probably continue to refine, as well. Imagine different strategies for managing both what is brought into the context of each request, as well as what form it could take (level of detail, additional references or commentary on it, etc). Things could get really unreadable even in English, and still be very interpretable for an LLM.

W.r.t. the graph-oriented interfaces, are you thinking something like Node-RED [1]? I'm seeing more and more people mention having LLMs produce non-text or structured outputs, like JSON, UI, and other things. Easy to imagine an LLM that wires together various open-source platforms, on-demand. Something like Node-RED for pipelines/functions, some UI tools for visualization/interactivity, other platforms for messaging, etc...

[1] https://nodered.org/