MQTT - FAQ

[Rince]

MQTT, FAQ zum mitmachen

Hi,
ich würde gerne in diesem Thread eine kleine FAQ zum Thema MQTT schreiben. Jeder darf mitmachen. Ich verlinke dann den Thread mit dem Thema im 1. Post.
Bitte hier keine Fragen stellen!

Grundlagen
MQTT - eine kurze Einführung Teil 1
MQTT - eine kurze Einführung Teil 2
MQTT - eine kurze Einführung Teil 3

Los gehts:
Best Practice um Topic Trees zu benennen
Übersicht MQTT Broker
Installation des MQTT Brokers Mosquitto auf RasPi mit Debian
MQTT auf OpenWRT  mit Installation der für FHEM benötigten Cpan Module
Sicherheit
Fehlersuche, Basic
Besipielkonfiguration in FHEM für sonoff mit Tasmota (Achtung, Tasmota scheint keinen Topic Tree zu kennen! Also keine / verwenden)

[Rince]

Installation auf einem RasPi

Leider wird auch mit Jessie ein veralteter MQTT Broker (Mosquito 1.3.4-2) ausgeliefert. (Stand: 05.04.2017) Da dieser MQTT in Version 3.1.1 noch nicht kann, muss er von Hand hinzugefügt werden:

Hier nachzulesen:
https://oshlab.com/install-mqtt-mosquitto-raspberry-pi/

Die Anleitung kann einfach von oben bis unten C&P werden. Einzig beachten,

Now install the packages list for your version of Raspbian.

hier die Zeile eurer Version kopieren.



Hier die Beschreibung wie man Mosquitto mit einem Zertifikat betreibt



Diksussion um den grundsätzlichen Sinn von MQTT 3.1.1 statt 3.1

[Rince]

MQTT Broker
Es gibt viele verschiedene Broker:


Wer selber einen Broker betreiben will:
(was dringend empfohlen ist)
Mosquitto,HiveMQ, emqttd, ...

Welchen man nimmt, hängt wohl von der eigenen Vorliebe hat.

Hier ist eine Vergleichsübersicht über diverse MQTT Broker


Mosqitto und emqttd sind beide Open Source mit einer bei Makern gefühlte hohen Verbreitung => nicht belastbare Aussage, nur mein subjektiver Eindruck



Wer einfach mal kurz in MQTT reinschnuppern will, ohne einen Broker zu installieren
test.mosquitto.org
www.cloudmqtt.com
(wenn der Client eine IP Adresse braucht, einfach mit "ping test.mosquitto.org" anpingen)

Achtung:
Das sind öffentlich zugängliche Broker. Dauerhaft Daten seiner Haussteuerung darüber zu übertragen fällt ins Kapitel DAU

[Rince]

Sicherheit

Grundlagen MQTT Sicherheit auf Heise Developer, geschrieben von Dominik Obermaier, Geschäftsführer der Firma, die HiveMQ vertreibt

Kurzfassung:
Keine MQTT Devices ans Internet bringen
Username / Passwort ist etwas besser als gar nichts, je nach Client & Broker erfolgt die Übertragung aber im Klartext
TLS: Königsweg, kommt aber für viele Clients mangels Unterstützung nicht in Frage (PubSubClient)

Wer Pfuscht ist in bester Gesellschaft 
MQTT-Protokoll: IoT-Kommunikation von Reaktoren und Gefängnissen öffentlich einsehbar

FHEM User sollten sich das zu Herzen nehmen und nicht ihren Broker mit einem Port-Forward oder einem exposed Host ans Internet anbinden
(Wir hatten die Diskussion im Forum schon mal, wie viele Leute aus Unwissenheit einfach Port 8083 weitergeleitet haben...)

[Rince]

Fehlersuche

1.Läuft überhaupt der Broker (Debian)
Mit folgendem Befehl bekommt man alle offenen Ports auf dem Rechner:

Code Auswählen Erweitern


netstat -an | grep LISTEN

