node-red-contrib-knx-ultimate 6.3.24 → 6.3.25

package/nodes/locales/de/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Ziel",
       "method": "HTTP-Methode",
       "modbusFunction": "Modbus-Funktion",
+      "modbusMessageFormat": "Modbus-Nachrichtenformat",
+      "modbusUnitId": "Unit-ID",
+      "modbusArea": "Modbus-Bereich",
+      "modbusDataType": "Datentyp",
       "scale": "Skalierung",
       "offset": "Offset",
       "timeout": "Zeitüberschreitung (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL oder Register",
       "target_mqtt": "Topic, z. B. knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Register (z. B. 40001)",
+      "target_modbus": "Nullbasierte Adresse (z. B. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Optionale Eigenschaft/Pfad",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Ziel",
         "mqtt": "MQTT-Topic",
         "rest": "REST-URL",
-        "modbus": "Modbus-Register"
+        "modbus": "Modbus-Adresse (nullbasiert)"
       },
       "method": {
         "default": "HTTP-Methode",
@@ -125,6 +129,20 @@
         "modbus": "Modbus-Funktion"
       }
     },
+    "modbus": {
+      "formatLegacy": "Legacy-Skalar-Nachricht",
+      "formatFlex": "Mit Flex Write kompatibel",
+      "areaCoil": "Coil (FC1 lesen / FC5 schreiben)",
+      "areaDiscreteInput": "Discrete Input (FC2 lesen, schreibgeschützt)",
+      "areaHoldingRegister": "Holding Register (FC3 lesen / FC6 schreiben)",
+      "areaInputRegister": "Input Register (FC4 lesen, schreibgeschützt)",
+      "dataTypeBool": "Boolesch",
+      "dataTypeUint16": "16 Bit ohne Vorzeichen",
+      "dataTypeInt16": "16 Bit mit Vorzeichen",
+      "zeroBasedHint": "Verwende die nullbasierte Protokolladresse (0–65535), nicht die in manchen Handbüchern angegebene 4xxxx-Referenz.",
+      "flexHint": "Flex gibt msg.payload = {value,fc,unitid,address,quantity} zur direkten Verbindung mit modbus-flex-write aus.",
+      "readOnlyHint": "Discrete Inputs und Input Register sind schreibgeschützt und können nur Modbus → KNX verwenden."
+    },
     "labels": {
       "outputKnxToIoT": "Strom KNX → IoT",
       "outputIoTToKnx": "Bestätigungen IoT → KNX",

package/nodes/locales/en/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ The rest of this help describes the classic **IoT bridge** mode.
 ## Mapping Fields
 
 - **Direction** — choose KNX→IoT, IoT→KNX or bidirectional.
-- **Channel type** — MQTT uses the target as topic; REST uses it as the base URL; Modbus expects a register identifier.
+- **Channel type** — MQTT uses the target as topic; REST uses it as the base URL; for Modbus, **Target** is the zero-based protocol address (0–65535).
+- **Modbus format / Unit ID / Area / Data type** — choose **Flex Write compatible** for new mappings, then select the unit, memory area and `bool`, `uint16` or `int16`. A missing format remains the legacy scalar contract so existing flows keep working.
 - **Scale & Offset** — applied to KNX→IoT; IoT→KNX applies the inverse transform.
 - **Template** — optional string replacing `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Retries** — informational fields exposed in the emitted message for downstream nodes to act on.
@@ -88,7 +89,32 @@ The rest of this help describes the classic **IoT bridge** mode.
 
 ### Modbus register sync
 
-- Pair the MQTT - IoT with `node-red-contrib-modbus` `modbus-flex-write` nodes. Output 1 carries the Modbus address in `msg.address` and the value in `msg.payload`.
+The bridge is a message adapter for `node-red-contrib-modbus`; it does not open a TCP/serial connection and does not poll a device. Install a version of that package compatible with your Node-RED runtime, then use its client and transport nodes.
+
+|Area|Read|Write|Allowed direction|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Either direction |
+| Discrete input | FC2 | — | Modbus → KNX only |
+| Holding register | FC3 | FC6 | Either direction |
+| Input register | FC4 | — | Modbus → KNX only |
+
+For a new mapping select `Format = Flex Write compatible`. On KNX → Modbus, Output 1 can be wired directly to a `modbus-flex-write` node and emits:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` is always zero-based: if a device manual labels a holding register as `40010`, its protocol address is commonly `9`; verify the convention in that manual. The bridge supports one bit or one 16-bit register per mapping. It does not currently combine words, decode 32-bit/float values or manage byte/word order.
+
+For Modbus → KNX, wire the data output of a `modbus-flex-getter` or `modbus-read` node to the bridge input. A Flex Getter provides the request (`fc`, `unitid`, `address`, `quantity`) in `msg.modbusRequest`; a Modbus Read node preserves it in `msg.input.payload`. The returned values array may be in `msg.payload` or `msg.values`. The bridge supports both message shapes, matches every Flex mapping covered by the response and uses the appropriate array element. Enable **Keep Msg Properties** on Flex Getter. Scale and offset are applied as `raw = KNX × scale + offset`; the incoming path applies the inverse transformation.
+
+`Read KNX values on deploy` reads KNX only; schedule Modbus reads in the external Modbus flow. Legacy mappings (including mappings without `modbusMessageFormat`) continue to emit the previous scalar payload plus top-level `msg.address`/`msg.modbusFunction` metadata.
 
 ## Sample Flow
 

package/nodes/locales/en/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Target",
       "method": "HTTP method",
       "modbusFunction": "Modbus function",
+      "modbusMessageFormat": "Modbus message format",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Modbus area",
+      "modbusDataType": "Data type",
       "scale": "Scale",
       "offset": "Offset",
       "timeout": "Timeout (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL or register",
       "target_mqtt": "Topic, e.g. knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Register (e.g. 40001)",
+      "target_modbus": "Zero-based address (e.g. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Optional property/path",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Target",
         "mqtt": "MQTT topic",
         "rest": "REST URL",
-        "modbus": "Modbus register"
+        "modbus": "Modbus address (zero-based)"
       },
       "method": {
         "default": "HTTP method",
@@ -125,6 +129,20 @@
         "modbus": "Modbus function"
       }
     },
