node-red-contrib-ccu 4.4.4 → 4.5.0

package/nodes/lib/transport.js

@@ -0,0 +1,80 @@
+/* TLS and authentication for the connections to the CCU (task 5, #27).
+
+   Both belong to the CCU's web server, which fronts the interface processes
+   for the LAN: XML-RPC on 2000/2001/2010/9292 in plain text and on
+   42000/42001/42010/49292 over TLS, the ReGaHSS on 8181 and 48181 - a CCU3
+   switches them on in its firewall settings, openccu-lite on its remote
+   access page ("classic RPC"). The processes themselves listen on the
+   loopback (31999, 32000, 32001, 32010, 39292) with neither. Hence:
+
+   - a local connection (Node-RED on the CCU) reaches the processes directly,
+     so TLS and credentials are not used whatever the dialog says: https to a
+     plain port or credentials in a BIN-RPC frame only break the connection;
+   - BIN-RPC has neither. With TLS on, BidCos-RF goes XML-RPC over TLS even
+     when BIN-RPC was asked for (the hidden `bcrfBinRpc` property); with
+     authentication and without TLS the option stays, and a warning says the
+     CCU will refuse it;
+   - CUxD (BIN-RPC on 8701) has neither, on any connection;
+   - the callback server Node-RED runs for the CCU's events stays plain: the
+     CCU presents no credentials and cannot verify our certificate.
+
+   Pure: the connection node feeds it the config and logs the notes. */
+
+/**
+ * @typedef {object} Transport
+ * @property {boolean} tls the XML-RPC and ReGa clients use TLS (the 4xxxx ports)
+ * @property {boolean} auth the clients send the username and password (HTTP basic)
+ * @property {boolean} inSecure invalid certificates are accepted (only with tls)
+ * @property {boolean} bcrfBinRpc BidCos-RF goes over BIN-RPC on a remote connection
+ * @property {Array<{level: 'info'|'warn', message: string}>} notes what to log once
+ */
+
+/**
+ * @param {object} config
+ * @param {boolean} config.isLocal Node-RED runs on the CCU (lib/localccu.js)
+ * @param {boolean} [config.tls]
+ * @param {boolean} [config.authentication]
+ * @param {boolean} [config.inSecure]
+ * @param {boolean} [config.bcrfBinRpc]
+ * @returns {Transport}
+ */
+function resolveTransport({isLocal, tls, authentication, inSecure, bcrfBinRpc}) {
+    const notes = [];
+
+    if (isLocal) {
+        if (tls || authentication) {
+            notes.push({
+                level: 'info',
+                message:
+                    'local connection: TLS and authentication are not used, the interface processes are reached directly',
+            });
+        }
+
+        return {tls: false, auth: false, inSecure: false, bcrfBinRpc: false, notes};
+    }
+
+    const useTls = Boolean(tls);
+    const useAuth = Boolean(authentication);
+    let binRpc = Boolean(bcrfBinRpc);
+
+    if (binRpc && useTls) {
+        binRpc = false;
+        notes.push({
+            level: 'warn',
+            message: 'BidCos-RF: BIN-RPC has no TLS - using XML-RPC over TLS (port 42001) instead',
+        });
+    } else if (binRpc && useAuth) {
+        notes.push({
+            level: 'warn',
+            message: 'BidCos-RF: BIN-RPC carries no credentials - the CCU refuses it while authentication is on',
+        });
+    }
+
+    if (useAuth && !useTls) {
+        notes.push({level: 'warn', message: 'authentication without TLS: the credentials are sent in plain text'});
+    }
+
+    return {tls: useTls, auth: useAuth, inSecure: useTls && Boolean(inSecure), bcrfBinRpc: binRpc, notes};
+}
+
+module.exports = {resolveTransport};

package/nodes/locales/de/ccu-alexa.html

@@ -0,0 +1,4 @@
+<script type="text/html" data-help-name="ccu-alexa">
+    <p>Homematic Geräte mit node-red-contrib-alexa-smart-home verbinden. Am Eingang den Node "alexa smart home v3"
+    anschließen, am Ausgang "alexa smart home v3 state".</p>
+</script>

package/nodes/locales/de/ccu-connection.html

