KNX2MQTT:
Die neue bidirektionale Verbindungsschnittstelle "KNX-Treiber Gateway" ermöglicht die schnelle Realisierung eines KNX nach MQTT Gateways. Über einen Export-/Importvorgang werden alle vorhandenen KNX-Kommunikationsobjekte als Topics im MQTT-Client abgebildet. Intern ist hierzu lediglich eine Netz-Verknüpfung erforderlich. Die MQTT-Topics sind 1:1-Abbildungen der vorhandenen KNX-Datenpunkte (Kommunikationsobjekte). Im MQTT-Client Kanaleditor können die automatisch generierten Topics in ihrer Kommunikationsrichtung angepasst werden (Eingang / Ausgang / Bidirektional) .
Zu den Anwendungsbereichen von MQTT zählt die standortübergreifende Vernetzung von KNX-Anlage(n), optional mit SSL-Verschlüsselung, über einen internen oder externen MQTT-Broker. Es ermöglicht die Aufschaltung mehrerer KNX-Anlagen einer Liegenschaft auf einen oder gar mehrere MQTT-Broker (Redundanz), deren einzelne Gebäude nicht über eine Standleitung vernetzt sein müssen. Die Erfassung von Zählerdaten, Stör- und Betriebsmeldungen, Verbrauchs- und Temperaturwerten oder die Übertragung von Einzel-/Zentralbefehle zählen zu den Hauptanwendungen.
In einem einzelnen Gebäude können dadurch schnell und effizient andere Systeme, die ebenfalls mit dem MQTT-Protokoll arbeiten, Meldungen und Zustände aus der KNX-Welt mitgeteilt werden und natürlich auch umgekehrt.
Vorgehensweise:
Im jeweiligen KNX-Treiber unter Einstellungen - Datenpunkte, wird zuerst ein Export mit der Option "(Export CSV (Tab))" über das Dateimenü ausgeführt, um alle vorhanden Kommunikationsobjekte des Treibers in einer CSV-Datei zu speichern. Das erstellte Exportfile wird anschließend in eine MQTT-Client-Treiberkomponente importiert. Im Kanaleditor des Clients wird in der oberen Menüleiste die Treiberquelle "KNX" für den Import ausgewählt und über den nachfolgenden Dialog die gewünschte Datei übernommen und importiert. Daraufhin werden im Kanaleditor vollautomatisch alle vorhandenen Kommunikationsobjekte in Topics umgewandelt und sind daraufhin zwischen KNX-Treiber und MQTT-Client intern verbunden, ohne die KNX-Datenpunkte mit den MQTT-Topics verknüpfen zu müssen. Die Abbildung der KNX-Datenpunkte sind dann die physikalische Adresse inklusive Objektnummer und Gruppenadressennamen je Kommunikationsobjekt.
Topic-Aufbau
Die physikalische Adresse + Objektnummer + GA Name z.B. "01.11.001.010 Demoanlage.Geschaltet.Flur ein/aus" wird dann als Topic in die Form "01/11/001/010<Demoanlage.Geschaltet.Flur ein|aus> umgewandelt und die Datentypeinstellung ebenfalls automatisch definiert. Das Retain- und Publish-Flag ist automatisch gesetzt. Für eine nötige Bidirektionalität können die Topics individuell mit dem Subscribe-Flag versehen werden.
Abb. 1: Export KNX-Datenpunkte zu CSV (Tab)
Abb. 2: KNX-Import im MQTT-Client Kanaleditor
Abb. 3: Kanaleditor nach KNX-Datenimport (CSV-Tab)
Mehrere KNX-Verbindungen / BaseTopic
Sollten mehrere KNX-Verbindungen z.B. aus mehreren Gebäuden vorhanden sein, bietet es sich an, mit der BaseTopic-Funktion zu arbeiten, welche im MQTT-Client in den Eigenschaften definiert werden kann. Der BaseTopic wird dann an jeden Topic während des Publish- und/oder Subscribe-Vorgangs vorangestellt.
Dadurch lassen sich die Topics am MQTT-Broker leichter zuordnen bzw. auch eindeutiger von anderen MQTT-Clients subscriben - dieser kann aus Zahlen- und/oder Buchstaben bestehen - vereinfacht lassen sich damit Gebäudenummern, Postleitzahlen und dergleichen abbilden. Beachtet werden muss nur, dass der BaseTopic nicht im Kanaleditor "sichtbar" angezeigt wird. Um eine detailgenaue Topicbeschreibung aus dem Client zu erhalten, ist ein "Detailexport" im Kanaleditor möglich.
Abb. 4 +5: BaseTopicBenennung in verschiedenen Variationen
Abb. 6: Auszug aus einem CSV generierten "Detailexport"
Über die Benutzer-/Clientsteuerung des EisBär MQTT-Brokers oder unserer MQTT-EisCloud (externer MQTT-Broker, kostenpflichtig) lassen sich dann beliebige Szenarien zur Verwaltung der Datenlage aus einer oder mehreren Anlagen abbilden - in Abhängigkeiten von Clients, Benutzern mit spezifischer Autorisierung und Authentifizierung.
Ein spezielles Features unseres EisBär MQTT-Clients erlaubt zudem die Daten nicht nur an einen, sondern an mehrere Broker gleichzeitig zu schicken bzw. zu empfangen (Redundanz). Perfektes Zusammenspiel zur Anlagenkopplung über Mobilfunk, Internet oder Standleitungen wird immer in der Kombination: EisBär MQTT-Client und EisBär MQTT-Broker bzw. EisBär MQTT-EisCloud erzielt, da es in diesem Falle nicht nur einen Primary-Broker (Master) gibt, sondern auch mindestens einen oder mehrere Secondary-Broker (Slaves). Die Datenlage und Verbindungen werden vollständig im EisBär MQTT-Client geregelt, das Datenmanagement über den Broker.