+    "modbus": {
+      "formatLegacy": "Legacy scalar message",
+      "formatFlex": "Flex Write compatible",
+      "areaCoil": "Coil (FC1 read / FC5 write)",
+      "areaDiscreteInput": "Discrete input (FC2 read only)",
+      "areaHoldingRegister": "Holding register (FC3 read / FC6 write)",
+      "areaInputRegister": "Input register (FC4 read only)",
+      "dataTypeBool": "Boolean",
+      "dataTypeUint16": "Unsigned 16-bit",
+      "dataTypeInt16": "Signed 16-bit",
+      "zeroBasedHint": "Use the zero-based protocol address (0–65535), not the 4xxxx reference printed by some manuals.",
+      "flexHint": "Flex emits msg.payload = {value,fc,unitid,address,quantity} for direct wiring to modbus-flex-write.",
+      "readOnlyHint": "Discrete inputs and input registers are read-only and can only use Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "KNX → IoT stream",
       "outputIoTToKnx": "IoT → KNX acknowledgements",

package/nodes/locales/es/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ El resto de esta ayuda describe el modo clásico **Bridge IoT**.
 ## Campos de mapeo
 
 - **Dirección** — elige KNX→IoT, IoT→KNX o bidireccional.
-- **Tipo de canal** — MQTT usa el target como topic; REST lo usa como URL base; Modbus espera un identificador de registro.
+- **Tipo de canal** — MQTT usa el target como topic; REST lo usa como URL base; para Modbus, **Target** es la dirección de protocolo desde cero (0–65535).
+- **Formato Modbus / Unit ID / Área / Tipo de dato** — para los mapeos nuevos elige **Compatible con Flex Write** y después la unidad, el área de memoria y `bool`, `uint16` o `int16`. Si falta el formato se mantiene el contrato escalar heredado, por lo que los flows existentes siguen funcionando.
 - **Escala y Offset** — aplicados a KNX→IoT; IoT→KNX usa la transformación inversa.
 - **Template** — cadena opcional que reemplaza `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Reintentos** — campos informativos expuestos en el mensaje para que los nodos posteriores gestionen reintentos/ventanas.
@@ -88,7 +89,32 @@ El resto de esta ayuda describe el modo clásico **Bridge IoT**.
 
 ### Sincronización de registro Modbus
 
-- Empareja el bridge con nodos `modbus-flex-write` de `node-red-contrib-modbus`. La salida 1 transporta la dirección Modbus en `msg.address` y el valor en `msg.payload`.
+El bridge es un adaptador de mensajes para `node-red-contrib-modbus`: no abre conexiones TCP/serie ni consulta dispositivos por sí mismo. Instala una versión del paquete compatible con tu runtime Node-RED y utiliza después sus nodos cliente y de transporte.
+
+|Área|Lectura|Escritura|Dirección permitida|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Ambas direcciones |
+| Discrete input | FC2 | — | Solo Modbus → KNX |
+| Holding register | FC3 | FC6 | Ambas direcciones |
+| Input register | FC4 | — | Solo Modbus → KNX |
+
+Para un mapeo nuevo selecciona `Formato = Compatible con Flex Write`. De KNX a Modbus, la salida 1 puede conectarse directamente a un nodo `modbus-flex-write` y emite:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` siempre empieza en cero: si el manual del dispositivo etiqueta un holding register como `40010`, su dirección de protocolo suele ser `9`; comprueba la convención del manual. El bridge admite un bit o un único registro de 16 bits por mapeo. Por ahora no combina palabras, no decodifica valores de 32 bits/float ni gestiona el orden de bytes/palabras.
+
+De Modbus a KNX, conecta la salida de datos de un nodo `modbus-flex-getter` o `modbus-read` a la entrada del bridge. Flex Getter proporciona la petición (`fc`, `unitid`, `address`, `quantity`) en `msg.modbusRequest`; Modbus Read la conserva en `msg.input.payload`. El array de valores devuelto puede estar en `msg.payload` o en `msg.values`. El bridge admite ambas formas de mensaje, relaciona todos los mapeos Flex cubiertos por la respuesta y usa el elemento correcto del array. Activa **Keep Msg Properties** en Flex Getter. Escala y offset siguen `raw = KNX × escala + offset`; en la entrada se aplica la transformación inversa.
+
+`Leer valores KNX al desplegar` solo lee KNX; programa las lecturas Modbus en el flow Modbus externo. Los mapeos heredados (incluidos los que no tienen `modbusMessageFormat`) continúan emitiendo el payload escalar anterior con los metadatos `msg.address`/`msg.modbusFunction` en el nivel superior.
 
 ## Flow de ejemplo
 

package/nodes/locales/es/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Destino",
       "method": "Método HTTP",
       "modbusFunction": "Función Modbus",
+      "modbusMessageFormat": "Formato del mensaje Modbus",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Área Modbus",
+      "modbusDataType": "Tipo de dato",
       "scale": "Escala",
       "offset": "Offset",
       "timeout": "Tiempo de espera (ms)",
@@ -103,7 +107,7 @@
       "target": "Tema, URL o registro",
       "target_mqtt": "Tema, p. ej. knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Registro (p. ej. 40001)",
+      "target_modbus": "Dirección desde cero (p. ej. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Propiedad/ruta opcional",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Destino",
         "mqtt": "Topic MQTT",
         "rest": "URL REST",
-        "modbus": "Registro Modbus"
+        "modbus": "Dirección Modbus (desde cero)"
       },
       "method": {
         "default": "Método HTTP",
@@ -125,6 +129,20 @@
         "modbus": "Función Modbus"
       }
     },