@@ -0,0 +1,103 @@
+<script type="text/html" data-help-name="ccu-connection">
+        <p>Im Connection Node wird die Verbindung zu den CCU Schnittstellenprozessen und zur Logikschicht verwaltet.</p>
+        <h3>Konfiguration</h3>
+            <ul>
+                <li><b>Name</b>: Frei wählbarer Name für die aktuelle CCU-Konfiguration. Er dient zur Unterscheidung falls mehrere CCUs an RedMatic angebunden werden und erscheint in allen anderen CCU Nodes.</li>
+            </ul>
+            <ul>
+                <li><b>CCU Address</b>: Die IP-Adresse oder der Hostname der CCU. Wird das CCU-Addon RedMatic genutzt, läuft Node-RED auf dem selben Server weshalb die Loopback-Adresse <code>localhost</code> bzw. <code>127.0.0.1</code> gewählt werden kann.</li>
+            </ul>
+            <ul>
+                <li><b>Listen Address</b>: Die IP-Adresse des Netzwerk-Interfaces auf welchem die RedMatic RPC Server "lauschen" sollen. Läuft RedMatic auf der CCU wird hier ebenfalls <code>localhost</code> bzw. <code>127.0.0.1</code> verwendet. Um auf allen Interfaces zu lauschen kann <code>0.0.0.0</code> verwendet werden.</li>
+            </ul>
+            <ul>
+                <li><b>Init Address</b>: entspricht normalerweise <i>Listen address</i>, Die Adresse unter der Node-RED von der
+        CCU aus erreichbar ist. Das Eingabefeld kann leer gelassen werden.</p>
+        <p>Für fortgeschrittene User: Wenn auf allen Interfaces gelauscht wird (Adresse 0.0.0.0) oder wenn Node-RED in
+        einem Container (z.B. Docker) mit NAT-Netzwerk läuft oder in anderen spezielleren Netzwerkumgebungen kann es
+        notwendig sein <i>Init address</i> und <i>Listen Address</i> auf unterschiedliche Werte zu setzen.</li>
+            </ul>
+            <ul>
+                <li><b>BinRPC Port</b>: Der Port des RedMatic BinRPC Dienstes an den die CCU Events schickt. Werden Verbindungen zu mehreren CCUs hergestellt (mehrere instanzen des ccu-configuration Node) braucht jede Verbindung einen exklusiven Port.</li>
+            </ul>
+            <ul>
+                <li><b>XMLRPC Port</b>: Der Port des RedMatic XMLRPC Dienstes an den die CCU Events schickt. Werden Verbindungen zu mehreren CCUs hergestellt braucht jede Verbindung einen exklusiven Port.</li>
+            </ul>
+            <ul>
+                <li><b>Interfaces</b>: Hier können die zu verwendenden Schnittstellen angegeben werden. Nutzt man Beispielsweise keinen CUxD oder HmIP Geräte, kann der Haken entfernt werden was die entsprechenden ungenutzten Komponenten deaktiviert.
+                    <ul>
+                        <li>ReGaHSS: Die Logikschicht der CCU, verwaltet CCU-Programme und CCU-Systemvariablen</li>
+                        <li>BidCos-RF: Homematic Funk</li>
+                        <li>BidCos-Wired: Homematic Wired</li>
+                        <li>HmIP-RF: Homematic-IP Funk</li>
+                        <li>VirtualDevices: Heizungsgruppen, in CCU eingebundene Systeme wie Osram Lightify</li>
+                        <li>CUxD</li>
+                        <li>CCU-Jack: XMLRPC-Schnittstelle des <a href="https://github.com/mdzio/ccu-jack" target="_blank">CCU-Jack</a> Addons (Port konfigurierbar, Standard 2121 bzw. 2122 mit TLS)</li>
+                    </ul>
+
+                </li>
+            </ul>
+            <ul>
+                <li><b>RPC Ping-Timeout</b>: Zeitinterval in Sekunden in dem die Verbindung zu den Schnittstellenprozessen geprüft wird.</li>
+            </ul>
+            <ul>
+                <li><b>ReGaHSS Polling</b>: Änderungen von CCU-Systemvariablen werden nicht automatisch an RedMatic übermittelt. Mit aktiviertem Polling fragt RedMatic die Variablen und deren Werte in den per Poll-Interval eingestellten Zeitintervallen ab.</li>
+            </ul>
+            <ul>
+                <li><b>ReGaHSS Poll-Interval</b>:
+                Das Zeitintervall in Sekunden in dem Systemvariablen von der CCU abgefragt werden.</li>
+            </ul>
+            <ul>
+                <li><b>Context-Store</b>: Hier wird der Node-RED Context-Store festgelegt in dem RedMatic die Zustände aller Geräte/Variablen vorhält.
+
+Weiteres unter <a target="_blank" href="https://nodered.org/docs/user-guide/context">Working</a> with context in der Node-RED Dokumentation.</li>
+            </ul>
+            <ul>
+                <li><b>openccu-lite Token</b>: Nur für <a href="https://github.com/hobbyquaker/openccu-lite" target="_blank">openccu-lite</a>,
+                eine CCU-Firmware ohne ReGaHSS. Namen, Räume und Gewerke kommen dort aus der Metadaten-API des Systems;
+                dafür wird ein Token benötigt, das dort unter <i>Benutzer</i> erzeugt wird. Läuft Node-RED
+                auf dem System selbst (RedMatic), bleibt das Feld leer – das lokale Token wird dann automatisch gelesen.
+                Das Token wird wie das Passwort in den Node-RED-Credentials gespeichert (verschlüsselt in
+                <code>flows_cred.json</code>, nie im Flow und nie im Export).
+                Eine CCU/RaspberryMatic/OpenCCU ignoriert das Feld vollständig. Systemvariablen, Programme und
+                HM-Scripte gibt es auf openccu-lite nicht; die entsprechenden Nodes bleiben im Flow, melden aber pro
+                Nachricht einen Fehler.</li>
+            </ul>
+            <ul>
+                <li><b>openccu-lite Port</b>: Nur nötig, wenn der Webserver des Systems nicht auf Port 80 bzw. 443 (TLS) läuft.</li>
+            </ul>
+            <ul>
+                <li><b>Device data / Re-read device data</b>: Liest die Geräteliste jeder verbundenen Schnittstelle neu ein.
+                Neue und geänderte Geräte (z.&nbsp;B. ein Kanal, dessen Typ sich geändert hat) bekommen ihre Datenpunkte neu
+                geholt, entfernte verschwinden aus der Tabelle. Ein Gerät, das die CCU mit geändertem Typ oder geänderter Version
+                meldet, wird auch ohne Klick automatisch neu eingelesen. Der Knopf setzt eine deployte Verbindung voraus.</li>
+            </ul>
+            <ul>
+                <li><b>Authentication</b>: Verschlüsselung und Anmeldung für eine CCU im Netzwerk (Node-RED läuft nicht auf der CCU).
+                Beides gehört zum Webserver der CCU, der die Schnittstellenprozesse nach außen vertritt: auf einer CCU3 werden
+                TLS und Authentifizierung in den Firewall-Einstellungen eingeschaltet, auf openccu-lite unter <i>Fernzugriff</i>
+                (klassisches RPC). Läuft Node-RED auf dem System selbst (RedMatic; Adresse <code>localhost</code> bzw.
+                <code>127.0.0.1</code>), werden die Prozesse direkt über den Loopback erreicht, BidCos per BIN-RPC – ohne TLS und
+                ohne Anmeldung; die Einstellungen werden dann nicht verwendet.
+                <ul>
+                    <li>Enabled: Benutzer und Passwort werden bei jedem Aufruf mitgeschickt (HTTP Basic Auth) – an alle
+                    XML-RPC-Schnittstellen (BidCos-RF, BidCos-Wired, HmIP-RF, VirtualDevices, CCU-Jack) und an die ReGaHSS. BIN-RPC
+                    (CUxD, die versteckte BIN-RPC-Option für BidCos-RF) kennt keine Anmeldung. Ohne TLS gehen die Zugangsdaten im
+                    Klartext über das Netz; der Dialog schaltet TLS deshalb mit ein.</li>
+                    <li>TLS/SSL: Transportverschlüsselung. Die Schnittstellen werden über die TLS-Ports der CCU erreicht (42000, 42001,
+                    42010, 49292, ReGaHSS 48181, CCU-Jack 2122), die Metadaten-API von openccu-lite über Port 443. BIN-RPC kennt kein
+                    TLS: mit TLS geht BidCos-RF immer über XML-RPC.</li>
+                    <li>Ignore invalid TLS Certificates: Node-RED akzeptiert auch ein nicht vertrauenswürdiges Zertifikat. Nötig,
+                    solange die CCU ihr selbst ausgestelltes Zertifikat verwendet.</li>
+                    <li>Username: Ein Benutzer der sich an der CCU anmelden darf.</li>
+                    <li>Password: Das Passwort des Benutzers. Es wird in den Node-RED-Credentials gespeichert
+                    (verschlüsselt in <code>flows_cred.json</code>), nicht im Flow. Ein Flow aus einer Version vor 4.4.6,
+                    der es noch im Klartext enthält, wird beim ersten Start übernommen; der nächste Deploy entfernt es aus
+                    <code>flows.json</code>.</li>
+                </ul>
+                Die Gegenrichtung bleibt unverschlüsselt: Die CCU schickt ihre Ereignisse an den XML-RPC- bzw. BIN-RPC-Server, den
+                Node-RED dafür öffnet (<i>Listen Address</i>, <i>BinRPC Port</i>, <i>XMLRPC Port</i>), ohne TLS und ohne Anmeldung –
+                sie kann sich dort nicht anmelden und unser Zertifikat nicht prüfen. Diese Ports sollten in der Firewall des
+                Node-RED-Hosts nur für die CCU offen sein.</li>
+            </ul>
+</script>

