de IoT Bridge Configuration - Supergiovane/node-red-contrib-knx-ultimate GitHub Wiki

🌐 Language: EN | IT | DE | FR | ES | 简体中文

Navigation: Startseite Übersicht: Changelog • FAQ • Sicherheit • Doku: Sprachleiste KNX Geräteknoten: Gateway • Gerät • Knotenschutz Weitere KNX‑Knoten: Szenencontroller • WatchDog • Logger • Global Context • Alerter • Laststeuerung • Viewer • Auto‑Responder • HA‑Übersetzer • IoT Bridge HUE: Bridge • Licht • Batterie • Taster • Kontakt • Geräte‑SW‑Update • Lichtsensor • Bewegung • Szene • Tap Dial • Temperatur • Zigbee‑Konnektivität Beispiele: Logger • Switch Light • Dimming • RGB color • RGBW color + White • Command a scene actuator • Datapoint 213.x 4x Setpoint • Datapoint 222.x 3x Setpoint • Datapoint 237.x DALI diags • Datapoint 2.x 1 bit proprity • Datapoint 22.x RCHH Status • Datetime to BUS • Read Status • Virtual Device • Subtype decoded • Alexa • Apple Homekit • Google Home • Switch on/off POE port of Unifi switch • Set configuration by msg • Scene Controller node • WatchDog node • Global Context node • Alerter node • Load control node • Viewer node • MySQL, InfluxDB, MQTT Sample Contribute to Wiki: Link

KNX ↔ IoT Bridge

Der Bridge normalisiert KNX-Telegramme zu strukturierten Nachrichten für IoT-Transporte (MQTT, REST, Modbus) und nimmt Flow-Eingaben entgegen, um zurück in den KNX-Bus zu schreiben. Diese Seite fasst die Konfiguration und empfohlene Drittanbieter-Nodes zusammen.

Feldübersicht

Feld Zweck Hinweise
Label Anzeigename Erscheint im Status und in msg.bridge.label.
GA / DPT Gruppenadresse und Datapoint Manuell oder über ETS-Autovervollständigung setzen.
Richtung KNX→IoT, IoT→KNX, Bidirektional Steuert, welche Ausgänge genutzt werden.
Kanaltyp MQTT / REST / Modbus Bestimmt die Bedeutung von Target.
Target Topic, Basis-URL oder Register Leer = Verwendung von outputtopic.
Template String-Format Platzhalter {{value}}, {{ga}}, {{type}}, {{target}}, {{label}}, {{isoTimestamp}}.
Skalierung / Offset Numerische Umrechnung Wird in KNX→IoT angewandt; IoT→KNX nutzt die inverse Rechnung.
Timeout / Wiederholungen Retry-Hinweise Können von nachfolgenden Nodes zur Steuerung von Wiederholungen genutzt werden.

Typische Transporte

MQTT-Broker

  • Publizieren: Ausgang 1 an den Core-Node mqtt out anschließen. msg.topic und msg.payload sind bereits gesetzt.
  • Abonnieren: Ein mqtt in-Node am Eingang wandelt MQTT-Nachrichten in KNX-Schreibvorgänge um. Ausgang 2 liefert eine Bestätigung.

REST-API

  • Ausgang 1 in den Core-Node http request (oder contrib wie node-red-contrib-http-request) führen.
  • Der Bridge kopiert bridge.method nach msg.method und den Template-Output nach msg.payload, ideal für Webhooks.

Modbus-Register

  • Mit node-red-contrib-modbus kombinieren (modbus-flex-write, modbus-write).
  • Target entspricht dem Register; msg.payload liefert den skalierten Wert.

Beispiel-Flows

Status KNX → MQTT

[
  {
    "id": "bridge1",
    "type": "knxUltimateIoTBridge",
    "z": "flow1",
    "server": "gateway1",
    "name": "Licht-Bridge",
    "emitOnChangeOnly": true,
    "readOnDeploy": true,
    "acceptFlowInput": true,
    "mappings": [
      {
        "id": "map-licht",
        "enabled": true,
        "label": "Wohnzimmerlicht",
        "ga": "1/1/10",
        "dpt": "1.001",
        "direction": "bidirectional",
        "iotType": "mqtt",
        "target": "knx/light/living",
        "method": "POST",
        "modbusFunction": "writeHoldingRegister",
        "scale": 1,
        "offset": 0,
        "template": "{{value}}",
        "property": "",
        "timeout": 0,
        "retry": 0
      }
    ],
    "wires": ["mqttOut"],["debugAck"](/Supergiovane/node-red-contrib-knx-ultimate/wiki/"mqttOut"],["debugAck")
  },
  {
    "id": "mqttOut",
    "type": "mqtt out",
    "name": "MQTT Status",
    "topic": "",
    "qos": "0",
    "retain": "false",
    "broker": "mqttBroker",
    "x": 520,
    "y": 120,
    "wires": []
  },
  {
    "id": "debugAck",
    "type": "debug",
    "name": "KNX Ack",
    "active": true,
    "tosidebar": true,
    "complete": "true",
    "x": 520,
    "y": 180,
    "wires": []
  }
]

MQTT-Befehl → KNX

[
  {
    "id": "mqttIn",
    "type": "mqtt in",
    "name": "MQTT Befehl",
    "topic": "knx/light/living/set",
    "qos": "1",
    "datatype": "auto",
    "broker": "mqttBroker",
    "x": 140,
    "y": 200,
    "wires": ["bridge1"](/Supergiovane/node-red-contrib-knx-ultimate/wiki/"bridge1")
  }
]

Kombinieren Sie beide Ausschnitte, um einen KNX ↔ MQTT Roundtrip mit Bestätigung zu erhalten.

REST-Snapshot

{
  "id": "bridge-rest",
  "type": "knxUltimateIoTBridge",
  "name": "Leistungs-Bridge",
  "mappings": [
    {
      "label": "Wirklast gesamt",
      "ga": "2/1/20",
      "dpt": "9.024",
      "direction": "knx-to-iot",
      "iotType": "rest",
      "target": "https://example/api/knx/power",
      "method": "POST",
      "template": "{\"value\":{{value}},\"ga\":\"{{ga}}\",\"ts\":\"{{isoTimestamp}}\"}"
    }
  ]
}

Leiten Sie Ausgang 1 in http request und nutzen Sie die Antwort samt bridge.retry für Wiederholstrategien.

Modbus-Schreibvorgang

  1. Setzen Sie Target = 40010, Typ = Modbus, Richtung = Bidirectional.
  2. Verbinden Sie Ausgang 1 mit modbus-flex-write und übergeben Sie msg.payload an den Werte-Eingang.
  3. Verwenden Sie das Ack, um KNX-Synchronisation nach Registeränderungen zu überwachen.

Tipps

  • Lassen Sie Target leer, wenn mehrere Zuordnungen dasselbe outputtopic nutzen sollen.
  • emitOnChangeOnly reduziert Sensordatenrauschen; deaktivieren Sie es bei Bedarf.
  • Ausgang 2 spiegelt immer den ursprünglichen IoT-Payload mit bridge-Metadaten wider – hilfreich zum Debuggen der Skalierung.
  • Für spezielle Modbus-Fließkommaformate kann ein function-Node das gewünschte Byte-Layout erzeugen.

Viel Erfolg beim Bridging!