+    "modbus": {
+      "formatLegacy": "Mensaje escalar heredado",
+      "formatFlex": "Compatible con Flex Write",
+      "areaCoil": "Coil (lectura FC1 / escritura FC5)",
+      "areaDiscreteInput": "Discrete input (lectura FC2 solamente)",
+      "areaHoldingRegister": "Holding register (lectura FC3 / escritura FC6)",
+      "areaInputRegister": "Input register (lectura FC4 solamente)",
+      "dataTypeBool": "Booleano",
+      "dataTypeUint16": "16 bits sin signo",
+      "dataTypeInt16": "16 bits con signo",
+      "zeroBasedHint": "Usa la dirección de protocolo desde cero (0–65535), no la referencia 4xxxx que aparece en algunos manuales.",
+      "flexHint": "Flex emite msg.payload = {value,fc,unitid,address,quantity}, conectable directamente a modbus-flex-write.",
+      "readOnlyHint": "Los discrete inputs e input registers son de solo lectura y únicamente admiten Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "Flujo KNX → IoT",
       "outputIoTToKnx": "Confirmaciones IoT → KNX",

package/nodes/locales/fr/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ Le reste de cette aide décrit le mode classique **Passerelle IoT**.
 ## Champs de correspondance
 
 - **Direction** — choisir KNX→IoT, IoT→KNX ou bidirectionnel.
-- **Type de canal** — MQTT utilise la cible comme topic, REST comme URL de base, Modbus comme identifiant de registre.
+- **Type de canal** — MQTT utilise la cible comme topic, REST comme URL de base ; pour Modbus, **Target** est l'adresse de protocole à base zéro (0–65535).
+- **Format Modbus / Unit ID / Zone / Type de donnée** — pour les nouvelles correspondances, choisissez **Compatible avec Flex Write**, puis l'unité, la zone mémoire et `bool`, `uint16` ou `int16`. En l'absence de format, l'ancien contrat scalaire reste actif afin de préserver les flows existants.
 - **Échelle & offset** — appliqués pour KNX→IoT ; IoT→KNX applique la transformation inverse.
 - **Template** — chaîne optionnelle remplaçant `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Tentatives** — informations exposées sur le message pour aider les nœuds en aval à gérer les reprises.
@@ -88,7 +89,32 @@ Le reste de cette aide décrit le mode classique **Passerelle IoT**.
 
 ### Synchronisation de registre Modbus
 
-- Associez la passerelle aux nœuds `modbus-flex-write` du paquet `node-red-contrib-modbus`. La sortie 1 transporte l’adresse Modbus dans `msg.address` et la valeur dans `msg.payload`.
+La passerelle est un adaptateur de messages pour `node-red-contrib-modbus` ; elle n'ouvre pas de connexion TCP/série et n'interroge pas elle-même un appareil. Installez une version du paquet compatible avec votre runtime Node-RED, puis utilisez ses nœuds client et transport.
+
+|Zone|Lecture|Écriture|Direction autorisée|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Les deux directions |
+| Discrete input | FC2 | — | Modbus → KNX uniquement |
+| Holding register | FC3 | FC6 | Les deux directions |
+| Input register | FC4 | — | Modbus → KNX uniquement |
+
+Pour une nouvelle correspondance, sélectionnez `Format = Compatible avec Flex Write`. De KNX vers Modbus, la sortie 1 se raccorde directement à un nœud `modbus-flex-write` et émet :
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` est toujours à base zéro : si le manuel de l'appareil désigne un holding register par `40010`, son adresse de protocole est généralement `9` ; vérifiez la convention du manuel. La passerelle prend en charge un bit ou un seul registre 16 bits par correspondance. Elle ne combine pas encore plusieurs mots, ne décode pas les valeurs 32 bits/float et ne gère pas l'ordre des octets/mots.
+
+De Modbus vers KNX, reliez la sortie de données d'un nœud `modbus-flex-getter` ou `modbus-read` à l'entrée de la passerelle. Flex Getter fournit la requête (`fc`, `unitid`, `address`, `quantity`) dans `msg.modbusRequest` ; Modbus Read la conserve dans `msg.input.payload`. Le tableau de valeurs retourné peut se trouver dans `msg.payload` ou `msg.values`. La passerelle accepte les deux formes de message, associe toutes les correspondances Flex couvertes par la réponse et utilise le bon élément du tableau. Activez **Keep Msg Properties** sur Flex Getter. L'échelle et le décalage suivent `raw = KNX × échelle + décalage` ; le chemin entrant applique la transformation inverse.
+
+`Lire les valeurs KNX au déploiement` lit uniquement KNX ; planifiez les lectures Modbus dans le flow Modbus externe. Les correspondances historiques (y compris celles sans `modbusMessageFormat`) continuent d'émettre l'ancien payload scalaire avec les métadonnées `msg.address`/`msg.modbusFunction` au premier niveau.
 
 ## Flow d’exemple
 

package/nodes/locales/fr/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Cible",
       "method": "Méthode HTTP",
       "modbusFunction": "Fonction Modbus",
+      "modbusMessageFormat": "Format du message Modbus",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Zone Modbus",
+      "modbusDataType": "Type de donnée",
       "scale": "Échelle",
       "offset": "Décalage",
       "timeout": "Délai (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL ou registre",
       "target_mqtt": "Topic, ex. knx/light/salon",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Registre (ex. 40001)",
+      "target_modbus": "Adresse à base zéro (ex. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Propriété/chemin optionnel",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Cible",
         "mqtt": "Topic MQTT",
         "rest": "URL REST",
-        "modbus": "Registre Modbus"
+        "modbus": "Adresse Modbus (base zéro)"
       },
       "method": {
         "default": "Méthode HTTP",
@@ -125,6 +129,20 @@
         "modbus": "Fonction Modbus"
       }
     },