package/nodes/locales/de/ccu-get-value.html

@@ -0,0 +1,16 @@
+<script type="text/html" data-help-name="ccu-get-value">
+    <p>Dieser Node gibt bei jeder eingehenden Message den aktuellen zwischengespeicherten Zustand eines Datenpunktes oder einer CCU Systemvariable aus.</p>
+        <h3>Konfiguration</h3>
+        Um über die eingehende Message die Attribute <code>iface</code>, <code>channel</code>, <code>datapoint</code> und <code>sysvar</code> setzen zu können müssen die entsprechenden Konfigurationsoptionen leer gelassen werden.
+    <ul>
+        <li><b>Topic</b>: <code>msg.topic</code> der ausgehenden Nachricht, dieselbe Vorlage wie in den anderen Nodes
+        (<code>${CCU}</code>, <code>${Interface}</code>, <code>${device}</code>, <code>${deviceName}</code>,
+        <code>${channel}</code>, <code>${channelName}</code>, <code>${channelType}</code>, <code>${channelIndex}</code>,
+        <code>${datapoint}</code>; bei einer Systemvariable <code>${Name}</code>), z.&nbsp;B.
+        <code>${CCU}/${Interface}/${channel}/${datapoint}</code>. Leer (Voreinstellung): <code>msg.topic</code> bleibt
+        wie es hereinkam.</li>
+    </ul>
+    <h3>Input</h3>
+    <h3>Output</h3>
+    <p>Was ein Datenpunkt bedeutet, sein Wertebereich und seine Einheit: die <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf" target="_blank">eQ-3 HmIP-Gerätedokumentation (PDF)</a>.</p>
+</script>

