📡

Vorlesung 7

MQTT & Publish/Subscribe
Wie tausend Sensoren zur selben App sprechen — ohne Chaos

Verteilte Systeme
Prof. Dr. Alexandra Mikityuk
HTW Berlin

MQTT Publish/Subscribe IoT

Lernziele für heute

Verstehen, warum HTTP für IoT-Geräte nicht reicht — und was Publish/Subscribe besser macht
Die drei Rollen Publisher · Broker · Subscriber sauber unterscheiden können
Die drei QoS-Stufen einordnen und wissen, wann ihr welche nehmt
Mit mosquitto_pub / mosquitto_sub oder Python einen ersten Pub/Sub-Test fahren

🤔

Denkt mal kurz mit…

Stellt euch vor: 1.000 Sensoren in einer Fabrik. 50 Apps wollen ihre Daten sehen. Ihr baut das mit HTTP aus VL 6.

💭 Was wird damit richtig unangenehm?

Rückblick — HTTP war Anrufen. Heute: Radio hören.

Letzte VL: HTTP & REST — Client fragt, Server antwortet. Funktioniert prima fürs Web. Aber stellt euch das mal mit 1.000 Sensoren vor:

📞 HTTP-Modell

Der Server kann den Client nicht von sich aus ansprechen. Wer wissen will „ist was Neues da?", muss regelmäßig nachfragen — das heißt Polling.

App pollt z.B. alle 5s → viele Requests, auch wenn nix passiert
Sensor und App müssen sich direkt kennen (URL, Auth)
Bei N Sensoren × M Apps → N × M Verbindungen
Keine eingebaute „eins-zu-viele"-Verteilung

📻 Pub/Sub-Modell (Push)

Sensoren senden, wenn's was Neues gibt. Wer interessiert ist, abonniert.

Daten fließen nur, wenn sich etwas ändert
Geringe Latenz: sofortige Benachrichtigung
Sensoren wissen nichts über die Empfänger
Wenig Overhead — perfekt für kleine Geräte

                Heute lernen wir das Pub/Sub-Modell — und sein bekanntester Vertreter heißt MQTT.
            

Die Idee — kennt ihr aus dem Alltag

Publish/Subscribe ist kein neues Konzept. Drei Beispiele aus eurem Leben:

📰 Zeitungs-Abo

Ihr abonniert die Zeitung. Der Verlag druckt und verteilt. Ihr wisst nicht, wer noch abonniert hat — das ist auch egal.

📻 Radio-Sender

Der Sender weiß nicht, wer gerade hört. Er broadcastet. Wer das Programm möchte, schaltet ein — alle anderen verpassen es nichts.

📺 YouTube-Channel

Creator lädt Video hoch (publish), Abonnenten kriegen Benachrichtigung (subscribe). YouTube ist der Mittelsmann.

                Gemeinsam: Sender und Empfänger kennen sich nicht direkt. Es gibt einen Vermittler dazwischen — im Pub/Sub heißt der Broker.
            

Die drei Rollen in einem Pub/Sub-System

📤

Publisher

sendet Daten

→

🏢

Broker

vermittelt + speichert

→

📥

Subscriber

empfängt Daten

📤 Publisher

Schickt Nachrichten zu einem Topic — z.B. ein Sensor schickt Temperatur. Weiß nicht, wer das liest.

🏢 Broker

Das Herzstück. Nimmt Nachrichten an, sortiert sie nach Topic, schickt sie an alle, die abonniert haben.

📥 Subscriber

Sagt dem Broker: „Ich will alles vom Topic X." Wartet dann passiv auf neue Nachrichten.

                Schlüssel-Wort: Entkopplung. Publisher und Subscriber kennen sich nicht — können auch zu unterschiedlichen Zeiten online sein. Der Broker macht's möglich.
            

Was ist MQTT?

Message Queuing Telemetry Transport — ein leichtgewichtiges Pub/Sub-Protokoll.

📜 Historie

1999: IBM + Cirrus Link entwickeln MQTT — Aufgabe: Öl-Pipelines per Satellit überwachen
2014: OASIS-Standard (Version 3.1.1)
2019: ISO/IEC 20922 + Version 5.0
Open Source Broker: mosquitto.org — auf jedem Linux installierbar