+    "modbus": {
+      "formatLegacy": "Message scalaire historique",
+      "formatFlex": "Compatible avec Flex Write",
+      "areaCoil": "Coil (lecture FC1 / écriture FC5)",
+      "areaDiscreteInput": "Discrete input (lecture FC2 uniquement)",
+      "areaHoldingRegister": "Holding register (lecture FC3 / écriture FC6)",
+      "areaInputRegister": "Input register (lecture FC4 uniquement)",
+      "dataTypeBool": "Booléen",
+      "dataTypeUint16": "16 bits non signé",
+      "dataTypeInt16": "16 bits signé",
+      "zeroBasedHint": "Utilisez l’adresse de protocole à base zéro (0–65535), et non la référence 4xxxx indiquée dans certains manuels.",
+      "flexHint": "Flex émet msg.payload = {value,fc,unitid,address,quantity}, directement raccordable à modbus-flex-write.",
+      "readOnlyHint": "Les discrete inputs et input registers sont en lecture seule et acceptent uniquement Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "Flux KNX → IoT",
       "outputIoTToKnx": "Accusés IoT → KNX",

package/nodes/locales/it/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ Il resto di questo aiuto descrive la modalità classica **Bridge IoT**.
 ## Campi della mappatura
 
 - **Direzione** — scegli KNX→IoT, IoT→KNX oppure bidirezionale.
-- **Tipo canale** — per MQTT il target è il topic; per REST è l'URL base; per Modbus è il registro/indirizzo.
+- **Tipo canale** — per MQTT il target è il topic; per REST è l'URL base; per Modbus **Target** è l'indirizzo di protocollo zero-based (0–65535).
+- **Formato Modbus / Unit ID / Area / Tipo di dato** — per le nuove mappature scegli **Compatibile con Flex Write**, quindi imposta unità, area di memoria e `bool`, `uint16` o `int16`. Se il formato è assente resta attivo il contratto scalare legacy, così i flow esistenti continuano a funzionare.
 - **Scala & Offset** — applicati su KNX→IoT; IoT→KNX usa la trasformazione inversa.
 - **Template** — stringa opzionale con segnaposto `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Tentativi** — campi informativi esposti nel messaggio in uscita per i nodi successivi.
@@ -88,7 +89,32 @@ Il resto di questo aiuto descrive la modalità classica **Bridge IoT**.
 
 ### Sincronizzazione Modbus
 
-- Abbina il bridge ai nodi `node-red-contrib-modbus` (`modbus-flex-write`). L'uscita 1 fornisce `msg.address` e `msg.payload` già pronti.
+Il bridge è un adattatore di messaggi per `node-red-contrib-modbus`: non apre connessioni TCP/seriali e non interroga autonomamente il dispositivo. Installa una versione del pacchetto compatibile con il tuo runtime Node-RED, poi usa i suoi nodi client e di trasporto.
+
+|Area|Lettura|Scrittura|Direzione ammessa|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Entrambe le direzioni |
+| Discrete input | FC2 | — | Solo Modbus → KNX |
+| Holding register | FC3 | FC6 | Entrambe le direzioni |
+| Input register | FC4 | — | Solo Modbus → KNX |
+
+Per una nuova mappatura seleziona `Formato = Compatibile con Flex Write`. Da KNX a Modbus, l'output 1 si collega direttamente a un nodo `modbus-flex-write` ed emette:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` è sempre zero-based: se il manuale del dispositivo indica un holding register come `40010`, il relativo indirizzo di protocollo è comunemente `9`; verifica la convenzione nel manuale. Il bridge gestisce un bit o un singolo registro a 16 bit per mappatura. Al momento non combina più word, non decodifica valori a 32 bit/float e non gestisce l'ordine di byte/word.
+
+Da Modbus a KNX, collega l'uscita dati di un nodo `modbus-flex-getter` o `modbus-read` all'ingresso del bridge. Flex Getter fornisce la richiesta (`fc`, `unitid`, `address`, `quantity`) in `msg.modbusRequest`; Modbus Read la conserva in `msg.input.payload`. L'array dei valori restituiti può trovarsi in `msg.payload` oppure in `msg.values`. Il bridge supporta entrambe le forme, abbina tutte le mappature Flex comprese nella risposta e usa l'elemento corretto dell'array. Abilita **Keep Msg Properties** su Flex Getter. Scala e offset seguono `raw = KNX × scala + offset`; in ingresso viene applicata la trasformazione inversa.
+
+`Leggi valori KNX al deploy` legge soltanto KNX; pianifica le letture Modbus nel flow Modbus esterno. Le mappature legacy (comprese quelle senza `modbusMessageFormat`) continuano a emettere il precedente payload scalare con i metadati `msg.address`/`msg.modbusFunction` al livello principale.
 
 ## Flow di esempio
 

package/nodes/locales/it/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Target",
       "method": "Metodo HTTP",
       "modbusFunction": "Funzione Modbus",
+      "modbusMessageFormat": "Formato messaggio Modbus",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Area Modbus",
+      "modbusDataType": "Tipo di dato",
       "scale": "Scala",
       "offset": "Offset",
       "timeout": "Timeout (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL o registro",
       "target_mqtt": "Topic, es. knx/light/soggiorno",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Registro (es. 40001)",
+      "target_modbus": "Indirizzo zero-based (es. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Proprietà/percorso opzionale",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Target",
         "mqtt": "Topic MQTT",
         "rest": "URL REST",
-        "modbus": "Registro Modbus"
+        "modbus": "Indirizzo Modbus (zero-based)"
       },
       "method": {
         "default": "Metodo HTTP",
@@ -125,6 +129,20 @@
         "modbus": "Funzione Modbus"
       }
     },
