#mqtt

In this part of the tutorial we will look closer the esp8266 sketch that will send the temperature info to our server.

Read More...

Meist wird MQTT verwendet, um Sensordaten oder Schaltzustände zu übertragen: Temperaturwerte, Luftfeuchtigkeit oder das Ein- und Ausschalten eines Relais. Klassisches IoT eben.

Doch was viele dabei übersehen: MQTT ist völlig unabhängig davon, was du überträgst.

Ob Zahlen, Texte oder sogar strukturierte Daten – für MQTT ist alles einfach nur eine Nachricht.

Und genau hier wird es spannend.

Denn im Grunde passiert beim Chatten nichts anderes: Eine Nachricht wird gesendet, verteilt und von anderen empfangen.

👉 Genau das macht MQTT bereits – nur normalerweise ohne Menschen.

https://youtu.be/zNiSUmRnl9c

Das bedeutet:

👉 Geräte „chatten“ längst miteinander – wir müssen nur den Menschen mit ins Spiel bringen.

In diesem Beitrag zeige ich dir, wie du mit MQTT, Node-RED und einer kleinen SQLite-Datenbank einen eigenen Chat baust. Kein riesiges Framework, keine komplizierte Architektur – sondern ein leicht verständliches Praxisprojekt, das dir gleichzeitig zeigt, wie flexibel MQTT wirklich ist.

Und das Beste daran: Der Chat funktioniert nicht nur im Browser, sondern lässt sich später problemlos auf ESP32, andere Clients oder sogar dein eigenes Smart Home erweitern.

Ziel des Projekts

In diesem Beitrag bauen wir gemeinsam einen einfachen Chat auf Basis von MQTT und Node-RED. Der Fokus liegt dabei nicht auf einer vollwertigen Chat-Anwendung, sondern auf dem Verständnis der zugrunde liegenden Kommunikation.

einfacher Chat umgesetzt mit MQTT und Node-RED

Das Ziel ist es, aufzuzeigen, wie Nachrichten über MQTT gesendet, verteilt und von mehreren Teilnehmern empfangen werden können – genau so, wie es auch in klassischen IoT-Szenarien passiert.

Dabei setzen wir auf folgende Komponenten:

- MQTT als Transportprotokoll für die Nachrichten - Node-RED zur Verarbeitung und Visualisierung - SQLite zur Speicherung der Chat-Historie

Die Datenbank dient dabei ausschließlich dazu, bereits gesendete Nachrichten persistent zu speichern und beim Beitritt zum Chat erneut anzeigen zu können.

Bewusst verzichten wir in diesem Projekt auf zusätzliche Funktionen wie:

- Upload von Bildern oder Dateien - Versand von Videos - komplexe Benutzerverwaltung

Stattdessen konzentrieren wir uns auf das Wesentliche:

👉 Das Senden und Empfangen von Textnachrichten über MQTT

Genau dieser reduzierte Ansatz macht das Projekt so interessant, denn er zeigt sehr deutlich, wie einfach sich mit MQTT ein verteiltes Kommunikationssystem umsetzen lässt.

Architektur & Funktionsweise des Chats

Bevor wir mit der eigentlichen Umsetzung starten, werfen wir einen Blick auf die Architektur unseres Chats und das Zusammenspiel der einzelnen Komponenten.

In diesem Projekt übernimmt Node-RED eine zentrale Rolle:

- Es stellt das Dashboard für die Benutzeroberfläche bereit - Es fungiert als Publisher und Subscriber im MQTT-System - Es dient als Schnittstelle zur SQLite-Datenbank, in der die Nachrichten gespeichert werden

Dadurch entsteht eine flexible Architektur, bei der Node-RED zwar das Frontend liefert, aber nicht zwingend der einzige Teilnehmer im System ist.

Ablauf der Kommunikation im Chat Client mit MQTT und Node-RED Offenes System durch MQTT

