Node RED VS Huginn

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/

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.

Myself, I'd probably prefer to use something like Huginn to create a customized approach to all of my online platforms I'm interested in, rather than a curated list.

https://github.com/huginn/huginn

I skipped to chapter 9 in the article ("Clogged"), and it looked like Pipes failed because it didn't have a large enough team or a well-defined mission. As a result they couldn't offer a super robust product that would lure in enterprise users. "You could not purchase some number of guaranteed-to-work Pipes calls per month" is the quote from the article.

The reason I think that interesting is because that's the model these days for everything from AI tokens to Monday.com seats. It makes me feel like Pipes was before its time.

That said I've been collecting different "business glue" products that are similar to Pipes. To me, like you say, they aren't as interesting, exciting and intuitive as Pipes was, but maybe it just takes a little more digging. I tried to focus on open source tools but some aren't.

- n8n io: https://n8n.io/integrations/mondaycom/

- Node-RED: https://nodered.org/ (just read about this one in this thread)

- trigger dev: trigger.dev

- automatisch.io: https://automatisch.io/docs/

- Activepieces: https://www.activepieces.com/docs/getting-started/introducti...

- Huginn: https://github.com/huginn/huginn

- budibase: https://budibase.com/

- windmill: https://www.windmill.dev/

- tooljet: https://www.tooljet.com/workflows

- Bracket: https://www.usebracket.com/pricing (just SalesForce <-> PostgreSQL)

- Zapier: zapier.com/

Anyway I hope some of these are fun!

"correct" is a value judgement that depends on lots of different things. Only you can decide which tool is correct. Here are some ideas:

- https://camel.apache.org/

- https://www.windmill.dev/

- https://github.com/huginn/huginn

Your idea about a queue (in redis, or postgres, or sqlite, etc) is also totally valid. These off-the-shelf tools I listed probably wouldn't give you a huge advantage IMO.

Huginn (https://github.com/huginn/huginn) has like some 39K stars on Github and the use cases it covered looks good.

Huginn is an another useful tool that allows you to wrangle CSS selectors and XPath nodes to create RSS feeds.

I use it quite successfully to get data out of undocumented APIs and out into RSS.

https://github.com/huginn/huginn

I know of Huginn that could be usefull depending on what you want to do.