⚙️ Steckbrief

Läuft über TCP (Port 1883, mit TLS Port 8883)
Leichtgewichtig: Mini-Header (~2 Byte), läuft auf Mikrocontrollern
Daten-agnostisch: Payload ist Bytes — JSON, Text, Binär, was ihr wollt
Implementierungen für C, Python, Java, Go, JS, …

                Warum so erfolgreich? Klein genug für Sensoren mit Batterie + Mikrocontroller, robust genug für Industrie-Telemetrie. Heute Standard im IoT.
            

Mini-Beispiel — Smart Home Temperatur

Konkretes Szenario: ein Sensor im Wohnzimmer, eine App auf dem Handy, ein Broker dazwischen.

🌡️

Sensor

Wohnzimmer

→

publish
home/wz/temp

🏢

Broker

mosquitto

→

subscribed
home/wz/temp

📱

App

Handy

1️⃣ Sensor publiziert

# alle 60 Sekunden:
publish("home/wz/temp", "22.3")

Sensor weiß nicht, ob die App da ist. Schickt einfach zum Broker.

2️⃣ App abonniert

# beim Start:
subscribe("home/wz/temp")
# danach: jede neue Temperatur kommt rein

App muss nicht pollen — Broker schiebt die Werte aktiv durch.

Topic-Designs aus echten Systemen

Sechs Branchen, sechs Topic-Hierarchien — alle nach dem gleichen Muster grob → fein.

🏠 Smart Home

home/livingroom/temperature
home/kitchen/smoke
home/garage/door/state
home/all/lights/control

🏭 Fabrik

factory/line-A/machine-3/temp
factory/line-A/machine-3/rpm
factory/quality/line-B/defects
factory/energy/total/kwh

🏥 Krankenhaus

hospital/ward-3/bed-12/hr
hospital/ward-3/bed-12/spo2
hospital/icu/alerts/critical
hospital/pharmacy/inventory

🚦 Verkehr

traffic/berlin/junction-5/light
traffic/berlin/A100/flow
traffic/berlin/A100/incident
traffic/berlin/parking/p3/free

🚛 LKW-Flotte

fleet/truck-42/location
fleet/truck-42/fuel
fleet/truck-42/door/cargo
fleet/dispatcher/orders/new

🌱 Smart Garden

garden/zone-A/moisture
garden/zone-A/light
garden/weather/forecast
garden/pump/zone-A/control

                Gemeinsames Muster: domain / standort / gerät / messwert. Sucht euch eine Konvention und haltet sie konsequent durch — sonst wird die Wildcard-Suche später ein Albtraum.
            

Topic-Strings — wie Datei-Pfade

Topics sind hierarchische Strings, getrennt mit / — fast wie ein Datei-Pfad. So bringt ihr Ordnung in tausende Nachrichten.

Beispiel für ein Smart Home

home/livingroom/temperature      ← konkret: Wohnzimmer
home/livingroom/humidity         ← anderes Sensor-Topic
home/kitchen/temperature         ← anderer Raum
home/garage/door/state           ← tiefer geschachtelt
factory/line-A/machine-3/status   ← industrielles Beispiel

                Konvention: Hierarchie geht vom Groben zum Feinen — standort / bereich / gerät / messwert. Klein-buchstaben, keine Leerzeichen.
            

                Wichtig: Topics werden bei der ersten Nachricht implizit erzeugt — kein „Setup" beim Broker nötig. Einfach publizieren, fertig.
            

🤔

Denkt mal kurz mit…

Ihr betreut ein Smart Building: 50 Räume, jeder mit 5 Sensoren.

Das sind 250 Topics insgesamt. Eine Monitoring-App will alle Temperaturen sehen.

💭 Würdet ihr im Code wirklich 50 mal subscribe(...) aufrufen?

Wildcards — nicht nur ein Topic abonnieren

Was, wenn ihr alle Temperaturen aus allen Räumen wollt? Dafür gibt's zwei Joker-Zeichen.

➕ Single-Level: `+`

Ersetzt genau eine Ebene des Topic-Pfads.

