node-red-contrib-ccu 4.4.4 → 4.5.0

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>

package/nodes/locales/en-US/ccu-get-value.html

@@ -0,0 +1,13 @@
+<script type="text/html" data-help-name="ccu-get-value">
+    <p>This Node outputs the current state of a datapoint or a ccu variable on any incoming message.</p>
+    <h3>Configuration</h3>
+    <ul>
+        <li><b>Topic</b>: <code>msg.topic</code> of the outgoing message, the same template as in the other 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>; for a variable <code>${Name}</code>), e.g.
+        <code>${CCU}/${Interface}/${channel}/${datapoint}</code>. Empty (the default): <code>msg.topic</code> stays as it
+        came in.</li>
+    </ul>
+    <p>What a datapoint means, its range and unit: the <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf" target="_blank">eQ-3 HmIP device documentation (PDF)</a>.</p>
+</script>

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

@@ -0,0 +1,23 @@
+<script type="text/html" data-help-name="ccu-homeassistant">
+    <p>Publishes Home Assistant MQTT discovery configurations for selected devices.</p>
+    <p>The node is a companion to the <b>ccu-mqtt</b> node: it reuses that node's topic templates and
+    payload format, so the discovery configs point at the topics ccu-mqtt already publishes and
+    consumes. State and commands keep flowing through ccu-mqtt.</p>
+    <h3>Wiring</h3>
+    <p>Connect the output to the same <b>mqtt out</b> node as the ccu-mqtt node. The node sends
+    <code>msg.topic</code>, <code>msg.payload</code> and <code>msg.retain</code>.</p>
+    <h3>Device selection</h3>
+    <p>Only checked devices are announced to Home Assistant (one HA device per Homematic device).
+    Unchecking a previously checked device publishes an empty config on the next deploy, which
+    removes the device from Home Assistant.</p>
+    <h3>Entities</h3>
+    <p>Switches, dimmers (light), blinds/shutters (cover), thermostats (climate), contacts/motion/
+    smoke/water (binary_sensor), keys (event), KeyMatic (lock), energy/weather (sensor). With the
+    <i>other datapoints</i> option every remaining datapoint is included as an entity that is
+    disabled by default.</p>
+    <h3>Input</h3>
+    <p>Any incoming message republishes the discovery configs.</p>
+    <h3>Requirements</h3>
+    <p>Home Assistant ≥ 2024.11 (device-based discovery). Device availability is derived from the
+    UNREACH datapoint of the maintenance channel.</p>
+</script>

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