Ein großer Vorteil von MQTT ist die Offenheit des Systems.

👉 Das bedeutet konkret: Dein Chat ist nicht auf das Dashboard beschränkt – er ist ein offenes System.

Neben dem Node-RED Dashboard können also auch andere Clients Nachrichten senden und empfangen, zum Beispiel:

- der MQTT Explorer zur direkten Analyse und zum Testen - ein Mikrocontroller wie ESP8266 oder ESP32 - eigene Anwendungen oder Skripte

Chatnachrichten vom MQTT Explorer als JSON

Diese Clients können problemlos Nachrichten in den Chat senden oder empfangen. Einziger Unterschied:

👉 Der Zugriff auf die Chat-Historie erfolgt in unserem Projekt ausschließlich über Node-RED und die angebundene SQLite-Datenbank.

Ablauf einer Chatnachricht

Der Ablauf einer Nachricht ist bewusst einfach gehalten und orientiert sich vollständig am MQTT-Prinzip:

- Der Benutzer meldet sich im Dashboard mit einem Benutzernamen an - Anschließend kann er – wie in jedem klassischen Chat – eine Nachricht eingeben und absenden - Node-RED veröffentlicht diese Nachricht auf einem MQTT-Topic - Der MQTT-Broker verteilt die Nachricht an alle verbundenen Clients - Node-RED empfängt die Nachricht erneut als Subscriber - Die Nachricht wird in der SQLite-Datenbank gespeichert - Der Chatverlauf wird aktualisiert und im Dashboard angezeigt

👉 Wichtig: Jede Nachricht durchläuft immer denselben Weg – unabhängig davon, ob sie vom Browser, einem Mikrocontroller oder einem anderen MQTT-Client stammt.

Verwendetes MQTT-Topic

Für die Kommunikation verwenden wir ein zentrales Topic:

chat/message

Alle Teilnehmer abonnieren dieses Topic und erhalten dadurch jede neue Nachricht in Echtzeit.

Speicherung der Nachrichten

Da MQTT selbst keine dauerhafte Speicherung vorsieht, wird jede Nachricht zusätzlich in einer SQLite-Datenbank abgelegt.

SQLite Datenbank mit Chat Historie

Das ermöglicht:

- das Nachladen der Chat-Historie beim Einstieg - die Anzeige vergangener Nachrichten - einen konsistenten Zustand im Dashboard Simple MQTT Chat mit Node-REDHerunterladen

Voraussetzungen

Für dieses Projekt benötigst du eine laufende Umgebung mit Node-RED, einem MQTT-Broker sowie einer SQLite-Datenbank.

Die gute Nachricht: Alle notwendigen Grundlagen habe ich bereits in separaten Beiträgen ausführlich erklärt.

👉 Wenn du diese Komponenten noch nicht eingerichtet hast, findest du hier die passenden Anleitungen:

- Node-RED mit Docker installieren – Schritt für Schritt - Node-RED unter Windows 11 mit WSL installieren – Schritt für Schritt - Node-RED mit Docker – SQLite Datenbank anbinden und erste Abfragen Benötigte Komponenten im Überblick

Für den Chat selbst setzen wir auf folgende Bausteine:

- Node-RED zur Verarbeitung der Daten und Bereitstellung des Dashboards - MQTT-Broker (z. B. Mosquitto) für die Verteilung der Nachrichten zwischen den Teilnehmern - SQLite-Datenbank zur Speicherung der Chat-Historie Hinweis

In diesem Beitrag konzentrieren wir uns vollständig auf die Umsetzung des Chats. Die Installation und Grundkonfiguration der einzelnen Komponenten wird daher nicht erneut behandelt.

👉 So kannst du dich direkt auf das Wesentliche konzentrieren: Das Senden und Empfangen von Nachrichten über MQTT.

Einrichten der SQLite-Datenbank für die Chat-Historie

