# RedMatic: Node-RED running on the Homematic controller itself

> RedMatic packages Node-RED as an addon for the Homematic CCU3, openccu-lite and OpenCCU, so a home automation user can build flows without touching Linux, and its version 9 line moved to Node.js 24 and Node-RED 5 while dropping the RedMatic web app. It suits installer-facing automations, and the removal of the package manager and the no native dependencies rule both narrow what you can do on the device.

**rdmtc/RedMatic** — Node-RED packaged as Addon for Homematic CCU3, openccu-lite and OpenCCU 🤹‍♂️

- Repository: https://github.com/rdmtc/RedMatic
- Stars: 528 · Forks: 48
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/rdmtc-redmatic

## What RedMatic is: Node-RED installed on the controller itself

RedMatic packages Node-RED as an addon for openccu-lite, the Homematic CCU3 and OpenCCU, which the README notes was formerly called RaspberryMatic. An addon is a software package that can be installed comfortably through the web interface of the device, and the point of RedMatic is that this particular software package is Node-RED, the flow based programming environment.

The base is Node-RED together with the CCU nodes for Node-RED, node-red-contrib-ccu. With them it is possible to implement rules, automations, scripts and connections to external services and systems for a Homematic system, and largely without programming knowledge. The wiki linked from the README holds more about Node-RED and a set of application examples, the flows.

The deployment claim is the other half of the pitch: setting up and operating RedMatic is very user friendly, it requires no Linux knowledge and no configuration files need to be edited. For the audience that matters, a Homematic installer who would not otherwise run a Linux shell, that is the difference between a project and a tool.

The repository is under the rdmtc organisation, the primary language is JavaScript, and the licence is Apache-2.0. The author named in the package manifest is Sebastian Raff. The last push to the tree was on 2026-10-16, and the newest release is v9.13.1 from the same day.

## RedMatic 9: Node.js 24, Node-RED 5, and a package manager that no longer exists

Version 9 was a large change, and the README summarises it as radical slimming and modernisation: Node.js 24 and Node-RED 5. The details matter for anyone upgrading.

From version 9, only node-red-contrib-ccu is preinstalled. Every other node, including the Dashboard, HomeKit and Matter nodes, is installed on demand through the Node-RED palette manager. The RedMatic package manager and the RedMatic web app are deprecated and have been removed without replacement.

That is a real loss of convenience, not just a refactor. The removed web app was the graphical place where those integrations were configured, and its replacement has to come from elsewhere. The README names it in the flow of a later project: feezal builds dashboards and apps for MQTT visually in the browser, with a WYSIWYG editor, web components, a PWA and export as a static page or an Android or iOS app, and it recognises the devices RedMatic reports through auto-discovery and wires them up with one click, described as a modern replacement for the removed RedMatic web app.

The migration has a hard prerequisite and a hard warning. The prerequisite is a CCU3 with firmware from 3.61.5 or a current OpenCCU. The warning is about the upgrade path from RedMatic 7: make a CCU backup first, and the README is explicit that the backup is the user's responsibility, that there is a way back only through that backup, and that the release notes for the RedMatic 9 migration should be read first.

So the 9 line is not a drop-in upgrade. It is a reinstall with a one way door behind it, which is why the release notes are the first link in the warning.

## The CCU limitation that shapes what you can install

The README states a known and accepted limitation, and it is the one that will shape an installer's day.

npm packages or nodes with binary, native dependencies cannot be installed on the CCU. The reason given is that there is no compiler toolchain on the CCU, and precompiled binaries are no longer shipped.

That is worth understanding rather than just noting, because it is a property of the target hardware and not of the packaging. A node that needs a native addon has to be compiled for the device's architecture, and the CCU has no toolchain to do it with. The RedMatic 9 answer is that such packages are simply not available, rather than that they fail at install time.

It also explains the build matrix in the package manifest. The addon itself is built for three architectures, and the build scripts take the architecture as an argument.

```json
  "scripts": {
    "build": "./build.sh",
    "build:armv7l": "./build_addon.sh armv7l",
    "build:aarch64": "./build_addon.sh aarch64",
    "build:x86_64": "./build_addon.sh x86_64",
```

The `armv7l` target is the classic Raspberry Pi, `aarch64` covers the newer 64-bit ARM boards, and `x86_64` covers a virtualised or x86 installation of the CCU. The same file also holds a general `build` entry that runs `build.sh`, and the package manifest records the Node runtime the addon expects.

```json
  "engines": {
    "node": "24.22.0"
  },
  "dependencies": {
    "node-red": "5.0.8",
    "node-red-contrib-ccu": "4.5.3",
    "npm": "11.21.1"
  },
```