package/nodes/locales/de/ccu-homeassistant.html

@@ -0,0 +1,23 @@
+<script type="text/html" data-help-name="ccu-homeassistant">
+    <p>Veröffentlicht Home-Assistant-MQTT-Discovery-Konfigurationen für ausgewählte Geräte.</p>
+    <p>Der Node ist ein Begleiter zum <b>ccu-mqtt</b>-Node: er übernimmt dessen Topic-Vorlagen und
+    Payload-Format, so dass die Discovery-Konfigurationen auf die Topics zeigen, die ccu-mqtt bereits
+    veröffentlicht bzw. entgegennimmt. Status und Befehle laufen weiterhin über ccu-mqtt.</p>
+    <h3>Verkabelung</h3>
+    <p>Den Ausgang mit demselben <b>mqtt out</b>-Node verbinden wie den ccu-mqtt-Node. Der Node sendet
+    <code>msg.topic</code>, <code>msg.payload</code> und <code>msg.retain</code>.</p>
+    <h3>Geräteauswahl</h3>
+    <p>Nur angehakte Geräte werden an Home Assistant gemeldet (ein HA-Gerät pro Homematic-Gerät).
+    Wird ein zuvor angehaktes Gerät abgehakt, sendet der Node beim nächsten Deploy eine leere
+    Konfiguration, die das Gerät in Home Assistant entfernt.</p>
+    <h3>Entitäten</h3>
+    <p>Schalter, Dimmer (light), Rollladen/Jalousie (cover), Thermostate (climate), Kontakte/Bewegung/
+    Rauch/Wasser (binary_sensor), Tasten (event), KeyMatic (lock), Energie/Wetter (sensor). Mit der
+    Option <i>weitere Datenpunkte</i> werden alle übrigen Datenpunkte als standardmäßig deaktivierte
+    Entitäten mitgeliefert.</p>
+    <h3>Eingang</h3>
+    <p>Jede eingehende Nachricht veröffentlicht die Discovery-Konfigurationen erneut.</p>
+    <h3>Voraussetzungen</h3>
+    <p>Home Assistant ≥ 2024.11 (gerätebasierte Discovery). Die Verfügbarkeit der Geräte wird aus dem
+    UNREACH-Datenpunkt des Wartungskanals abgeleitet.</p>
+</script>

package/nodes/locales/de/ccu-mqtt.html

@@ -0,0 +1,21 @@
+<script type="text/html" data-help-name="ccu-mqtt">
+    <p>Die CCU an MQTT anbinden: Events der Geräte und Änderungen der Systemvariablen gehen als Nachrichten mit fertigem Topic heraus, eingehende Nachrichten schalten, lesen oder rufen RPC-Methoden auf. Verdrahtet wird der Node zwischen einem <i>mqtt in</i>- und einem <i>mqtt out</i>-Node.</p>
+    <h3>Konfiguration</h3>
+    <ul>
+        <li><b>CCU</b>: Die zu verwendende CCU-Konfiguration.</li>
+        <li><b>Cache</b>: Beim Start werden die zwischengespeicherten Werte aller Datenpunkte einmal ausgegeben.</li>
+        <li><b>Topics</b>, jeweils eine Vorlage mit Platzhaltern (<code>${channelName}</code>, <code>${channelNameOrAddress}</code>, <code>${datapoint}</code>, <code>${name}</code>, <code>${iface}</code>, <code>${paramset}</code>, <code>${param}</code>, <code>${method}</code>, <code>${callid}</code>, <code>${rxtx}</code>):
+            <ul>
+                <li><b>Event</b>: ausgehende Geräte-Events, Standard <code>hm/status/${channelName}/${datapoint}</code>.</li>
+                <li><b>setValue</b>: eingehend, schreibt <code>payload</code> in den Datenpunkt; <code>${channelNameOrAddress}</code> nimmt den Kanalnamen oder die Adresse.</li>
+                <li><b>get</b>: eingehend, gibt den zwischengespeicherten Wert des Datenpunkts auf dem Event-Topic aus.</li>
+                <li><b>Sysvar/Program Change</b>: ausgehend, Änderungen von Systemvariablen und Programmen; <b>Sysvar/Program Set</b>: eingehend, setzt eine Variable bzw. startet ein Programm.</li>
+                <li><b>putParam</b>, <b>putParamset</b>: eingehend, schreibt einen Parameter bzw. einen ganzen Parametersatz (<code>MASTER</code>, <code>VALUES</code>) als JSON.</li>
+                <li><b>RPC</b>: eingehend, ruft eine RPC-Methode der Schnittstelle auf (<code>payload</code>: die Parameter als JSON-Array); die Antwort geht auf dem <b>RPC Response</b>-Topic mit derselben <code>${callid}</code> heraus.</li>
+                <li><b>Message Counters</b>: ausgehend, die Zähler empfangener und gesendeter Nachrichten je Schnittstelle (<code>${rxtx}</code> = <code>rx</code>/<code>tx</code>).</li>
+            </ul>
+        </li>
+        <li><b>Output Payload</b>: <i>Plain</i> (nur der Wert), <i>MQTT-Smarthome JSON Basic</i> (<code>{"val", "ts", "lc"}</code>) oder <i>MQTT-Smarthome JSON Extended</i> (zusätzlich die Homematic-Eigenschaften der Nachricht: <code>hm.iface</code>, <code>hm.channel</code>, <code>hm.datapoint</code> usw.). Eingehend werden ein nackter Wert und ein Objekt mit <code>val</code> gleichermaßen verstanden.</li>
+    </ul>
+    <p>Für Home Assistant gibt es den <i>ccu-homeassistant</i>-Node, der die Discovery-Konfigurationen zu diesen Topics erzeugt.</p>
+</script>