Die Historie des Chats wird in einer SQLite-Datenbank gespeichert. Diese liegt als einfache Datei im Dateisystem vor – genau das ist einer der großen Vorteile von SQLite: Es wird kein separater Datenbankserver benötigt.

SQLite Datenbank im Docker Container von Node-RED

Für unser Projekt reicht eine einzige Tabelle aus, da wir zunächst nur einen Chatraum verwenden.

Tabellenstruktur

Die Tabelle chat_messages enthält folgende Spalten:

- id – fortlaufende, eindeutige Nummer (Primärschlüssel) - name – Name des Benutzers, der die Nachricht gesendet hat - message – eigentlicher Text der Nachricht - zeit – UNIX-Timestamp der Nachricht SQL zum Anlegen der Tabelle CREATE TABLE chat_messages ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, message TEXT NOT NULL, zeit INTEGER NOT NULL );

Node-RED Flow erstellen

Nachdem die Datenbank vorbereitet ist, kümmern wir uns im nächsten Schritt um den eigentlichen Node-RED Flow. Dieser verbindet das Dashboard, den MQTT-Broker und die SQLite-Datenbank zu einem einfachen, aber erstaunlich flexiblen Chat-System.

👉 Ziel ist es, drei zentrale Komponenten miteinander zu verbinden:

- Benutzeroberfläche (Dashboard) - Nachrichtenübertragung (MQTT) - Speicherung der Historie (SQLite) Aufbau des Flows im Überblick

Der Flow besteht im Kern aus drei Bereichen:

1. Dashboard (ui-template) Hier wird die Chat-Oberfläche dargestellt und Benutzereingaben werden erfasst.

Code Chat beitreten Absenden Angemeldet als {{ username }} {{ entry.name }} {{ entry.message }} {{ entry.zeit_format }} Senden

Anmeldung an einen einfachen Chat

aktiver Chat mit drei Teilnehmern

2. MQTT-Kommunikation Nachrichten werden über das Topic chat/message versendet und empfangen.

3. Datenbank-Anbindung (SQLite) Alle Nachrichten werden gespeichert und bei Bedarf wieder geladen.

Der komplette Flow

kompletter Node-RED Flow für ein einfaches Chat System

👉 Importiere den folgenden Flow in Node-RED:

Simple MQTT Chat mit Node-REDHerunterladen Verarbeitung eingehender Nachrichten

Sobald eine Nachricht im Dashboard abgesendet wird, passiert Folgendes:

- Das Dashboard sendet eine Nachricht mit: - name (Benutzername) - message (Text) - In der Function-Node „baue Nachricht“ wird die Nachricht erweitert: let name = msg.payload.name; let message = msg.payload.message; let time = Date.now(); msg.payload = { name: name, message: message, timestamp: time }; return msg;

👉 Hier wird der UNIX-Zeitstempel ergänzt, damit die Nachricht später korrekt sortiert und angezeigt werden kann.

Nachricht via MQTT versenden

Die aufbereitete Nachricht wird anschließend über eine mqtt out-Node veröffentlicht:

Topic:

chat/message

👉 Wichtig: Alle Teilnehmer im System abonnieren genau dieses Topic.

Nachricht empfangen (Subscriber)

Node-RED ist gleichzeitig auch Subscriber und empfängt jede gesendete Nachricht erneut über die mqtt in-Node.

Das bedeutet:

👉 Egal ob die Nachricht vom Browser, einem ESP32 oder dem MQTT Explorer kommt – sie wird immer gleich verarbeitet.

Speicherung in der SQLite-Datenbank

Die empfangene Nachricht wird anschließend in der Datenbank gespeichert.

Dazu wird in einer Function-Node ein SQL-Statement erzeugt:

