Aktueller Master-Broker

Ausgang

Der Name des derzeitigen Master-Brokers wird als Text ausgegeben.

Alle Topics veröffentlichen

Eingang

Über diesen Eingang kann das Publishen des MQTT-Clients erzwungen werden. Alle zwischengespeicherten Netzinhalte werden über die Topics veröffentlicht. Sollte der Broker beispielsweise unerreichbar gewesen sein, könnten somit bei Reconnect die letzten Zustände an den Broker gesendet werden.

Diagnose [Text]

Ausgang

Hier werden Fehlertexte ausgegeben. Diese können z.B. mit der Komponente "Protokollfenster" angezeigt werden. Achtung: Diagnose oder Debug - Ausgängen sind nur für den Fehlerfall vorgesehen. Bitte nur mit Rücksprache mit dem Supportteam verwenden! Diese können bei Verwendung die Leistung des Dienstes erheblich beeinträchtigen

Erweiterte Diagnose (Level-Einstellungen)

Eingang

(De)Aktiviert die erweiterte Debug-Ausgabe. Die erweiterte Diagnose kann hierbei über verschiedene Levels ausgabetechnisch (z.B. an einem Protokollfenster zur Ausgabe) gesteuert werden. Es können hierbei Werte von 0, 1 und 2 auf diesen Eingang über 8Bit geschickt werden und damit die Ausgaben übersichtlicher gestaltet werden.

0 = Deaktiviert den erweiterten Diagnoseausgang

1 = Aktiviert die Ausgabe von relevanten Ereignissen (z.B. Connect, Disconnect, Limitausgaben) ohne weitere Details.

2 = Aktiviert die komplette Protokollausgabe inkl. Publish-/Subscribe-Meldungen des Clients, sofern in den Einstellung der Komponente die Subscription-/Publish-Meldungen nicht abgeschaltet wurden.

KNX Gateway - Anzahl Objekte in Sendeschlange

Ausgang

Gibt die Anzahl der Objekte aus, die sich in der Send-Queue befinden.

KNX Gateway - Sendeschlange löschen

Eingang

Löscht die gesamte Sendeschlange.

Primärer Broker ist Master-Broker

Ausgang

Ausgabestatus, ob der primäre Broker der aktuelle Master-Broker ist oder nicht.

Dynamisch

Ordner

In diesem Ordner werden die dynamischen Datenpunkte aus den Kanälen (Topics) erzeugt.

Statistik

Ordner

Über die Datenpunkte können in Echtzeit empfangene und gesendete Nachrichten, wie auch Datenmengen in Bytes je Minute/Stunde/Tag und seit Start ausgegeben und analysiert werden. Ein Reset zur Laufzeit ist ebenso möglich.

Treiber An/Aus

Bidirektional

(De)Aktivieren der Komponente

Treiber Gateway - Allgemein

Bidirektional

Unidirektionale Kommunikationsschnittstelle zwischen diesem Treiber und dem Serial-Treiber.

Treiber Gateway - BACnet Client

Bidirektional

Bidirektionale Kommunikationsschnittstelle zwischen BACnet Client und  MQTT-Client. Siehe Treiber Gateway.

Treiber Gateway - BACnet Server

Bidirektional

Bidirektionale Kommunikationsschnittstelle zwischen BACnet Server und  MQTT-Client. Siehe Treiber Gateway.

Treiber Gateway - KNX

Bidirektional

Bidirektionale Kommunikationsschnittstelle zwischen KNX und MQTT-Client. Siehe Treiber Gateway.

Treiber Gateway - Modbus Master

Bidirektional

Bidirektionale Kommunikationsschnittstelle zwischen Modbus Master und  MQTT-Client. Siehe Treiber Gateway.

Uptime

Ausgang

Laufzeit des MQTT-Clients ab Start als Zeichenkette im Format Tag.Stunden:Minuten:Sekunden (00.00:00:00).

Uptime [s]

Ausgang

Laufzeit des MQTT-Clients ab Start in Sekunden.

Verbindungsstatus

Ausgang

Gibt den derzeitigen Verbindungsstatus als "An/Aus/Undefiniert"-Signal aus. An=Verbindung OK, Aus=Verbindung gestört/nicht registriert, Undefiniert=Client nicht initialisiert.

