Payload-Profile / Geräteprofile (gilt für MQTT-Client / Broker, TTN und LoRBaer Geräteprofile):
Der Vorteil eines Payload-Profils besteht vor allem darin, falls man mehrere Topics mit gleichem Inhalt (JSON-Strings) von verschiedenen Sensoren/Aktoren auswerten möchte, dass das Profil nur einmal definiert werden muss, aber den verschiedenen Topics zur Auswertung zugewiesen werden können - das spart eine Menge Arbeit und damit auch Zeit. Zudem ist es nicht mehr nötig, den Topic durch die Zusatzkomponente "JSON/XML-Parser" parsen zu müssen.
Im Beispiel enthält der definierte Topic: "sp111_1/tele/sp111_1/SENSOR" statt Rohdaten, Werte oder String, also einen JSON-String mit mehreren Werten, der inhaltlich wie folgt aufgebaut ist: {"Time":"2020-11-11T06:01:52","ENERGY":{"TotalStartTime":"2020-03-01T00:00:00","Total":154.219,"Yesterday":0.366,"Today":0.043,"Period":0,"Power":6,"ApparentPower":21,"ReactivePower":20,"Factor":0.30,"Voltage":232,"Current":0.091}}.
In einer etwas schöneren Darstellung des JSON-Strings wird die Hierarchie etwas deutlicher, um diese korrekt nachbilden zu können:
{
"Time":"2020-11-11T06:01:52",
"ENERGY":{
"TotalStartTime":"2020-03-01T00:00:00",
"Total":154.219,
"Yesterday":0.366,
"Today":0.043,
"Period":0,
"Power":6,
"ApparentPower":21,
"ReactivePower":20,
"Factor":0.30,
"Voltage":232,
"Current":0.091
}
}
Im Payload-Profil-Editor wird über die Haupt- und Untereinträge diese Hierarchie genauso nachgebaut. Wichtig ist, dass die Bezeichnungen der Einträge genau mit den JSON-Inhaltseinträgen übereinstimmen und eine eindeutige Profil-ID vergeben wird. Der Haupteintrag beinhaltet somit einmal Time und ENERGY, wobei Letzterer nochmals in separate Untereinträge (TotalStartTime, Total, etc. ) unterteilt ist. Zusätzlich sind Einstellungen für Richtung, Datentyp und weitere Unterteilungen in Form von Arrays, sofern vorhanden, zu tätigen. Mittels Schaltfläche OK wird dieser Aufbau für die weitere Verwendung übernommen. Verschiedene Import-, als auch Exportfunktionen sind ebenfalls enthalten, sowie einen Wizzard zum automatischen generieren der Profile direkt aus einem JSON heraus.
Hinweis: Beim JSON Import muss der Datentyp kontrolliert werden!
Bezeichnung |
Beschreibung |
|---|---|
Name |
Bezeichnung der Haupt- und Untereinträge der Hierarchie |
Profil ID |
Eindeutige Profil ID |
Container |
Mit dieser Auswahl wird ein Kanal zum Container, welcher weitere Untereinträge haben kann. |
Richtung |
Einstellung der Kommunikationsrichtung |
Datentyp |
Der Datentyp des Kanals muss eingestellt werden. Für den Timestamp gilt die Formatierung: HH:mm:ss für Stunde:Minute:Sekunden dd.MM.yyyy für Tag/Monat/Jahr. |
Ist Array |
Hat der Datenpunkt mehr als eine Information, muss "Ist Array" gesetzt werden. |
Anzahl (Array-) Elemente |
Angabe, wie viele Daten das Array enthält. |
Als Trigger verwenden |
(bei MQTT/LoRBaer) Ist diese Option gesetzt, werden die Daten sofort veröffentlicht. Sonst erst, wenn |
Auto-Trigger wenn alle Felder beschrieben |
(bei MQTT/LoRBaer) Haben alle Datenpunkte einer Gruppe Werte erhalten, wird die gesamte Gruppe veröffentlicht. |
Feldwerte nach Trigger verwerfen |
(bei MQTT/LoRBaer) Löscht den Wert dem Übertragungsprotokoll, sodass dies immer wieder neu gesetzt werden muss und keine alten Daten mehr enthalten kann. |
Faktor |
Mit dem eingestellten Wert wird die Zahl faktorisiert. |
Standard Wert |
Beschreibt das Topic (intern im JSON) mit einem Standard Wert, damit dieser beim Trigger mit gesendet werden kann. |
Ausgabe Standard Wert |
Legt fest, ob der Standard Wert beim setzen auch auf den Ausgang gesendet werden soll. |
Im Kanaleditor des MQTT-Clients/Brokers können nun dem oder den Topics die jeweiligen definierten Payload-Profile zugeordnet werden. Nach der Übernahme der neuen Einstellungen wird automatisch im Kommunikationsfenster der "Dynamisch"-Ordner aktualisiert und spiegelt nun 1:1 den Datenpunktaufbau für den Abgriff des eigentlichen JSON-Strings wieder. Nicht vergessen den Topic-Datentyp auf String einzustellen, wenn mit Payload-Profilen gearbeitet wird.
Kanal Einstellungen (Topics):
Spalten die mit einem (*) gekennzeichnet sind, sind über Multiselectfunktion gleichzeitig editierbar.
Kanal-Editor:
+ |
Hinzufügen eines Topics. |
x |
Löschen des markierten Topics. |
Import (CSV) |
Importiert eine Topic Liste aus einer CSV-Datei. Bestehende Topics werden hierbei gelöscht! |
Import und Hinzufügen (CSV) |
Importiert eine Topic Liste aus einer CSV-Datei. Die Importierten Topics werden zu den bestehenden hinzugefügt. |
Export (CSV) |
Die angelegten Topics können als CSV-Datei exportiert werden. Dabei gibt es 3 Möglichkeiten: CSV: Exportiert die angelegten Topics. Diese Datei kann auch im MQTT Broker importiert werden. CSV mit Basetopic: Wurde ein Basetopic in den Eigenschaften der Komponente definiert, wird dieses vor dem Topic-Namen eingefügt. Diese Datei kann auch im MQTT Broker importiert werden. Details: Dieser Export dient nur zur Dokumentation und kann nicht importiert werden. |
(NUR MQTT-Client) Mit dieser Funktion können Topics gesucht und hinzugefügt werden. Shelly, Tasmota und Hommeassistent |
|
Auswahl Import |
Mit dieser Funktion können Topics generiert werden, die auf Basis anderer Treiber-Exporte erzeugt werden. Siehe Treiber Gateway |
Ausgewählte Topics editieren |
Mit dieser Funktionen können die Topic-Namen geändert werden. |
Name |
Funktion |
|---|---|
Topic |
Struktur- bzw. Themenaufbau des Topics z.B. geaeude/gebaeudeteil/raum/sensor/temperatur/wert. |
Name (*) |
Frei definierbarer Name für den Topic. |
Datentyp (*) |
Typ der Daten, wie sie vom/zum Broker übermittelt/umgesetzt werden. |
An Wert (*) |
Standard: True (Bool). Diese Spalte gilt nur in Verbindung mit Datentyp "Boolean" und ist für eine Ersetzungsregel gedacht, wenn z.B. ein Topic nicht True, sondern ON / AN / OPEN / AUF / UP / etc. beinhaltet oder beinhalten sollte. |
Aus Wert (*) |
Standard: False (Bool). Diese Spalte gilt nur in Verbindung mit Datentyp "Boolean" und ist für eine Ersetzungsregel gedacht, wenn z.B. ein Topic nicht False, sondern OFF / AUS / CLOSE / AB / DOWN / etc. beinhaltet oder beinhalten sollte. |
Faktor (*) |
Faktor für numerische Werte. |
QoS Level (*) |
Einstellung des "Quality of Service" Niveaus. |
Retain (*) |
Ist Retain aktiv, wird der letzte Wert vom Client am Broker vorgehalten. Verbindet sich ein Client oder mehrere Clients wieder auf den Broker und haben diese Topic abonniert, wird sofort dieser Wert veröffentlicht. |
Publish (*) |
Aktiviert das Senden von Daten zum Broker (veröffentlichen). |
Subscribe (*) |
Aktiviert das Empfangen von Daten vom Broker (abonnieren). |
Profile |
Verwendet das eingestellte Profil (siehe Payload Profile). Payload-Profile kommen dann zum Einsatz, wenn der Topic einen JSON-String enthält. Der Datentyp des Topics muss dann auf String eingestellt sein. |
Wildcard:
In MQTT werden Wildcards verwendet, um mehrere Topics gleichzeitig anzusprechen. Es gibt zwei Hauptarten von Wildcards: den Einzelplatz-Wildcard (+) und den Mehrplatz-Wildcard (#).
1. Einzelplatz-Wildcard (+)
Wird verwendet, um genau einen Platz in einem Topic zu ersetzen. Der + Wildcard ersetzt genau einen "Level" in der Topic-Struktur.
Beispiel:
Topic: home/+/temperature
Dies würde alle Topics abdecken, die dem Muster home/{irgendein Platz}/temperature entsprechen, wie zum Beispiel:
home/livingroom/temperature
home/bedroom/temperature
2. Mehrplatz-Wildcard (#)
Wird verwendet, um alle verbleibenden Levels eines Topics zu ersetzen. Der # Wildcard steht für alle nachfolgenden "Levels" im Topic.
Beispiel:
Topic: home/+/temperature/#
Dies würde alle Topics abdecken, die mit home/{irgendein Platz}/temperature beginnen und beliebig viele weitere Levels enthalten, z.B.:
home/kitchen/temperature/sensor1
home/bedroom/temperature/humidity
Hinweise:
•Der # Wildcard muss immer am Ende eines Topics verwendet werden und darf nur einmal auftreten.
•Der + Wildcard kann an beliebiger Stelle im Topic verwendet werden, aber es wird nur ein Level ersetzt
Discovery-Funktion (Topics sammeln)
Die Discovery-Funktion dient zum automatischen anlegen von MQTT-Topics im MQTT-Client. Hierzu wird ein vorhandener Broker (Verbindungseinstellungen müssen voreingestellt werden), oder der integrierte eigene Broker verwendet.
Falls der Broker im EisBär angelegt ist, muss der Dienst laufen.
Gerate-Discovery auswerten
Wertet die Discovery-Configs aus, mit denen Gerate sich selbst ankündigen: das Home-Assistant-Format, das Zigbee2MQTT, ESPHome, Shelly-BLU-Gateways und andere sprechen, sowie Tasmotas eigenes Format unter tasmota/discovery.
Topics ganz ohne Config werden weiterhin angeboten
Hersteller-Regeln benennen und typisieren die von Shelly, Tasmota, Zigbee2MQTT und ESPHome
Vorhandene Kanäle ersetzen
An: die Kanalliste wird durch das hier Importierte ersetzt.
Aus: die importierten Kanäle kommen dazu, ein Topic mit bereits vorhandenem Kanal wird übersprungen.
Profile werden in keinem Fall gelöscht - ein Import verweist auf ein strukturgleiches vorhandenes Profil, statt eine Kopie anzulegen.