function esc(str) { return String(str).replace(/'/g, "''"); } const name = esc(msg.payload.name); const message = esc(msg.payload.message); const zeit = esc(msg.payload.timestamp); msg.topic = `INSERT INTO chat_messages (name, message, zeit) VALUES ('${name}', '${message}', ${zeit});`; return msg;

👉 Die SQLite-Node führt dieses Statement aus und speichert die Nachricht persistent.

Chat-Historie laden

Damit der Benutzer alle bisherigen Nachrichten sieht, wird nach jedem Event die Historie neu geladen.

Das erfolgt über folgende SQL-Abfrage:

SELECT id, name, message, strftime('%d.%m.%Y %H:%M:%S', zeit / 1000, 'unixepoch', 'localtime') AS zeit_format FROM chat_messages ORDER BY zeit ASC;

👉 Hier passiert etwas Wichtiges:

- Der gespeicherte UNIX-Timestamp wird direkt in ein lesbares Datum umgewandelt - Format: Tag.Monat.Jahr Stunde:Minute:Sekunde Steuerung über Topics

Im Flow wird zwischen zwei Aktionen unterschieden:

- load_chat → lädt die Historie - send_message → sendet eine neue Nachricht

Das erfolgt über eine switch-Node:

👉 Dadurch bleibt der Flow übersichtlich und klar strukturiert.

Warum funktioniert das Ganze so gut mit MQTT?

Ganz einfach: MQTT ist von Grund auf für verteilte Systeme gebaut.

Jeder Teilnehmer kann:

- Nachrichten senden (Publisher) - Nachrichten empfangen (Subscriber)

👉 Und genau das macht einen Chat aus.

Der große Vorteil: Neue Teilnehmer können jederzeit hinzugefügt werden, ohne dass die bestehende Architektur angepasst werden muss.

Ob Browser, ESP32 oder ein eigenes Script: Solange das richtige Topic verwendet wird, ist jeder sofort Teil des Systems.

Nachrichten mit anderen MQTT-Clients senden

Ein großer Vorteil dieses Aufbaus ist, dass der Chat nicht fest an das Node-RED Dashboard gebunden ist.

Da alle Nachrichten über das MQTT-Topic chat/message laufen, kann grundsätzlich jeder MQTT-fähige Client an der Kommunikation teilnehmen. Das kann ein weiteres Node-RED Dashboard sein, ein ESP32, ein ESP8266 oder auch ein externes MQTT-Tool wie CorreoMQTT.

CorreoMQTT Tool

Wichtig ist nur, dass die Nachricht im erwarteten JSON-Format gesendet wird:

{ "name": "CorreoMQTT", "message": "Hallo aus einem externen MQTT-Client!", "timestamp": 1715779200000 }

Die Nachricht wird anschließend vom Node-RED Subscriber empfangen, in der SQLite-Datenbank gespeichert und beim erneuten Laden der Historie im Dashboard angezeigt.

Damit wird sehr schön sichtbar, worum es bei MQTT eigentlich geht:

👉 Der Absender muss das Dashboard nicht kennen. 👉 Der Empfänger muss den Absender nicht kennen. 👉 Beide müssen nur dasselbe MQTT-Topic verwenden.

Für unser Beispiel lautet dieses Topic:

chat/message

Dadurch lässt sich der Chat sehr einfach erweitern. So könnte später zum Beispiel ein ESP32 automatisch Statusmeldungen senden oder ein anderes System Benachrichtigungen in den Chat schreiben.

Fazit

Mit diesem Projekt hast du gesehen, dass MQTT deutlich mehr kann als nur Sensordaten oder Schaltbefehle zwischen Geräten auszutauschen.

Mit überraschend wenig Aufwand haben wir einen einfachen Chat aufgebaut, der Nachrichten in Echtzeit verteilt, dauerhaft speichert und unabhängig vom eigentlichen Client funktioniert.

Dabei übernehmen die einzelnen Komponenten klar getrennte Aufgaben:

- MQTT verteilt die Nachrichten - Node-RED übernimmt Oberfläche und Logik - SQLite speichert die Historie dauerhaft

Genau diese Trennung macht den Aufbau so flexibel.

Das Spannende daran: Der Chat selbst ist am Ende nur ein Beispiel.

Denn technisch betrachtet unterscheiden sich Chatnachrichten kaum von Sensordaten, Statusmeldungen oder Befehlen aus einem Smart-Home-System.

Heute schreibt ein Benutzer eine Nachricht. Morgen sendet ein ESP32 eine Warnung. Übermorgen meldet ein Shelly automatisch einen Zustand.

Und genau hier zeigt sich die eigentliche Stärke von MQTT: Nicht die Nachricht ist entscheidend – sondern dass jeder Teilnehmer dieselbe Sprache spricht.

Ich hoffe, ich konnte dir mit diesem Projekt zeigen, dass MQTT weit mehr ist als nur ein Protokoll für Temperaturwerte.

Nachdem wir im letzten Beitrag einen eigenen MQTT-Broker mit Mosquitto MQTT Broker eingerichtet und erste Nachrichten über die Konsole gesendet haben, wird es nun deutlich komfortabler.

Die Arbeit mit mosquitto_pub und mosquitto_sub ist zwar ideal für den Einstieg, stößt aber schnell an ihre Grenzen – vor allem, wenn viele Topics und Nachrichten gleichzeitig im Spiel sind.

Genau hier kommt der MQTT Explorer ins Spiel und bringt endlich Übersicht in dein MQTT-System.

https://youtu.be/TkPLVbkcoE4

Mit diesem Tool kannst du:

- alle Topics deines Brokers übersichtlich als Baumstruktur anzeigen - Nachrichten in Echtzeit verfolgen - Payloads analysieren und bearbeiten - eigene Nachrichten direkt versenden

In diesem Beitrag zeige ich dir Schritt für Schritt, wie du den MQTT Explorer installierst und deinen Broker visuell analysierst.

MQTT Explorer installieren (Windows, macOS & Linux)

Den MQTT Explorer kannst du unter Windows, macOS sowie verschiedenen Linux-Distributionen wie Ubuntu installieren. Wichtig ist dabei: Das Tool benötigt eine grafische Oberfläche (GUI) – auf reinen Server-Systemen ohne Desktop-Umgebung lässt es sich daher nicht direkt ausführen.

MQTT Explorer - download der Versionen für die Betriebssysteme Windows, macOS, Ubuntu und Linux

Verbindung zum MQTT Broker herstellen

Nach dem Start des MQTT Explorer richten wir im nächsten Schritt die Verbindung zu unserem Broker ein.

Dazu legst du zunächst eine neue Verbindung an und vergibst einen beliebigen Namen, z. B. „RaspberryPi MQTT“ oder „Lokaler Broker“.

MQTT Explorer - Connection zum Raspberry Pi

Anschließend trägst du die IP-Adresse deines MQTT-Brokers ein. In meinem Fall läuft der Mosquitto MQTT Broker auf einem Raspberry Pi im lokalen Netzwerk.

Die wichtigsten Einstellungen im Überblick:

- Host: IP-Adresse deines Brokers (z. B. 192.168.x.x oder localhost) - Port: Standardmäßig 1883

Der Default-Port 1883 bleibt in den meisten Fällen unverändert. Solltest du jedoch einen Docker-Container verwenden, bei dem der Port umgeleitet wurde (z. B. -p 1884:1883), musst du hier den entsprechend gemappten Port eintragen.

Status des Docker Containers - MQTT Broker Mosquitto

Optional kannst du zusätzlich:

- Benutzername und Passwort setzen (falls konfiguriert) - eine sichere Verbindung (TLS) nutzen

Nachdem du alle Einstellungen vorgenommen hast, kannst du die Verbindung speichern und direkt herstellen.

MQTT Explorer - Benutzername und Passwort - sowie Verbindung herstellen

Erste Topics und Nachrichten im MQTT Explorer beobachten

Nachdem die Verbindung erfolgreich hergestellt wurde, wird es spannend: Der MQTT Explorer zeigt dir nun alle vorhandenen Topics deines Brokers in einer übersichtlichen Baumstruktur an. Und solltest du numerische Werte senden so werden diese in einem Liniendiagramm visualisiert.

MQTT Explorer - Auflistung der Topics im Baum

Ich habe auf meinem Raspberry Pi bereits einige Nachrichten an die Topics sensor/humidity, sensor/temp sowie house/door/bell gesendet. Die zuletzt gesendeten Werte werden nun im MQTT Explorer übersichtlich im Topic-Baum dargestellt.

MQTT Explorer - Übersicht der Topicss

Nachrichten direkt im MQTT Explorer senden

Mit dem MQTT Explorer kannst du nicht nur Topics beobachten, sondern auch selbst Nachrichten versenden.

Dazu wählst du zunächst das gewünschte Topic im Baum aus. Auf der rechten Seite findest du anschließend den Bereich „Publish“.

MQTT Explorer - publish auf ein topic

Hier kannst du festlegen, in welchem Format die Daten gesendet werden sollen. Zur Auswahl stehen unter anderem:

- raw (reiner Text) - XML - JSON

Anschließend gibst du deine Daten in das Eingabefeld ein, zum Beispiel:

{ "temperature": 22.5, "humidity": 60 }

Mit einem Klick auf die Schaltfläche „PUBLISH“ wird die Nachricht an den Broker gesendet und direkt an alle Subscriber ausgeliefert.

In meinem Fall ist das unter anderem wieder mein Raspberry Pi, der die Daten empfängt und weiterverarbeitet.

Retained Messages verstehen und gezielt löschen

Beim Arbeiten mit MQTT kann es passieren, dass beim Verbinden zu einem Topic sofort eine alte Nachricht angezeigt wird – selbst wenn gerade keine neue gesendet wurde.

MQTT Explorer - Ansicht der vorhandenen Retained Messages

Dieses Verhalten liegt an sogenannten Retained Messages.

Die „alten“ Nachrichten lassen sich im MQTT Explorer besonders einfach löschen – in vielen Fällen genügt bereits ein Klick. Zudem erkennst du auf einen Blick, in welchen Topics noch Retained Messages vorhanden sind, und kannst diese gezielt entfernen.

Das bietet einen großen Vorteil, um den eigenen MQTT-Broker sauber und übersichtlich zu halten.

Dennoch solltest du prüfen, warum Nachrichten überhaupt dauerhaft gespeichert bleiben: Werden diese regelmäßig nicht abgeholt, kann das ein Hinweis darauf sein, dass ein angebundenes System nicht mehr aktiv ist oder nicht mehr benötigt wird.

Hinweis: Wenn du die Schaltfläche zum Löschen eines Topics im MQTT Explorer verwendest, wird dieses lediglich aus der Baumansicht entfernt. Das Topic selbst existiert weiterhin auf dem Broker.

Sobald erneut eine Nachricht auf dieses Topic veröffentlicht wird, erscheint es automatisch wieder im MQTT Explorer und die Daten werden wie gewohnt an alle Subscriber ausgeliefert. Bereits angebundene Subscriber werden durch das Entfernen in der Oberfläche nicht beeinflusst.

Fazit

Mit dem MQTT Explorer hast du ein äußerst hilfreiches Werkzeug kennengelernt, um deinen MQTT Broker nicht nur zu überwachen, sondern aktiv damit zu arbeiten.

Du kannst:

- Topics und deren Struktur übersichtlich analysieren - Nachrichten in Echtzeit verfolgen - eigene Daten direkt senden (Publish) - numerische Werte visualisieren - Retained Messages gezielt verwalten und löschen

Gerade für Einsteiger, aber auch für fortgeschrittene Projekte, bietet der MQTT Explorer einen großen Mehrwert beim Debugging und beim Verständnis von MQTT.

Ausblick