package/nodes/locales/de/ccu-poll.html

@@ -0,0 +1,8 @@
+<script type="text/html" data-help-name="ccu-poll">
+    <p>Führt einen sofortigen Poll von ReGaHSS Systemvariablen durch.</p>
+    <p>Dieser Node ist dazu vorgesehen die Änderung von Systemvariablen mit möglichst geringer Verzögerung zu empfangen.
+      Hierzu kann man ein Programm auf der CCU anlegen dass bei Änderung von Variablen einen virtuellen Taster betätigt.
+      In Node-RED wird dann ein <i>rpc event</i> oder <i>value</i> Node so konfiguriert dass er diese
+      "Tastenbetätigungen" empfängt und über den <i>ccu poll</i> Node eine Aktualisierung der Variablenwerte auslöst.
+    </p>
+</script>

package/nodes/locales/de/ccu-program.html

@@ -0,0 +1,26 @@
+<script type="text/html" data-help-name="ccu-program">
+    <p>Führt ein ReGaHSS Programm aus.</p>
+    <h3>Inputs</h3>
+    <dl class="message-properties">
+        <dt>payload
+            <span class="property-type">*</span>
+        </dt>
+        <dd>
+            Ist der Payload vom Typ boolean wird das Programm bei <code>true</code> aktiviert und ausgeführt und bei
+            <code>false</code> deaktiviert. In allen anderen Fällen (Payload ist z.B. ein leerer String) wird das
+            Programm ausgeführt.
+        </dd>
+    </dl>
+    <h3>Outputs</h3>
+     <ol class="node-ports">
+         <li>Output
+             <dl class="message-properties">
+                 <dt>payload <span class="property-type">string</span></dt>
+                 <dd>
+                   Im Payload ist der Zeitstempel der letzten Programmausführung (Attribut <code>ts</code>) sowie
+                   die Information ob ein Programm aktiv oder inaktiv ist (Attribut <code>active</code>) enthalten.
+                 </dd>
+             </dl>
+         </li>
+     </ol>
+</script>

package/nodes/locales/de/ccu-rpc-event.html

