Wer zuletzt einen CAPS-konformen Lehrplan für Coding and Robotics angeschaut oder versucht hat, eine Praxiseinheit zum Internet der Dinge (IoT) für den Unterricht zu entwerfen, ist vermutlich über das Kürzel MQTT und die Anforderung eines „MQTT-Brokers“ gestolpert. Für eine Informatiklehrkraft oder eine vielbeschäftigte Technikkoordination wirkt das wie unnötige Komplexität. Warum kann ein Mikrocontroller wie ein ESP32 oder ein Raspberry Pi Pico W seine Sensordaten nicht einfach direkt über das lokale WLAN an das Notebook oder Handy einer Schülerin schicken?

Die kurze Antwort: Direkte Kommunikation zwischen Geräten ist fragil, ressourcenhungrig und mit der Sicherheit von Schulnetzen fast völlig unvereinbar. MQTT (Message Queuing Telemetry Transport) löst das, indem es den Absender der Daten vom Empfänger trennt und alle Nachrichten über eine zentrale Vermittlungsstelle leitet, den Broker. Es ist der Industriestandard für industrielles IoT und wird für Physical Computing im Klassenzimmer immer unverzichtbarer.

Das schwarze Brett im Klassenzimmer: Pub/Sub verstehen

Um zu verstehen, warum MQTT funktioniert, stellen Sie sich eine Klasse mit 40 Lernenden vor. Müsste jeder, der die aktuelle Außentemperatur wissen will, zu der einen Person am Fenster gehen und fragen: „Wie warm ist es?“, dann würde diese Person die ganze Stunde damit verbringen, dieselbe Frage zu beantworten, statt selbst zu arbeiten. Wollten zehn weitere Lernende wissen, wann die nächste Pause ist, müssten sie direkt die Lehrkraft unterbrechen.

Nun hängen Sie ein schwarzes Brett in den Flur. Die Person am Fenster schreibt „Temperatur: 22 °C“ auf einen Zettel und heftet ihn unter die Überschrift „Wetter“. Die Lehrkraft heftet „Nächste Pause: 10:30“ unter „Zeitplan“. Wer die Temperatur oder die Pausenzeit wissen will, geht einfach zum Brett und liest sie ab. Die Person am Fenster weiß nicht und interessiert es nicht, wer die Temperatur liest; sie hängt nur die Aktualisierung aus. Die Lesenden müssen sie nicht stören.

Das ist das Publish/Subscribe-Modell (Pub/Sub), das MQTT verwendet:

• Der Publisher: Der Mikrocontroller mit einem Sensor (die Person am Fenster), der Daten an den Broker sendet.
• Der Subscriber: Das Dashboard, die Handy-App oder die Datenbank (die Lernenden, die das Brett lesen), die diese Daten empfangen möchte.
• Der Broker: Der zentrale Server (das schwarze Brett), der Nachrichten von Publishern entgegennimmt und an die richtigen Subscriber weiterleitet.

Der technische Kern: Topics, Retained Messages und Last Wills

MQTT stützt sich auf drei Kernkonzepte, die die Kommunikation auch über schlechte Funkverbindungen effizient und zuverlässig halten.

1. Topics: Nachrichten gehen nicht an bestimmte Geräte, sie werden auf „Topics“ veröffentlicht. Topics sind mit Schrägstrichen strukturiert und bilden eine Hierarchie wie school/lab1/temp oder home/garden/moisture. Ein Gerät kann ein sehr spezifisches Topic abonnieren oder mit Platzhaltern mehrere Topics auf einmal mithören. Ein Abo auf school/+/temp etwa erlaubt es einem einzigen Dashboard, die Temperaturwerte aus jedem Labor auf dem Gelände anzuzeigen.

2. Retained Messages: Wenn ein Sensor einen Messwert veröffentlicht und in genau dieser Millisekunde niemand abonniert hat, ist die Nachricht normalerweise für immer verloren. Öffnet eine Schülerin fünf Minuten später ihre Dashboard-App, sieht sie einen leeren Bildschirm, bis der Sensor erneut sendet. Setzt der Publisher das „Retained“-Flag auf einer Nachricht, sagt er dem Broker: „Behalte diesen letzten Wert. Gib ihn dem Nächsten, der dieses Topic abonniert, sofort mit.“ Für sich langsam ändernde Daten wie Bodenfeuchte oder Wasserstände in Tanks ist das entscheidend.

3. Last Will and Testament (LWT): Mikrocontroller in südafrikanischen Klassenzimmern erleben häufige, plötzliche Verbindungsabbrüche durch Load Shedding, leere Akkus oder Lernende, die versehentlich ein Stromkabel herausziehen. Wenn sich ein Gerät erstmals mit dem Broker verbindet, hinterlegt es eine „Last Will“-Nachricht (zum Beispiel Topic: status/sensor1, Nachricht: offline). Verliert das Gerät plötzlich die Stromversorgung, ohne sich sauber abzumelden, erkennt der Broker die abgerissene Verbindung und veröffentlicht die „Last Will“-Nachricht automatisch stellvertretend – und meldet dem Rest des Systems damit, dass die Hardware offline ist.

Drei Dinge, die im Schulnetz schiefgehen

MQTT ist robust, doch der Einsatz im Bildungsumfeld erfordert den Umgang mit der Realität schulischer IT-Infrastruktur. Drei typische Fehlerbilder stören den Unterricht regelmäßig:

Typische Ausfälle im Schulnetz

Um diese lokalen Netzwerkhürden zu umgehen, bleibt Lehrenden meist die Wahl, mit der IT-Abteilung um individuelle Router-Konfigurationen zu ringen oder ihren Datenverkehr über einen externen, cloudgehosteten Broker zu leiten, der über gängige Web-Ports erreichbar ist. Für Lehrkräfte, die eine schlanke, unterrichtsfertige Lösung suchen, die diesen lokalen Netzwerkärger komplett umgeht, bietet die Sheen IoT Plattform eine vorkonfigurierte, cloudgehostete MQTT-Umgebung, die eigens für die Beschränkungen von Schul-Firewalls ausgelegt ist.

Indem MQTT die Last der Nachrichtenvermittlung von den Mikrocontrollern auf einen dedizierten Broker verlagert, sorgt es dafür, dass die IoT-Geräte im Klassenzimmer zuverlässig und sicher kommunizieren – selbst wenn der Code einer Schülerin unoptimiert ist oder das Schul-WLAN einbricht.