Übungsaufgaben zu MQTT
https://bildung.social/@oerinformatik/
https://oer-informatik.de/mqtt-uebungsaufgaben
MQTT, Publish/Subscribe, Broker, Topic, Wildcard, QoS, Retain, Last Will, Mosquitto, OPC UA, Übungsaufgaben, Prüfungsvorbereitung
tl/dr; (Bearbeitungszeit insgesamt 98 min, mehrere Aufgaben): Vier Übungsaufgaben zu MQTT: Du erläuterst den Ablauf zwischen E-Ink-Türschildern, Broker und Dashboard bei einem Barcamp, wählst Topic-Filter und berechnest, ob das IoT-WLAN für neue Raumsensoren reicht. Danach entwirfst Du eine Topic-Struktur für die Akku-Ladeschränke eines Fahrradhändlers und prüfst Filter mit Wildcards. In einer Pulverbeschichtung vergleichst Du MQTT mit OPC UA anhand eines englischen Textes, wählst QoS-Stufen für Motoren und bestimmst, welche Werte dank Retain zu welchem Zeitpunkt vorliegen. Zum Schluss meldest Du Raumsensoren passend zur Broker-Konfiguration an und sicherst die Verbindung ab. Alle Beispiellösungen sind ausgeblendet und mit Punkteverteilung versehen [AI-Assisted]. (Zuletzt geändert am 28.10.2026)
Diese Übungsaufgaben gehören zum Artikel MQTT: Publish/Subscribe, Topics, Wildcards und QoS.
Hinweise zur Bearbeitung: Als FISY, FIDV oder ISE musst Du zur Teil-2-Prüfung Aufgaben auf Kernkompetenz-Ebene lösen können, das ist Aufgabe 2.1. Von FIDV wird zusätzlich erwartet, dass ihnen Aufgaben auf Profilkompetenz-Ebene (Aufgabe 3.1, Aufgabe 3.2 und Aufgabe 3.3) keine Probleme bereiten. Achte auf den Operator: „Nennen“ und „angeben“ verlangen Stichworte oder Werte, „beschreiben“ und „erläutern“ ganze Sätze mit Bezug zur Situation, „berechnen“ einen nachvollziehbaren Rechenweg. Schreib Deine Antwort zuerst vollständig auf, bevor Du die Beispiellösung aufklappst; andere sachlich richtige Antworten sind ebenfalls richtig.
Aufgabe 2.1: Türschilder und Raumsensoren beim Barcamp (Kernkompetenz)
(ca. 21 min Bearbeitungszeit)
Am Ratz und Rübe Berufskolleg (RRB) in Bielefeld findet am 13.03.2027 das Barcamp „Lernen.Digital.Leben 2027“ statt. Du unterstützt als Auszubildende*r das Technikteam von Emre Aksoy. Zwölf E-Ink-Türschilder im VLAN 120 zeigen das Programm des jeweiligen Raums an. Den Text berechnet der Info-Server und verteilt ihn über den MQTT-Broker, eine virtuelle Maschine im Servernetz (VLAN 140). Die Türschilder melden ihren Akkustand an ein Orga-Dashboard. Der folgende Ausschnitt zeigt den Ablauf für das Türschild in Raum A.104; das Verbinden von Info-Server und Dashboard ist nicht dargestellt.
a) Erkläre, was MQTT ist, und nenne zwei typische Einsatzgebiete. (3 Punkte)
MQTT (ursprünglich Message Queuing Telemetry Transport bzw. MQ Telemetry Transport; heute gilt der Name nicht mehr als Abkürzung) ist ein leichtgewichtiges, nachrichtenorientiertes Protokoll der Anwendungsschicht, mit dem viele Geräte kurze Nachrichten über einen zentralen Broker austauschen (Publish/Subscribe). (1 Punkt)
Einsatzgebiete (je 1 Punkt, zwei genügen): Internet der Dinge, Industrie 4.0 bzw. Maschinendaten, Gebäudetechnik und Smart Home, Energiemanagement, Sensornetze, Flottenüberwachung.
b) Erläutere den Ablauf des Publish/Subscribe-Verfahrens anhand des Sequenzdiagramms. (6 Punkte)
Das Türschild baut eine Verbindung zum Broker auf und meldet sich mit
CONNECTan; der Broker bestätigt mitCONNACK. (1 Punkt)Das Türschild abonniert mit
SUBSCRIBEdas Topicbarcamp/raum/A.104/anzeige, das Dashboard abonniertbarcamp/raum/+/akku. Der Broker speichert die Abonnements und bestätigt sie mitSUBACK. (2 Punkte)Der Info-Server veröffentlicht (
PUBLISH) einen neuen Anzeigetext an den Broker. Der Broker vergleicht das Topic mit den Abonnements und leitet die Nachricht an das Türschild weiter, das genau dieses Topic abonniert hat. (2 Punkte)Das Türschild ist selbst auch Publisher: Es veröffentlicht seinen Akkustand; der Broker leitet ihn an das Dashboard weiter, dessen Filter mit
+auf alle Räume passt. Info-Server, Türschild und Dashboard haben keine direkte Verbindung zueinander, sie kennen nur den Broker. (1 Punkt)
c) Erläutere, warum MQTT auf TCP und nicht auf UDP aufsetzt. (3 Punkte)
Die Nachrichten gehen an einen bestimmten Broker. Dafür wird eine Verbindung aufgebaut, die dauerhaft bestehen bleibt (1 Punkt). TCP stellt sicher, dass die Daten vollständig, fehlerfrei und in der richtigen Reihenfolge ankommen, und wiederholt verlorene Segmente (1 Punkt). Verbindung, Sitzung und die Zustellgarantien (QoS) von MQTT bauen darauf auf; mit UDP könnten Nachrichten unbemerkt verloren gehen oder vertauscht ankommen (1 Punkt).
d) Für eine Übersicht im Foyer sollen die Anzeigetexte aller Türschilder auf einem Infomonitor erscheinen. Gib das Topic an, das der Infomonitor dafür abonnieren muss. (2 Punkte)
barcamp/raum/+/anzeige (2 Punkte; das + ersetzt genau die Ebene mit der Raumnummer).
e) Mia Schröder schlägt stattdessen barcamp/raum/# vor. Beschreibe, was der Infomonitor damit abonniert, und begründe, warum das hier ungeeignet ist. (2 Punkte)
# steht für beliebig viele Ebenen ab dieser Stelle. Der Infomonitor erhielte damit alle Nachrichten aller Räume, also auch die Akkustände und alle künftigen Werte (1 Punkt). Er bekäme unnötige Nachrichten, müsste sie selbst aussortieren, und neue Topics würden ungewollt mitangezeigt (1 Punkt).
f) Svenja Krämer von der Schul-IT OWL möchte auf dem Dashboard außerdem sehen, wie viele Clients gerade mit dem Broker verbunden sind. Der Broker veröffentlicht dazu Statistiken unter $SYS/…. Erläutere, warum ein Abonnement von # diese Werte nicht liefert, und gib einen passenden Filter an. (2 Punkte)
Topics, die mit $ beginnen, sind für den Broker reserviert; Wildcards in der ersten Ebene (#, +) erfassen sie nicht (1 Punkt). Passend ist z. B. $SYS/# oder gezielt $SYS/broker/clients/connected (1 Punkt).
g) Die Schul-IT möchte nach dem Barcamp in 120 Unterrichtsräumen Raumsensoren (CO₂, Temperatur, Luftfeuchte) installieren. Jeder Sensor sendet alle 5 Sekunden eine MQTT-Nachricht von 90 Byte. Die Datenrate der IoT-SSID ist auf 16 kbit/s begrenzt. Bestimme durch Rechnung, ob die Datenrate ausreicht. Der Protokoll-Overhead bleibt unberücksichtigt. (3 Punkte)
Geg.: n = 120, s = 90\ \text{Byte}, t = 5\ \text{s}, B_{\text{max}} = 16\ \tfrac{\text{kbit}}{\text{s}}
Ges.: benötigte Datenrate B
\begin{aligned} B &= \frac{n \cdot s}{t} = \frac{120 \cdot 90 \cdot 8\ \text{bit}}{5\ \text{s}} = \frac{86\,400\ \text{bit}}{5\ \text{s}} = \underline{\underline{17{,}280\ \tfrac{\text{kbit}}{\text{s}}}} \end{aligned}
Rechnung 2 Punkte. Da 17{,}28\ \tfrac{\text{kbit}}{\text{s}} > 16\ \tfrac{\text{kbit}}{\text{s}}, reicht die Datenrate nicht aus (1 Punkt).
h) Berechne, wie groß das Sendeintervall mindestens sein muss, damit die 16 kbit/s ausreichen. (2 Punkte)
Ges.: Mindestintervall t
\begin{aligned} B &= \frac{n \cdot s}{t} &&\quad | \cdot t \quad | : B \\ t &= \frac{n \cdot s}{B} = \frac{120 \cdot 90 \cdot 8\ \text{bit}}{16\,000\ \tfrac{\text{bit}}{\text{s}}} = \frac{86\,400\ \text{bit}}{16\,000\ \tfrac{\text{bit}}{\text{s}}} = \underline{\underline{5{,}400\ \text{s}}} \end{aligned}
Das Sendeintervall muss mindestens 5,4 s betragen (höchstens eine Nachricht je Sensor in 5,4 s); praktisch wird z. B. ein Intervall von 6 s oder mehr eingestellt (Reserve für Overhead). (Rechnung 1 Punkt, Ergebnis mit Folgerung 1 Punkt)
Aufgabe 3.1: Eine Topic-Struktur für die Akku-Ladeschränke (Profilkompetenz)
(ca. 26 min Bearbeitungszeit)
Die CSB-Rad GmbH lagert in ihrem Akkulager in Bielefeld-Sennestadt die Akkus von E-Bikes und Lastenrädern. Funksensoren melden die Temperatur bereits über ein Gateway per MQTT. Neu kommen vier Ladeschränke mit je sechs abschließbaren Fächern hinzu; zwei weitere Schränke stehen ab 2027 im Showroom in der Bielefelder Innenstadt. Geschäftsführer Cem Sarıkaya bittet Dich, die Topic-Struktur zu planen. Geräte und Fächer sollen zweistellig nummeriert werden (Schema name/99).
a) Beschreibe den Aufbau einer Topic-Struktur in MQTT. (3 Punkte)
Topics sind hierarchisch aufgebaut (1 Punkt) und bestehen aus einer oder mehreren Ebenen, die durch einen Schrägstrich / getrennt werden (1 Punkt). Sie werden vom Allgemeinen zum Speziellen geordnet, Groß- und Kleinschreibung wird unterschieden, und ein Topic entsteht mit der ersten Nachricht, ohne vorher angelegt zu werden (1 Punkt für eine dieser Angaben).
b) Nenne zwei sinnvolle Kriterien zur Sortierung der Topic-Struktur. (2 Punkte)
Je 1 Punkt, z. B. Standort (Sennestadt, Showroom), Bereich bzw. Raum (Akkulager, Verkauf), Gerätetyp (Sensor, Ladeschrank), Gerätenummer bzw. Fachnummer, Messgröße bzw. Befehl.
c) Entwirf eine Topic-Struktur, mit der jedes Fach jedes Ladeschranks an beiden Standorten einzeln angesprochen werden kann und in die auch die Funksensoren passen. Gib damit die Topics für folgende Nachrichten an: (1) Ladezustand von Fach 3 in Ladeschrank 2 in Sennestadt, (2) Temperatur von Funksensor 5 im Akkulager, (3) Befehl zum Entriegeln von Fach 4 in Ladeschrank 1 im Showroom. (6 Punkte)
Beispiel für eine Struktur (2 Punkte): csbrad/<standort>/<bereich>/<geraetetyp>/<nr>/[fach/<nr>/]<wert>
| Nachricht | Topic | Punkte |
|---|---|---|
| (1) | csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/ladezustand |
1 |
| (2) | csbrad/sennestadt/akkulager/sensor/05/temperatur |
1 |
| (3) | csbrad/showroom/verkauf/ladeschrank/01/fach/04/befehl (Payload z. B. entriegeln) |
2 |
Die Namen der Ebenen sind frei wählbar; die Hierarchie muss vom Allgemeinen zum Speziellen gehen, jedes Fach eindeutig erreichbar sein, und Befehle sollten von Messwerten getrennt sein (z. B. eigene Ebene befehl bzw. set).
Als Baum dargestellt (grün die drei gesuchten Topics, gestrichelt weitere Schränke, Fächer und Sensoren):
Cem entscheidet sich für die Struktur csbrad/<standort>/<bereich>/<geraetetyp>/<nr>/…. Die Ladeschränke liefern ihren Zustand je Fach mit dem Befehl lsctl status; die Feldnamen der Ausgabe sollen als letzte Ebene übernommen werden:
$ lsctl status --schrank 02 --fach 03
SCHRANK : 02
FACH : 03
CHG_STATE : laden
SOC : 64
TEMP : 27.5
DOOR : zud) Ergänze die Tabelle um die Topics für Ladestatus, Temperatur und Türzustand dieses Fachs. Die erste Zeile ist vorgegeben. (4 Punkte)
| Wert | Topic |
|---|---|
| Ladezustand in Prozent | csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/SOC |
| Ladestatus | |
| Temperatur | |
| Türzustand |
| Wert | Topic |
|---|---|
| Ladezustand in Prozent | csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/SOC |
| Ladestatus | csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/CHG_STATE |
| Temperatur | csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/TEMP |
| Türzustand | csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/DOOR |
Je richtiger Zeile 1 Punkt, 1 Punkt für die durchgängig übernommene Hierarchie und Schreibweise der Feldnamen (Groß- und Kleinschreibung zählt).
Am Broker kommen unter anderem diese Topics vor:
(1) csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/SOC
(2) csbrad/sennestadt/akkulager/ladeschrank/02/fach/03/TEMP
(3) csbrad/sennestadt/akkulager/ladeschrank/01/fach/06/SOC
(4) csbrad/showroom/verkauf/ladeschrank/01/fach/02/SOC
(5) csbrad/sennestadt/akkulager/sensor/05/temperatur
(6) csbrad/sennestadt/akkulager/ladeschrank/02/TEMPe) Gib an, welche dieser Topics durch SUBSCRIBE csbrad/sennestadt/+/ladeschrank/+/fach/+/SOC abonniert werden. (2 Punkte)
- und (3) (je 1 Punkt). (4) liegt am Standort
showroom, (2) und (6) enden nicht aufSOC, (5) hat eine andere Ebenenfolge.
f) Erläutere die Eigenschaften der Platzhalter + und # und die Einschränkung, die für # gilt. (4 Punkte)
+(Single-Level-Wildcard) steht für genau eine beliebige Ebene der Hierarchie, z. B.fach/+/SOCfür alle Fächer, aber nicht fürfach/03/x/SOC. Es darf mehrfach im Filter vorkommen. (2 Punkte)#(Multi-Level-Wildcard) steht für beliebig viele Ebenen ab dieser Stelle, also für alles darunter. (1 Punkt) Es darf nur einmal und nur als letztes Zeichen des Filters stehen. Beide Platzhalter sind nur beim Abonnieren erlaubt, nicht beim Veröffentlichen. (1 Punkt)
g) Gib den kürzest möglichen Filter an, mit dem ausschließlich alle Werte von Ladeschrank 2 im Akkulager in Sennestadt abonniert werden – auch dann noch, wenn später in anderen Bereichen weitere Ladeschränke hinzukommen. (2 Punkte)
csbrad/sennestadt/akkulager/ladeschrank/02/# (2 Punkte). …/02/+ reicht nicht, weil die Fachwerte zwei Ebenen tiefer liegen; csbrad/sennestadt/+/ladeschrank/02/# wäre zu weit, weil es auch Ladeschrank 02 eines anderen Bereichs erfassen würde.
h) Gib eine PUBLISH-Nachricht (Nachrichtentyp, Topic, Payload) an, mit der Funksensor 5 im Akkulager 31 °C meldet. Gib außerdem die SUBSCRIBE-Nachricht(en) an, mit denen eine Brandschutz-Software alle Temperaturen im Akkulager, aber nichts anderes erhält, und beurteile die Benennung der Temperatur-Topics. (5 Punkte)
| Nachrichtentyp | Topic | Payload |
|---|---|---|
PUBLISH |
csbrad/sennestadt/akkulager/sensor/05/temperatur |
31 (oder z. B. {"wert": 31, "einheit": "°C"}) |
(2 Punkte)
Die Temperaturen liegen in unterschiedlicher Tiefe und heißen einmal temperatur, einmal TEMP. Mit einem einzigen Filter ohne „zu viel“ geht es nicht, daher drei Abonnements (2 Punkte):
SUBSCRIBE csbrad/sennestadt/akkulager/sensor/+/temperatur
SUBSCRIBE csbrad/sennestadt/akkulager/ladeschrank/+/TEMP
SUBSCRIBE csbrad/sennestadt/akkulager/ladeschrank/+/fach/+/TEMPBeurteilung (1 Punkt): Die uneinheitliche Bezeichnung erschwert Filter und Auswertung; besser wäre ein einheitlicher Name für dieselbe Messgröße (z. B. überall temperatur, notfalls durch Umsetzen im Gateway).
Aufgabe 3.2: QoS und Retain in der Pulverbeschichtung (Profilkompetenz)
(ca. 29 min Bearbeitungszeit)
Die Rahmenwerk OWL GmbH in Gütersloh fertigt für die CSB-Rad GmbH Rahmen nach Maß und beschichtet sie mit Pulverlack. Die Steuerungen der Anlage sprechen bisher OPC UA. Projektleiter Ole Petersen möchte für einen neuen Leitstand und für Dashboards zusätzlich MQTT einsetzen. Du hilfst ihm bei der Vorbereitung.
Ole schickt Dir einen Auszug aus dem Whitepaper eines Herstellers:
„Both protocols have their place on the shop floor. MQTT keeps devices and networks lean: a client needs only a few kilobytes of memory and is quickly set up and maintained. However, it leaves the meaning of a message entirely to you – there is no built-in description of data types or units, and security depends on how you configure TLS and the broker. OPC UA brings a rich, standardised information model and signs and encrypts messages out of the box, but it needs considerably more processing power and know-how to configure and service.“
a) Kennzeichne für jedes Kriterium das laut Text vorteilhaftere Protokoll. (4 Punkte)
| Kriterium | MQTT | OPC UA |
|---|---|---|
| eingebaute Sicherheitsfunktionen | ||
| ressourcensparend | ||
| standardisiertes Datenmodell | ||
| geringer Aufwand für Einrichtung und Wartung |
| Kriterium | MQTT | OPC UA |
|---|---|---|
| eingebaute Sicherheitsfunktionen | x | |
| ressourcensparend | x | |
| standardisiertes Datenmodell | x | |
| geringer Aufwand für Einrichtung und Wartung | x |
Je richtiger Zeile 1 Punkt.
b) Erläutere zwei Vorteile des Publish/Subscribe-Prinzips gegenüber dem klassischen Client-Server-Modell für die Anbindung von Leitstand und Dashboards. (4 Punkte)
Je Vorteil 2 Punkte, z. B.:
Flexibilität und Erweiterbarkeit: Publisher und Subscriber haben keine direkte Verbindung und kennen sich nicht. Ein weiteres Dashboard abonniert einfach die Topics; an den Steuerungen muss nichts geändert werden.
Entlastung der Steuerungen: Eine Steuerung sendet jeden Wert nur einmal an den Broker, statt von jedem Leitstand und Dashboard einzeln abgefragt zu werden; der Broker verteilt an beliebig viele Empfänger.
Lose Kopplung: Fällt ein Dashboard aus oder ist es offline, arbeitet die Anlage ungestört weiter.
Echtzeitnähe: Änderungen werden sofort weitergeleitet, statt erst beim nächsten Abfragen bemerkt zu werden.
c) Erläutere die Aufgaben des Brokers in Bezug auf Nachrichtenübermittlung und Abonnementverwaltung. (4 Punkte)
Nachrichtenübermittlung: Der Broker empfängt die Nachrichten der Publisher (z. B. der Ofensteuerung), prüft ihr Topic und leitet sie an alle Clients weiter, die ein passendes Topic abonniert haben; bei QoS 1 und 2 puffert er sie, bis die Zustellung bestätigt ist. (2 Punkte)
Abonnementverwaltung: Der Broker registriert die verbundenen Clients und speichert ihre Abonnements mit den angegebenen Optionen (z. B. QoS-Stufe); bei dauerhaften Sitzungen bleiben sie auch über eine Verbindungsunterbrechung hinweg erhalten, mit
UNSUBSCRIBEwerden sie entfernt. (2 Punkte)
d) Nenne die wesentliche Eigenschaft jeder QoS-Stufe. (3 Punkte)
- QoS 0 – at most once: Die Nachricht wird einmal ohne Bestätigung gesendet und kann verloren gehen. (1 Punkt)
- QoS 1 – at least once: Die Nachricht wird wiederholt, bis sie bestätigt ist; sie kommt sicher, ggf. aber mehrfach an. (1 Punkt)
- QoS 2 – exactly once: Die Nachricht kommt sicher und genau einmal an (vierstufiger Handschlag). (1 Punkt)
e) Ordne den folgenden Nachrichten jeweils die niedrigste geeignete QoS-Stufe zu und begründe kurz: (1) Ofentemperatur, die jede Sekunde gesendet wird; (2) Meldung „Pulvervorrat Kabine 2 fast leer“ an die Logistik; (3) Befehl an den Kettenförderer „ein Gehänge weiterfahren“; (4) neuer Sollwert der Ofentemperatur 190 °C. (4 Punkte)
| Nachricht | QoS | Begründung |
|---|---|---|
| (1) Ofentemperatur | 0 | Ein verlorener Wert wird nach einer Sekunde ersetzt. |
| (2) Pulvervorrat fast leer | 1 | Die Meldung darf nicht verloren gehen; eine doppelte Meldung schadet nicht. |
| (3) ein Gehänge weiterfahren | 2 | Relativer Befehl: doppelt ausgeführt stünde der Förderer falsch. |
| (4) Sollwert 190 °C | 1 | Absoluter Wert: zweimal empfangen ändert nichts. |
Je richtiger Zeile mit Begründung 1 Punkt.
f) In der Kabine dreht ein Drehtisch die Rahmen zur Pistole. Zur Auswahl stehen ein Antrieb mit Servomotor, dem per MQTT die Zielposition (z. B. 90°) gesendet wird, und ein Antrieb mit Schrittmotor, dem die Anzahl der Schritte bzw. der Drehwinkel (z. B. +90°) gesendet wird. Es soll sichergestellt werden, dass der Motor genau das macht, was in der Nachricht steht, aber kein höheres QoS-Level als nötig verwendet werden. Gib für beide Antriebe das QoS-Level an und begründe. (4 Punkte)
Servomotor: QoS 1 (1 Punkt). Er erhält eine absolute Zielposition; kommt die Nachricht doppelt an, fährt er erneut auf 90° und steht trotzdem richtig. Sie darf aber nicht verloren gehen, daher nicht QoS 0. (1 Punkt)
Schrittmotor: QoS 2 (1 Punkt). Er erhält eine relative Drehung; würde die Nachricht doppelt ausgeführt, drehte er um 180° statt 90°. Nur QoS 2 stellt sicher, dass sie genau einmal ankommt. (1 Punkt)
Die Nachrichten der Anlage laufen über einen Broker. Das folgende Sequenzdiagramm zeigt die Veröffentlichungen der Steuerungen von Ofen 1, Ofen 2 und Kabine 2 sowie die Anmeldung des Leitstands. Nachrichten, die der Broker an den Leitstand zustellt, sind nicht eingezeichnet.
g) Gib an, welche Werte dem Leitstand zu den Zeitpunkten X, Y und Z vorliegen, und begründe kurz. (6 Punkte)
| Zeitpunkt | Werte | Begründung |
|---|---|---|
| X | keine | Der Leitstand ist verbunden, hat aber noch nichts abonniert. |
| Y | ofen1/temperatur = 185 |
Der Wert wurde mit Retain veröffentlicht; der Broker hat ihn gespeichert und sendet ihn beim Abonnieren von rw/gt/pulver/ofen1/# sofort zu. |
| Z | ofen1/temperatur = 185, ofen1/tuer = zu, kabine2/status = stoerung |
tuer und stoerung wurden nach dem jeweiligen Abonnement veröffentlicht und live weitergeleitet. bereit wurde ohne Retain vor dem Abonnement gesendet, ofen2/temperatur passt zu keinem Filter. |
Je Zeitpunkt 2 Punkte (Z: 1 Punkt für die drei Werte, 1 Punkt für das Fehlen von bereit und ofen2).
h) MQTT wird als zustandshaltendes Protokoll bezeichnet. Erläutere die Bedeutung von „zustandshaltend“ und begründe, ob der Leitstand sich mit Clean Session = true oder false anmelden sollte. (3 Punkte)
Die Verbindung zwischen Client und Broker bleibt dauerhaft bestehen und wird über Keep-alive überwacht; der Broker speichert je Client eine Sitzung mit Abonnements und noch nicht zugestellten bzw. bestätigten Nachrichten – anders als beim zustandslosen HTTP, bei dem jede Anfrage für sich steht. (2 Punkte)
Der Leitstand sollte Clean Session = false verwenden: Nach einer kurzen Unterbrechung bleiben seine Abonnements erhalten, und Meldungen mit QoS 1 oder 2, die in der Zwischenzeit eingegangen sind (z. B. Störungen), werden nachgeliefert. Dafür muss der Leitstand sich immer mit derselben Client-ID anmelden; in MQTT 5 heißt die Einstellung Clean Start = false mit einer Sitzungsdauer (Session Expiry Interval). (1 Punkt)
Aufgabe 3.3: Raumsensoren am Broker der Schul-IT anmelden (Profilkompetenz)
(ca. 22 min Bearbeitungszeit)
Nach dem Barcamp richtet die Schul-IT OWL am Ratz und Rübe Berufskolleg die ersten Raumsensoren „KlimaPunkt K2“ ein. Der MQTT-Broker läuft auf der virtuellen Maschine mqtt-bc mit der Adresse 10.140.0.6. Svenja Krämer zeigt Dir die Konfiguration:
Datei /etc/mosquitto/mosquitto.conf:
listener 8883 10.140.0.6
cafile /etc/mosquitto/certs/schul-it-owl-root-ca.crt
certfile /etc/mosquitto/certs/mqtt-bc.crt
keyfile /etc/mosquitto/certs/mqtt-bc.key
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/aclDatei /etc/mosquitto/acl (Auszug):
user infoserver
topic readwrite barcamp/#
pattern write rrb/klima/%u/#
pattern read rrb/klima/%u/befehlIn der Passwortdatei stehen die Passwörter nur als Hash. Die Zugangsdaten für den ersten Sensor stehen im Passwort-Tresor der Schul-IT: Benutzername klima-a104, Passwort Ku7!pQ2r-x. In der ACL ersetzt der Broker %u durch den Benutzernamen des Clients.
Die Weboberfläche des Sensors zeigt folgende Voreinstellungen:
| Feld | Voreinstellung |
|---|---|
| MQTT aktivieren | aus |
| Server | cloud.klimapunkt.example |
| Port | 1883 |
| TLS verwenden / CA-Zertifikat | aus / – |
| Benutzername | – |
| Passwort | – |
| Topic-Präfix | klimapunkt/<Seriennummer> |
| Keep alive (s) | 60 |
| Clean Session | an |
| Retain | aus |
| Max QoS | 0 |
a) Nenne die Felder, die für den Betrieb am Broker der Schul-IT geändert werden müssen, mit den zugehörigen Werten. (10 Punkte)
| Feld | neuer Wert | Punkte |
|---|---|---|
| MQTT aktivieren | an | 1 |
| Server | 10.140.0.6 (bzw. der DNS-Name von mqtt-bc, passend zum Zertifikat) |
1 |
| Port | 8883 |
1 |
| TLS verwenden / CA-Zertifikat | an / Stammzertifikat „Schul-IT OWL Root CA“ | 2 |
| Benutzername | klima-a104 |
1 |
| Passwort | Ku7!pQ2r-x |
1 |
| Topic-Präfix | rrb/klima/klima-a104 |
3 |
Das Präfix muss mit dem Benutzernamen beginnen, sonst verweigert der Broker wegen der ACL das Veröffentlichen. Keep alive und Clean Session können bleiben; zu Retain und Max QoS siehe b) und e).
b) Die Infomonitore sollen nach einem Neustart sofort die aktuellen Raumwerte anzeigen, auch wenn der nächste Messwert erst in einer Minute kommt. Gib an, welche Einstellung dafür geändert werden sollte, und begründe. (2 Punkte)
Retain einschalten (1 Punkt). Der Broker speichert dann je Topic den letzten Messwert und schickt ihn jedem Infomonitor sofort, sobald dieser nach dem Neustart abonniert (1 Punkt).
c) Erläutere, welche Topics der Sensor klima-a104 laut ACL veröffentlichen und abonnieren darf, und begründe, warum diese Einschränkung sinnvoll ist. (3 Punkte)
Er darf alles unterhalb von rrb/klima/klima-a104/ veröffentlichen (1 Punkt) und nur rrb/klima/klima-a104/befehl abonnieren (1 Punkt). Ein übernommener oder fehlerhafter Sensor kann so weder Werte anderer Räume fälschen noch Befehle für andere Geräte senden oder fremde Nachrichten mitlesen (Prinzip der minimalen Rechte) (1 Punkt).
d) In einer alten Dokumentation findest Du noch die Zeile listener 1883 ohne TLS. Nenne zwei Risiken dieser Einstellung und zwei Maßnahmen, die der neue Broker umsetzt. (4 Punkte)
Risiken (je 1 Punkt): Benutzernamen und Passwörter werden im Klartext übertragen und können mitgeschnitten werden; Nachrichten können mitgelesen oder verändert werden (z. B. gefälschte Anzeigetexte); ohne bind-Adresse lauscht der Broker auf allen Schnittstellen.
Maßnahmen (je 1 Punkt): TLS auf Port 8883 mit Zertifikat der Schul-IT-CA; keine anonymen Clients (allow_anonymous false) und eigene Zugangsdaten je Gerät; Zugriffsliste je Benutzerkonto; Bindung an die Adresse im Servernetz (VLAN 140).
e) Fällt ein Sensor aus, soll das Dashboard das sofort anzeigen. Gib eine geeignete Last-Will-Nachricht für den Sensor an und erläutere, wann der Broker sie veröffentlicht. (3 Punkte)
Last Will z. B. Topic rrb/klima/klima-a104/status, Payload offline, QoS 1 (dafür Max QoS auf 1 stellen), Retain an (1 Punkt; das Topic muss innerhalb der erlaubten Topics liegen).
Der Sensor hinterlegt die Nachricht beim CONNECT. Der Broker veröffentlicht sie, wenn die Verbindung unerwartet abbricht, z. B. bei Stromausfall oder wenn die Keep-alive-Zeit überschritten wird (1 Punkt), nicht aber bei einer ordentlichen Abmeldung mit DISCONNECT (1 Punkt).
f) Der Sensor sendet seine Messwerte alle 60 Sekunden, Keep alive steht auf 60 s. Beschreibe, wie der Broker erkennt, dass ein Sensor nicht mehr erreichbar ist, und nach welcher Zeit er die Verbindung spätestens trennt. (2 Punkte)
Der Client muss innerhalb der Keep-alive-Zeit eine Nachricht senden – einen Messwert oder, wenn es nichts zu senden gibt, ein PINGREQ, das der Broker mit PINGRESP beantwortet (1 Punkt). Hört der Broker innerhalb des 1,5-Fachen dieser Zeit, also 90 s, nichts vom Sensor, trennt er die Verbindung und veröffentlicht den Last Will (1 Punkt).
Links und weitere Informationen
Grundlagen: MQTT: Publish/Subscribe, Topics, Wildcards und QoS
Voraussetzung: OSI- und TCP/IP-Modell, Protokolle und Ports
weiterführend: Kryptografie, VLAN und Netzsegmentierung
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Übungsaufgaben zu MQTT” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/mqtt-uebungsaufgaben veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/mcu/iot-grundlagen. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