@@ -0,0 +1,32 @@
+<script type="text/html" data-help-name="ccu-rpc-event">
+    <p>Gibt RPC Events aus.</p>
+    <h3>Konfiguration</h3>
+    <ul>
+        <li><b>CCU</b>: Die zu verwendende CCU-Konfiguration.</li>
+        <li><b>topic</b>: <code>msg.topic</code> ausgehender Nachrichten, mit Platzhaltern: <code>${CCU}</code>,
+        <code>${Interface}</code>, <code>${device}</code>, <code>${deviceName}</code>, <code>${deviceType}</code>,
+        <code>${channel}</code>, <code>${channelName}</code>, <code>${channelType}</code>, <code>${channelIndex}</code>,
+        <code>${datapoint}</code>, <code>${datapointName}</code>. Dieselbe Vorlage gibt es in jedem Node, der Nachrichten
+        ausgibt (value, get value, sysvar, program, rpc, script).</li>
+        <li><b>interface</b>: Die Schnittstelle über welche die gewüschten Geräte angebunden sind. <code>*</code> erlaubt Events aller verbundenen Schnittstellen.</li>
+        <li><b>room</b>: Raum Filter. Beispiel: <code>Wohnzimmer</code>.</li>
+        <li><b>function</b>: Gewerk Filter. Beispiel: <code>Taster</code></li>
+        <li><b>device</b>: Die Seriennummer der Homematic Komponente. Beispiel: <code>OEQ1662328</code></li>
+        <li><b>deviceName</b>: Der in der CCU vergebene Name der Homematic Komponente. Beispiel: <code>Rauchmelder Arbeitszimmer</code>; alle Rauchemelder über RegEx: <code>Rauchmelder.*</code></li>
+        <li><b>deviceType</b>: Die Typen-Bezeichnung der Homematic Komponente. Beispiel: <code>HM-Sec-SD-2</code></li>
+        <li><b>channel</b>: Die Kanaladresse bestehend aus Serien- und Kanalnummer. Beispiel: <code>OEQ1245312:4</code></li>
+        <li><b>channelName</b>: Der in der CCU vergebene Kanalname. Beispiel: <code>Bad Lichte Decke PIR</code></li>
+        <li><b>channelType</b>: Der Typ des Kanals. Beispiel: <code>VIRTUAL_KEY</code> oder <code>DIMMER</code></li>
+        <li><b>channelIndex</b>: Der Index des Kanals. Beispiel: <code>2</code>
+        <li><b>datapoint</b>: Der Datenpunkt des Kanals. Beispiel: <code>PRESS_SHORT</code> oder <code>ACTUAL_TEMPERATURE</code>. Was ein Datenpunkt bedeutet:
+        die <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf" target="_blank">eQ-3 HmIP-Gerätedokumentation (PDF)</a>.</li>
+        <li><b>Nur geänderte Werte ausgeben</b> - Ein Event wird nur dann erzeugt, wenn sich der Wert seit dem letztn Event verändert hat.</li>
+        <li><b>Während WORKING keine Werte ausgeben</b> - Es gibt Aktoren, z.B. Dimmer oder Rolladen, die während einer Rampe (Öffnen/Schließen eines Rollladen, Dimmen einer Lampe) fortwährend den aktuellen Zustand ausgeben. Um nur den End-Status auszugeben kann diese Option benutzt werden. Gebräuchlich auch bei Verwendung mit Dashboard-Nodes um "springende" Slider zu verhindern.</li>
+        <li><b>Beim Start letzten bekannten Wert ausgeben</b> - Wenn Node-RED gestartet wird, dann wird der letzte Wert (sofern in der ReGaHSS bekannt) ausgegeben. Z.B. um beim Start einen korrekten Wert an das Dashboard zu übergeben. <b>Achtung:</b> Wird durch die ausgegebene Nachricht im weiteren Verlauf des Flows ein Homematic Wert gesetzt wirkt sich jedes (Full-)Deployment negativ auf den DutyCycle aus.</li>
+    </ul>
+
+    <p>Jeder Filter ist ein Text oder, mit dem Wahlschalter daneben, ein regulärer Ausdruck; ein leerer Filter passt auf alles. Eine Nachricht muss alle gesetzten Filter passieren.</p>
+
+    <h3>Output</h3>
+    <p>Eine Nachricht pro Event. Neben <code>payload</code> (dem Wert) trägt sie den Kontext des Datenpunkts: <code>ccu</code>, <code>iface</code>, <code>device</code>, <code>deviceName</code>, <code>deviceType</code>, <code>channel</code>, <code>channelName</code>, <code>channelType</code>, <code>channelIndex</code>, <code>datapoint</code>, <code>datapointName</code>, <code>datapointType</code>, <code>datapointMin</code>, <code>datapointMax</code>, <code>datapointEnum</code>, <code>datapointDefault</code>, <code>datapointControl</code>, <code>value</code>, <code>valuePrevious</code>, <code>valueEnum</code>, <code>valueStable</code>, <code>rooms</code>/<code>room</code>, <code>functions</code>/<code>function</code>, <code>ts</code>, <code>tsPrevious</code> und <code>lc</code> (Zeitpunkt des Events, des vorigen Events, der letzten Änderung), <code>change</code>, <code>cache</code> (true für einen beim Start ausgegebenen Wert), <code>working</code>, <code>direction</code>, <code>uncertain</code> sowie <code>topic</code> wie konfiguriert.</p>
+</script>

package/nodes/locales/de/ccu-rpc.html

@@ -0,0 +1,31 @@
+<script type="text/html" data-help-name="ccu-rpc">
+    <p>Führt eine RPC Methode aus und gibt das Ergebnis zurück.</p>
+    <h3>Inputs</h3>
+    <dl class="message-properties">
+        <dt>topic
+            <span class="property-type">String</span>
+        </dt>
+        <dd>
+            Die Methode die aufgerufen werden soll. Siehe <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM_XmlRpc_API.pdf">XMLRPC API Dokumentation</a>
+        </dd>
+        <dt>payload
+            <span class="property-type">Array|String</span>
+        </dt>
+        <dd>
+            Ein Array oder ein in einem JSON-string enthaltenes Array von Parametern die für den RPC Methodenaufruf
+            genutzt werden.
+        </dd>
+
+    </dl>
+    <h3>Outputs</h3>
+     <ol class="node-ports">
+         <li>Output
+             <dl class="message-properties">
+                 <dt>payload <span class="property-type">array</span></dt>
+                 <dd>
+                    Die Rückgabe des RPC Methodenaufrufs.
+                 </dd>
+             </dl>
+         </li>
+     </ol>
+</script>

package/nodes/locales/de/ccu-script.html

@@ -0,0 +1,13 @@
+<script type="text/html" data-help-name="ccu-script">
+    <p>Führt ein HM-Script (ReGaHSS) auf der CCU aus und gibt das Ergebnis aus.</p>
+    <h3>Konfiguration</h3>
+    <ul>
+        <li><b>CCU</b>: Die zu verwendende CCU-Konfiguration.</li>
+        <li><b>Topic</b>: <code>msg.topic</code> der ausgehenden Nachricht, Vorlage mit Platzhaltern (<code>${CCU}</code>, <code>${Interface}</code>), Standard <code>${CCU}/${Interface}</code>.</li>
+        <li><b>Script</b>: Das Script. Bleibt das Feld leer, wird <code>msg.payload</code> der eingehenden Nachricht als Script ausgeführt.</li>
+    </ul>
+    <h3>Input</h3>
+    <p>Jede eingehende Nachricht startet das Script; ohne konfiguriertes Script ist <code>msg.payload</code> das Script.</p>
+    <h3>Output</h3>
+    <p><code>msg.payload</code> ist die Ausgabe des Scripts (was es mit <code>WriteLine</code> schreibt), <code>msg.objects</code> die Werte der Variablen, die das Script gesetzt hat, dazu <code>iface</code> (<code>ReGaHSS</code>) und <code>ccu</code>. Ein Script, das nicht bis zum Ende läuft, meldet <i>Script call failed</i>. Auf openccu-lite gibt es keine ReGaHSS; der Node meldet dort pro Nachricht einen Fehler.</p>
+</script>

