node-red-contrib-ccu 4.4.5 → 4.5.1

package/CHANGELOG.md

@@ -5,6 +5,181 @@ Notable changes to node-red-contrib-ccu. Format follows
 user-visible symptom and the cause, not the commit list (the release notes
 append commits automatically).
 
+## 4.5.1 (2026-10-02)
+
+### Fixed
+
+- **A burst of `getParamsetDescription Error: XML-RPC fault: Invalid device`
+  at the first start after an update** (B-36). A device deleted from the CCU
+  while Node-RED was not running stayed in the cached device table
+  (`ccu_<host>.json`) and in the values cache (`ccu_values_<host>.json`).
+  At the start its paramset descriptions were queued from the cached table;
+  hmipserver answered `-2 Invalid device`, a failed description was never
+  remembered, so every lookup queued it again (one item per channel and
+  paramset, duplicates included), each fault was logged twice without the
+  address, and each one threw away and rebuilt the interface's RPC client.
+  Seen on a CCU3 after a remote had been replaced: 150 failed calls in 40 s.
+  Now a description the interface refuses with a fault is asked for once
+  per address and paramset in a run, with one warning that names the
+  address, the paramset and the fault (a device paired anew is asked
+  again); the queue holds each description key once; `deleteDevices` drops
+  the device's queued fetches and its address from the type lists, and the
+  values cache is pruned against the device table at the start and a few
+  seconds after a `deleteDevices` or the ReGa's value read (the ReGa keeps
+  reporting the datapoints of a deleted device). An XML-RPC fault no longer
+  closes and recreates the RPC client: only a transport error does; the
+  fault is logged once, with the arguments of the call.
+
+## 4.5.0 (2026-09-29)
+
+### Added
+
+- **TLS and authentication for every connection to a CCU on the network**
+  (task 5, #27). With _TLS/SSL_ on, all XML-RPC interfaces are reached over
+  the CCU's TLS ports (42000, 42001, 42010, 49292; CCU-Jack 2122), the ReGaHSS
+  over 48181 and openccu-lite's metadata api over 443; with _Authentication_
+  on, the username and password go out as HTTP basic auth on every call, the
+  `init` included, to every XML-RPC interface and the ReGaHSS. Both are the
+  CCU's web server's - a CCU3 switches them on in its firewall settings,
+  openccu-lite under remote access. A local connection (Node-RED on the
+  system, `localhost` / `127.0.0.1`) reaches the interface processes directly
+  on the loopback and uses neither, whatever the dialog says: https to a plain
+  port or credentials in a BIN-RPC frame only broke the connection before;
+  the dialog hides the fields for a loopback address and says so. BIN-RPC has
+  neither: with TLS on, BidCos-RF goes XML-RPC over TLS even when the hidden
+  `bcrfBinRpc` property asked for BIN-RPC (a warning names it); CUxD's BIN-RPC
+  never has them. Node-RED's own callback server for the CCU's events stays
+  plain HTTP - the CCU presents no credentials and cannot verify our
+  certificate; the help text says so and asks for a firewall rule on the
+  Node-RED host. Ticking _Authentication_ ticks _TLS/SSL_ with a notice in the
+  editor instead of a browser alert. Without _Ignore invalid TLS
+  certificates_, the CCU's self-signed certificate is refused, as before.
+
+- **One topic template in every node that emits, the value node's input
+  takes the emitted shape** (task 6, #39 @psi-4ward). The `get value` node has a _Topic_
+  field now, the same `${…}` template as rpc-event, value, sysvar, program,
+  rpc and script; empty (the default, and every existing flow) leaves
+  `msg.topic` as it came in. The value node's input accepts a datapoint
+  address in `msg.topic` in the shape the nodes emit
+  (`ccu3/BidCos-RF/OEQ1868878:1/STATE`, `hm/BidCos-RF/OEQ1868878:1/STATE`: the
+  last three slash-separated segments) besides the old
+  `BidCos-RF.OEQ1868878:1.STATE`, so an event's topic can be fed straight back.
+  No default changed: whoever wants one scheme everywhere enters e.g.
+  `hm/${Interface}/${channel}/${datapoint}` in each node; the README's _Topics_
+  section lists the defaults and the placeholders, the help texts of
+  rpc-event, value and get value the placeholders.
+
+- **Help texts for every node in German and English, as locale files**
+  (task 7, #58). The help moved from inline blocks in the node files into
+  `nodes/locales/de/` and `nodes/locales/en-US/`, the layout Node-RED
+  documents for node help: the runtime serves one language's text per
+  request through the same lookup as its own nodes (`de` and `de-DE` both
+  get the German text, everything else the English one) instead of shipping
+  every language's block with the node. German is the source; the English texts of the connection,
+  value, rpc-event, set-value, sysvar and switch nodes, which were missing or
+  one-line stubs, are complete now, the mqtt node's help describes its topics,
+  commands and payload formats in both languages, the set-value node's German
+  configuration list (empty bullets since 3.x) and the rpc-event node's output
+  section are written, and the value nodes link the eQ-3 HmIP device
+  documentation for what a datapoint means (@lolli78). A unit test guards
+  that every node has both files, that neither is a stub, and that no inline
+  help is left.
+
+### Fixed
+
+- **Writing one party-mode datapoint of an HmIP thermostat reset the other
+  two** (task 2, #156 @ben-5555, #161 @lolli78). An HmIP eTRV/WTH takes
+  `PARTY_TIME_START`, `PARTY_TIME_END` and `PARTY_SET_POINT_TEMPERATURE` only
+  together: a `setValue` of one of them put the others back to
+  `1999_11_30 00:00`, so party or holiday mode could not be set from the
+  value nodes at all. A write to one of the three through the value or
+  set-value node now goes out as one `putParamset` on `VALUES` with all
+  three, the other two taken from our own last write, the value cache or a
+  `getParamset` read of the channel - the way the WebUI writes them. The two
+  times may be given as the device's `YYYY_MM_DD HH:MM` string, a JavaScript
+  Date, an ISO string or epoch milliseconds; they are formatted for the device
+  in local time. Any other datapoint of the channel is written as before. The
+  older HM thermostats (`PARTY_MODE_SUBMIT`) are not covered.
+- **A callback call with an unknown interface id ended Node-RED** (B-32).
+  Anything on the system can connect to the connection's callback ports on
+  the loopback; a `system.listMethods` without parameters, an `event` with an
+  id that is not one of ours, or a `newDevices` list with a malformed entry
+  threw inside the RPC server's handler, which runs from an event emitter -
+  an uncaught `TypeError`, and the whole Node-RED process exited. Such a call
+  is now answered with an empty result (the method list for
+  `system.listMethods`) and logged at debug; a throw inside a handler is
+  logged as an error and answered instead of ending the process.
+- **A metadata api detection that timed out at start left the connection in
+  ReGa mode for good** (B-28). On openccu-lite the connection asks
+  `GET /api/meta/v1/version` once at start; when that probe ran into its 5 s
+  timeout - on a Raspberry Pi 3 Node-RED's own start blocks the event loop
+  long enough for that at every start, on a busy system now and then - the
+  connection settled for the ReGaHSS, the ReGa polls failed every 30 s and
+  names, rooms and functions stayed empty; the only re-detection ran from rare
+  error paths, at most every five minutes. A timeout, a refused connection or
+  a 502/503/504 is now taken as "not decided": the ReGa path starts as before,
+  the detection is repeated after 1, 2, 4, 8 s and then every 15 s (up to 20
+  times, then the five-minute rule again), and the failing ReGa poll asks for
+  a re-detection too. A CCU's 404 is still a conclusive "no".
+- **After an hmipserver restart HmIP-RF events stopped for up to ten minutes**
+  (B-29). hmipserver forgets its clients when it restarts and does not tell
+  them: the `init` had succeeded, nothing failed, and the events simply stopped
+  until the 600 s silence timeout called `init` again. The connection now
+  pings HmIP-RF after 30 s without an event and, when no event (the PONG)
+  arrives within 10 s, subscribes again at once - the interface shows
+  _waiting_ meanwhile, one warning names the reason, and the retry of 4.4.4
+  covers the time the process is down. A `newDevices` from the restarted
+  hmipserver (it sends one about 16 s in) triggers the ping right away, so
+  events are back well within a minute. An interface that never delivered an
+  event since its `init` is not re-subscribed on a missing PONG alone.
+- **A queued write of the same set point was dropped after the actuator had
+  been operated by hand** (B-19, #151 @vigeland). The value node's _Queue_ compared the
+  new value with the value cache, and the cache of a control channel
+  (HmIP-FROLL/BROLL `:4`, the status lives in `:3`) holds the echo of our own
+  last write for good - a blind moved by hand reports no new set point there,
+  so the same `1` could never be sent again while Homematic Manager moved the
+  blind at once. A cached value that is the echo of our own last write no
+  longer dedupes; only a value from another source does. The value node has a
+  _Force_ option (and `msg.config.force`), as set-value has it; set-value's
+  own pre-check no longer drops a forced write when the cache already holds
+  the value.
+
+### Security
+
+- **The CCU password and the openccu-lite token were stored in plain text in
+  `flows.json`** and went out with every exported flow (B-31). Both are
+  Node-RED credentials now (`flows_cred.json`, encrypted, never exported).
+  A flow written before this version still carries them as plain properties:
+  the connection uses them once, moves them into the credentials and warns;
+  the editor no longer knows the two properties, so the next deploy removes
+  them from `flows.json`. Nothing to do by hand.
+
+### Changed
+
+- **The device table follows the CCU, and can be re-read by hand** (task 9,
+  #146 @guny74, #181 @vore). A device or channel the CCU reports with another TYPE,
+  VERSION or FIRMWARE than the cache holds replaces the cached entry, leaves
+  its old type list and gets its datapoints fetched again - a channel whose
+  type changed in place kept its old datapoints before, until the cache file
+  was deleted. The connection node's dialog has a _Re-read device data_
+  button that asks every connected interface for its device list again
+  (new and changed devices get their datapoints, removed ones go) and
+  reports what changed. The editor's channel pickers no longer empty the
+  configured channel when the connection is still initialising: they show
+  _loading device data_ and ask again.
+- **An interface without devices is watched too** (task 9, old B-11). The
+  ping watchdog returned early for an interface with no devices in the
+  cache, so such an interface never pinged and never re-initialised after a
+  CCU reboot. It pings now, and re-initialises after the ping timeout once
+  it has ever delivered an event (a PONG counts) - a process that answers no
+  ping at all is not asked to `init` every timeout.
+- **The `listDevices` answer to hmipserver lists the CCU's virtual remote
+  control (HmIP-RCV-1) again** (task 13). It was left out since CCU3 firmware
+  3.43.15 (2019), whose hmipserver failed on an answer that held it; current
+  hmipservers take it, and without it every `init` made hmipserver log a
+  _handleIDMigration_ warning and send the whole virtual remote (52
+  descriptions) again with `newDevices`.
+
 ## 4.4.5 (2026-09-26)
 
 ### Fixed

package/README.md

@@ -41,6 +41,28 @@ ReGaHSS; the connection node detects this at start (`GET /api/meta/v1/version`),
 - **System variables, programs and HM-Script do not exist there.** The `ccu-sysvar`, `ccu-program`, `ccu-script` and
   `ccu-poll` nodes stay in the flows and answer every message with an error.
 
+## Topics
+
+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.
+
 ## Home Assistant
 
 The `ccu-homeassistant` node publishes

package/nodes/ccu-alexa.html

@@ -30,6 +30,7 @@
             let ifacesLoaded = false;
             let ifacesPending = false;
             let ifaceLoadRetries = 5;
+            let channelLoadRetries = 30;
 
             function loadIfaces(iface, cb) {
                 if (ifacesPending) {
@@ -73,7 +74,16 @@
 
                 const nodeId = $nodeInputCcuConfig.val();
                 const url = 'ccu?config=' + nodeId + '&type=channels&iface=' + $nodeInputIface.val();
-                $.getJSON(url, d => {
+                $.getJSON(url, (d, _status, xhr) => {
+                    // task 9: an empty list while the connection is still initialising is "not yet",
+                    // not "nothing" - keep what is configured, say so, and ask again
+                    if (Object.keys(d).length === 0 && xhr.getResponseHeader('X-CCU-Loading') && channelLoadRetries-- > 0) {
+                        $nodeInputChannel.attr('placeholder', 'loading device data ...');
+                        setTimeout(loadConfig, 2000);
+                        return;
+                    }
+
+                    $nodeInputChannel.removeAttr('placeholder');
                     data = d;
                     autocompleteChannel();
                 });
@@ -124,7 +134,7 @@
 
                 // ${ENV} placeholders are substituted by Node-RED before the node is
                 // constructed (subflow parameters, #158) - do not clear them
-                if (!/^\$\{[^}]+\}$/.test($nodeInputChannel.val()) && !data[$nodeInputChannel.val().split(' ')[0]]) {
+                if (Object.keys(data).length > 0 && !/^\$\{[^}]+\}$/.test($nodeInputChannel.val()) && !data[$nodeInputChannel.val().split(' ')[0]]) {
                     $nodeInputChannel.val('');
                 }
             }
@@ -170,21 +180,9 @@
         <input type="text" id="node-input-channel">
     </div>
 
-
     <div class="form-row">
         <label for="node-input-name"><i class="icon-bookmark"></i> Name</label>
         <input type="text" id="node-input-name">
     </div>
 
-
-</script>
-
-<script type="text/x-red" data-help-name="ccu-alexa" lang="de">
-    <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>
-
-<script type="text/x-red" data-help-name="ccu-alexa" lang="en-US">
-    <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/ccu-connection.html

@@ -29,9 +29,7 @@
             inSecure: {value: false},
             authentication: {value: false},            
             username: {value: ''},
-            password: {value: ''},
 
-            metaToken: {value: ''},
             metaPort: {value: ''},
 
             queueTimeout: {value: 5000, required: true},
@@ -39,6 +37,12 @@
 
             contextStore: {value: ''}
         },
+        // B-31: the CCU password and the openccu-lite token live in Node-RED's
+        // credentials (flows_cred.json, encrypted, never exported), not in the flow
+        credentials: {
+            password: {type: 'password'},
+            metaToken: {type: 'password'}
+        },
         label() {
             return this.name || this.host;
         },
@@ -133,17 +137,51 @@
                     $nodeConfigInputHost.focus();
                 }
             }, 250);
-        }
-    });
 
-    // called from the inline onclick attribute of the authentication checkbox
-    // eslint-disable-next-line no-unused-vars
-    function TLSSSL(){        
-        if (document.getElementById('node-config-input-authentication').checked && !document.getElementById('node-config-input-tls').checked){
-            document.getElementById('node-config-input-tls').checked = true
-            alert('TLS/SSL activated. \nWithout TLS/SSL your credentials would be sent unencrypted!')
+            // task 5 (#27): credentials without TLS travel in plain text - turning
+            // authentication on turns TLS on too (it can be unticked again)
+            const $auth = $('#node-config-input-authentication');
+            const $tls = $('#node-config-input-tls');
+            $auth.on('change', () => {
+                if ($auth.is(':checked') && !$tls.is(':checked')) {
+                    $tls.prop('checked', true);
+                    RED.notify('TLS/SSL switched on: without it the credentials would be sent in plain text.', {type: 'warning', timeout: 6000});
+                }
+            });
+
+            // a loopback address is Node-RED on the system: the interface processes are
+            // reached directly, TLS and credentials are not used (lib/localccu.js)
+            const isLoopback = host => /^(127\.|localhost$|::1$)/.test(String(host || '').trim());
+            const showAuthRows = () => {
+                const local = isLoopback($nodeConfigInputHost.val());
+                $('#node-config-auth-fields, #node-config-auth-hint').toggle(!local);
+                $('#node-config-input-username, #node-config-input-password').closest('.form-row').toggle(!local);
+                $('#node-config-auth-local').toggle(local);
+            };
+            $nodeConfigInputHost.on('change keyup', showAuthRows);
+            showAuthRows();
+
+            // task 9: re-read the device table of the deployed connection
+            const $reread = $('#node-config-reread');
+            const $rereadStatus = $('#node-config-reread-status');
+            $reread.on('click', () => {
+                $reread.prop('disabled', true);
+                $rereadStatus.text('Re-reading ...');
+                $.ajax({url: 'ccu/' + this.id + '/reread', type: 'POST', dataType: 'json'})
+                    .done(summary => {
+                        const parts = Object.keys(summary).map(iface => {
+                            const s = summary[iface];
+                            return iface + ': ' + (s.error ? s.error : s.total + ' entries (' + s.added + ' new, ' + s.changed + ' changed, ' + s.removed + ' removed)');
+                        });
+                        $rereadStatus.text(parts.length > 0 ? parts.join('; ') : 'no interface connected');
+                    })
+                    .fail(xhr => {
+                        $rereadStatus.text(xhr.status === 404 ? 'Deploy this connection first.' : 'Failed: ' + (xhr.responseJSON && xhr.responseJSON.error || xhr.statusText));
+                    })
+                    .always(() => $reread.prop('disabled', false));
+            });
         }
-    }
+    });
 
 </script>
 
