node-red-contrib-ccu 4.4.5 → 4.5.0

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>

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

@@ -0,0 +1,98 @@
+<script type="text/html" data-help-name="ccu-value">
+    <p>Geräte steuern und/oder Events von einem Gerät empfangen.</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; wer überall z.&nbsp;B. <code>hm/${Interface}/${channel}/${datapoint}</code> einträgt, bekommt überall
+        dasselbe Topic-Schema.</li>
+        <li><b>Interface</b>: Hier wird das Interface gewählt, über welches das gewüschnte Geräte angebunden ist.</li>
+        <li><b>Channel</b>: Der Kanal dessen Datenpunkte verwendet werden sollen. Er besteht aus der Serien- sowie der Kanalnummer. Eine Autovervollständigung hilft bei der Auswahl anhand der Klarnamen.</li>
+        <li><b>Datapoint</b>: Der Datenpunkt des Kanals, auch hier wird über eine Autovervollständigung die Auswahl vereinfacht. 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>ON_TIME</b>:
+            Zeit in Sekunden nach der ein Schaltaktor/Dimmer nach dem anschalten wieder ausgeschaltet werden soll.<br>
+            Dabei ist:
+            <ul>
+                <li><code>undefined</code> Keine automatische Ausschaltung</li>
+                <li><code>number</code> Eine feste Verzögerung in Sekunden</li>
+                <li><code>global</code>, <code>flow</code> Die Verzögerung in Sekunden wird aus einer Context-Variablen übernommen</li>
+                <li><code>msg</code> Die Verzögerung in Sekunden wird kann über eine msg property übergeben werden</li>
+            </ul>
+
+        </li>
+        <li><b>set Mode</b>:
+            Eine Erweiterung für Geräte, die sowohl den rx_mode BURST als auch WAKEUP unterstützen wie z.B.:
+            Batterie-Schaltaktoren oder Rauchmelder mit Sirenenfunktion. Mit dem Parameter kann in diesem Fall angegeben
+            werden, ob der übergebene Wert über BURST oder WAKEUP übertragen werden soll.
+            <ul>
+                <li><b>WAKEUP</b> - Überträgt den Wert sobald sich der entsprechende Empfänger bei der Zentrale meldet.</li>
+                <li><b>BURST</b> - Versucht alle BURST-Empfänger für die Übertragung aufzuwecken was sich negativ auf den DutyCycle und die Batterielaufzeit aller Burst-Empfänger auswirkt.</li>
+            </ul>
+        </li>
+        <li><b>Flags</b>:
+            <ul>
+                <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> </li>
+            </ul>
+
+        </li>
+    </ul>
+
+    <h3>Input</h3>
+    <p>
+        Für den Input des Value Node wird <code>msg.payload</code> als der Wert verwendet der in den Datenpunkt geschrieben wird.
+
+        Die Bestimmung des Datenpunkts sowie des Kanals und der Schnittstellen können hier dynamisch sein. Dazu werden die Eingabefelder leer gelassen und über die eingehende <code>msg</code> gesetzt.
+    </p>
+    <b>Option 1</b>: Interface, Channel und Datapoint können in der msg als Properties angegeben werden:
+    <code>
+<pre>{
+  "interface": "BidCos-RF",
+  "channel": "OEQ1868878:1",
+  "datapoint": "STATE",
+  "payload": true
+}</pre>
+    </code>
+
+    <b>Option 2</b>: Der Datenpunkt kann über <code>msg.topic</code> angegeben werden wobei Interface, Channel und Datapoint mit Punkt getrennt werden:
+    <code>
+<pre>{
+  "topic": "BidCos-RF.OEQ1868878:1.STATE",
+  "payload": true
+}</pre>
+    </code>
+    Oder in der Form, in der die Nodes ihre Topics ausgeben – mit Schrägstrichen, die letzten drei Teile zählen
+    (<code>ccu3/BidCos-RF/OEQ1868878:1/STATE</code>, <code>hm/BidCos-RF/OEQ1868878:1/STATE</code> und
+    <code>BidCos-RF/OEQ1868878:1/STATE</code> meinen denselben Datenpunkt), so dass das Topic eines Events unverändert
+    zurückgeschickt werden kann.
+
+
+    <h3>Output</h3>
+    <p>Der Value Node gibt nur Events aus, wenn Interface, Channel und Datapoint gesetzt sind. Die Nachricht ist die beim rpc-event Node beschriebene.</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>datapoint</code></li>
+        <li><code>force</code></li>
+    </ul>
+    <p>Eine Nachricht ohne <code>payload</code> schreibt nichts, richtet aber die Ausgabe-Seite des Nodes neu aus.</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>Queue und Erzwingen</h3>
+    <p>Mit <i>Queue</i> werden Schreibbefehle nacheinander gesendet, und ein Wert, den der Cache schon von einer anderen Quelle kennt, wird nicht noch einmal gesendet. Ein Wert, den dieser Node selbst zuletzt geschrieben hat, wird immer gesendet: ein von Hand bewegter Rollladen meldet auf seinem Steuerkanal keinen neuen Sollwert. <i>Erzwingen</i> (auch <code>msg.config.force</code>) sendet in jedem Fall.</p>
+</script>