home/+/temperature

Matcht:

home/livingroom/temperature ✓
home/kitchen/temperature ✓
home/garage/door/state ✗ (eine Ebene zu tief)

#️⃣ Multi-Level: `#`

Ersetzt alles ab dieser Position. Darf nur am Ende stehen.

home/#

Matcht:

home/livingroom/temperature ✓
home/garage/door/state ✓
factory/line-A/machine-3 ✗ (anderer Stamm)

                Anwendung: Eine Monitoring-App abonniert factory/# — und kriegt alles, was in der Fabrik passiert. Eine Raum-App nimmt home/livingroom/+.
            

Wildcard-Praxis — matcht's oder matcht's nicht?

Vier Subscribe-Patterns links, sieben publizierte Topics rechts. Welche Nachrichten kriegt wer?

🎯 Vier Abonnent:innen

A: home/livingroom/temperature
B: home/+/temperature
C: home/kitchen/#
D: home/#

📡 Sieben publizierte Nachrichten

Topic	A	B	C	D
`home/livingroom/temperature`	✅	✅	—	✅
`home/kitchen/temperature`	—	✅	✅	✅
`home/kitchen/smoke`	—	—	✅	✅
`home/kitchen/fridge/temp`	—	—	✅	✅
`home/garage/door`	—	—	—	✅
`factory/line-A/temp`	—	—	—	—
`home`	—	—	—	—

                ⚠️ Subtilitäten: + matcht genau eine Ebene — home/kitchen/fridge/temp hat zu viele für home/+/temperature. Und home/# matcht nicht nur „home" allein — es braucht mindestens eine Ebene danach.
            

Hands-on — `mosquitto` im Terminal

Auf jedem Linux/Mac mit zwei Befehlen testbar. Probiert das daheim aus!

📥 Terminal 1 — Subscriber

# Installation (einmalig):
$ brew install mosquitto    # Mac
$ apt install mosquitto-clients  # Linux

# Auf Topic hören:
$ mosquitto_sub -h "test.mosquitto.org" \
                -t "htw/test/#"

Bleibt offen, wartet auf Nachrichten.

📤 Terminal 2 — Publisher

# Eine Nachricht senden:
$ mosquitto_pub -h "test.mosquitto.org" \
                -t "htw/test/temp" \
                -m "22.3"

# im ersten Terminal seht ihr:
22.3

Nachricht erscheint sofort im Subscriber.

                Public Broker zum Testen: test.mosquitto.org (Port 1883, ohne Passwort). Praktisch für die Lab-Übung — keine eigene Installation nötig.
            

Python — der „Hello, MQTT!"-Code

In Python heißt die Standard-Library paho-mqtt — pip install paho-mqtt. Hier ein minimaler Subscriber:

📥 Subscriber

import paho.mqtt.client as mqtt

def on_message(client, userdata, msg):
    print(f"{msg.topic}: {msg.payload.decode()}")

client = mqtt.Client()
client.on_message = on_message
client.connect("test.mosquitto.org", 1883)
client.subscribe("htw/test/#")
client.loop_forever()

📤 Publisher

import paho.mqtt.client as mqtt
import time, random

client = mqtt.Client()
client.connect("test.mosquitto.org", 1883)

while True:
    temp = 20 + random.random() * 5
    client.publish("htw/test/temp", str(temp))
    time.sleep(5)

                Das war's. Mehr braucht ihr für einen funktionierenden IoT-Prototypen nicht. Vergleicht mal mit dem HTTP-Code aus letzter VL — da musstet ihr Flask hochziehen + Routen registrieren.
            

Volles Smart Home — wie alles zusammenspielt

Drei Sensoren publizieren, drei Konsumenten abonnieren mit unterschiedlichen Wildcards — der Broker macht den Rest.

📤 Publisher (Sensoren)

🌡️ Temp-Sensor Wohnzimmer: home/livingroom/temp
🚪 Garagentor: home/garage/door
🔥 Rauchmelder Küche: home/kitchen/smoke

📥 Subscriber (Apps)

📱 Handy-App: home/# → bekommt alles
📊 Dashboard: home/+/temp → nur Temperaturen
🚨 Sirene: home/+/smoke + home/garage/door → nur Alarm-relevantes