@@ -0,0 +1,21 @@
+<script type="text/html" data-help-name="ccu-mqtt">
+    <p>Connect the CCU to MQTT: device events and system variable changes go out as messages with a ready-made topic, incoming messages switch, read or call RPC methods. Wire the node between an <i>mqtt in</i> and an <i>mqtt out</i> node.</p>
+    <h3>Configuration</h3>
+    <ul>
+        <li><b>CCU</b>: The CCU configuration to use.</li>
+        <li><b>Cache</b>: At start the cached values of all datapoints are emitted once.</li>
+        <li><b>Topics</b>, each a template with placeholders (<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>: outgoing device events, default <code>hm/status/${channelName}/${datapoint}</code>.</li>
+                <li><b>setValue</b>: incoming, writes <code>payload</code> into the datapoint; <code>${channelNameOrAddress}</code> takes the channel's name or its address.</li>
+                <li><b>get</b>: incoming, emits the datapoint's cached value on the event topic.</li>
+                <li><b>Sysvar/Program Change</b>: outgoing, changes of system variables and programs; <b>Sysvar/Program Set</b>: incoming, sets a variable or starts a program.</li>
+                <li><b>putParam</b>, <b>putParamset</b>: incoming, writes one parameter or a whole paramset (<code>MASTER</code>, <code>VALUES</code>) given as JSON.</li>
+                <li><b>RPC</b>: incoming, calls an RPC method of the interface (<code>payload</code>: the parameters as a JSON array); the answer goes out on the <b>RPC Response</b> topic with the same <code>${callid}</code>.</li>
+                <li><b>Message Counters</b>: outgoing, the counters of received and sent messages per interface (<code>${rxtx}</code> = <code>rx</code>/<code>tx</code>).</li>
+            </ul>
+        </li>
+        <li><b>Output Payload</b>: <i>Plain</i> (the value only), <i>MQTT-Smarthome JSON Basic</i> (<code>{"val", "ts", "lc"}</code>) or <i>MQTT-Smarthome JSON Extended</i> (plus the message's Homematic properties: <code>hm.iface</code>, <code>hm.channel</code>, <code>hm.datapoint</code> and so on). Incoming, a bare value and an object with <code>val</code> are both understood.</li>
+    </ul>
+    <p>For Home Assistant the <i>ccu-homeassistant</i> node publishes the discovery configurations for these topics.</p>
+</script>

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

@@ -0,0 +1,7 @@
+<script type="text/html" data-help-name="ccu-poll">
+    <p>Triggers an immediate polling of Sysvars from ReGaHSS.</p>
+    <p>This node is intended to receive changes of variables with lower latency. You can create a CCU Program that
+    reacts to variable changes by pressing a virtual button, this virtual button presses can then be received by a
+    <i>value</i> or <i>rpc event</i> node that triggers an update of the variables through the <i>ccu poll</i>
+    node.</p>
+</script>

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

@@ -0,0 +1,25 @@
+<script type="text/html" data-help-name="ccu-program">
+    <p>Executes a ReGaHSS program.</p>
+    <h3>Inputs</h3>
+    <dl class="message-properties">
+        <dt>payload
+            <span class="property-type">*</span>
+        </dt>
+        <dd>
+            If the payload is of type boolean the program gets (de)activated. On activation it is executed also. In all
+            other cases the program will be executed.
+        </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>
+                    The payload contains a timestamp of the last program run (property <code>ts</code> and the
+                    information if the program is activated (property <code>active</code>).
+                 </dd>
+             </dl>
+         </li>
+     </ol>
+</script>

package/nodes/locales/en-US/ccu-rpc-event.html

@@ -0,0 +1,31 @@
+<script type="text/html" data-help-name="ccu-rpc-event">
+    <p>Emits the CCU's events: one message per datapoint change that passes the filters.</p>
+    <h3>Configuration</h3>
+    <ul>
+        <li><b>CCU</b>: The CCU configuration to use.</li>
+        <li><b>Topic</b>: <code>msg.topic</code> of the outgoing messages, with placeholders: <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>. Every node that emits messages has the same template
+        (value, get value, sysvar, program, rpc, script).</li>
+        <li><b>Interface</b>: The interface the devices are connected through; <code>*</code> passes the events of every connected interface.</li>
+        <li><b>room</b>: Room filter, e.g. <code>Living room</code>.</li>
+        <li><b>function</b>: Function filter, e.g. <code>Buttons</code>.</li>
+        <li><b>device</b>: The serial number of the device, e.g. <code>OEQ1662328</code>.</li>
+        <li><b>deviceName</b>: The device's name in the CCU, e.g. <code>Smoke detector study</code>; every smoke detector with a regular expression: <code>Smoke detector.*</code>.</li>
+        <li><b>deviceType</b>: The device type, e.g. <code>HM-Sec-SD-2</code>.</li>
+        <li><b>channel</b>: The channel address - serial number and channel index, e.g. <code>OEQ1245312:4</code>.</li>
+        <li><b>channelName</b>: The channel's name in the CCU, e.g. <code>Bathroom ceiling light PIR</code>.</li>
+        <li><b>channelType</b>: The channel type, e.g. <code>VIRTUAL_KEY</code> or <code>DIMMER</code>.</li>
+        <li><b>channelIndex</b>: The channel index, e.g. <code>2</code>.</li>
+        <li><b>datapoint</b>: The channel's datapoint, e.g. <code>PRESS_SHORT</code> or <code>ACTUAL_TEMPERATURE</code>. What a datapoint means:
+        the <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf" target="_blank">eQ-3 HmIP device documentation (PDF)</a>.</li>
+        <li><b>Only changed values</b> - an event is emitted only when the value differs from the last event's.</li>
+        <li><b>No values while WORKING</b> - dimmers and blinds report their state continuously during a ramp (a blind moving, a lamp dimming). This option emits the end state only; useful with dashboard nodes to keep sliders from jumping.</li>
+        <li><b>Emit the last known value at start</b> - when Node-RED starts, the last value (as far as known) is emitted, e.g. to hand a dashboard a correct value at start. <b>Note:</b> if the emitted message ends in a Homematic write further down the flow, every (full) deploy costs duty cycle.</li>
+    </ul>
+    <p>Every filter is a text or, with the selector next to it, a regular expression; an empty filter matches everything. A message must pass all filters that are set.</p>
+
+    <h3>Output</h3>
+    <p>One message per event. Besides <code>payload</code> (the value) it carries the datapoint's context: <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> and <code>lc</code> (the event's time, the previous event's, the last change's), <code>change</code>, <code>cache</code> (true for a value emitted at start), <code>working</code>, <code>direction</code>, <code>uncertain</code>, and <code>topic</code> as configured.</p>
+</script>

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

@@ -0,0 +1,30 @@
+<script type="text/html" data-help-name="ccu-rpc">
+    <p>Executes a RPC method and outputs the return value.</p>
+    <h3>Inputs</h3>
+    <dl class="message-properties">
+        <dt>topic
+            <span class="property-type">String</span>
+        </dt>
+        <dd>
+            The method that should be called
+        </dd>
+        <dt>payload
+            <span class="property-type">Array|String</span>
+        </dt>
+        <dd>
+            An array or an JSON string containing an array of parameters for the rpc call.
+        </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>
+                    The return value of the rpc call.
+                 </dd>
+             </dl>
+         </li>
+     </ol>
+</script>

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

@@ -0,0 +1,13 @@
+<script type="text/html" data-help-name="ccu-script">
+    <p>Runs an HM-Script (ReGaHSS) on the CCU and emits its result.</p>
+    <h3>Configuration</h3>
+    <ul>
+        <li><b>CCU</b>: The CCU configuration to use.</li>
+        <li><b>Topic</b>: <code>msg.topic</code> of the outgoing message, a template with placeholders (<code>${CCU}</code>, <code>${Interface}</code>), default <code>${CCU}/${Interface}</code>.</li>
+        <li><b>Script</b>: The script. Left empty, <code>msg.payload</code> of the incoming message is run as the script.</li>
+    </ul>
+    <h3>Input</h3>
+    <p>Every incoming message runs the script; without a configured script <code>msg.payload</code> is the script.</p>
+    <h3>Output</h3>
+    <p><code>msg.payload</code> is the script's output (what it writes with <code>WriteLine</code>), <code>msg.objects</code> the values of the variables the script set, plus <code>iface</code> (<code>ReGaHSS</code>) and <code>ccu</code>. A script that does not run to its end reports <i>Script call failed</i>. openccu-lite has no ReGaHSS; the node reports an error per message there.</p>
+</script>

package/nodes/locales/en-US/ccu-set-value.html

@@ -0,0 +1,45 @@
+<script type="text/html" data-help-name="ccu-set-value">
+    <p>Write one value to several devices at once: every channel the filters match gets <code>msg.payload</code> written into the chosen datapoint.</p>
+    <h3>Configuration</h3>
+    <ul>
+        <li><b>CCU</b>: The CCU configuration to use.</li>
+        <li><b>Interface</b>: The interface whose devices are addressed; <code>*</code> for every connected interface.</li>
+        <li><b>room</b>, <b>function</b>: Room and function filters, e.g. <code>Living room</code>, <code>Lights</code>.</li>
+        <li><b>device</b>, <b>deviceName</b>, <b>deviceType</b>: Filters on the device's serial number, CCU name and type, e.g. <code>OEQ1662328</code>, <code>Ceiling lamp.*</code>, <code>HM-LC-Sw1-FM</code>.</li>
+        <li><b>channel</b>, <b>channelName</b>, <b>channelType</b>, <b>channelIndex</b>: Filters on the channel address (<code>OEQ1245312:4</code>), channel name, channel type (<code>SWITCH</code>, <code>DIMMER</code>) and channel index.</li>
+        <li><b>datapoint</b>: The datapoint written to, e.g. <code>STATE</code> or <code>LEVEL</code>. What a datapoint means, its range and unit:
+        the <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf" target="_blank">eQ-3 HmIP device documentation (PDF)</a>.</li>
+        <li><b>force</b>: Writes even when the cache already holds the value (see <i>Queue and force</i> in the value node's help).</li>
+    </ul>
+    <p>Every filter is a text or, with the selector next to it, a regular expression; an empty filter matches everything. The value is written to every channel that passes all filters set and has the datapoint.</p>
+
+    <h3>Input</h3>
+    <p><code>msg.payload</code> is the value written. Filters left empty are filled from properties of the message with the same name (<code>msg.iface</code>, <code>msg.rooms</code>, <code>msg.channel</code>, <code>msg.datapoint</code> and so on); <code>msg.config</code> overrides the configuration for that one message (below).</p>
+
+    <h3>Party and holiday mode (HmIP)</h3>
+    <p>An HmIP thermostat (eTRV, WTH) takes <code>PARTY_TIME_START</code>, <code>PARTY_TIME_END</code> and
+    <code>PARTY_SET_POINT_TEMPERATURE</code> only together; written alone, one resets the other two. A write to one of the
+    three therefore goes out as one <code>putParamset</code> with all three - the other two from our own last write, the
+    value cache or a read from the device. The times may be the device's own <code>YYYY_MM_DD HH:MM</code> string, a
+    JavaScript Date, an ISO string or epoch milliseconds; they are formatted for the device in local time. The older HM
+    thermostats (<code>PARTY_MODE_SUBMIT</code>) are not covered.</p>
+
+    <h3>Dynamic configuration</h3>
+    <p><code>msg.config</code> is an object whose properties override this node's configuration for that one message. The stored configuration is never modified.</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>and the matching <code>...Rx</code> selectors</li>
+    </ul>
+    <p>Properties of the message itself (<code>msg.rooms</code> and so on) also fill in fields left empty in the dialog, as they always did.</p>
+</script>

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

@@ -0,0 +1,29 @@
+<script type="text/html" data-help-name="ccu-signal">
+    <p>Send LED- and Sound-Signals.</p>
+
+    <h3>Dynamic configuration</h3>
+    <p><code>msg.config</code> is an object whose properties override this node's configuration for that one message. The stored configuration is never modified.</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> and <code>dimmerList</code> also accept a plain array of values, e.g. <code>msg.config.soundList = [1, 2]</code>.</p>
+</script>

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

@@ -1,4 +1,10 @@
 <script type="text/html" data-help-name="ccu-switch">
+    <p>Route a message depending on the state of an actuator or a system variable.</p>
+    <h3>Details</h3>
+    <p>The ccu switch node behaves like Node-RED's own switch node: it routes a message depending on the state of an actuator (a datapoint's property) or a system variable, to different outputs per rule if wanted. <i>Interface</i>, <i>Channel</i>/<i>Datapoint</i> or <i>Sysvar</i> and <i>Property</i> pick the value the rules are checked against.</p>
+    <h4>Documentation</h4>
+    <a target="_blank" href="https://github.com/rdmtc/RedMatic/wiki/CCU-Nodes#ccu-switch-node">ccu switch node in the RedMatic wiki</a> (German)
+
     <h3>Dynamic configuration</h3>
     <p><code>msg.config</code> is an object whose properties override this node's configuration for that one message. The stored configuration is never modified.</p>
     <ul>

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

@@ -0,0 +1,42 @@
+<script type="text/html" data-help-name="ccu-sysvar">
+    <p>Set and read ReGaHSS system variables.</p>
+        <h3>Inputs</h3>
+    <dl class="message-properties">
+        <dt>payload
+            <span class="property-type">*</span>
+        </dt>
+        <dd>
+            The value that should be assigned to the variable.
+        </dd>
+    </dl>
+
+    <h3>Outputs</h3>
+    <ol class="node-ports">
+        <li>Output - every change of the variable (with <i>Rega poll</i> on in the connection) and, after a write, its new state. <code>msg</code> example:<br>
+            <pre><code>
+{
+	"ccu": "localhost",
+	"iface": "ReGaHSS",
+	"type": "SYSVAR",
+	"name": "Presence",
+	"payload": false,
+	"value": false,
+	"valueType": "boolean",
+	"valueEnum": "absent",
+	"ts": 1525197999611,
+	"lc": 1525197999611,
+	"enum": ["absent", "present"],
+	"id": 950,
+	"topic": "ReGaHSS/Presence"
+}
+            </code></pre>
+        </li>
+    </ol>
+
+    <h3>Dynamic configuration</h3>
+    <p><code>msg.config</code> is an object whose properties override this node's configuration for that one message. The stored configuration is never modified.</p>
+    <ul>
+        <li><code>name</code></li>
+    </ul>
+    <p>The <em>Value from</em> field selects where the value to write comes from (msg/flow/global/env); it no longer has to be <code>msg.payload</code>.</p>
+</script>

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

@@ -0,0 +1,81 @@
+<script type="text/html" data-help-name="ccu-value">
+    <p>Control a device and/or receive its events: one datapoint of one channel.</p>
+    <h3>Configuration</h3>
+    <ul>
+        <li><b>CCU</b>: The CCU configuration to use.</li>
+        <li><b>Topic</b>: <code>msg.topic</code> of the outgoing messages, with placeholders: <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>. Every node that emits messages has the same template;
+        enter e.g. <code>hm/${Interface}/${channel}/${datapoint}</code> everywhere for one topic scheme.</li>
+        <li><b>Interface</b>: The interface the device is connected through.</li>
+        <li><b>Channel</b>: The channel whose datapoint is used - its serial number and channel index. Autocomplete finds it by its name.</li>
+        <li><b>Datapoint</b>: The channel's datapoint, with autocomplete as well. What a datapoint means, its range and unit:
+        the <a href="https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_Device_Documentation.pdf" target="_blank">eQ-3 HmIP device documentation (PDF)</a>.</li>
+        <li><b>ON_TIME</b>: Seconds after which a switch or dimmer is switched off again once switched on:
+            <ul>
+                <li><code>undefined</code> no automatic switch-off</li>
+                <li><code>number</code> a fixed delay in seconds</li>
+                <li><code>global</code>, <code>flow</code> the delay in seconds comes from a context variable</li>
+                <li><code>msg</code> the delay in seconds comes from a message property</li>
+            </ul>
+        </li>
+        <li><b>set Mode</b>: For devices that support both the BURST and the WAKEUP rx_mode, such as battery switch actuators or smoke detectors with a siren: whether the value goes out through BURST or WAKEUP.
+            <ul>
+                <li><b>WAKEUP</b> - sends the value once the receiver reports to the CCU.</li>
+                <li><b>BURST</b> - wakes every BURST receiver up for the transmission, which costs duty cycle and the battery life of all burst receivers.</li>
+            </ul>
+        </li>
+        <li><b>Flags</b>:
+            <ul>
+                <li><b>Only changed values</b> - an event is emitted only when the value differs from the last event's.</li>
+                <li><b>No values while WORKING</b> - dimmers and blinds report their state continuously during a ramp (a blind moving, a lamp dimming). This option emits the end state only; useful with dashboard nodes to keep sliders from jumping.</li>
+                <li><b>Emit the last known value at start</b> - when Node-RED starts, the last value (as far as known) is emitted, e.g. to hand a dashboard a correct value at start. <b>Note:</b> if the emitted message ends in a Homematic write further down the flow, every (full) deploy costs duty cycle.</li>
+            </ul>
+        </li>
+    </ul>
+
+    <h3>Input</h3>
+    <p><code>msg.payload</code> is the value written to the datapoint. Interface, channel and datapoint may come from the message: leave the fields empty and set them through the incoming <code>msg</code>.</p>
+    <b>Option 1</b>: as message properties:
+    <code>
+<pre>{
+  "interface": "BidCos-RF",
+  "channel": "OEQ1868878:1",
+  "datapoint": "STATE",
+  "payload": true
+}</pre>
+    </code>
+    <b>Option 2</b>: through <code>msg.topic</code>, interface, channel and datapoint separated by dots:
+    <code>
+<pre>{
+  "topic": "BidCos-RF.OEQ1868878:1.STATE",
+  "payload": true
+}</pre>
+    </code>
+    Or in the shape the nodes emit their topics in - with slashes, the last three segments count
+    (<code>ccu3/BidCos-RF/OEQ1868878:1/STATE</code>, <code>hm/BidCos-RF/OEQ1868878:1/STATE</code> and
+    <code>BidCos-RF/OEQ1868878:1/STATE</code> address the same datapoint), so an event's topic can be fed straight back.
+
+    <h3>Output</h3>
+    <p>The value node emits events only when interface, channel and datapoint are set. The message is the one described for the rpc-event node.</p>
+
+    <h3>Dynamic configuration</h3>
+    <p><code>msg.config</code> is an object whose properties override this node's configuration for that one message. The stored configuration is never modified.</p>
+    <ul>
+        <li><code>iface</code></li>
+        <li><code>channel</code></li>
+        <li><code>datapoint</code></li>
+        <li><code>force</code></li>
+    </ul>
+    <p>A message without a <code>payload</code> writes nothing but retargets the node's output side.</p>
+    <h3>Party and holiday mode (HmIP)</h3>
+    <p>An HmIP thermostat (eTRV, WTH) takes <code>PARTY_TIME_START</code>, <code>PARTY_TIME_END</code> and
+    <code>PARTY_SET_POINT_TEMPERATURE</code> only together; written alone, one resets the other two. A write to one of the
+    three therefore goes out as one <code>putParamset</code> with all three - the other two from our own last write, the
+    value cache or a read from the device. The times may be the device's own <code>YYYY_MM_DD HH:MM</code> string, a
+    JavaScript Date, an ISO string or epoch milliseconds; they are formatted for the device in local time. The older HM
+    thermostats (<code>PARTY_MODE_SUBMIT</code>) are not covered.</p>
+    <h3>Queue and force</h3>
+    <p>With <i>Queue</i> the writes go out one after another, and a value the cache already knows from another source is not sent again. A value this node itself wrote last is always sent: a blind moved by hand does not report a new set point on its control channel. <i>Force</i> (also <code>msg.config.force</code>) always sends.</p>
+</script>

package/nodes/locales/en-US/ccu-value.json

@@ -9,6 +9,7 @@
     "cache": "Emit cached value on start",
     "working": "Don't emit values while actuator is in WORKING state",
     "queue": "Queue Commands",
+    "force": "Force (ignore the value cache)",
     "certainOnly": "Discard uncertain values"
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "node-red-contrib-ccu",
-  "version": "4.4.4",
+  "version": "4.5.0",
   "license": "MIT",
   "main": "none",
   "keywords": [