> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/gateways/mqtt-edge-gateways.md). # MQTT-Edge-Gateways MQTT-Edge-Gateways für Kilo IoT — Brücken von Modbus, BACnet, OPC-UA, Sparkplug B und Zigbee2MQTT zu MQTT. In kommerziellen Bereitstellungen ist der MQTT-Connector oft die Integrationsschnittstelle für **Edge-Gateways** — kleine Computer oder Industriegeräte, die Nicht-MQTT-Protokolle in MQTT-Veröffentlichungen übersetzen. Modbus-PLCs, BACnet-Gebäudemanagementsysteme, OPC-UA-exponierte Steuerungssysteme, mit Sparkplug B ausgestattete Automatisierung und Zigbee-Meshes sprechen MQTT nicht nativ, aber gut unterstützte Gateway-Software kann jedes davon über ein einheitliches Topic- und Payload-Modell in den Connector der Plattform einbinden. Diese Seite behandelt die Architekturmuster für MQTT-Edge-Gateways und die Designentscheidungen, die beeinflussen, wie sauber sie sich integrieren. Es ist keine Schritt-für-Schritt-Einrichtungsanleitung für ein bestimmtes Gateway-Produkt — die Installation wird in der Herstellerdokumentation behandelt; diese Seite ist die Integrationsreferenz. ## Was ein MQTT-Edge-Gateway tut Das Edge-Gateway sitzt zwischen Nicht-MQTT-Feldgeräten und dem MQTT-Broker. Seine Aufgaben: 1. **Aus dem Quellprotokoll lesen** — Modbus-RTU/TCP-Abfragezyklen, BACnet-COV-Abonnements, OPC-UA-Abonnements, Sparkplug-B-Knotensitzungen, Teilnahme am Zigbee-Mesh. 2. **Werte normalisieren** — Skalierungsfaktoren anwenden, Einheiten in einen konsistenten Satz umrechnen, Bitfelder und Enumerationen in menschenlesbare Werte dekodieren. 3. **An MQTT veröffentlichen** — JSON-Payloads in eine Topic-Struktur ausgeben, die von nachgelagerten Abonnenten verarbeitet werden kann. (Sparkplug-B-Protocol-Buffers müssen vor dem Publizieren an Topics, die der MQTT-Connector der Plattform verarbeitet, in JSON übersetzt werden — siehe unten „Gängige Gateway-Kategorien“.) 4. **Optional Befehle annehmen** — sich bei Steuerungs-Topics anmelden (`/set`, `/cmd`, herstellerspezifisch) und zurück in das Quellprotokoll schreiben. (Der Connector der Plattform verarbeitet Telemetriedaten; Steuerungsflüsse liegen auf der Gateway-Seite.) Das Gateway ist typischerweise ein kleines Linux-Gerät in der Nähe der Feldgeräte — ein Industrie-PC, ein Rechner für die Hutschiene, ein Raspberry Pi oder ein Herstellergerät. Im Betrieb läuft es als Systemdienst mit Neustart-bei-Fehler-Semantik. ## Gängige Gateway-Kategorien | Kategorie | Typische Software / Appliances | Topic-Struktur | Payload-Format | | ------------------------------ | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Modbus → MQTT** | Modbus2MQTT, von Anbietern bereitgestellte Gateways (Advantech, Moxa), benutzerdefinierte Node-RED-Flows | `{site}/{plc}/{deviceId}/data` oder Topics pro Register | JSON-Objekt oder ein Wert pro Topic | | **BACnet → MQTT** | Herstellerseitige BMS-Bridges, EasyIO, benutzerdefinierte Integrationsplattformen | `building/{floor}/{ahu-id}/{point}` | JSON mit Zuordnung von Punkt zu Wert | | **OPC-UA → MQTT** | OPC Router, FactoryStudio, Sparkplug-B-Edge-Nodes | Sparkplug `spBv1.0/{group}/DDATA/{node}/{device}` oder benutzerdefiniert | **Muss JSON sein, damit der Connector der Plattform es aufnehmen kann.** Sparkplug-B-Protocol-Buffers müssen vom Edge-Gateway vor dem Publizieren in JSON übersetzt werden. | | **Sparkplug-B nativ** | Inductive Automation Ignition Edge, Cirrus-Link-Edge-Gateways | `spBv1.0/{group}/DDATA/{node}/{device}` | **Müssen vom Edge-Gateway vor der Aufnahme durch den MQTT-Connector in JSON übersetzt werden.** Der MQTT-Connector der Plattform dekodiert Sparkplug-B-Protocol-Buffers nicht. | | **Zigbee → MQTT** | Zigbee2MQTT (Open Source, häufig in Pilotprojekten und kleinen kommerziellen Bereitstellungen) | `zigbee2mqtt/{friendlyName}` | Flaches JSON | | **Benutzerdefinierte Bridges** | Selbst entwickelte Python-/Node.js-Bridges über Hersteller-APIs | Was auch immer der Bridge-Autor gewählt hat | Meist JSON | Die Plattform verarbeitet jede dieser Varianten — der Connector ist protokollunabhängig. Entscheidend bei der Integration ist, dass die Topic-Struktur des Gateways im Feld Device ID Topic und die Payload-Struktur des Gateways im Tab Mapping übereinstimmen. Siehe [Topics und Geräte-Routing](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md) für die Routing-Details. ## Designüberlegungen für neue Edge-Gateway-Integrationen Bei der Auswahl oder Konfiguration eines Edge-Gateways für eine neue kommerzielle Integration beeinflussen vier Designentscheidungen die Qualität der Aufnahme: ### Topic-Struktur Eine vorhersehbare, hierarchische Topic-Struktur vereinfacht die Geräteregistrierung und macht Topic-Muster für ähnliche Geräte wiederverwendbar. Empfohlen: ``` {site}/{system}/{deviceId}/{metric-or-data} ``` Zum Beispiel, `plant-3/line-a/extruder-04/data` für ein Statusobjekt in flachem JSON, oder `plant-3/line-a/extruder-04/temperature` für einen Wert pro Topic. Musterfreundliche Strukturen erlauben es, mit einem Device-ID-Topic-Muster viele Geräte derselben Familie abzudecken — `plant-3/line-a/{{deviceId}}/data` funktioniert für jedes Gerät auf Linie A. Vermeiden: * Leerzeichen in irgendeinem Segment, besonders im Segment der Gerätekennung. Das Device-ID-Eingabefeld entfernt Leerzeichen. * Das Mischen von Kennungs-Konventionen innerhalb einer einzelnen Integration. Wenn einige Geräte Bindestriche und andere Unterstriche verwenden, dokumentieren Sie die Wahl und wenden Sie sie konsistent an. * Freiform-Metadaten im Topic einzubetten (Bedienernamen, Daten, Arbeitsauftragsnummern). Topics sind Routing-Keys, keine Anmerkungen — Metadaten gehören in die Payload. ### Payload-Format Flaches oder nur leicht verschachteltes JSON vereinfacht den Tab Mapping. Die Plattform flacht verschachtelte Objekte automatisch zu Pfaden in Punktnotation ab, sodass `{"vibration": {"rms": 0.42, "peak": 1.8}}` wird zu `vibration.rms` und `vibration.peak` als Kandidaten für Connector Keys. Tief verschachtelte Hierarchien funktionieren weiterhin, sind für Betreiber, die Zuordnungen prüfen, aber weniger ergonomisch. **Sparkplug B erfordert eine JSON-Übersetzung am Edge.** Der MQTT-Connector der Plattform verarbeitet JSON-Payloads — er dekodiert Sparkplug-B-Protocol-Buffers nicht nativ. Edge-Gateways, die Sparkplug B verwenden (Inductive Automation Ignition Edge, Cirrus Link MQTT Modules, OPC Router mit Sparkplug-Ausgabe), müssen so konfiguriert werden, dass sie Protocol Buffers vor dem Publizieren an Topics, die der Connector abonniert, in JSON übersetzen. Die meisten kommerziellen Sparkplug-fähigen Edge-Gateways bieten diese Übersetzung als Standardkonfigurationsoption an. ### Veröffentlichungsrate Die Veröffentlichungsrate ist eine deploymentspezifische Entscheidung, die von Zielvorgaben für die Reaktionszeit der Rules Engine, der Broker-Kapazität und den Fähigkeiten der Gerätefirmware bestimmt wird. Die COV-/Dead-Band-Konfiguration des Edge-Gateways ist der Hebel, um redundante Veröffentlichungen zu reduzieren, sobald für eine bestimmte Geräteklasse eine Basisfrequenz festgelegt wurde. Prüfen Sie die Rate, die das Edge-Gateway aufrechterhalten kann, gegen die Regeln und Dashboards, die die Daten verwenden, und passen Sie sie an, wenn die Bereitstellung reift. ### Zuverlässigkeit und Verhalten bei Verbindungsunterbrechungen Konfigurieren Sie das Gateway für betriebsrelevante Telemetrie mit: * **MQTT QoS 1** für Telemetrie-Topics — Zustellung mindestens einmal; das Gateway wiederholt beim Wiederverbinden mit dem Broker. * **MQTT Last Will and Testament (LWT)** — die Mitteilung des Gateways „Ich wurde unerwartet getrennt“, typischerweise als retained message an ein Status-Topic veröffentlicht. Wenn Ihr Broker die LWT-Nachricht als normales abonniertes Publish an den Connector liefert, kann ein `Status` Feld so zugeordnet werden, dass die Gateway-Konnektivität abgebildet wird — validieren Sie den Pfad mit einem absichtlichen Trennungstest, bevor Sie sich im Betrieb darauf verlassen. * **Beibehaltene „online“-Nachrichten** — beim Verbinden veröffentlicht, beim Trennen durch LWT ersetzt. Abonnenten (einschließlich neu später verbundener) sehen den aktuellen Verbindungsstatus sofort. * **Persistenter lokaler Speicher** — das Gateway puffert Telemetrie, solange es vom Broker getrennt ist, und spielt sie bei der Wiederverbindung erneut ab. Die meisten kommerziellen Edge-Gateways unterstützen dies; prüfen Sie die Puffergröße im Hinblick auf erwartete Trennungszeiträume. ## In diesem Abschnitt * [**Zigbee2MQTT-Hubs**](/kilo-docs-de/kilo-iot-server/gateways/mqtt-edge-gateways/zigbee2mqtt-hubs.md) — Zigbee2MQTT als ein MQTT-Edge-Gateway-Muster: Hub-Topologie, Eignung für den Einsatz, Hinweise zur Kapazitätsvalidierung und wie der resultierende MQTT-Stream in den standardmäßigen Geräte-Routing-Flow einfließt. ## Wohin als Nächstes * [Topics und Geräte-Routing](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/topics-and-device-routing.md) — das Registrieren von Geräten hinter einem dieser Gateways. * [Cloud-MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/cloud-mqtt.md) und [Externes MQTT](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/external-mqtt.md) — die Broker-Seite auswählen. * [Fehlerbehebung](/kilo-docs-de/kilo-iot-server/connectors/mqtt-connector/troubleshooting.md) — Probleme bei der Aufnahme diagnostizieren. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/gateways/mqtt-edge-gateways.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.