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]

netstat -an | grep LISTEN
Da sollte ein 1883 auftauchen. Wenn das nicht der Fall ist, mal

Code: [Auswählen]

mosquitto -deingeben 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]

#
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