The dependency list is where the pinned versions live. Node-RED is pinned at 5.0.8, the CCU node collection at 4.5.3 and npm itself at 11.21.1, alongside bootstrap, jquery, bcryptjs and the Font Awesome free package. Pinning in the manifest rather than floating is what makes a reproducible addon build, and it also means an addon release is tied to a specific Node-RED major version.

## How RedMatic talks to the CCU: one subscriber, BIN-RPC, loopback only

The README explains at length why the integration runs on the CCU rather than in a separate bridge project, and the reasoning is about the controller's internal processes rather than about convenience.

The interface processes on the CCU, rfd, hs485d and HmIPServer, react sensitively to many concurrent RPC event subscribers and to network disruptions. RedMatic bundles all the connections into a single subscriber per interface, speaks the more efficient BIN-RPC instead of XML-RPC with rfd and hs485d, and keeps the entire RPC traffic on the loopback interface of the CCU, so network outages never reach the CCU processes at all.

That is a specific engineering claim with three parts. One subscriber instead of many means the internal processes are not each maintaining a separate event stream, which is where the sensitivity comes from. BIN-RPC instead of XML-RPC means less data on the wire for the same information, which matters on a device with limited resources. Loopback only means the transport between Node-RED and the CCU processes is not exposed to the network, so a flaky Wi-Fi link or a switch reboot cannot cause the interface processes to misbehave.

The other half of the design is that a single `ccu-connection` carries everything, and it is opt-in: the devices selected on the CCU are released to it by a tick. One connection, one set of released devices, and every integration on top of it.

The alternatives are named, which is what makes the comparison concrete. The README points to good alternatives such as CCU-Jack, openccu-loom and matterbridge-homematic, and then explains why RedMatic is different. The difference is not that those projects cannot do the job. It is where the RPC traffic goes and how many subscribers the CCU's own processes have to serve.

## The bridge surfaces: MQTT, Home Assistant, Matter and HomeKit

RedMatic is described as a good way to connect a Homematic CCU to other systems, directly on the CCU and without an additional server, and the README names the four targets explicitly.

MQTT is the base. The ccu-mqtt node publishes all data points with a freely configurable topic and payload structure and accepts commands, with an example flow in the wiki. Home Assistant is the ccu-homeassistant node, which extends ccu-mqtt with MQTT auto-discovery, so selected devices appear automatically as entities in Home Assistant. Matter is RedMatic-Matter, which exposes Homematic devices as a Matter bridge, usable with Apple Home, Amazon Alexa and Google Home. HomeKit is RedMatic-HomeKit, which exposes Homematic devices as HomeKit accessories, and the README describes it as a possible addition to Matter for Apple users who need to work around missing Matter support for certain devices such as garage doors or irrigation systems.

The install paths differ, and the distinction is practical rather than editorial. Matter and HomeKit are installed through the Node-RED palette manager, while MQTT and Home Assistant are already included in the preinstalled CCU nodes.

Two related projects by the same author sit on the far side of the MQTT bridge, and both understand RedMatic's auto-discovery data directly. feezal is the visual dashboard and app builder described earlier. she is a Smart Home Engine where automations are plain JavaScript scripts with MQTT, an integrated Matter controller, a scheduler and a web IDE with an AI assistant, aimed at people who prefer writing logic as code rather than as flows, or who want a central engine away from the usual suspects such as Home Assistant or ioBroker.

On top of that sits the wider Node-RED ecosystem, which the README credits with a library of thousands of additional nodes installable in an easy way, covering KNX, Loxone, Somfy Tahoma, Velux KLF200, Home Connect appliances, smart TVs and AV receivers, Sonos, Netatmo, Hue, Amazon Alexa, Google Home, databases such as InfluxDB or MySQL, and web services for things like weather data.

## Building, testing and releasing the addon

The repository is a build pipeline as much as it is an addon, and the scripts show how the artefact is assembled and checked.

Unit tests run on Node's built in test runner, and there is a separate end to end script.

```json
    "test:unit": "node --test test/*.test.js",
    "test:e2e": "test/e2e.sh"
```

The presence of an end to end script is what makes this more than a package assembly job. An addon that installs onto a physical device and talks to a real controller has more failure modes than a library, and a shell script driving the whole thing is the only way to catch the ones that only appear after installation.

The rest of the manifest is maintenance tooling rather than product code. There are scripts to update the package metadata, the README, the versions and the release body, and a script to build the change history. `outdated` runs npm outdated against three separate prefixes, the addon_files directories for lib, var and www, which reflects a package that keeps several separately installed trees rather than one.

The repository layout matches that. There is `addon_files/` holding the addon payload, `assets/` for images, `docs/`, `tools/`, `test/`, an `alpine-packages.mjs` module for the Alpine packages the addon needs, and a family of `build_*.sh` scripts for the addon, the change history and the release body. There are also `AGENTS.md`, `CLAUDE.md` and `BUILD.md` at the root, an `eslint.config.js`, and an `update_versions.js`.