@@ -206,6 +244,13 @@
         <label for="node-config-input-rpcPingTimeout"><i class="icon-tag"></i> RPC ping timeout (s)</label>
         <input type="text" id="node-config-input-rpcPingTimeout">
     </div>
+    <div class="form-row">
+        <label for="node-config-reread"><i class="icon-tag"></i> Device data</label>
+        <div style="width: 70%; display: inline-block; vertical-align: text-top;">
+            <button type="button" class="red-ui-button" id="node-config-reread">Re-read device data</button><br>
+            <small id="node-config-reread-status">Asks every connected interface for its device list again; new and changed devices get their datapoints fetched, removed ones go.</small>
+        </div>
+    </div>
     <div class="form-row">
         <label for="node-config-input-regaPoll"><i class="icon-tag"></i> Rega poll</label>
         <div style="width: 70%; display: inline-block; vertical-align: text-top;">
@@ -238,9 +283,13 @@
     <div class="form-row">
         <label for="node-config-input-authentication"><i class="icon-tag"></i> Authentication</label>
         <div style="width: 70%; display: inline-block; vertical-align: text-top;">
-            <label class="ccu-checkbox"><input type="checkbox" id="node-config-input-authentication" onclick="TLSSSL()"> Enabled</label><br>
-            <label class="ccu-checkbox"><input type="checkbox" id="node-config-input-tls"> TLS/SSL</label><br>
-            <label class="ccu-checkbox"><input type="checkbox" id="node-config-input-inSecure"> Ignore invalid TLS Certificates</label><br>
+            <span id="node-config-auth-fields">
+                <label class="ccu-checkbox"><input type="checkbox" id="node-config-input-authentication"> Enabled</label><br>
+                <label class="ccu-checkbox"><input type="checkbox" id="node-config-input-tls"> TLS/SSL</label><br>
+                <label class="ccu-checkbox"><input type="checkbox" id="node-config-input-inSecure"> Ignore invalid TLS Certificates</label><br>
+            </span>
+            <small id="node-config-auth-hint">For a CCU on the network: TLS uses the CCU's 4xxxx ports, the credentials are sent as HTTP basic auth (switch both on in the CCU's firewall settings, on openccu-lite under remote access). Node-RED's own callback server for the CCU's events stays plain HTTP.</small>
+            <small id="node-config-auth-local" style="display: none;">Node-RED runs on the system itself: the interface processes are reached directly on the loopback (BIN-RPC for BidCos), without TLS and without credentials. These settings are not used.</small>
         </div>
     </div>
     <div class="form-row">