🔀 Wer kriegt was beim Broker?

Sensor publiziert auf	📱 Handy	📊 Dashboard	🚨 Sirene
`home/livingroom/temp`	✅	✅	—
`home/garage/door`	✅	—	✅
`home/kitchen/smoke`	✅	—	✅

                Pointe: Sensoren ändern sich nicht, wenn eine neue App dazukommt. Eine neue Smart-Lampe abonniert einfach home/livingroom/temp — und schaltet ab 25°C auf rot. Niemand muss umkonfiguriert werden.
            

🤔

Denkt mal kurz mit…

Drei verschiedene MQTT-Nachrichten gehen unterwegs verloren. Bei welcher davon ist das schlimm — und warum?

🌡️ Temperatur

Sensor publiziert alle 60s.
Eine Messung geht verloren.

Schlimm?

🚨 Einbruchsalarm

Bewegungsmelder schlägt an.
Die Sirene kriegt's nicht mit.

Schlimm?

💳 Bezahlung

Bestätigung wird dupliziert.
Kunde zahlt 2× das Gleiche.

Schlimm?

💭 Soll MQTT für alle drei dieselbe Garantie bieten? Oder braucht ihr verschiedene „Sicherheitsstufen" pro Nachricht?

Quality of Service — wie sicher soll's ankommen?

MQTT bietet drei Zustellungs-Garantien. Denkt sie wie verschiedene Versand-Arten:

📨 QoS 0 — fire & forget

„At most once"

Wie eine Postkarte: rausgeschickt, fertig. Kann verloren gehen, kein Re-Try.

Nutzt für: Temperatur-Sensor — nächste Messung kommt eh in 60s.

📩 QoS 1 — at least once

Mindestens 1×

Wie ein Einschreiben: Empfänger bestätigt. Kommt sicher an — aber evtl. mehrfach.

Nutzt für: Alarm-Nachricht — soll garantiert ankommen, Duplikat egal.

📦 QoS 2 — exactly once

Genau 1×

Wie Einschreiben mit Rückschein + Zähler. 4-Wege-Handshake, kein Duplikat.

Nutzt für: Banking, Bestellungen — wo Duplikate schaden würden.

                Faustregel: QoS 0 als Default — sparsam mit Bandbreite. Höher gehen nur, wenn ihr eine konkrete Begründung habt. QoS 2 ist teuer (4 Pakete pro Nachricht statt 1).
            

QoS im Code — drei Zeilen, drei Garantien

In Python ist QoS ein einzelner Parameter — sowohl beim Publish als auch beim Subscribe.

📤 Publisher mit QoS

# QoS 0 — Temperaturmessung
client.publish("home/wz/temp",
              "22.3", qos=0)

# QoS 1 — Bewegungsalarm
client.publish("home/door/alarm",
              "intrusion", qos=1)

# QoS 2 — Bezahlvorgang
client.publish("shop/payment",
              payload_json, qos=2)

📥 Subscriber mit QoS

# Subscriber wählt maximalen QoS
client.subscribe("home/+/temp", qos=0)
client.subscribe("home/+/alarm", qos=1)
client.subscribe("shop/payment", qos=2)

# Effektiver QoS = min(pub, sub)
# Publisher=2, Subscriber=1 → tatsächl. 1

                Wichtig: Der effektive QoS ist immer das Minimum aus Publisher- und Subscriber-Wahl. Wenn der Publisher mit QoS 2 sendet, der Subscriber aber nur QoS 0 anfordert, kommt's als QoS 0 raus.
            

                Default in paho-mqtt: qos=0, wenn ihr nichts angebt. Bewusst, weil's der häufigste Fall ist.
            

Vier nützliche MQTT-Extras

Funktionen, die euch das Leben leichter machen — kurz im Überblick:

💓 Keep-Alive

Client sendet alle X Sekunden ein Mini-Ping. Wenn er ausfällt, merkt's der Broker und markiert ihn offline.

💾 Retained Messages

Broker speichert die letzte Nachricht pro Topic. Neue Subscriber kriegen sofort den letzten Stand — perfekt für „aktuelle Temperatur".