The licence deserves a note. The manifest declares Apache-2.0 and the repository carries a LICENSE file, and the README has a section headed licences in its navigation. The dependencies are what make the licensing question more than a formality: Node-RED, the CCU node collection, npm, bootstrap, jquery and bcryptjs all carry their own terms, and an addon that redistributes them inherits obligations that a written licence alone does not settle.

## Where RedMatic is the wrong choice

Three limitations are stated in the README itself, and one more follows from the design.

The first is the native dependency limitation already covered. A flow that needs a node with a native addon simply cannot be installed on the CCU, and no configuration changes that. If your automation depends on such a node, RedMatic on the controller is not an option and you need a separate machine.

The second is the removal of the web app and package manager in version 9. If your existing flows relied on the RedMatic web app for configuration, that configuration has to be rebuilt elsewhere, and the feezal project is the author's answer for the dashboard case, not a drop-in replacement for the package manager.

The third is the CCU itself. RedMatic runs on a Homematic CCU3, openccu-lite or OpenCCU, and the 9 line needs CCU3 firmware from 3.61.5 or a current OpenCCU. The gateway is a closed device with a browser interface and a web UI installation path, not a general purpose Linux host, and everything in the design assumes that.

The alternative approach, and there are several named in the README, is a separate bridge. CCU-Jack, openccu-loom and matterbridge-homematic all do the job of exposing Homematic devices to other systems from a machine you control, and they do it without putting Node-RED on the controller at all. The difference in approach is exactly the argument the README makes. A separate bridge runs the RPC subscription from your own hardware, which means it adds a network hop to the controller's interface processes and gives you a second place where the CCU's tolerance for concurrent subscribers and network disruptions matters. RedMatic's argument is that the loopback design removes that exposure, at the cost of the constraints listed above.

There is also the option of writing the logic as code rather than as flows, which is what the she project is for, and the option of doing the automation in Home Assistant or ioBroker, which the README names as the usual suspects, with a central engine elsewhere.

## Conclusion

Adopt RedMatic if you run a Homematic CCU3, openccu-lite or OpenCCU and want to build automations as flows on the controller itself, without a separate Linux machine and without a bridge that puts RPC traffic on your network. Do not adopt it if any of your flows need nodes with native dependencies, because the CCU has no compiler toolchain, and do not plan an upgrade from RedMatic 7 without a CCU backup, since the README says the only way back is through that backup. Before you install, read the RedMatic 9 migration notes in the wiki, check that your CCU runs firmware from 3.61.5 or a current OpenCCU, and confirm that the Dashboard, HomeKit or Matter nodes you relied on are still reachable through the Node-RED palette manager.

## FAQ

### What is RedMatic and which devices does it run on?

RedMatic packages Node-RED as an addon for openccu-lite, the Homematic CCU3 and OpenCCU, formerly RaspberryMatic, and it installs through the device web interface without Linux knowledge or hand edited configuration files. It is built on Node-RED with the node-red-contrib-ccu node collection.

### What changed in RedMatic 9?

Version 9 was radically slimmed and modernised, moving to Node.js 24 and Node-RED 5. Only node-red-contrib-ccu is preinstalled and everything else comes from the Node-RED palette manager, and the RedMatic package manager and web app were deprecated and removed. It needs a CCU3 with firmware from 3.61.5 or a current OpenCCU.

### Why can I not install nodes with native dependencies on RedMatic?

The README states this as a known and accepted limitation: there is no compiler toolchain on the CCU and precompiled binaries are no longer shipped, so npm packages with binary dependencies cannot be installed there. Such a flow needs a separate machine.

### How does RedMatic connect the Homematic CCU to MQTT, Home Assistant, Matter and HomeKit?

All the connections run over a single `ccu-connection` that releases the devices selected on the CCU, and the CCU nodes bundle them into one subscriber per interface, using BIN-RPC with rfd and hs485d and keeping RPC traffic on the CCU loopback interface. MQTT and Home Assistant ship in the preinstalled CCU nodes, while Matter and HomeKit are installed from the Node-RED palette manager.

### Is there a way back if I upgrade from RedMatic 7 to RedMatic 9?

The README says to make a CCU backup before updating from RedMatic 7, that the backup is the user's responsibility, and that there is a way back only through that backup. It also points to the RedMatic 9 migration release notes in the wiki.

## Sources

- [Issues](https://github.com/rdmtc/RedMatic/issues)
- [License: Apache-2.0](https://github.com/rdmtc/RedMatic/blob/master/LICENSE)
- [rdmtc/RedMatic on GitHub](https://github.com/rdmtc/RedMatic)
- [README](https://github.com/rdmtc/RedMatic/blob/master/README.md)
- [Releases](https://github.com/rdmtc/RedMatic/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rdmtc-redmatic