@@ -262,84 +311,3 @@
         <small>Only needed when the box's web server is not on the default port.</small>
     </div>
 </script>
-
-
-
-
-<script type="text/x-red" data-help-name="ccu-connection" lang="de-DE">
-        <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 der Box;
-                dafür wird ein Token benötigt, das auf der Box unter <i>Benutzer</i> erzeugt wird. Läuft Node-RED
-                auf der Box selbst (RedMatic), bleibt das Feld leer – das lokale Token wird dann automatisch gelesen.
-                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 der Box nicht auf Port 80 bzw. 443 (TLS) läuft.</li>
-            </ul>
-            <ul>
-                <li><b>Authentication</b>: Hier kann angegeben werden wie mit der CCU Kommuniziert werden soll.</li>
-                <ul>
-                    <li>Enabled: Es soll via Benutzer/Passwort kommuniziert werden</li>
-                    <li>TLS/SSL: Aktiviert die Transportverschlüsselung</li>
-                    <li>Ignore invalid TLS Certificates: Node-RED akzeptiert nicht vertrauenswürdige Zertifikate. Notwendig wenn die CCU kein vertrauenswürdiges Zertifikat hat.</li>
-                    <li>Username: Ein Benutzer der sich an der CCU anmelden darf.</li>
-                    <li>Password: Das Passwort des Benutzers.</li>                    
-                </ul>
-            </ul>
-</script>