Da sollte ein 1883 auftauchen. Wenn das nicht der Fall ist, mal

Code Auswählen Erweitern

mosquitto -d
eingeben und nochmals versuchen.

Ich hab den Aufruf in meiner fhem Startdatei eingebaut, ebenso wird der Broker mit FHEM auch beendet. Ob das schlau ist weiß ich nicht, aber es funktioniert.

2. Daten kommen nicht an
Meist stimmen dann die Topics nicht.

Hier ist ein Analysetool gefragt. Diese kann man auf irgend einem Rechner in seinem Netzwerk laufen lassen.

MQTT Spy
oder auch
MQTT.fx

Die Vorgehensweise ist bei beiden Programmen ähnlich.
Zunächst den eigenen Broker angeben (also z.B. die IP des Rechners, wo FHEM läuft, wenn ihr auch da den Broker drauf laufen habt)

Dann subscriben. Um zu sehen was überhaupt alles läuft, kann man zum Test ja mal alles subscriben.

Code Auswählen Erweitern

#
Dann sieht man schön, was wo gepublished wird. Das Topic muss mit der Subscription übereinstimmen.

Auch verschiedene Inhalte kann man so recht bequem publishen. So sieht man gut, ob ein Subscriber mit verschiedenen Daten umgehen kann.

Kommandozeile

Was ist der Vorteil gegenüber dem "client" auf debian z.b. mosquitto_sub -d -v -t \#

Mit obigem Befehl subscribed man auch # auf seinem Broker.
Ich denke nicht, dass es besser oder schlechter ist über eine Kommandozeile zu arbeiten. Ich persönlich finde die Programme mit grafischem UI übersichtlicher.

Am besten beides ausprobieren 

[maruro]

Hallo Rince,

ich fände es noch stark, wenn man bspw in einfachen Worten die Unterschiede zwischen MQTT_DEVICE, MQTT_Bridge, MQTT_Server, Client, MQTT2 erklärt. wär das was für die FAQ-Section?

[Beta-User]

Moin zusammen,

generell finde ich die Anregung gut, in den bestehenden Artikeln zu checken, ob es vor dem Hintergrund der neuen Module Klarstellungsbedarf gibt.

Eine kurze generelle Übersicht unter Berücksichtigung der neuen Module habe ich mal hier angefangen, das darf gerne verbessert und erweitert werden.
MQTT_BRIDGE findet darin gar keine Erwähnung mehr. Das hat den Hintergrund, dass die Funktionalität dieses Moduls durch MQTT_GENERIC_BRIDGE seit einiger Zeit allgemein und generell verfügbar gemacht wird, ohne dass bisher Nachteile erkennbar wären. Dafür hat die neue Version der Generic Bridge den Vorteil, jetzt auch mit MQTT2_CLIENT zusammenzuarbeiten.

Kurz gefaßt: Für zukünftige Installationen, die mit mosquitto laufen oder weitere FHEM-Instanzen, die mit dem MQTT-Protokoll über einen MQTT2-Server auf einem anderen FHEM eingebunden werden sollen, scheint es empfehlenswert, statt dem MQTT (-IO)-Modul den MQTT2_CLIENT zu nutzen und dann die Devices alle als MQTT2_DEVICE einzubinden (statt MQTT_DEVICE) bzw. "andere" FHEM-Devices über MQTT_GENERIC_BRIDGE "mqtt-fähig" zu machen.

MQTT_DEVICE und MQTT_BRIDGE sind also vor allem erforderlich, um nichts an bestehenden Installationen ändern zu müssen.

Hoffe, den aktuellen Stand halbwegs verständlich zusammengefaßt zu haben.

Gruß, Beta-User

[andies]

Ich zitiere mal aus einem anderen Thread mit folgenden Vorschlägen:

Ich zähle derzeit die folgenden Einträge

MQTT
MQTT Einführung
MQTT Einführung Teil 2
MQTT Einführung Teil 3
MQTT2 CLIENT
MQTT2 DEVICE
MQTT2-Module - Praxisbeispiele

