node-red-nodes is a catalogue of Node-RED nodes you install one at a time

A store of nodes, not a bundle

This repository is a collection of nodes for Node-RED, and the first thing the readme says about how to use it is that it is not a bundle.

All of these nodes are available as individual npm packages, and the README says to see the list for the npm package names or to search npm. This repository acts as an overall store for these nodes and is not intended as a way to install them, unless you really do want some development.

The package manifest says the same thing in a blunter form. The package is called node-red-nodes, its version is 0.1.0, and its description is that it is a Node-RED-nodes package to hold the test framework ONLY, with the instruction to use npm to install individual nodes.

So the repository has two jobs. It is the place where the nodes live, so that a contributor has somewhere to work and so the documentation has one home, and it is the test harness that runs the suite across all of them. What it is not is a dependency you add to your Node-RED install.

That distinction is worth understanding before you start, because the directory structure looks like a plugin bundle and the install instructions at the top of the file are about a single node, not about the collection.

Installing one node, or one from this repository

There are two installation routes, and the readme gives both.

The first is the normal one. Either use the manage palette option in the editor, or change to your Node-RED user directory and install the node package.

cd ~/.node-red
npm install node-red-node-{filename}

The second is for working on the nodes themselves. You cd into the nodes directory of Node-RED, then either download the zip of the repository and extract it, or clone it.

git clone https://github.com/node-red/node-red-nodes.git

Then you run npm install in any of the node subfolders to install that individual node's dependencies.

That last step is the one to note. Each node has its own dependencies, installed per subfolder, which is why a node for a specific piece of hardware can depend on a driver for that hardware without dragging it into every other node.

The install command is also where the naming convention shows up. The npm package name is node-red-node- followed by a short name that often differs from the folder name, as with node-red-node-badwords in 74-swearfilter, so the mapping is not mechanical, and the Extra Node Information table exists to make it explicit.

The hardware nodes are where the catalogue earns its keep

The hardware section is the longest part of the catalogue, and it is a list of specific devices rather than generic abstractions.

The Arduino node provides analogue and digital input and output nodes and uses the firmata protocol to talk to the board. The Beaglebone node does the same for the BeagleBone Black, and the Intel Galileo node covers the Galileo and the Edison through the mraa library.

Then there is a run of USB LED devices, with the Blink1, the BlinkStick, the DigiSpark RGB, the LEDborg for Raspberry Pi, and the Pi-LITEr, the Pibrella and the PiFace add-on boards for the Pi, plus a Pimoroni Unicorn HAT 8 by 8 display.

The Pi entries are the most varied, and each one exists because of a specific limitation. The pi-gpiod node is an alternative to the default Pi GPIO nodes that allows remote access, so a host machine can reach a remote Pi over the network, and it is better for driving multiple servos. The pimcp3008 node reads the MCP300x series of analogue to digital converter chips over the SPI bus. The neopixel node drives a strip of NeoPixels directly, and the unicorn node controls the HAT display.

The other hardware is equally specific. The Heatmiser node reads and writes temperature and frost protection settings on Heatmiser thermostats, the MakeyMakey node reads from the input device, the sensortag node reads the TI Bluetooth Low Energy SensorTag, the wemo node drives the socket and switch without using discovery, and the scanBLE node scans for a particular Bluetooth Low Energy device.

That specificity is the value and the cost. A node for the WeMo socket without discovery does exactly what the documentation says and nothing else, which is what you want in a flow, and it is also why there is a catalogue rather than a plugin.

I/O nodes for the network and the serial port

The I/O section is smaller and covers the nodes that move data rather than drive hardware.

The discovery node, under the mdns directory, discovers other Avahi or Bonjour services on the network. That is the node you use to find a printer or a media server on the local network without configuring it by hand.

The emoncms node posts to an Emoncms server.

The mqlight node sends and receives using MQlight, an example of the kind of integration a node catalogue accumulates over time.

The ping node pings a machine and returns the trip time in milliseconds, returning false if there is no response within three seconds or if the host cannot be resolved. The default ping interval is every twenty seconds, and it is configurable. The behaviour of returning false rather than throwing is the Node-RED convention, since a flow should not die because a host is down.

The serialport node sends messages to and receives messages from a physical serial port, and it is one of the most commonly used nodes in the catalogue for anything with a device attached to a USB or a Pi GPIO header.