package/nodes/locales/de/ccu-set-value.html

@@ -0,0 +1,46 @@
+<script type="text/html" data-help-name="ccu-set-value">
+    <p>Einen Wert in mehrere Geräte auf einmal schreiben: alle Kanäle, auf die die Filter passen, bekommen <code>msg.payload</code> in den gewählten Datenpunkt.</p>
+    <h3>Konfiguration</h3>
+    <ul>
+        <li><b>CCU</b>: Die zu verwendende CCU-Konfiguration.</li>
+        <li><b>Interface</b>: Die Schnittstelle, deren Geräte angesprochen werden; <code>*</code> für alle verbundenen Schnittstellen.</li>
+        <li><b>room</b>, <b>function</b>: Raum- und Gewerke-Filter, z.&nbsp;B. <code>Wohnzimmer</code>, <code>Licht</code>.</li>
+        <li><b>device</b>, <b>deviceName</b>, <b>deviceType</b>: Filter auf Seriennummer, CCU-Name und Typ des Geräts, z.&nbsp;B. <code>OEQ1662328</code>, <code>Deckenlampe.*</code>, <code>HM-LC-Sw1-FM</code>.</li>
+        <li><b>channel</b>, <b>channelName</b>, <b>channelType</b>, <b>channelIndex</b>: Filter auf Kanaladresse (<code>OEQ1245312:4</code>), Kanalname, Kanaltyp (<code>SWITCH</code>, <code>DIMMER</code>) und Kanalindex.</li>
+        <li><b>datapoint</b>: Der Datenpunkt, in den geschrieben wird, z.&nbsp;B. <code>STATE</code> oder <code>LEVEL</code>. Was ein Datenpunkt bedeutet, sein Wertebereich und seine Einheit:
+        die <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf" target="_blank">eQ-3 HmIP-Gerätedokumentation (PDF)</a>.</li>
+        <li><b>force</b>: Schreibt auch dann, wenn der Cache den Wert schon kennt (siehe <i>Queue und Erzwingen</i> beim value Node).</li>
+    </ul>
+    <p>Jeder Filter ist ein Text oder, mit dem Wahlschalter daneben, ein regulärer Ausdruck; ein leerer Filter passt auf alles. Geschrieben wird in jeden Kanal, der alle gesetzten Filter passiert und den Datenpunkt hat.</p>
+
+    <h3>Input</h3>
+    <p><code>msg.payload</code> ist der Wert, der geschrieben wird. Leer gelassene Filter füllen gleichnamige Eigenschaften der Nachricht (<code>msg.iface</code>, <code>msg.rooms</code>, <code>msg.channel</code>, <code>msg.datapoint</code> usw.); <code>msg.config</code> überschreibt die Konfiguration für genau diese Nachricht (siehe unten).</p>
+
+    <h3>Party-/Urlaubsmodus (HmIP)</h3>
+    <p>Ein HmIP-Thermostat (eTRV, WTH) nimmt <code>PARTY_TIME_START</code>, <code>PARTY_TIME_END</code> und
+    <code>PARTY_SET_POINT_TEMPERATURE</code> nur gemeinsam an; einzeln geschrieben setzt er die anderen beiden zurück. Ein
+    Schreiben auf einen der drei Datenpunkte geht deshalb als ein <code>putParamset</code> mit allen dreien hinaus – die
+    beiden anderen aus dem letzten eigenen Schreiben, dem Wertecache oder einem Lesen vom Gerät. Die Zeiten können als
+    Gerätestring <code>YYYY_MM_DD HH:MM</code>, als JavaScript-Date, ISO-String oder Millisekunden angegeben werden; sie
+    werden in lokaler Zeit für das Gerät formatiert. Ältere HM-Thermostate (<code>PARTY_MODE_SUBMIT</code>) sind nicht
+    abgedeckt.</p>
+
+    <h3>Dynamische Konfiguration</h3>
+    <p><code>msg.config</code> ist ein Objekt, dessen Eigenschaften die Konfiguration dieses Nodes für genau diese Nachricht überschreiben. Die gespeicherte Konfiguration bleibt unverändert.</p>
+    <ul>
+        <li><code>iface</code></li>
+        <li><code>rooms</code></li>
+        <li><code>functions</code></li>
+        <li><code>device</code></li>
+        <li><code>deviceType</code></li>
+        <li><code>deviceName</code></li>
+        <li><code>channel</code></li>
+        <li><code>channelType</code></li>
+        <li><code>channelIndex</code></li>
+        <li><code>channelName</code></li>
+        <li><code>datapoint</code></li>
+        <li><code>force</code></li>
+        <li>sowie die zugehörigen <code>...Rx</code>-Selektoren</li>
+    </ul>
+    <p>Zusätzlich füllen gleichnamige Eigenschaften der Nachricht selbst (<code>msg.rooms</code> usw.) leer gelassene Felder — so war es schon immer.</p>
+</script>