und das muss ja nicht sein. Mein Vorschlag wäre das umzustrukturieren:

MQTT mit den Unterabschnitten
Einführung (alle drei Teile, umstellen, sortieren)
FHEM Einbindung mit klassisch (kurz) und MQTT2 mit den Unterunterabschnitten CLIENT und DEVICE [Alternativ: Einzelne Seiten]
  Praxisbeispiele

Wie ist die Meinung?

[Beta-User]

und das muss ja nicht sein.

...dann zitiere ich mal folgendes:

Falscher Thread und Einspruch , jedenfalls, was den MQTT2-Teil angeht.

Und so "unstrukturiert" finde ich das auch nicht:

MQTT - enthält den groben Überblick "über alles" (soweit es FHEM betrifft). Der kann ggf. verbessert werden, Vorschläge sind willkommen, aber als Überblicksartikel finde ich das unter dem Schlagwort richtig, genau einen Überblick zu erhalten.

Die anderen sind entweder (wie häufig üblich) "Modulartikel" und entsprechend kurz gefaßt, oder eben eine Praxisanleitung für diverses, in der die Dinge im Zusammenhang dargestellt sind (@MQTT2_DEVICE/SERVER). Finden die meisten, die ihn gefunden haben ganz gut... Hier passen m.E. auch die Verlinkungen soweit (Verbesserungsvorschläge: gerne!).

Was m.E. verbessert werden kann, sind die MQTT-Einführungs-Artikel; diese sind vor "MQTT2"-entstanden (die Anführungszeichen sollen nur darauf hinweisen, dass es sich um die FHEM-interne Terminologie handelt, das Protokoll selbst ist unverändert), und könnten nach meinem persönlichen Geschmackt noch besser rausarbeiten, wo die Unterschiede zu den alternativen neueren Modulen liegen. Da ist aber auch manches zum Protokoll (und den (Arduino-) Clients) erläutert, was auch Sinn macht (aber ein ganz anderer Schwerpunkt!).
Zu der "Einführung" gibt es auch einen angepinnten Thread im MQTT-Bereich. Bitte ggf. da konkrete Anregungen anbringen.

M.E. wird es völlig unübersichtlich, wenn man 00_MQTT und 00_MQTT2.* nicht sauber trennt. Das einzige, was gleich ist, sind die Einstellungen auf den Clients...

[Beta-User]

Nachtrag noch: Es gibt auch noch weitere Artikel . Zumindest:
https://wiki.fhem.de/wiki/MQTT_DEVICE
https://wiki.fhem.de/wiki/MQTT_(Modul)
In den zweiten habe ich eben noch eine Hinweisbox auf MQTT2_CLIENT als Alternative reingebastelt sowie ein paar "Kleinigkeiten" zu MQTT_GENERIC_BRIDGE.

[andies]

Na super.

Wollen wir erstmal einen Teil klären? Ich bin für wenig Artikel. Wozu zB drei einzelne Einführungen mit Titeln wie ,,Hände schmutzig machen"? Welche Artikel? Und wer entscheidet am Ende unserer Diskussion?

[Beta-User]

Habe dazu mal einen Thread angefangen:

https://forum.fhem.de/index.php/topic,101549.0.html

Wenn, dann sollte man m.E. wissen, wo man hinwill, und wenige Artikel sind m.E. kein Mehrwert für sich, v.a. dann nicht, wenn die Schwerpunktsetzung sehr unterschiedlich ist. Dafür gibt es die Option, Links einzufügen, damit jeder (hoffentlich) das findet, was für ihn relevant ist.

Am Ende hatten wir m.E. in den meisten Fällen einer Diskussion zu Wiki-Artikeln ein halbwegs sinnvolles gemeinsames Ergebnis - jeder hat da halt einen etwas anderen Blickwinkel auf die Dinge. (Und btw.: ich hänge nicht an bestimmten Artikeln; die derzeitige Struktur v.a. rund um MQTT2 hat sich schlicht so im Lauf der Zeit ergeben...)