💀 Last Will

Wenn ein Client ungeplant abstürzt, schickt der Broker eine vorher hinterlegte „Abschieds-Nachricht" — andere können reagieren.

🔍 $SYS-Topics

Broker veröffentlicht eigene Statistiken (Clients, Bytes, Uptime) unter $SYS/.... Praktisch zum Monitoring.

                Take-away: Ihr braucht das nicht alles auf einmal. Aber gut zu wissen, dass MQTT diese Mechanismen schon eingebaut hat — nicht selbst über HTTP nachbasteln müssen.
            

Retained Messages in Aktion — die Zeitleiste

Was passiert, wenn ein neuer Subscriber spät einsteigt? Genau dafür gibt's Retained Messages.

Szenario: Temperatursensor + Dashboard

Zeit	Was passiert	Broker speichert	Dashboard sieht
t=0s	Sensor: `publish("home/temp", "22.1", retain=True)`	22.1	noch nicht da
t=60s	Sensor: `publish("home/temp", "22.3", retain=True)`	22.3 (ersetzt)	noch nicht da
t=120s	Sensor: `publish("home/temp", "22.5", retain=True)`	22.5 (ersetzt)	noch nicht da
t=150s	📱 Dashboard startet + abonniert `home/temp`	22.5	22.5 — sofort!
t=180s	Sensor: `publish("home/temp", "22.6", retain=True)`	22.6	22.6

⚠️ Ohne Retain

Dashboard startet → Broker hat nichts gespeichert → leeres Display, bis der Sensor das nächste Mal sendet (in bis zu 60s!).

✅ Mit Retain

Dashboard startet → Broker liefert sofort den letzten Wert → Display sofort gefüllt. Perfekt für aktuelle-Stand-Anzeigen.

                Faustregel: Status-Werte (Temperatur, Türzustand, Online-Status) → retain=True. Events (Knopfdruck, Alarm) → retain=False.
            

MQTT vs. HTTP — wann nehme ich was?

	HTTP / REST	MQTT
Kommunikationsmodell	Request / Response (Pull)	Publish / Subscribe (Push)
Overhead pro Nachricht	~ 200-500 Byte (Header)	~ 2-5 Byte (Mini-Header)
Wer ist „dumm"?	Client kennt Server-URL	Niemand kennt jemanden direkt
Stateful?	Zustandslos — jede Anfrage neu	Persistente Sessions möglich
Latenz für Updates	Hoch (Polling)	Sehr niedrig (Push)
Stärke	Web-APIs, anfragen + transformieren	IoT, Telemetrie, viele kleine Geräte
Tools / Debugging	curl, Browser, Postman	mosquitto-CLI, MQTT-Explorer

                Kombi-Hinweis: In der Praxis nutzen viele Systeme beide — HTTP für Konfiguration + REST-API, MQTT für Echtzeit-Telemetrie. Schließen sich nicht aus.
            

Wo MQTT heute wirklich läuft

🏠 Smart Home

Home Assistant, Zigbee2MQTT, Tasmota — die meisten Bastler-Stacks im DIY-IoT.

🏭 Industrie 4.0

Sensoren in Maschinen, SPS-Kopplung, OPC-UA-Bridges — MQTT ist hier de-facto Standard.

🚗 Connected Cars

BMW, Daimler & Co nutzen MQTT für Telemetrie zwischen Fahrzeug und Backend (Position, Status).

🛰️ Satelliten-Telemetrie

Der ursprüngliche Einsatzfall — bis heute aktiv. Wenig Bandbreite, viele Sensoren.

📱 Mobile Push

Facebook Messenger nutzt MQTT seit Jahren für Chat-Push auf Handys (akkuschonend).

🌡️ Wetterstationen

DIY und kommerziell — Sensor-Netze melden Messwerte an zentrale Dashboards.

                Gemeinsam: Viele Sender, wenige Empfänger, kleine Nachrichten, oft schwache Geräte. Genau das Profil, für das MQTT designt wurde.
            

Deep-Dive — Fabrik-Linie mit MQTT

Eine konkrete Fertigungslinie. So sieht's in echt aus — und ihr seht direkt, warum Wildcards goldwert sind.