Function and analysis nodes, and the sample node

The function section is the pure computation part of the catalogue, and the nodes are small by design.

The datagenerator node can generate dummy data in various formats, including names, addresses, emails, numbers and words, which is what you use to build and test a flow before the real data source exists.

The PID node is a PID control node for numeric inputs and provides a simple control loop feedback capability. The random node generates integers from x to y, or floats between them. The rbe node provides report by exception and deadband or bandgap capability for simple inputs, which is how you filter a noisy signal so a flow reacts to changes rather than to every sample. The smooth node provides various functions across several previous values, including max, min, mean, and high and low pass filters.

The analysis section has two nodes. The swearfilter analyses the payload and tries to filter out messages containing bad swear words, and it only operates on payloads of type string, with everything else blocked. The wordpos node classifies the part of speech of each word and adds msg.pos to the message, where a word may appear in several categories, since great is both a noun and an adjective.

And there is the sample node, listed as N/A for the npm name, described as a sample node with more comments than most to try to help you get started without any other docs. It exists to be read, and it is the first thing in the table because that is what it is for.

One test harness for every node, run with Grunt

The testing section is short and it explains the repository's real purpose.

Node.js v6 or newer is required, and to run tests on all of the nodes you need the node-red runtime.

npm i node-red-nodes
npm test

The test script in the manifest is grunt, and the development dependencies are where the testing story lives. There is node-red itself at 4.1.8, and node-red-node-test-helper, the library the Node-RED project provides for testing a node in isolation. There is mocha as the test runner with should and sinon for assertions and stubbing, and proxyquire for injecting dependencies into a module under test.

The rest of the list is the union of what the individual nodes need, and that is the point of a shared harness. exif and mailparser and imap and node-pop3 and nodemailer and smtp-server for the email nodes, feedparser for the feed node, markdown-it for the markdown nodes, msgpack-lite and ngeohash and sentiment and multilang-sentiment for the data nodes, and pushbullet for the notification node. All of them are devDependencies of the test harness, which is what lets one command run the suite across every node in the collection.

The overrides block is worth a look too. utf7 is pinned to semver 5.7.2, lodash to 4.18.0 and minimatch to 3.1.5, which are transitive dependency pins applied across the tree, the kind of thing a project adds after a dependency advisory affects one of its nodes.

The linting is similarly old fashioned and appropriate. There is a Gruntfile.js at the root, a .jshintrc and a .jscsrc, and the grunt configuration runs jshint, jscs, an inline lint task, and the simple mocha task.

Apache 2.0, a long silence, and a maintained repository

The copyright and license section is short. Copyright JS Foundation and other contributors, under the Apache 2.0 license, with the LICENSE file in the repository.

The package manifest agrees, with license set to Apache-2.0, and the licence file in the repository listing is the one GitHub cannot classify, which is a discrepancy to check if you are looking for a clean automated licence detection.

The release history is the odd part. The recent releases are 0.8.0 from 2014-06-25, 0.7.0 from 2014-04-16 and 0.6.0 from 2014-02-21, all of them milestone releases, and those are the last tags. So this repository has not published a release in over a decade.

That does not mean it is abandoned, and the distinction matters here. The repository is not archived, and the last push was on 2026-10-04, so the nodes are still being worked on. What has stopped is the versioned publication of the collection as a whole, which is consistent with the design, because each node is published separately on npm and the collection is only ever a store.

The contribution guidance reflects the same split. Now that npm installation of nodes is supported, the project recommends people post their own nodes via npm, and points at the packaging guide. For simple typos and single line fixes, just raise an issue. And for a pull request, read the contribution guidelines first.

Editorial conclusion

Adopt individual nodes from this catalogue when you need one specific capability, a hardware driver for a Pi or an Arduino, or a PID loop, and you can take the dependency per node. Do not install the repository as a whole, because the package manifest describes it as holding the test framework only, and the readme says the repository is not intended as a way to install them. Verify first which npm package corresponds to the node you want, since the names and the directory names differ, and check the node's own dependencies, because the catalogue's own manifest is a test harness and does not describe what each node pulls in.

Frequently asked questions

Official sources

1. Issues
2. node-red/node-red-nodes on GitHub
3. README
4. Releases