Ich frag' mal hier, obwohls nicht direkt mit Smart Behausung zu tun hat, aber ich geh' mal davon aus, dass hier doch eher Leute Bescheid wissen.
Grad guck' ich mir zum 1. Mal so ein bisschen MQTT an - und schon stolper ich ueber ein paar Dinge, die wahrscheinlich jedem, der das schon laenger/oefter gemacht hat, voellig klar sind. Nur mir halt noch nicht.
Alzont:
Ich hab' hier kein echtes MQTT-Equipment rumfliegen, sondern das ist nur eine Trockenschwimmuebung unter Linux; Netzwerk ist nur der lokale Horst. Da hab' ich mir mosquitto installiert und folgendes Setup:
mit "mosquitto" den Broker gestartet
in einem Terminal lausch' ich so:
1
mosquitto_sub -h 127.0.0.1 -t bla/blupp
im anderen quake ich so:
1
mosquitto_pub -h 127.0.0.1 -t bla/blupp -m dfgghf
So weit so gut. Laeuft erstmal.
Jetzt frage ich mich/euch:
Gibt's bei MQTT irgendein genormtes Verfahren, wie man von einem Geraet mitbekommt, auf was fuer topics es was publiziert? und was das dann bedeutet (Scheint ja auch "gerne" mal JSON als Payload genommen zu werden)? Oder auf welchen topics es selbst subscribed ist?
Also so aehnlich wie evtl. eine MIB bei SNMP?
Oder muss das stumpf alles im Datenblatt des Geraets stehen, sonst hab' ich keine Chance - ausser mit wireshark mir einen Wolf zu lauschen und auf Nachrichten zu hoffen?
Gibts ein genormtes Verfahren, bei einem Geraet eine "Publikation" per MQTT zu triggern? Also z.b. hab' ich ein Thermometer. Das kann jetzt z.b. alle Sekunde die Temperatur per MQTT ins Netz troeten, obwohl es keinen interessiert. Da waer's doch evtl. gscheider, das Thermometer im Bedarfsfall einfach zu fragen: "Wieviel Grad hats denn bei dir"...Ist da was bei MQTT vorgesehen?
Es gibt wildcards in den Topics, auch ein ‚Ich möchte alles‘.
Man kann ein Topic als Kommandokanal einrichten und darüber Funktionen triggern. Einen Standard gibt dafür es afaik nicht.
MQTT ist ein Protokoll zur Nachrichtenübermittlung, wie Mail.
Da gibt es auch keine Info wem jemand eine Mail zu schreiben gedenkt, oder ein Verfahren eine Mail anzufordern.
Also
Nur der Broker weiß, was jemand abonniert hat. Vielleicht teilt er dir das sogar mit.
Was ein Gerät schickt, wann und an welches Topic weiß allein der Programmierer des Geräts. Wenn er dir nix erzählt: Pech.
Was ein Gerät belauscht, kann dir der Broker sagen, das ist der einzige der das weiß. Was man da hin schicken kann und was dann passiert weiß auch hier wieder nur der Gerätekonstrukteur. Keine Info? Keine Kekse.
MQTT ist ein Protokoll zur Nachrichtenübermittlung, wie Mail.
Da gibt es auch keine Info wem jemand eine Mail zu schreiben gedenkt,
oder ein Verfahren eine Mail anzufordern.
Genau, nicht einmal die Sprache ist standardisiert. Tatsächlich ist die Payload kein String sondern binärdaten, d.h. da kann wie bei TCP oder UDP alles als Payload drinstehen. MQTT selbst regelt nur den Transport, nicht den Inhalt.
Nur der Broker weiß, was jemand abonniert hat. Vielleicht teilt er dir
das sogar mit.
Was ein Gerät schickt, wann und an welches Topic weiß allein der
Programmierer des Geräts. Wenn er dir nix erzählt: Pech.
Es gibt mehrere "Standards" wie der Namensraum der Topics aufgeteilt ist und auch der Inhalt definiert ist. Sparkplug hört man ab und zu mal als Beispiel. Wir haben unsere eigene Definition gemacht.
Wenn du nur eine Seite (Client oder Server) in der Hand hast, dann musst du mit dem leben, was die entsprechenden Geräte liefern. Ggf. kannst du wenigstens die Namen und Pfade der Topics definieren und damit den Clients das Leben erleichtern.
Mit wildcard wie '#' kannst du dann z.B. alles von einem Gerät oder einer Gruppe von Geräten subscriben, hier ein paar Beispiele
MQTT ist halt ein Transportprotokoll. Alle höheren Schichten muss man entweder selber basteln oder einen Standard für die höheren Schichten finden an dem man sich dann hält.
Wenn du insgesamt ein System, nicht nur ein Transportprotokoll haben möchtest, in dem auch höhere Schichtens standardisiert sind, dann wäre das LwM2M mit CoAP und IPSO Smart Objects, statt MQTT.
Der Stack ist aber vielen Bastlern zu kompliziert - obwohl er es praktisch gar nicht ist. So sind IPSO Smart Objects weder Smart noch wirkliche Objects, sondern einfach Datenstrukturen. Jede standardisierte Datenstruktur hat eine Nummer, die Object ID.
Für dein Thermometer-Beispiel wäre die standardisierte Object ID 3303 und ein Sensor würde z.B. als /3303/0/5700 adressiert werden. Dabei sind
0: Erste Instanz eines Temperatursensors, also der erste Sensor im Client
5700: die Resource ID, auch standardisiert, 5700 adressiert die aktuelle oder zuletzt gemessene Temperatur.
Der Server würde vom Client einfach dann /3303/0/5700 auslesen wenn er es braucht. Oder der Server fordert eine Observation vom Client an. In der Observation-Anforderungen würde der Server Bedingungen angeben unter denen er vom Client hören möchte. Wie sofort, ein Zeitintervall, nur wenn sich die Temperatur um einen gewissen Wert geändert hat oder Minimal- oder Maximalwerte unter- oder überschritten werden.
Sind die Bedingungen erfüllt sendet der Client ein Notify.
Ich hatte mir MQTT angeschaut, als ich angefangen habe, mit den Shelly-Strommessgeräten und Zwischensteckern (Pro 3EM und Plus Plug S) herumzubasteln. Die Dinger haben einen ESP32, verbinden sich mit dem WLAN und ich habe keinen Mehrwert mehr zu HTTP-basierten Varianten gefunden - außer, daß diese MQTT-Nachrichten sehr umständlich zu basteln und zu dekodieren sind. Variable Länge einzelner Werte, höchstes Bit gibt an, ob weitere Bytes folgen - für unterdimensionerte µCs mit zu wenig Speicher und kaum messbarer Bandbreite des Übertragungskanals evtl. brauchbar, dazu hat man keine Kontrolle darüber, wann aktuelle Daten zum Broker gesendet werden - bei meinen Steckdosen führte das dazu, daß diese Daten bei Ankunft bereits schon wieder veraltet waren und geringfügige Änderungen in den Messwerten (die ich aber durchaus sehen wollte) überhaupt nicht übertragen wurden. Also das sind für mich keine Mehrwerte, sondern Krücken, die MQTT zumindest bei meinen Versuchen unbrauchbar machen.
Es geht doch nichts über ein selbst geschriebenes Script und eine eigene Datenbank, das funktioniert selbst mit WLAN sekundengenau und die Shellys bieten eine super Schnittstelle dafür, wo man sich die Messwerte einfach via HTTP ziehen kann.
Ich kann noch einen Hinweis auf den "MQTT-Explorer" beisteuern.
Ein hilfreiches freies Tool, um einen MQTT-Server abzulauschen und Nachrichten abzusetzen.
dazu hat man keine Kontrolle darüber, wann aktuelle
Daten zum Broker gesendet werden - bei meinen Steckdosen führte das
dazu, daß diese Daten bei Ankunft bereits schon wieder veraltet waren
und geringfügige Änderungen in den Messwerten (die ich aber durchaus
sehen wollte) überhaupt nicht übertragen wurden.
Na das liegt aber an den Krücken von Shellies, die die Messwerte nur in einem festgelegten Zeitraster senden, nicht an MQTT. Und wenn du bei MQTT QoS 1 oder 2 einstellst, kommen alle Nachrichten auch kontrolliert an. MQTT-Parser gibts auch für den ESP32 (und ESP8266) fertig als Lib. Und mit CayenneLPP bekommst du auch höhere Protokollschichten ausreichend gut hin.
Ja, das schrieb ich ja - kann sein, daß es bei anderen besser funktioniert. Ich habs nur recht schnell weggeschmissen weil die HTTP-basierte Lösung die deutlich bessere war.