🏭 Topic-Hierarchie

# Pattern: factory/{line}/{machine}/{sensor}
factory/line-A/machine-1/temp
factory/line-A/machine-1/rpm
factory/line-A/machine-1/state
factory/line-A/machine-2/temp
factory/line-A/machine-2/rpm
factory/line-B/machine-1/temp
factory/line-B/machine-1/rpm
factory/line-B/machine-2/temp

2 Linien × 2 Maschinen × 3 Sensoren = 12 Topics

👥 Wer abonniert wie?

🧑‍💼 Schichtleitung Linie A:
factory/line-A/# — alles aus Linie A
🌡️ Temperatur-Monitor:
factory/+/+/temp — nur Temperaturen
🔧 Wartung Maschine 1:
factory/+/machine-1/# — beide Linien, nur Maschine 1
📊 Werks-Dashboard:
factory/# — alles für die Übersicht

                Skalierung: Wenn morgen Linie C dazukommt mit 5 neuen Maschinen — kein Code muss geändert werden. Die Dashboards mit factory/# oder factory/+/+/temp picken automatisch alles Neue mit auf.
            

                Genau deshalb ist MQTT in der Industrie so beliebt — System wächst, Topic-Struktur skaliert mit, ohne Re-Architecting.
            

🧠 Quiz 1 — QoS wählen

Ihr habt einen Sensor, der Bewegungsalarme im Hauseingang sendet. Welcher QoS-Level passt?

AQoS 0 — die Nachricht kann auch verloren gehen, ist nicht so wichtig.

BQoS 1 — Alarm muss ankommen, Duplikat ist akzeptabel.

CQoS 2 — egal welche Kosten, Hauptsache exakt einmal.

✅ Lösung — QoS wählen

BQoS 1 — Alarm muss ankommen, Duplikat ist akzeptabel.

                Begründung: Bei Alarmen ist „at least once" der Sweet Spot — Verlust wäre ein Sicherheitsproblem, ein Duplikat löst halt zweimal denselben Alarm aus (kein Drama). QoS 2 wäre Overkill und teurer (4 Pakete statt 2).
            

🧠 Quiz 2 — Topic-Design

Eine Monitoring-App will alle Temperatur-Werte aus allen Räumen im Haus empfangen. Welches Subscribe-Topic ist korrekt?

Ahome/livingroom/temperature

Bhome/+/temperature

Chome/#

D+/+/temperature

✅ Lösung — Topic-Design

Bhome/+/temperature

                Warum nicht C? home/# matcht alles — auch Türsensoren, Licht, etc. Zu breit. Warum nicht D? Es matcht auch factory/line/temperature — verlässt das Haus. B ist präzise: nur Temperatur, nur im Haus, in beliebigen Räumen.
            

🧠 Quiz 3 — Architektur-Frage

Eine IoT-Wetterstation publiziert alle 60s ihre Temperatur. Eine Dashboard-App soll (1) sofort beim Start den aktuellen Wert sehen und (2) sofort wissen, wenn die Station ausfällt. Welche zwei MQTT-Features braucht ihr?

AKeep-Alive + $SYS-Topics — Broker meldet den Offline-Status.

BRetained Message + Last Will — letzte Temperatur sofort verfügbar, beim Crash automatische „offline"-Nachricht.

CQoS 2 + Wildcards — exakt einmal Zustellung schützt vor Ausfall.

DPersistent Session + Subscribe — Session bleibt offen, alles wird zwischengespeichert.

✅ Lösung — Architektur-Frage

BRetained Message + Last Will — letzte Temperatur sofort verfügbar, beim Crash automatische „offline"-Nachricht.

                Warum B? Retained Message löst Punkt 1 — neuer Subscriber kriegt sofort den letzten gespeicherten Wert. Last Will löst Punkt 2 — beim Verbindungs­abbruch der Station schickt der Broker automatisch die hinterlegte „offline"-Nachricht an alle Subscriber. Genau dafür wurden beide Mechanismen gebaut.
            

Take-aways aus heute