Payload [Bytes]

Bidirektional

Payload sind die eigentlichen transportierten Rohdaten (ohne MQTT-Header)  in Form eines Byte Arrays.

Payload Profil

Ordner

Sofern Payload-Profile angelegt und einem Topic (Datentyp: String) zugeordnet wurden, wird ein weiterer Unterordner erzeugt, in welchem die Ein-/ Ausgänge der Payload-Profilfelder zu finden sind. Hinweise zu den Payload-Profilen weiter unten in einem Beispiel.

Payload Profil (Publish JSON)

Ausgang

Ausgabe der zu Veröffentlichen Daten für das gesetzte Profil.

Payload Profil (Publish Trigger)

Eingang

Triggert das Veröffentlichen der Daten für das gesetzte Profil. Anmerkung: Der Anschluss ist nur vorhanden, wenn ein Profil im Topic-Kanaleditor auch zugeordnet wurde.

QoS

Ausgang

Das Quality of Service (QoS)-Niveau ist eine Vereinbarung zwischen dem Absender einer Nachricht und dem Empfänger einer Nachricht, die die Zustellgarantie für eine bestimmte Nachricht definiert.

 
Es gibt 3 QoS-Stufen in MQTT:

•0: „Fire-and-forget“ – das Paket wird genau einmal verschickt. Kommt an, unter Umständen auch vielleicht mal nicht, analog dem UDP-Protokoll. Zustellung: enorm schnell.

•1: „Acknowledgement“ – der Empfänger bestätigt dem Sender, das Paket erhalten zu haben. Es ist möglich, dass ein Paket mehrmals ankommt. Zustellung: sehr schnell.

•2: „Synchronisiert“ – das Paket erreicht garantiert das Ziel, und zwar garantiert nur einmal, jedoch erzeugt diese Variante etwas mehr "Verkehr". Zustellung: etwas langsamer.

Wert

Bidirektional

Wert des Topics unter Berücksichtigung des definierten Faktors im zugehörigen Kanaleditors. Bitte die Einstellung Publish/Subscribe im Kanaleditor je Topic beachten.

Zeitstempel

Ausgang

Zeitstempel des zuletzt erhaltenen Wertes.

Verbindung

...

Eingabe der Verbindungsdaten zum MQTT-Broker - siehe unten.

Weitere Broker-Verbindungen

0

Hier können zusätzliche Broker angelegt werden, die ebenfalls die Daten zeitgleich erhalten sollen. Mit dieser Funktion ist es möglich, Topics an mehrere Broker zu publishen und/oder zu abonnieren - es kann hierüber eine Redundanzlösung aufgebaut werden.

Payload Profile

...

Über selbstdefinierte Payload-Profile ist es möglich, JSON-Strings die in einem Topic übertragen werden, in einzelne Unter-Datenpunkte des jeweiligen Topics entsprechend der Hierarchie aufzusplitten.

Kanäle

0

Für jeden Kanal muss das zu abonnierende MQTT-Topic, sowie der zugehörige Datentyp angegeben werden. Optional kann ein beschreibender Name angegeben werden, der ebenfalls beim Anlegen der Datenpunkte berücksichtigt und dort angezeigt wird. Eingestellt können zusätzlich der QoS-Level, ob die Nachricht Retained werden soll und der Topic gepublished und/oder subscribed werden soll.

Letzter Wille

...

Oft auch als Testament bezeichnet. Der Einsatzzweck dieser speziellen Funktion ist hauptsächlich dem verbundenen MQTT-Broker mitzuteilen, wenn der Client unerwartet offline ist (z.B. Verbindungsabbruch). In der Payload wird der entsprechende Inhalt für diesen Zustand hinterlegt und mit einem eigenen Topic definiert.

Alle Topics bei Reconnect veröffentlichen

Deaktiviert

Mittels dieser Eigenschaft, kann das Publishen des MQTT-Clients bei Reconnect des Brokers erzwungen werden. Alle zwischengespeicherten Netzinhalte werden über die Topics veröffentlicht. Sollte der Broker beispielsweise unerreichbar gewesen sein, könnten somit bei Reconnect die letzten Zustände an den Broker gesendet werden.

Basetopic

leer