package/nodes/locales/de/ccu-value.json

@@ -9,6 +9,7 @@
     "cache": "Beim Start letzten bekannten Wert ausgeben",
     "working": "Während WORKING keine Werte ausgeben",
     "queue": "Queue",
+    "force": "Erzwingen (Cache ignorieren)",
     "certainOnly": "Unsichere Werte verwerfen"
   }
 }

package/nodes/locales/en-US/ccu-alexa.html

@@ -0,0 +1,4 @@
+<script type="text/html" data-help-name="ccu-alexa">
+    <p>Connect Homematic Devices with node-red-contrib-alexa-smart-home. Connect a Node "alexa smart home v3" to the
+    input and "alexa smart home v3 state" to the output.</p>
+</script>

package/nodes/locales/en-US/ccu-connection.html

@@ -0,0 +1,41 @@
+<script type="text/html" data-help-name="ccu-connection">
+    <p>The connection node manages the connection to the CCU's interface processes and to its logic layer.</p>
+    <h3>Configuration</h3>
+    <ul>
+        <li><b>Name</b>: A name of your choice for this CCU configuration. It tells several CCUs apart and appears in every other CCU node.</li>
+        <li><b>CCU Address</b>: The IP address or host name of the CCU. With the RedMatic addon Node-RED runs on the CCU itself, so the loopback address <code>localhost</code> or <code>127.0.0.1</code> is the right one.</li>
+        <li><b>Listen Address</b>: The address of the network interface the RPC servers listen on for the CCU's events. On the CCU itself (RedMatic) this is <code>localhost</code> / <code>127.0.0.1</code> as well; <code>0.0.0.0</code> listens on every interface.</li>
+        <li><b>Init Address</b>: Normally the same as <i>Listen Address</i>: the address under which the CCU reaches Node-RED. It may stay empty.
+        <p>For advanced setups: when listening on every interface (<code>0.0.0.0</code>), when Node-RED runs in a container (Docker) behind NAT, or in other special networks, <i>Init Address</i> and <i>Listen Address</i> may have to differ.</p></li>
+        <li><b>BINRPC listening port</b>: The port of the BIN-RPC server the CCU sends its events to. Several connections (several connection nodes) each need a port of their own.</li>
+        <li><b>XMLRPC listening port</b>: The port of the XML-RPC server the CCU sends its events to. Several connections each need a port of their own.</li>
+        <li><b>Interfaces</b>: The interfaces to use. Untick what you do not have (no CUxD, no HmIP devices, say) to switch the unused parts off.
+            <ul>
+                <li>ReGaHSS: the CCU's logic layer, which holds the programs and system variables</li>
+                <li>BidCos-RF: Homematic radio</li>
+                <li>BidCos-Wired: Homematic wired</li>
+                <li>HmIP-RF: Homematic IP radio</li>
+                <li>VirtualDevices: heating groups and systems the CCU integrates, such as Osram Lightify</li>
+                <li>CUxD</li>
+                <li>CCU-Jack: the XML-RPC interface of the <a href="https://github.com/mdzio/ccu-jack" target="_blank">CCU-Jack</a> addon (port configurable, 2121 by default, 2122 with TLS)</li>
+            </ul>
+        </li>
+        <li><b>RPC ping</b> and <b>RPC ping timeout (s)</b>: How often the connection to the interface processes is checked with a ping, and after how many seconds without an answer it subscribes again. Off means no pings and no timeout-triggered re-init for this connection.</li>
+        <li><b>Rega poll</b>: Changes of system variables are not pushed by the CCU. With polling on, the variables and their values are read every <i>Rega poll interval</i> seconds.</li>
+        <li><b>Names/rooms refresh (min)</b>: How often channel names, rooms and functions are re-read; 0 never.</li>
+        <li><b>Queue timeout (ms)</b>, <b>Queue pause (ms)</b>: The write queue's timeout per write and the pause between two writes.</li>
+        <li><b>Context Store</b>: The Node-RED context store the states of all devices and variables are kept in. See <a target="_blank" href="https://nodered.org/docs/user-guide/context">Working with context</a> in the Node-RED documentation.</li>
+        <li><b>openccu-lite token</b>: Only for <a href="https://github.com/hobbyquaker/openccu-lite" target="_blank">openccu-lite</a>, a CCU firmware without ReGaHSS. Names, rooms and functions come from the system's metadata API there, which needs a token made under <i>Users</i> on the system. When Node-RED runs on the system itself (RedMatic) the field stays empty: the local token is read automatically. The token is kept, like the password, in Node-RED's credentials (encrypted in <code>flows_cred.json</code>, never in the flow, never in an export). A CCU, RaspberryMatic or OpenCCU ignores the field. openccu-lite has no system variables, programs or HM-Script; those nodes stay in the flow and report an error per message.</li>
+        <li><b>openccu-lite port</b>: Only needed when the system's web server is not on port 80 (443 with TLS).</li>
+        <li><b>Device data / Re-read device data</b>: Reads the device list of every connected interface again. New and changed devices (a channel whose type changed, say) get their datapoints fetched anew, removed ones leave the table. A device the CCU reports with a changed type or version is re-read without the button as well. The button needs a deployed connection.</li>
+        <li><b>Authentication</b>: Encryption and login for a CCU on the network (Node-RED not on the CCU). Both belong to the CCU's web server, which fronts the interface processes: on a CCU3 TLS and authentication are switched on in the firewall settings, on openccu-lite under <i>Remote access</i> (classic RPC). When Node-RED runs on the system itself (RedMatic; address <code>localhost</code> / <code>127.0.0.1</code>) the processes are reached directly on the loopback, BidCos over BIN-RPC, without TLS and without a login; these settings are then not used.
+            <ul>
+                <li>Enabled: The username and password are sent with every call (HTTP basic auth) to every XML-RPC interface (BidCos-RF, BidCos-Wired, HmIP-RF, VirtualDevices, CCU-Jack) and to the ReGaHSS. BIN-RPC (CUxD, the hidden BIN-RPC option for BidCos-RF) has no login. Without TLS the credentials travel in plain text, so the dialog switches TLS on with it.</li>
+                <li>TLS/SSL: Transport encryption. The interfaces are reached over the CCU's TLS ports (42000, 42001, 42010, 49292, ReGaHSS 48181, CCU-Jack 2122), openccu-lite's metadata API over 443. BIN-RPC has no TLS: with TLS on, BidCos-RF always goes over XML-RPC.</li>
+                <li>Ignore invalid TLS Certificates: Node-RED accepts an untrusted certificate too. Needed as long as the CCU uses its self-signed certificate.</li>
+                <li>Username: A user allowed to log in to the CCU.</li>
+                <li>Password: The user's password. It is kept in Node-RED's credentials (encrypted in <code>flows_cred.json</code>), not in the flow. A flow from a version before 4.4.6 that still carries it in plain text is taken over at the first start; the next deploy removes it from <code>flows.json</code>.</li>
+            </ul>
+            The other direction stays unencrypted: the CCU sends its events to the XML-RPC or BIN-RPC server Node-RED opens for it (<i>Listen Address</i>, <i>BINRPC</i> and <i>XMLRPC listening port</i>) without TLS and without a login - it cannot log in there or verify our certificate. Those ports should be open in the Node-RED host's firewall for the CCU only.</li>
+    </ul>
+</script>