Publish/Subscribe entkoppelt Sender + Empfänger — ein Broker sitzt dazwischen und vermittelt.
MQTT = leichtgewichtiges Pub/Sub-Protokoll über TCP, ideal für IoT mit vielen kleinen Geräten.
Topics sind hierarchische Strings (home/wz/temp). Wildcards: + (eine Ebene), # (alles drunter, nur am Ende).
3 QoS-Stufen: 0 = Postkarte, 1 = Einschreiben, 2 = Einschreiben+Bestätigung. Default = 0.
Tools: mosquitto_pub/mosquitto_sub im Terminal, paho-mqtt in Python.
MQTT vs. HTTP: Push vs. Pull — beide haben ihren Platz, ihr könnt sie kombinieren.

Fragen?

Im Übung: Pub/Sub-System mit mosquitto + Python — Sensor zu App.

Prof. Dr. Alexandra Mikityuk
HTW Berlin · Büro Raum 308
Probiert test.mosquitto.org aus — kostet nichts und läuft sofort!

Vorlesung 7

MQTT & Publish/SubscribeWie tausend Sensoren zur selben App sprechen — ohne Chaos

Lernziele für heute

Denkt mal kurz mit…

Rückblick — HTTP war Anrufen. Heute: Radio hören.

📞 HTTP-Modell

📻 Pub/Sub-Modell (Push)

Die Idee — kennt ihr aus dem Alltag

📰 Zeitungs-Abo

📻 Radio-Sender

📺 YouTube-Channel

Die drei Rollen in einem Pub/Sub-System

📤 Publisher

🏢 Broker

📥 Subscriber

Was ist MQTT?

📜 Historie

⚙️ Steckbrief

Mini-Beispiel — Smart Home Temperatur

1️⃣ Sensor publiziert

2️⃣ App abonniert

Topic-Designs aus echten Systemen

🏠 Smart Home

🏭 Fabrik

🏥 Krankenhaus

🚦 Verkehr

🚛 LKW-Flotte

🌱 Smart Garden

Topic-Strings — wie Datei-Pfade

Beispiel für ein Smart Home

Denkt mal kurz mit…

Wildcards — nicht nur ein Topic abonnieren

➕ Single-Level: +

#️⃣ Multi-Level: #

Wildcard-Praxis — matcht's oder matcht's nicht?

🎯 Vier Abonnent:innen

📡 Sieben publizierte Nachrichten

Hands-on — mosquitto im Terminal

📥 Terminal 1 — Subscriber

📤 Terminal 2 — Publisher

Python — der „Hello, MQTT!"-Code

📥 Subscriber

📤 Publisher

Volles Smart Home — wie alles zusammenspielt

📤 Publisher (Sensoren)

📥 Subscriber (Apps)

🔀 Wer kriegt was beim Broker?

Denkt mal kurz mit…

🌡️ Temperatur

🚨 Einbruchsalarm

💳 Bezahlung

Quality of Service — wie sicher soll's ankommen?

📨 QoS 0 — fire & forget

📩 QoS 1 — at least once

📦 QoS 2 — exactly once

QoS im Code — drei Zeilen, drei Garantien

📤 Publisher mit QoS

📥 Subscriber mit QoS

Vier nützliche MQTT-Extras

💓 Keep-Alive

💾 Retained Messages

💀 Last Will

🔍 $SYS-Topics

Retained Messages in Aktion — die Zeitleiste

Szenario: Temperatursensor + Dashboard

⚠️ Ohne Retain

✅ Mit Retain

MQTT vs. HTTP — wann nehme ich was?

Wo MQTT heute wirklich läuft

🏠 Smart Home

🏭 Industrie 4.0

🚗 Connected Cars

🛰️ Satelliten-Telemetrie

📱 Mobile Push

🌡️ Wetterstationen

Deep-Dive — Fabrik-Linie mit MQTT

🏭 Topic-Hierarchie

👥 Wer abonniert wie?

🧠 Quiz 1 — QoS wählen

✅ Lösung — QoS wählen

MQTT & Publish/Subscribe
Wie tausend Sensoren zur selben App sprechen — ohne Chaos

➕ Single-Level: `+`

#️⃣ Multi-Level: `#`

Hands-on — `mosquitto` im Terminal