Der BaseTopic wird in der Kanalliste bei allen Topics vorangestellt. BaseTopic 1234 würde einen bestehenden Topic "sensor/luftfeuchte/wert" in "1234/sensor/luftfeuchte/wert" automatisch umwandeln. Es ist somit möglich, wenn viele Clients von Gebäuden, Anlagen oder Geräten im Broker eindeutig abgebildet werden müssen, dies über den BaseTopic automatisch zu lösen und auch viel schneller und einfacher Kopien zu erzeugen, die sich dann nur über den BaseTopic unterscheiden.

Name an Topic anfügen

Deaktiviert

Hier kann ausgewählt werden, ob der Name (Bezeichnung) des Topics zusätzlich an den Topic angefügt wird, wie er im Kanaleditor definiert wurde. Entsprechend gibt es einen neuen zusätzlichen Export-Mechanismus (Kanaleditor - Export Details), um die Topics inkl. aller Einstellungen und Datentypendefinitionen als Liste ausgeben zu können.

Zyklischen Heartbeat deaktivieren

Deaktiviert

Die zyklische Heartbeat-Meldung wird nicht mehr an den Broker gepublished, wenn die Option aktiv gesetzt wird.

Nachrichten beim Start ignorieren (Dauer [s])

0

Ignoriert beim Starten des Clients über die festgelegte Dauer eingehende Nachrichten wie z.B. retained Topics. Standardwert: 0

Subscription-Meldungen nicht ausgeben

Deaktiviert

Subscription-Meldungen werden im LogLevel 2 der erweiterten Diagnose nicht ausgegeben, sofern aktiviert.

Publish-Meldungen nicht ausgeben

Deaktiviert

Publish-Meldungen werden im LogLevel 2 der erweiterten Diagnose nicht ausgegeben, sofern aktiviert.

JSON immer direkt bei Feldänderung ermitteln

Deaktiviert

Meldungen über empfangene Nachrichten werden im LogLevel 2 der erweiterten Diagnose nicht ausgegeben, sofern aktiviert.

Treiber An/Aus

Deaktiviert

(De)Aktivieren der Komponente

Server URL/IP:

IP-Adresse oder Hostname des abzufragenden Servers.

Port:

Angabe des Kommunikationsport zum MQTT-Broker (Standard: 1883 bzw. 8883 (TLS)). Dieser Port muss in der Firewall eingetragen werden, sobald eine bidirektionale Kommunikation stattfinden soll.

Benutzer / Passwort:

Falls für den Zugriff auf den Broker eine Authentifizierung gefordert wird, können Benutzername und Passwort hinterlegt werden (leer lassen für anonymen Zugang).

Timeout [s]:

Kommunikations-Timeout in Sekunden (Standard: 5 Sekunden)

Client-ID:

Eindeutige Bezeichnung für diesen Client, welche nur einmal verwendet werden darf. Wird die Komponente kopiert, muss eine neue ID generiert oder ein neuer eindeutiger Name gewählt werden.
Die ID für den Client, sofern er auf einen EisBär MQTT-Broker verbinden soll, muss aus Sicherheitsgründen mindestens 10 Zeichen lang sein. Ansonsten wird die Verbindung verweigert.

Websocket:

Optional kann angegeben werden, ob der Telegrammverkehr über Websockets stattfinden soll.

TLS:

Abhängig vom Server kann die Verbindung auch über TLS verschlüsselt werden. Damit werden die Felder für "Alle Zertifikate akzeptieren" und "Server-Zertifikat" aktiv.

Server-Zertifikat:

Pfadangabe zum Server-Zertifikat, welches für die Kommunikation verwendet werden soll. Standardmäßig finden Sie ein von uns selbstsigniertes Zertifkat in Ihrem EisBär-Installationsverzeichnis.
Der Standardpfad inkl. Zertifikat für eine geschützte TLS-Verbindung zwischen EisBär MQTT-Client und EisBär MQTT-Server mit diesem Zertifikat lautet: C:\Program Files (x86)\Alexander Maier GmbH\EisBär SCADA 3.0\mqttbroker.cer

Für den EisBär MQTT-Broker liegt das zu verwendende Zertifikat als pfx-Datei im gleichen Pfad, welches für den Broker nicht speziell übergeben werden muss.