+    "modbus": {
+      "formatLegacy": "Messaggio scalare legacy",
+      "formatFlex": "Compatibile con Flex Write",
+      "areaCoil": "Coil (lettura FC1 / scrittura FC5)",
+      "areaDiscreteInput": "Discrete input (lettura FC2, sola lettura)",
+      "areaHoldingRegister": "Holding register (lettura FC3 / scrittura FC6)",
+      "areaInputRegister": "Input register (lettura FC4, sola lettura)",
+      "dataTypeBool": "Booleano",
+      "dataTypeUint16": "16 bit senza segno",
+      "dataTypeInt16": "16 bit con segno",
+      "zeroBasedHint": "Usa l’indirizzo di protocollo zero-based (0–65535), non il riferimento 4xxxx riportato da alcuni manuali.",
+      "flexHint": "Flex emette msg.payload = {value,fc,unitid,address,quantity}, collegabile direttamente a modbus-flex-write.",
+      "readOnlyHint": "Discrete input e input register sono di sola lettura e possono usare solo Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "Flusso KNX → IoT",
       "outputIoTToKnx": "Ack IoT → KNX",

package/nodes/locales/zh-CN/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ KNX 总线的值会发布到 MQTT，可写的数据点接受来自 Home Assistan
 ## 映射字段
 
 - **方向** — 选择 KNX→IoT、IoT→KNX 或双向。
-- **通道类型** — MQTT 将目标视为主题；REST 将其视为基础 URL；Modbus 视为寄存器标识。
+- **通道类型** — MQTT 将目标视为主题；REST 将其视为基础 URL；对于 Modbus，**目标**是从零开始的协议地址（0–65535）。
+- **Modbus 格式 / Unit ID / 区域 / 数据类型** — 新映射请选择**兼容 Flex Write**，然后选择单元、内存区域以及 `bool`、`uint16` 或 `int16`。如果没有格式字段，则继续使用旧版标量协议，现有 Flow 不受影响。
 - **缩放 & 偏移** — 应用于 KNX→IoT；在 IoT→KNX 时使用逆向变换。
 - **模板** — 可选字符串，可替换 `{{value}}`、`{{ga}}`、`{{label}}`、`{{target}}`、`{{type}}`、`{{isoTimestamp}}`。
 - **超时 / 重试** — 信息字段，用于告知下游节点应如何处理重试和时间窗口。
@@ -88,7 +89,32 @@ KNX 总线的值会发布到 MQTT，可写的数据点接受来自 Home Assistan
 
 ### Modbus 寄存器同步
 
-- 将桥接节点与 `node-red-contrib-modbus` 的 `modbus-flex-write` 节点配合使用。输出 1 会在 `msg.address` 中携带 Modbus 地址，在 `msg.payload` 中携带数值。
+本桥接节点是 `node-red-contrib-modbus` 的消息适配器；它本身不会打开 TCP/串行连接，也不会轮询设备。请安装与你的 Node-RED 运行环境兼容的该软件包版本，然后使用其中的客户端和传输节点。
+
+|区域|读取|写入|允许的方向|
+|--|--|--|--|
+| 线圈 | FC1 | FC5 | 双向 |
+| 离散输入 | FC2 | — | 仅 Modbus → KNX |
+| 保持寄存器 | FC3 | FC6 | 双向 |
+| 输入寄存器 | FC4 | — | 仅 Modbus → KNX |
+
+对于新映射，请选择`格式 = 兼容 Flex Write`。从 KNX 到 Modbus 时，输出 1 可直接连接到 `modbus-flex-write` 节点，并输出：
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` 始终从零开始：如果设备手册将某个保持寄存器标为 `40010`，其协议地址通常为 `9`；请确认该手册采用的规则。每条映射支持一个位或一个 16 位寄存器。目前不会组合多个字、解码 32 位/浮点值，也不处理字节/字顺序。
+
+从 Modbus 到 KNX 时，将 `modbus-flex-getter` 或 `modbus-read` 节点的数据输出连接到桥接输入。Flex Getter 在 `msg.modbusRequest` 中提供请求（`fc`、`unitid`、`address`、`quantity`）；Modbus Read 则将请求保留在 `msg.input.payload` 中。返回的值数组可以位于 `msg.payload` 或 `msg.values`。桥接节点支持这两种消息形式，会匹配该响应覆盖的所有 Flex 映射，并使用正确的数组元素。请在 Flex Getter 上启用 **Keep Msg Properties**。缩放和偏移遵循 `raw = KNX × 缩放 + 偏移`；输入路径应用逆变换。
+
+`部署时读取 KNX 数值`只读取 KNX；Modbus 读取应在外部 Modbus Flow 中安排。旧版映射（包括没有 `modbusMessageFormat` 的映射）仍会输出之前的标量 payload，并在顶层保留 `msg.address`/`msg.modbusFunction` 元数据。
 
 ## 示例 Flow
 

package/nodes/locales/zh-CN/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "目标",
       "method": "HTTP 方法",
       "modbusFunction": "Modbus 功能",
+      "modbusMessageFormat": "Modbus 消息格式",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Modbus 区域",
+      "modbusDataType": "数据类型",
       "scale": "缩放",
       "offset": "偏移",
       "timeout": "超时 (ms)",
@@ -103,7 +107,7 @@
       "target": "主题、URL 或寄存器",
       "target_mqtt": "主题，例如 knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "寄存器（如 40001）",
+      "target_modbus": "从零开始的地址（如 0）",
       "template": "{\"value\":{{value}}}",
       "property": "可选属性/路径",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "目标",
         "mqtt": "MQTT 主题",
         "rest": "REST URL",
-        "modbus": "Modbus 寄存器"
+        "modbus": "Modbus 地址（从零开始）"
       },
       "method": {
         "default": "HTTP 方法",
@@ -125,6 +129,20 @@
         "modbus": "Modbus 功能"
       }
     },
+    "modbus": {
+      "formatLegacy": "旧版标量消息",
+      "formatFlex": "兼容 Flex Write",
+      "areaCoil": "线圈（FC1 读取 / FC5 写入）",
+      "areaDiscreteInput": "离散输入（FC2 读取，只读）",
+      "areaHoldingRegister": "保持寄存器（FC3 读取 / FC6 写入）",
+      "areaInputRegister": "输入寄存器（FC4 读取，只读）",
+      "dataTypeBool": "布尔值",
+      "dataTypeUint16": "16 位无符号整数",
+      "dataTypeInt16": "16 位有符号整数",
+      "zeroBasedHint": "请使用从零开始的协议地址（0–65535），不要使用某些手册中标注的 4xxxx 引用编号。",
+      "flexHint": "Flex 输出 msg.payload = {value,fc,unitid,address,quantity}，可直接连接到 modbus-flex-write。",
+      "readOnlyHint": "离散输入和输入寄存器为只读，只能使用 Modbus → KNX。"
+    },
     "labels": {
       "outputKnxToIoT": "KNX → IoT 流",
       "outputIoTToKnx": "IoT → KNX 确认",

package/package.json

@@ -3,8 +3,8 @@
   "engines": {
     "node": ">=20.18.1"
   },
-  "version": "6.3.24",
-  "description": "KNX Ultimate is the most advanced KNX integration for Node-RED, providing secure KNX/IP communication, routing, ETS project import, Philips Hue, Matter Controller and Matter Bridge (control matter device via KNX and expose KNX GA via Matter), MQTT, diagnostics with AI, virtual devices, and powerful automation nodes. Build professional, reliable, and scalable smart home and building automation projects with minimal effort.",
+  "version": "6.3.25",
+  "description": "KNX Ultimate is the most advanced KNX integration for Node-RED, providing secure KNX/IP communication, routing, ETS project import, Philips Hue, Matter Controller and Matter Bridge (control matter device via KNX and expose KNX GA via Matter), MQTT and Modbus adapters, diagnostics with AI, virtual devices, and powerful automation nodes. Build professional, reliable, and scalable smart home and building automation projects with minimal effort.",
   "files": [
     "nodes/",
     "resources/",
@@ -19,7 +19,6 @@
     "@matter/main": "^0.17.9",
     "@matter/nodejs": "^0.17.9",
     "@project-chip/matter.js": "^0.17.9",
-    "dns-sync": "0.2.1",
     "google-translate-tts": "^0.3.0",
     "js-yaml": "4.3.1",
     "knxultimate": "6.0.2",
@@ -94,6 +93,7 @@
     "hue",
     "matter",
     "mqtt",
+    "modbus",
     "home-assistant",
     "building-automation",
     "home-automation",