package/nodes/locales/de/ccu-signal.html

@@ -0,0 +1,29 @@
+<script type="text/html" data-help-name="ccu-signal">
+    <p>Senden von LED- und Tonsignalen an Displaytaster und Funk-Gongs.</p>
+
+    <h3>Dynamische Konfiguration</h3>
+    <p><code>msg.config</code> ist ein Objekt, dessen Eigenschaften die Konfiguration dieses Nodes für genau diese Nachricht überschreiben. Die gespeicherte Konfiguration bleibt unverändert.</p>
+    <ul>
+        <li><code>iface</code></li>
+        <li><code>channel</code></li>
+        <li><code>channelType</code></li>
+        <li><code>chime</code></li>
+        <li><code>led</code></li>
+        <li><code>signal</code></li>
+        <li><code>volume</code></li>
+        <li><code>repeat</code></li>
+        <li><code>repetitions</code></li>
+        <li><code>durationUnit</code></li>
+        <li><code>durationValue</code></li>
+        <li><code>rampTimeUnit</code></li>
+        <li><code>rampTimeValue</code></li>
+        <li><code>acousticAlarmSelection</code></li>
+        <li><code>opticalAlarmSelection</code></li>
+        <li><code>dimmerLevel</code></li>
+        <li><code>dimmerColor</code></li>
+        <li><code>dimmerList</code></li>
+        <li><code>soundLevel</code></li>
+        <li><code>soundList</code></li>
+    </ul>
+    <p><code>soundList</code> und <code>dimmerList</code> akzeptieren auch ein einfaches Array von Werten, z.B. <code>msg.config.soundList = [1, 2]</code>.</p>
+</script>

package/nodes/locales/de/ccu-switch.html

@@ -0,0 +1,18 @@
+<script type="text/html" data-help-name="ccu-switch">
+    <p>Nachricht abhängig von einem Zustand eines Aktors oder einer Systemvariablen weiterleiten.</p>
+    <h3>Details</h3>
+    <p>Der ccu switch Node verhält sich ähnlich wie der switch Node von Node-RED. Er leitet eine Nachricht abhängig von einem Zustand eines Aktors oder einer Systemvariablen weiter, wahlweise auch je nach Zustand an unterschiedliche Ausgänge.</p>
+    <h4>Dokumentation</h4>
+    <a target="_blank" href="https://github.com/rdmtc/RedMatic/wiki/CCU-Nodes#ccu-switch-node">ccu switch node im RedMatic Wiki</a>
+
+    <h3>Dynamische Konfiguration</h3>
+    <p><code>msg.config</code> ist ein Objekt, dessen Eigenschaften die Konfiguration dieses Nodes für genau diese Nachricht überschreiben. Die gespeicherte Konfiguration bleibt unverändert.</p>
+    <ul>
+        <li><code>iface</code></li>
+        <li><code>channel</code></li>
+        <li><code>datapoint</code></li>
+        <li><code>datapointProperty</code></li>
+        <li><code>sysvar</code></li>
+        <li><code>sysvarProperty</code></li>
+    </ul>
+</script>

package/nodes/locales/de/ccu-sysvar.html

@@ -0,0 +1,43 @@
+<script type="text/html" data-help-name="ccu-sysvar">
+    <p>Setzen und lesen von ReGaHSS Systemvariablen.</p>
+    <h3>Inputs</h3>
+    <dl class="message-properties">
+        <dt>payload
+            <span class="property-type">*</span>
+        </dt>
+        <dd>
+            Der Wert der der Systemvariablen zugewiesen werden soll.
+        </dd>
+    </dl>
+    <h3>Outputs</h3>
+     <ol class="node-ports">
+         <li>Output
+
+               <code>msg</code> Beispiel:<br>
+               <pre><code>
+{
+	"ccu": "localhost",
+	"iface": "ReGaHSS",
+	"type": "SYSVAR",
+	"name": "Anwesenheit",
+	"payload": false,
+	"value": false,
+	"valueType": "boolean",
+	"valueEnum": "nicht anwesend",
+	"ts": 1525197999611,
+	"lc": 1525197999611,
+	"enum": ["nicht anwesend", "anwesend"],
+	"id": 950,
+	"topic": "ReGaHSS/Anwesenheit"
+}
+               </code></pre>
+         </li>
+     </ol>
+
+    <h3>Dynamische Konfiguration</h3>
+    <p><code>msg.config</code> ist ein Objekt, dessen Eigenschaften die Konfiguration dieses Nodes für genau diese Nachricht überschreiben. Die gespeicherte Konfiguration bleibt unverändert.</p>
+    <ul>
+        <li><code>name</code></li>
+    </ul>
+    <p>Woher der zu schreibende Wert kommt, stellt das Feld <em>Wert aus</em> ein (msg/flow/global/env) — er muss nicht mehr in <code>msg.payload</code> stehen.</p>
+</script>