Node-RED Nodes for the Homematic CCU
With these Nodes you can connect Homematic and Node-RED. Homematic is a series of smart home automation hardware from the manufacturer eQ-3, popular especially in Germany.
For the communication with the CCU both RPC and ReGaHSS remote script are used. It's possible to connect to multiple CCUs from one Node-RED instance. RPC setValue calls can be comfortably complemented with ON_TIME and RAMP_TIME values and special nodes ease the control of displays and mp3 actuators. RPC events can be filtered comprehensively (even through regular expressions and also by rooms and functions). It's possible to start rega-programs and set rega-variables and last but not least there are nodes to execute arbitrary rega-scripts and RPC calls.
These nodes are included in RedMatic which ships Node-RED as an addon package for installation on a Homematic CCU3 or RaspberryMatic.
Some example flows can be found in the RedMatic Wiki (German language).
A modern Browser is required, Internet Explorer won't work.
Starting with Version 3.x these Nodes need Node-RED >= 1.0 to work correctly
openccu-lite is a Homematic CCU firmware based on OpenCCU without
ReGaHSS. The interface processes (rfd, hs485d, hmipserver) are the same, so everything these nodes do over
BINRPC/XMLRPC works unchanged. Device, channel, room and function names come from the system's metadata API instead of
ReGaHSS; the connection node detects this at start (GET /api/meta/v1/version), nothing has to be configured, and
msg.channelName, msg.rooms, msg.functions and the room/function filters keep their shape.
Since 4.7.0 the interface processes are reached through the system's lite-rpc as well, with
occulite-client: the requests over the system's web port, the events
from a stream the connection opens (replayed after a break, re-read after a restart of the system), one subscriber at
the processes for every program on the system, no callback server and no init of this node's own; the value cache is
filled from the system's state store at deploy. The connection node's openccu-lite interfaces setting chooses
auto (the default: lite-rpc on openccu-lite, the CCU way on a CCU), openccu-lite (lite-rpc only) or CCU (the
direct connection with callbacks, on openccu-lite too); an existing connection is moved to lite-rpc once at its first
start on openccu-lite, the log says so, and a choice made in the node is never changed by a later version. CUxD and
CCU-Jack keep their own connections.
- Node-RED on the system (RedMatic from its addon catalogue): lite-rpc with RedMatic's own token, which the system mints for it from RedMatic's manifest (RedMatic 9.15.1 or later); the names come with the system's read-only token. Nothing to configure. An older RedMatic has no such token and connects the CCU way, the log says so.
- Node-RED elsewhere: an API token of the system goes into the connection node's openccu-lite token field -
for lite-rpc it needs the
rpc:*scope of what the flow does (rpc:readfor events and reads,rpc:operateforsetValue,rpc:configurefor paramsets and links,rpc:adminfor the rest; the rpc node may call anything). - System variables, programs and HM-Script do not exist there. The
ccu-sysvar,ccu-program,ccu-scriptandccu-pollnodes stay in the flows and answer every message with an error.
Every node that emits messages builds msg.topic from the same template, configurable per node, with these defaults:
| Node | Default topic |
|---|---|
| rpc-event | ${CCU}/${Interface}/${channelName}/${datapoint} |
| value | ${CCU}/${Interface}/${channel}/${datapoint} |
| get value | (empty: msg.topic stays as it came in) |
| sysvar, program | ReGaHSS/${Name} |
| rpc | ${CCU}/${Interface}/${Method} |
| script | ${CCU}/${Interface} |
Placeholders are the message's properties, matched case-insensitively: ${CCU}, ${Interface}, ${device},
${deviceName}, ${deviceType}, ${channel}, ${channelName}, ${channelType}, ${channelIndex}, ${datapoint},
${datapointName}; ${Name} for a variable or program, ${Method} for an RPC call. To get one scheme everywhere -
hm/<interface>/<channel>/<datapoint>, say - enter hm/${Interface}/${channel}/${datapoint} in each node; the defaults
stay as they are so existing flows and subscriptions keep working. The value node's input accepts a datapoint address in
msg.topic either as iface.channel.datapoint or in the emitted shape (ccu3/BidCos-RF/OEQ1868878:1/STATE,
hm/BidCos-RF/OEQ1868878:1/STATE: the last three segments count), so an event's topic can be fed straight back. The
ccu-mqtt node has its own templates for its MQTT topics.
The ccu-homeassistant node publishes
MQTT discovery configurations (device-based,
Home Assistant >= 2024.11) for the devices you tick in its config dialog. It is a companion to the ccu-mqtt node:
it reuses that node's topic templates and payload format, so state and commands keep flowing through ccu-mqtt and
the discovery configs simply point Home Assistant at those topics. Wire both nodes to the same mqtt out node and
feed the hm/set/# topics from an mqtt in node into ccu-mqtt — see
examples/home-assistant.json. One Home Assistant device is created per Homematic
device with switch, light, cover, climate, binary_sensor, event, lock and sensor entities; every other datapoint can
optionally be included as a disabled-by-default entity. Unticking a device removes it from Home Assistant on the
next deploy.
A device's availability in Home Assistant follows the UNREACH datapoint of its maintenance channel. The node
publishes its current value (retained) right after the discovery configs and every change after that, so a device
is available without ever having been unreachable. Any message on the node's input republishes both; the example
wires Home Assistant's birth message (homeassistant/status) to it, so a Home Assistant restart gets them again.
The device is created in the room of its channels: the discovery config carries it as the device's suggested_area
(Home Assistant's areas are per device, the CCU's rooms per channel). The rule: the room shared by all channels of the
device that lie in a room, otherwise the room of the lowest-numbered channel that lies in one; a channel in several
rooms counts with its first - on openccu-lite, where rooms can be nested, with the most specific one - and a room of
the device itself comes first. The rooms come from the ReGaHSS on a CCU and from the system's metadata on openccu-lite.
Home Assistant applies the suggestion only when it first creates the device; a room changed later on the CCU stays as
assigned in Home Assistant (change it there, or delete the device in Home Assistant and republish the discovery). The
node's option Suggest the channel's room as the device's area (on by default) switches it off.
Most nodes can be reconfigured per message: put an object in msg.config and its
properties override that node's own configuration for that one message. The stored
configuration is never modified, so the next message starts from the dialog settings
again — sending a different room, channel or brightness each time works as you would
expect.
// one signal node, a different colour and duration per message
msg.config = {dimmerColor: 4, durationValue: 10};
// one set-value node, a different room per message
msg.config = {rooms: 'Kitchen'};
return msg;Which keys a node accepts is listed in its help panel in the editor. Anything not on
that list is ignored, so an unrelated property in msg.config cannot reach node
internals. msg.ccu is not used for this because it already carries the CCU host name.
The value, get value and set value nodes additionally read plain top-level
properties (msg.channel, msg.datapoint, msg.rooms, …) to fill in fields left empty
in the dialog. That is the older mechanism and is unchanged; msg.config wins over it.
Inside a subflow, Node-RED substitutes ${PARAMETER} placeholders in a node's text
fields before the node is created, so a subflow parameter can be typed straight into the
Channel or Datapoint field and each instance reads its own device.
The communication with the Homematic CCU needs independent connections in two directions. Node-red-contrib-ccu connects to the CCU's interface listeners (e.g. 2001/TCP for BidCos-RF) while the CCU connects to node-red-contrib-ccu's BINRPC/XMLRPC listeners (2048/tcp and 2049/tcp in examples below).
If Node-RED/node-red-contrib-ccu runs inside a Container or a VM with NAT'd network it's necessary to forward/expose the ports for connections from the CCU to node-red-contrib-ccu's callback listeners (example below for a Docker container: use options -p 2048:2048 -p 2049:2049in the docker run command).
The config option Init addresswill be used to tell the CCU on which Address node-red-contrib-ccu is reachable. As 172.17.0.20 is not reachable for the CCU the Hosts IP Address and port forwarding/exposal has to be used. As Listen address setting also 0.0.0.0 (which tells node-red-contrib-ccu to bind it's listeners to all available interfaces) would be possible.
This example shows a configuration for piVCCU and Node-RED running in containers with bridged networking.
In this example both Node-RED and debmatic are installed on the same (possibly virtual) host.
With the same logic as shown above, multiple CCUs can be managed within one Node-RED instance. This will require two individual configuration nodes, in which the respective connection setting are provided.
Listen addresstypically is the same for both Configurations as it is determined by the host that is running Node-REDBINRPC listening portandXMLRPC listening portneed to be different across the two configurations. One configuration can use the defaults (2048/tcp and 2049/tcp), the other needs to use two new ports. node-red-contrib-ccu will make a proposal, but this can be modified, e.g. if the proposed ports are already used.- The examples for NAT'd network, piVCCU and debmatic will apply likewise for multiple CCUs. This means, for running Node-RED within a docker, all BINRPC and XMLRPC ports must be forwarded, e.g.
-p 2048:2048 -p 2049:2049 -p 2061:2061 -p 2062:2062
MIT (c) Sebastian Raff and node-red-contrib-ccu contributors