Moin,
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?
Gruss
WK
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.
Jens M. schrieb:> 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.
Bei MQTT Version 3 ging das noch nicht, ab Version 5 kann man das
abfragen. Hier ein paar Infos, was bei MQTT 5 anders ist:
https://www.heise.de/hintergrund/Evolution-der-IoT-Kommunikation-MQTT-5-3941656.html> - 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
- 'home/#'
- 'home/kitchen/#'
- 'home/kitchen/heating/#'
- 'home/kitchen/heating/current_temperatur'
- '#'
Michael
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.
Ben B. schrieb:> 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.
Thread beobachten
Seitenaufteilung abschalten