Unbetitelt

MQTT ist das Kommunikationsprotokoll für IoT-Projekte – egal ob du mit einem ESP32 Sensordaten überträgst, ein Dashboard mit Node-RED aufbaust oder komplexe Smart-Home-Systeme betreibst.

Doch nicht nur im Hobbybereich spielt MQTT eine Rolle: Auch in Enterprise-Projekten, Industrieanwendungen und skalierbaren Cloud-Systemen ist MQTT längst etabliert. Immer dann, wenn viele Geräte zuverlässig und effizient miteinander kommunizieren müssen, kommt dieses Protokoll ins Spiel.

👉 MQTT ist ein leichtgewichtiges Publish/Subscribe-Protokoll zur Übertragung von Nachrichten zwischen Geräten.

https://youtu.be/UScUhc0y6AU

Dieser Beitrag ist der Auftakt zu einer mehrteiligen MQTT-Serie.

Wir starten mit den Grundlagen und bauen direkt ein erstes kleines Testsystem auf. In den folgenden Teilen greifen wir dann Daten aus verschiedenen smarten Systemen ab, übertragen diese per MQTT und verarbeiten sie weiter – z. B. in Node-RED oder eigenen Anwendungen.

Was bedeutet MQTT eigentlich?

Bevor wir tiefer einsteigen, stellt sich erstmal eine einfache Frage: 👉 Wofür steht MQTT eigentlich?

MQTT steht für Message Queuing Telemetry Transport.

Klingt im ersten Moment etwas sperrig – lässt sich aber ziemlich einfach herunterbrechen:

- Message → es werden Nachrichten übertragen - Queuing → Nachrichten werden nicht direkt von Gerät zu Gerät gesendet, sondern über eine zentrale Stelle gesammelt und verteilt - Telemetry → meist Sensordaten (z. B. Temperatur, Luftfeuchte, Statuswerte) - Transport → die Übertragung zwischen Geräten

Vereinfacht gesagt bedeutet das: MQTT ist ein Protokoll, das speziell dafür entwickelt wurde, Daten effizient zwischen Geräten auszutauschen, ohne dass diese direkt miteinander verbunden sein müssen.

Und genau das macht es so interessant für IoT-Projekte.

Ein Mikrocontroller wie ein ESP32 kann seine Daten einfach „in den Raum senden“, ohne zu wissen, wer diese später empfängt – sei es ein Dashboard, eine Datenbank oder ein anderes Gerät.

Damit das Ganze funktioniert, braucht MQTT im Hintergrund eine zentrale Instanz, die alle Nachrichten entgegennimmt und verteilt.

Genau diese Rolle übernimmt der sogenannte Broker.

Und genau diesen setzen wir jetzt gemeinsam auf.

MQTT Broker – Mosquitto mit Docker Compose

Damit wir unser Testsystem sauber und dauerhaft betreiben können, benötigen wir einen sogenannten MQTT-Broker. Dieser übernimmt die zentrale Rolle in unserem Setup und verteilt später alle Nachrichten zwischen den Geräten.

Eine der bekanntesten und leichtgewichtigen Lösungen ist Eclipse Mosquitto.

Eine sehr gute und ausführliche Beschreibung zum offiziellen Docker-Image findest du direkt auf Docker Hub: https://hub.docker.com/_/eclipse-mosquitto

Image herunterladen

Zunächst laden wir uns das offizielle Image:

docker pull eclipse-mosquitto Docker Compose Datei erstellen

Jetzt erstellen wir eine eigene Docker-Compose-Datei:

nano mosquitto-docker-compose.yml

Füge folgenden Inhalt ein:

services: mosquitto: image: eclipse-mosquitto container_name: mosquitto restart: unless-stopped ports: - "1883:1883" volumes: - ./mosquitto/config:/mosquitto/config - ./mosquitto/data:/mosquitto/data - ./mosquitto/log:/mosquitto/log mosquitto.conf anlegen

Die Datei mosquitto.conf wird nicht automatisch erstellt und muss daher einmalig von dir angelegt werden.

Zuvor muss jedoch die Verzeichnisstruktur angelegt werden, dafür gibt es zwei Möglichkeiten:

Variante 1: Der bequeme Weg

Du kannst den Container einmal kurz starten, damit die Verzeichnisstruktur automatisch angelegt wird:

docker compose -f mosquitto-docker-compose.yml up -d

Anschließend stoppst du den Container wieder:

docker compose -f mosquitto-docker-compose.yml down

👉 Danach sind die benötigten Ordner vorhanden und du kannst die Konfigurationsdatei hinzufügen.

Variante 2: Manuell anlegen

Alternativ kannst du die Struktur direkt selbst erstellen:

mkdir mosquitto; cd mosquitto; mkdir config; mkdir data; mkdir log; Berechtigungen auf die Verzeichnisse geben

Damit der Mosquitto Broker Service in die Verzeichnisse schreiben kann, müssen die berechtigungen angepasst werden.

sudo chown -R 1883:1883 config sudo chown -R 1883:1883 data sudo chown -R 1883:1883 log Konfigurationsdatei erstellen

Im Verzeichnis: ./mosquitto/config legst du nun die Datei mosquitto.conf an:

edit ./mosquitto/config/mosquitto.conf listener 1883 allow_anonymous true persistence true persistence_location /mosquitto/data/ log_dest file /mosquitto/log/mosquitto.log

Editor - mosquitto.conf Broker erneut starten

Jetzt kannst du den Container wieder starten:

docker compose -f mosquitto-docker-compose.yml up -d Status prüfen docker compose -f mosquitto-docker-compose.yml ps

MQTT Broker Mosquitto gestartet Logs anzeigen docker compose -f mosquitto-docker-compose.yml logs -f

Ausgabe der Logdatei des Mosquitto Brokers im Docker Container

Zugriff auf den MQTT Broker im Docker Container

Da wir den MQTT-Broker in einem Docker-Container betreiben, müssen wir für einige Befehle direkt innerhalb des Containers arbeiten.

Dafür können wir uns eine interaktive Shell im Container öffnen.

In den Container wechseln

Zunächst schauen wir uns an, wie unser Container heißt:

docker ps --format "{{.Names}}"

Ausgabe der Containernamen in der Konsole mit docker ps

In der Regel haben wir ihn bereits mosquitto genannt.

Nun wechseln wir in den Container:

docker exec -it mosquitto sh

Zugriff auf die Shell in einem Docker Container mit docker exec

Erstes Praxisbeispiel: Temperaturwert senden und empfangen

Nachdem unser MQTT-Broker läuft und wir Zugriff auf den Container haben, schauen wir uns jetzt ein erstes praxisnahes Beispiel an.

Ein klassisches Beispiel: Temperaturwerte.

Mosquitto MQTT Broker - Beispiel - Temperatur - Publisher und Subscriber Terminal 1 – Publisher

Der Publisher sendet eine Nachricht an den MQTT-Broker. Dieser verteilt die Nachricht anschließend automatisch an alle Subscriber, die das entsprechende Topic abonniert haben.

mosquitto_pub -h localhost -t sensor/temperature -m "22.5"

Gibt es keinen Subscriber für dieses Topic, wird die Nachricht zwar vom Broker entgegengenommen, aber nicht gespeichert und somit verworfen.

Retain-Flag

Mit dem Parameter retain kannst du dieses Verhalten beeinflussen.

Wird dieser auf true gesetzt, speichert der Broker die letzte gesendete Nachricht und liefert sie automatisch an neue Subscriber aus, sobald diese das Topic abonnieren.

mosquitto_pub -h localhost -t sensor/temperature -m "22.5" -r

Beispiel - senden einer MQTT Nachricht mit retain flag

Hinweis: Es wird dabei immer nur die letzte Nachricht gespeichert. Sobald eine neue Nachricht mit gesetztem Retain-Flag gesendet wird, ersetzt diese die vorherige.

Terminal 2 – Subscriber

Der Subscriber lauscht auf ein bestimmtes Topic und empfängt automatisch alle Nachrichten, die darauf veröffentlicht werden.

In unserem Beispiel ist das Topic:

sensor/temperature

Der Subscriber wird mit folgendem Befehl gestartet:

mosquitto_sub -h localhost -t sensor/temperature

Sobald nun eine Nachricht auf dieses Topic gesendet wird, erscheint sie direkt im Terminal.

Wichtig zu verstehen: Der Subscriber muss den Publisher nicht kennen. Er „hört“ einfach auf das Topic und bekommt alle Nachrichten, die dort ankommen.

Topics strukturieren: Geräte und Sensoren gruppieren

Ein großer Vorteil von MQTT ist die Möglichkeit, Topics hierarchisch zu strukturieren. Dazu werden die einzelnen Ebenen mit einem / getrennt.

So lassen sich Geräte und Sensoren logisch gruppieren, zum Beispiel nach Ort und Funktion:

erdgeschoss/steckdosen erdgeschoss/lampen erdgeschoss/kueche/steckdosen erdgeschoss/kueche/lampen erdgeschoss/kueche/sensoren/temperatur erdgeschoss/kueche/sensoren/luftfeuchtigkeit erdgeschoss/wohnstube/steckdosen erdgeschoss/wohnstube/lampen erdgeschoss/wohnstube/sensoren/temperatur erdgeschoss/wohnstube/sensoren/luftfeuchtigkeit

Wildcards in MQTT: Mehrere Topics gleichzeitig abonnieren

Bisher haben wir einzelne Topics gezielt abonniert, zum Beispiel:

mosquitto_sub -h localhost -t erdgeschoss/kueche/lampen

Doch was passiert, wenn wir nicht nur einen Raum, sondern mehrere gleichzeitig überwachen möchten?

👉 Genau hier kommen sogenannte Wildcards ins Spiel.

Beispiel: Alle Lampen im Erdgeschoss

Mit folgendem Topic kannst du alle Lampen im Erdgeschoss abonnieren:

mosquitto_sub -h localhost -t erdgeschoss/+/lampen

Damit würdest du z. B. folgende Topics empfangen:

- erdgeschoss/kueche/lampen - erdgeschoss/wohnstube/lampen

Beispiel - senden und empfangen von Nachrichten mit Wildcard auf einem Topic Wildcard # – mehrere Ebenen gleichzeitig abonnieren

Neben der + Wildcard gibt es noch eine zweite, sehr mächtige Möglichkeit: die # Wildcard

Bedeutung von #

Die Wildcard # steht für beliebig viele Ebenen innerhalb eines Topics. Damit kannst du komplette Bereiche auf einmal abonnieren.

Wichtige Regel

Die # Wildcard darf nur am Ende eines Topics stehen.

Beispiel - Wildcard auf einer Ebene zu einem Topic in MQTT

Typischer Effekt bei Retained Messages

Wenn du ein Topic abonnierst und sofort alte Nachrichten angezeigt bekommst, liegt das in der Regel an sogenannten Retained Messages.

alte Nachrichten vom MQTT Broker

Der MQTT-Broker speichert dabei die letzte Nachricht pro Topic, wenn diese mit dem Retain-Flag (-r) gesendet wurde.

Beispiel

Du abonnierst: mosquitto_sub -h localhost -t erdgeschoss/# -v

👉 Und erhältst direkt mehrere Nachrichten, obwohl aktuell nichts gesendet wurde.

alte Nachrichten vom MQTT Broker welche via Retain Flag gesendet wurden Warum passiert das?

Für jedes Topic unterhalb von erdgeschoss/... kann eine retained Nachricht gespeichert sein.

Zum Beispiel:

- erdgeschoss/kueche/lampen - erdgeschoss/kueche/sensoren/temperatur - erdgeschoss/wohnstube/lampen

👉 Für jedes dieser Topics wird die letzte gespeicherte Nachricht sofort ausgeliefert.

Retained Nachrichten löschen

Um eine retained Nachricht zu löschen, sendest du einfach eine leere Nachricht auf das gleiche Topic – ebenfalls mit gesetztem Retain-Flag:

mosquitto_pub -h localhost -t erdgeschoss/kueche/lampen -n -r

Alternativ:

mosquitto_pub -h localhost -t erdgeschoss/kueche/lampen -m "" -r

Fazit

Wenn du das Prinzip von Publish und Subscribe einmal verstanden hast und weißt, wie Topics aufgebaut sind und mit Wildcards funktionieren, ist der Einstieg in MQTT bereits geschafft.

Viele Dinge wirken am Anfang vielleicht etwas abstrakt – spätestens nach den ersten eigenen Tests wird jedoch schnell klar, wie einfach und flexibel dieses System eigentlich ist.

Gerade die Möglichkeit, Daten unabhängig voneinander zu senden und zu empfangen, macht MQTT so leistungsfähig und perfekt für IoT-Projekte.

Ausblick

Im nächsten Beitrag gehen wir einen Schritt weiter in die Praxis:

Ich zeige dir anhand eines ESP32, wie du echte Sensordaten erfassen und auf ein MQTT-Topic senden kannst.

Diese Daten werden wir anschließend weiterverarbeiten – zum Beispiel in Node-RED oder anderen Anwendungen.

👉 Damit baust du dir Schritt für Schritt dein eigenes kleines IoT-System auf.

FAQ – MQTT einfach erklärt

Was ist MQTT einfach erklärt?

MQTT ist ein leichtgewichtiges Kommunikationsprotokoll, mit dem Geräte Nachrichten untereinander austauschen können.

Dabei senden Geräte ihre Daten an ein sogenanntes Topic, ohne zu wissen, wer diese empfängt. Andere Geräte können diese Topics abonnieren und die Daten verarbeiten.

Was ist ein MQTT Broker?

Ein MQTT-Broker ist die zentrale Instanz im System.

Er nimmt Nachrichten von Sendern (Publishern) entgegen und verteilt diese an alle Empfänger (Subscriber), die das entsprechende Topic abonniert haben.

Ein häufig verwendeter Broker ist Eclipse Mosquitto.

Was ist ein Topic bei MQTT?

Ein Topic ist eine Art „Adresse“ oder „Kanal“, über den Nachrichten gesendet werden.

Beispiel: sensor/temperature

Geräte können gezielt auf bestimmte Topics hören und so nur die für sie relevanten Daten empfangen.

Was bedeutet Publish und Subscribe? - Publish bedeutet, eine Nachricht an ein Topic zu senden - Subscribe bedeutet, ein Topic zu abonnieren und Nachrichten zu empfangen

Dieses Prinzip nennt man Publish/Subscribe-Modell.

Was ist der Unterschied zwischen MQTT und HTTP?

Der wichtigste Unterschied liegt im Kommunikationsmodell:

- HTTP arbeitet mit Anfrage und Antwort (Request/Response) - MQTT arbeitet mit Publish/Subscribe

MQTT ist dadurch deutlich effizienter und besser für IoT-Projekte geeignet, bei denen viele Geräte gleichzeitig Daten austauschen.

Was sind Wildcards in MQTT?

Wildcards ermöglichen es, mehrere Topics gleichzeitig zu abonnieren.

- + steht für genau eine Ebene - # steht für mehrere Ebenen (nur am Ende erlaubt)

Beispiel: erdgeschoss/+/lampen

Damit können alle Lampen in verschiedenen Räumen gleichzeitig empfangen werden.

Was ist das Retain-Flag bei MQTT?

Mit dem Retain-Flag kann eine Nachricht beim Broker gespeichert werden.

Neue Subscriber erhalten diese Nachricht sofort, sobald sie das Topic abonnieren.

👉 Wichtig: Es wird immer nur die letzte Nachricht gespeichert.

Wann sollte ich MQTT einsetzen?

MQTT eignet sich besonders gut für:

- Systeme mit vielen Geräten - IoT-Projekte mit Mikrocontrollern (z. B. ESP32) - Smart Home Anwendungen - Echtzeit-Datenübertragung Kann ich mehrere Geräte gleichzeitig verbinden?

Nachdem ich das Waveshare ESP32-S3 RLCD 4.2 Display bereits in einem ersten Beitrag vorgestellt und im zweiten Teil die grundlegende Programmierung mit der Arduino IDE gezeigt habe, wird es nun etwas praktischer.

Denn ein Display wird natürlich erst dann richtig spannend, wenn nicht nur einfache Texte oder Demo-Elemente angezeigt werden, sondern auch eigene Grafiken, Icons oder Bilder. Genau darum soll es in diesem Beitrag gehen.

- ESP32-S3 mit 4,2″ Display: ePaper Killer? Unboxing & erster Eindruck (Teil 1) - ESP32-S3 RLCD Display ansteuern: So klappt die Programmierung mit Arduino IDE (Teil 2) https://youtu.be/cSbd2kzE7Cs

Ich zeige dir, wie du Bilder auf dem Waveshare RLCD Display mit LVGL anzeigen kannst. Dafür nutze ich eine kleine eigene Library, mit der sich JPEG-Grafiken über eine URL laden und auf dem Display darstellen lassen.

Die Library findest du auf GitHub und kannst sie direkt in dein eigenes Projekt einbinden.

SW Bild auf dem RLCD Display von Waveshare

SW Logo auf dem RLCD Display von Waveshare

SW Wettersymbole auf dem RLCD Display von Waveshare

Transparenzhinweis: Das Gerät wurde mir von Waveshare für dieses Review kostenfrei zur Verfügung gestellt. Ich freue mich immer, wenn ich in dieser Form unterstützt werde und neue Hardware frühzeitig testen kann.

Selbstverständlich hat dies keinen Einfluss auf meine Bewertung – ich teile wie gewohnt meine ehrliche Meinung und praktische Erfahrungen mit dem Board.

Ziel des Projektes

Nachdem das Waveshare ESP32-S3 RLCD 4.2 Display grundsätzlich eingerichtet ist und mit der Arduino IDE programmiert werden kann, geht es in diesem Beitrag um eine etwas praxisnähere Anwendung: Grafiken auf dem Display anzeigen.

Das Ziel ist es, eine Bilddatei nicht fest in den Quellcode einzubauen, sondern diese über eine URL aus dem Internet zu laden und anschließend mit LVGL auf dem RLCD Display darzustellen.

Gerade für kleine Anzeigeprojekte ist dieser Ansatz sehr praktisch. Die Grafik kann auf einem Webserver liegen und bei Bedarf einfach ausgetauscht werden, ohne dass der ESP32 jedes Mal neu programmiert werden muss.

Damit eignet sich das Projekt zum Beispiel für:

- Statusanzeigen - Wettergrafiken - Logos und Icons - News-Displays - einfache Dashboards - dynamisch erzeugte Bilder von einem Server

Ablauf laden eines Bildes auf dem ESP32-S3 von Waveshare mit LVGL und eigener Library

Im Mittelpunkt steht dabei ein möglichst einfacher Ablauf: Der ESP32-S3 verbindet sich mit dem WLAN, lädt eine vorbereitete JPEG-Grafik über eine URL und zeigt diese anschließend mit LVGL auf dem Display an.

Warum eine eigene Library?

Das Anzeigen von Bildern mit LVGL auf dem Waveshare ESP32-S3 RLCD 4.2 Display ist grundsätzlich gut machbar, bringt aber schnell einiges an zusätzlichem Code mit sich. Besonders dann, wenn die Grafik nicht fest im Sketch hinterlegt ist, sondern dynamisch aus dem Internet geladen werden soll.

Für diesen Beitrag wollte ich den eigentlichen Beispielcode möglichst schlank und verständlich halten. Der Fokus soll nicht darauf liegen, sich durch viele Hilfsfunktionen, Dateiverarbeitung und interne Details zu arbeiten, sondern darauf, wie man eine Grafik praktisch auf dem Display anzeigen kann.

Ein weiterer Vorteil ist die Wiederverwendbarkeit. Die Library kann nicht nur für dieses eine Beispiel genutzt werden, sondern später auch in anderen Projekten eingesetzt oder erweitert werden. Gerade bei Displays ist das praktisch, weil man häufig ähnliche Funktionen benötigt, etwa zum Anzeigen von Logos, Icons, Wettergrafiken oder Statusbildern.

Auch spätere Erweiterungen lassen sich so sauberer umsetzen. Das Waveshare Board besitzt beispielsweise einen SD-Karten-Slot, der in dieser Version noch nicht unterstützt wird. Da die Bildlogik aber bereits in einer eigenen Library gekapselt ist, kann diese Funktion später gezielt ergänzt werden, ohne den eigentlichen Beispielsketch unnötig aufzublähen.

Die Library findest du auf GitHub: https://github.com/StefanDraeger/lvgl-image-loader-esp32

So bleibt der Beispielcode nachvollziehbar und die Bildlogik sauber gekapselt.

Benötigte Komponenten

Für dieses Projekt benötigst du neben dem Waveshare ESP32-S3 RLCD 4.2 Display nur wenige zusätzliche Komponenten. Wichtig ist ein ESP32-Board mit ausreichend PSRAM, da die Bilddaten im Speicher verarbeitet werden.

Hardware

Für den Aufbau verwende ich:

- Waveshare ESP32-S3 RLCD 4.2 - USB-C Kabel - WLAN-Verbindung - PC mit Arduino IDE - Bilddatei auf einem Webserver oder GitHub

Das Waveshare Board eignet sich für dieses Projekt besonders gut, da es bereits einen ESP32-S3 mit PSRAM besitzt. Genau dieser zusätzliche Speicher ist wichtig, wenn Bilddaten geladen, zwischengespeichert und anschließend mit LVGL auf dem Display angezeigt werden sollen.

Warum PSRAM wichtig ist

Beim Anzeigen von Grafiken werden deutlich mehr Speicherressourcen benötigt als bei einfachen Textausgaben oder kleinen UI-Elementen. Die Bilddaten müssen zunächst geladen und anschließend so bereitgestellt werden, dass LVGL diese als Grafik anzeigen kann.

Ein ESP32 ohne ausreichend PSRAM kann hier schnell an seine Grenzen kommen. Deshalb richtet sich diese Library aktuell an Boards mit genügend Speicher, wie zum Beispiel das Waveshare ESP32-S3 RLCD 4.2.

Software

Auf der Softwareseite benötigst du:

- Arduino IDE - ESP32 Boardpaket - LVGL - Waveshare Display-Konfiguration aus Teil 2 - lvgl-image-loader-esp32 Library Hinweis zum Cheap Yellow Display

Das weit verbreitete Cheap Yellow Display ESP32-2432S028R wird von dieser Library derzeit nicht unterstützt.

Der Grund dafür ist, dass dieses Board in der bekannten Standardvariante nicht die gleichen Speicherreserven wie das Waveshare ESP32-S3 RLCD Board bietet. Für einfache LVGL-Oberflächen ist das Cheap Yellow Display weiterhin sehr interessant, für dieses konkrete Projekt mit dynamisch geladenen Grafiken aus dem Internet ist es aktuell jedoch nicht vorgesehen.

Der Fokus dieser Anleitung liegt daher klar auf dem Waveshare ESP32-S3 RLCD 4.2 Display beziehungsweise auf ESP32-Boards mit ausreichend PSRAM.

Vorbereitung der Grafiken

Bevor eine Grafik auf dem Waveshare ESP32-S3 RLCD 4.2 Display angezeigt wird, sollte sie möglichst gut für das Display vorbereitet werden. Das ist bei diesem Display besonders wichtig, da es sich nicht um ein klassisches Farbdisplay handelt.

Das RLCD Display kann nur Schwarz, Weiß und Graustufen darstellen. Grundsätzlich lassen sich damit auch Bilder mit Helligkeitsverläufen anzeigen, in der Praxis wirkt die Darstellung von Graustufen jedoch schnell etwas körnig. Besonders bei Fotos oder sehr detailreichen Grafiken fällt das deutlich auf.

farbiger Drache in SW auf RLCD Display von Waveshare

farbiger Drache

Die besten Ergebnisse erzielst du daher mit Grafiken, die möglichst klar auf Schwarz und Weiß reduziert sind.

schwarz/weiß Drache auf dem RLCD Display von Waveshare

Gut geeignet sind zum Beispiel:

- Logos - Icons - Piktogramme - einfache Symbole - kontrastreiche Grafiken

Weniger gut geeignet sind dagegen:

- Fotos mit vielen Details - Bilder mit weichen Farbverläufen - dunkle Motive - Grafiken mit feinen Graustufen - sehr kleine Schrift

Für dieses Projekt empfiehlt es sich daher, die Grafik bereits vorab passend aufzubereiten. Idealerweise wird das Bild auf die benötigte Größe skaliert und anschließend in ein klares Schwarz-Weiß-Bild umgewandelt. Dadurch wirkt die Darstellung auf dem RLCD Display deutlich sauberer und besser lesbar.

Die Auflösung des Displays beträgt 300 × 400 Pixel. Wenn du eine Grafik bildschirmfüllend anzeigen möchtest, sollte sie daher möglichst genau auf diese Größe vorbereitet werden. Kleinere Grafiken, Icons oder Logos können natürlich ebenfalls verwendet und später passend auf dem Display positioniert werden.

Besonders wichtig ist ein hoher Kontrast. Je klarer sich helle und dunkle Bereiche voneinander unterscheiden, desto besser wirkt das Ergebnis auf dem RLCD Display.

Library von GitHub einbinden

Die Library wird direkt über GitHub als ZIP-Datei heruntergeladen.

In der Arduino IDE wird die ZIP-Datei anschließend über folgenden Menüpunkt eingebunden:

Sketch > Bibliothek einbinden > .ZIP-Bibliothek hinzufügen...

Arduino IDE - ZIP Bibliothek einbinden

Nach der Installation muss im Sketch nur noch diese Include-Zeile ergänzt werden:

#include "lvgl_image_loader.h"

Damit steht die Library im Projekt zur Verfügung und kann für das Laden und Anzeigen der Grafiken verwendet werden.

Beispielcode Schritt für Schritt erklärt

Nachdem die Library eingebunden wurde, kann der eigentliche Sketch sehr übersichtlich gehalten werden. Wichtig sind im Wesentlichen drei Punkte: Die Library wird eingebunden, ein ImageLoader-Objekt wird erzeugt und anschließend wird die gewünschte Grafik geladen und auf einem LVGL-Objekt angezeigt.

kompletter Quellcode - Anzeigen von einem Bild auf dem RLCD Display von Waveshare /** * LvglImageLoader - Example for Waveshare RLCD 4.2" * * Hardware: * - Waveshare RLCD 4.2" (400x300) (https://www.waveshare.com/esp32-s3-rlcd-4.2.htm) * - ESP32-S3 with PSRAM * * Wiring: * - GPIO 12 → MOSI * - GPIO 11 → CLK * - GPIO 5 → CS * - GPIO 40 → DC * - GPIO 41 → RST */ #include "display_bsp.h" #include "src/app_bsp/lvgl_bsp.h" #include "src/ui_src/generated/gui_guider.h" #include #include #include "lvgl_image_loader.h" #define MOSI 12 #define SCL 11 #define DC 5 #define CS 40 #define RST 41 #define SCREEN_WIDTH 400 #define SCREEN_HEIGHT 300 const char *ssid = "YOUR_WIFI_SSID"; const char *password = "YOUR_WIFI_PASSWORD"; const char *imageUrl = "https://github.com/StefanDraeger/lvgl-image-loader-esp32/blob/main/images/drache.jpg?raw=true"; const int IMAGE_WIDTH = 300; const int IMAGE_HEIGHT = 300; DisplayPort RlcdPort(MOSI, SCL, DC, CS, RST, SCREEN_WIDTH, SCREEN_HEIGHT); LvglImageLoader imageLoader; static void Lvgl_FlushCallback(lv_display_t *drv, const lv_area_t *area, uint8_t *color_map) { uint16_t *buffer = (uint16_t *)color_map; for (int y = area->y1; y y2; y++) { for (int x = area->x1; x x2; x++) { uint8_t color = (*buffer < 0x7fff) ? ColorBlack : ColorWhite; RlcdPort.RLCD_SetPixel(x, y, color); buffer++; } } RlcdPort.RLCD_Display(); lv_disp_flush_ready(drv); } void setup() { Serial.begin(115200); RlcdPort.RLCD_Init(); Lvgl_PortInit(400, 300, Lvgl_FlushCallback); WiFi.begin(ssid, password); while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); } Serial.println("nVerbunden!"); if (Lvgl_lock(-1)) { // Screen vorbereiten lv_obj_t *screen = lv_scr_act(); lv_obj_set_style_bg_color(screen, lv_color_white(), LV_PART_MAIN); // Container mittig lv_obj_t *container = lv_obj_create(screen); lv_obj_set_size(container, IMAGE_WIDTH, IMAGE_HEIGHT); lv_obj_set_style_border_width(container, 0, LV_PART_MAIN); lv_obj_set_style_pad_all(container, 0, LV_PART_MAIN); lv_obj_set_style_bg_color(container, lv_color_white(), LV_PART_MAIN); lv_obj_center(container); // Bild laden imageLoader.loadImage(imageUrl, container, IMAGE_WIDTH, IMAGE_HEIGHT); Lvgl_unlock(); } } void loop() { vTaskDelay(pdMS_TO_TICKS(1000)); }

Zunächst wird die Library im Sketch eingebunden:

#include "lvgl_image_loader.h"

Danach wird ein Objekt der Library erzeugt:

LvglImageLoader imageLoader;

Dieses Objekt übernimmt später das Laden der Bilddatei und die Übergabe an LVGL.

Damit das Bild auf dem Display angezeigt werden kann, wird zunächst ein Container erstellt. Dieser Container dient als Zielbereich für die Grafik:

lv_obj_t *container = lv_obj_create(lv_scr_act()); lv_obj_set_size(container, 300, 300); lv_obj_center(container);

In diesem Beispiel wird der Container auf 300 × 300 Pixel gesetzt und mittig auf dem Display platziert. Das passt gut zu den zuvor vorbereiteten Beispielgrafiken.

Wichtig ist, dass der ESP32-S3 zu diesem Zeitpunkt bereits mit dem WLAN verbunden ist, da die Grafik über eine URL geladen wird.

Anschließend wird die Grafik über eine URL geladen:

imageLoader.loadImage("https://github.com/StefanDraeger/lvgl-image-loader-esp32/blob/main/images/drache.jpg?raw=true", container, 300, 300);

Die erste Angabe ist die URL zur Bilddatei. Danach folgt der LVGL-Container, in dem die Grafik angezeigt werden soll. Die letzten beiden Werte geben die gewünschte Breite und Höhe des Bildes an.

Die Library selbst unterstützt das Laden von JPEG-Bildern über HTTPS, nutzt PSRAM für den Bildpuffer und kann die Grafik für RLCD- beziehungsweise ePaper-ähnliche Displays in Graustufen umwandeln. Außerdem sind Wiederholungsversuche, Redirects und Timeouts vorgesehen.

Optional können die Verbindungsparameter angepasst werden:

imageLoader.setMaxRetries(3); imageLoader.setRetryDelay(5000); imageLoader.setTimeout(15000);

Damit lässt sich festlegen, wie oft ein Download erneut versucht wird, wie lange zwischen zwei Versuchen gewartet wird und wann ein Verbindungsversuch abgebrochen werden soll.

Für den Einstieg reicht der Ablauf aber bereits aus:

#include "lvgl_image_loader.h" LvglImageLoader imageLoader; lv_obj_t *container = lv_obj_create(lv_scr_act()); lv_obj_set_size(container, 300, 300); lv_obj_center(container); imageLoader.loadImage("https://github.com/StefanDraeger/lvgl-image-loader-esp32/blob/main/images/drache.jpg?raw=true", container, 300, 300);

Der eigentliche Sketch bleibt dadurch angenehm kurz. Die Display-Initialisierung und LVGL-Konfiguration stammen aus dem vorherigen Teil der Beitragsreihe. In diesem Abschnitt geht es nur noch darum, eine vorbereitete Grafik über eine URL zu laden und auf dem RLCD Display auszugeben.

Ergebnis auf dem RLCD Display

Nach dem Hochladen des Sketches verbindet sich der ESP32-S3 mit dem WLAN und lädt die hinterlegte Bilddatei aus dem Internet. Anschließend wird die Grafik über die Library verarbeitet und im LVGL-Container auf dem RLCD Display angezeigt.

In meinem Beispiel verwende ich eine Grafik mit 300 × 300 Pixeln, die mittig auf dem Display platziert wird. Dadurch bleibt rundherum noch etwas Abstand, und das Motiv wirkt nicht gequetscht.

schwarz/weiß Drache auf dem RLCD Display von Waveshare

Das Ergebnis zeigt, dass sich das Waveshare RLCD nicht nur für Texte oder UI-Elemente eignet, sondern auch für eigene Grafiken.

Aktuelle Einschränkungen

Die Library ist aktuell bewusst schlank gehalten und unterstützt derzeit nur JPEG-Bilder. Andere Bildformate wie PNG, BMP oder GIF werden in dieser Version noch nicht verarbeitet.

Außerdem werden die Bilder momentan ausschließlich von einem Webspace beziehungsweise über eine URL geladen. Das bedeutet: Die Grafik muss online erreichbar sein, damit der ESP32-S3 sie herunterladen und anschließend auf dem RLCD Display anzeigen kann.

Der vorhandene SD-Karten-Slot des Waveshare ESP32-S3 RLCD 4.2 wird in dieser Version noch nicht genutzt. Eine spätere Erweiterung, bei der Bilder direkt von der SD-Karte geladen werden können, ist jedoch geplant.

Ausblick & Fazit

Einfache Schwarz-Weiß-Bilder lassen sich auf dem Waveshare ESP32-S3 RLCD 4.2 gut darstellen. Besonders bei klaren Motiven wirkt das Ergebnis sauber und gut lesbar.

Im nächsten Beitrag geht es einen Schritt weiter: Ich zeige dir, wie du eine News von Tagesschau.de lädst und anschließend Text und Bild gemeinsam auf dem Display anzeigen kannst.

News auf dem RLCD Display von Waveshare

Damit wird aus der reinen Bildanzeige ein kleines Praxisprojekt für eine dynamische Informationsanzeige.

FAQ – Bilder auf dem Waveshare ESP32-S3 RLCD 4.2 anzeigen

Im ersten Teil habe ich mir das Board im Detail angeschaut und einen ersten Eindruck gesammelt. Jetzt wird es praktisch.

In diesem Beitrag zeige ich dir, wie du das ESP32-S3 RLCD Display von Waveshare ganz bequem mit der Arduino IDE programmierst und erste Inhalte auf dem Display darstellst.

Dank der Unterstützung von LVGL (Light and Versatile Graphics Library) ist der Einstieg überraschend einfach. Wenn du bereits Erfahrungen mit dem bekannten CYD (Cheap Yellow Display) gesammelt hast, wirst du dich hier sehr schnell zurechtfinden.

👉 Ziel ist es, nicht nur das Demo-Programm zu nutzen, sondern eigene Inhalte wie Text, Werte oder später sogar kleine Dashboards auf dem RLCD darzustellen.

https://youtu.be/-ohhYlIscEo

Transparenzhinweis: Das Gerät wurde mir von Waveshare für dieses Review kostenfrei zur Verfügung gestellt. Ich freue mich immer, wenn ich in dieser Form unterstützt werde und neue Hardware frühzeitig testen kann.

Selbstverständlich hat dies keinen Einfluss auf meine Bewertung – ich teile wie gewohnt meine ehrliche Meinung und praktische Erfahrungen mit dem Board.

Arduino IDE für das ESP32-S3 RLCD einrichten

Damit wir das Display programmieren können, müssen wir zunächst die Arduino IDE vorbereiten.

1. ESP32 Boardpaket installieren - Arduino IDE öffnen - Datei → Einstellungen - folgende URL hinzufügen: https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json 2. Board installieren - Werkzeuge → Board → Boardverwalter - nach ESP32 suchen - „esp32 by Espressif Systems“ installieren

Arduino IDE - einrichten der Boardtreiber für ESP32 von Espressif - Step1

Arduino IDE - einrichten der Boardtreiber für ESP32 von Espressif - Step2

Arduino IDE - einrichten der Boardtreiber für ESP32 von Espressif - Step3

Arduino IDE - einrichten der Boardtreiber für ESP32 von Espressif - Step4 3. Richtiges Board auswählen

Auf dem Board ist ein ESP32-S3 verbaut, somit wählen wir unter Werkzeuge > Boards > esp32 das Modul ESP32S3 Dev Module aus.

Arduino IDE - Auswahl des ESP32-S3

Arduino IDE - Konfiguration des ESP32-S3

Für serielle Ausgaben muss zusätzlich noch die Auswahl bei der Konfiguration "USB CDC On Boot" auf Enabled gesetzt werden.

4. Boardkonfiguration

Damit das Board korrekt angesteuert werden kann, müssen zunächst die richtigen Einstellungen in der Boardkonfiguration vorgenommen werden.

- USB CDC On Boot > Enabled - Flash Mode > "QIO 80 MHz" - Flash Size > "16MB (128Mb)" - Partition Scheme > "16M Falsh (3MB APP/9.9 FATS)" - PSRAM >"OPI PSRAM"

Wird diese Konfiguration nicht korrekt gesetzt, kommt es zu einem Assertion Error. Im seriellen Monitor der Arduino IDE erscheint dann folgende Fehlermeldung:

E (285) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0 E (294) esp_core_dump_elf: Elf write init failed! E (298) esp_core_dump_common: Core dump write failed with error=-1 Rebooting... ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT) Saved PC:0x4037f489 SPIWP:0xee mode:DIO, clock div:1 load:0x3fce2820,len:0x10cc load:0x403c8700,len:0xc2c load:0x403cb700,len:0x30c0 entry 0x403c88b8 assert failed: DisplayPort::DisplayPort(int, int, int, int, int, int, int, spi_host_device_t) C:UsersstefaDownloadsESP32-S3-RLCD-4.2-mainESP32-S3-RLCD-4.2-main�2_ExampleArduino�9_LVGL_V9_Test

Erstes Beispiel: „Hello World!“ auf dem RLCD anzeigen

Nachdem die Arduino IDE korrekt eingerichtet ist und das Board erkannt wird, starten wir mit einem einfachen ersten Beispiel.

👉 Ziel: Eine erste Ausgabe auf dem Display – unser klassisches „Hello World!“.

Als Grundlage nutze ich das von Waveshare bereitgestellte Beispielprojekt: 👉 09_LVGL_V9_Test

Dieses findest du im offiziellen Repository unter: ESP32-S3-RLCD-4.2/02_Example/Arduino/09_LVGL_V9_Test/

#include "display_bsp.h" #include "src/app_bsp/lvgl_bsp.h" #include "src/ui_src/generated/gui_guider.h" static lv_ui init_ui; DisplayPort RlcdPort(12, 11, 5, 40, 41, 400, 300); static void Lvgl_FlushCallback(lv_display_t *drv, const lv_area_t *area, uint8_t *color_map) { uint16_t *buffer = (uint16_t *)color_map; for (int y = area->y1; y y2; y++) { for (int x = area->x1; x x2; x++) { uint8_t color = (*buffer < 0x7fff) ? ColorBlack : ColorWhite; RlcdPort.RLCD_SetPixel(x, y, color); buffer++; } } RlcdPort.RLCD_Display(); lv_disp_flush_ready(drv); } void setup() { RlcdPort.RLCD_Init(); Lvgl_PortInit(400, 300, Lvgl_FlushCallback); if (Lvgl_lock(-1)) { create_hello_world_pyramid(); Lvgl_unlock(); } } void loop() { vTaskDelay(pdMS_TO_TICKS(1000)); } void create_hello_world_pyramid() { lv_obj_t *screen = lv_scr_act(); lv_obj_set_style_bg_color(screen, lv_color_white(), LV_PART_MAIN); lv_obj_set_style_bg_opa(screen, LV_OPA_COVER, LV_PART_MAIN); const lv_font_t *fonts = { &lv_font_montserrat_48, &lv_font_montserrat_40, &lv_font_montserrat_32, &lv_font_montserrat_24, &lv_font_montserrat_18, &lv_font_montserrat_12, }; int yPositions = { 25, 85, 135, 180, 220, 250 }; for (int i = 0; i < 6; i++) { lv_obj_t *label = lv_label_create(screen); lv_label_set_text(label, "Hello World!"); lv_obj_set_style_text_font(label, fonts, LV_PART_MAIN); lv_obj_set_style_text_color(label, lv_color_black(), LV_PART_MAIN); lv_obj_align(label, LV_ALIGN_TOP_MID, 0, yPositions); } } Zusätzliche Schriftgrößen in LVGL aktivieren

Für unser Beispiel möchten wir verschiedene Schriftgrößen verwenden. Standardmäßig sind in LVGL jedoch nicht alle Fonts aktiviert, um Speicher zu sparen.

👉 Deshalb müssen wir einige Schriftgrößen manuell freischalten.

Datei anpassen

Öffne die Datei:

C:UsersDocumentsArduinolibrarieslvgllv_conf.h

👉 Scrolle dort zum Abschnitt „FONT USAGE“.

Schriftgrößen aktivieren

Setze die folgenden Einträge von 0 auf 1:

#define LV_FONT_MONTSERRAT_12 1 #define LV_FONT_MONTSERRAT_14 1 #define LV_FONT_MONTSERRAT_16 1 #define LV_FONT_MONTSERRAT_18 1 #define LV_FONT_MONTSERRAT_24 1 #define LV_FONT_MONTSERRAT_32 1 #define LV_FONT_MONTSERRAT_40 1 #define LV_FONT_MONTSERRAT_48 1

👉 Dadurch werden die jeweiligen Schriftgrößen im Projekt verfügbar.

Hintergrund

LVGL ist so aufgebaut, dass nur die tatsächlich benötigten Ressourcen eingebunden werden. 👉 Das spart Speicher – ist aber am Anfang etwas ungewohnt.

Fazit: Einstieg geschafft – jetzt wird es spannend

Mit der richtigen Konfiguration in der Arduino IDE und der Einrichtung von LVGL ist der Einstieg in das Waveshare ESP32-S3 RLCD Display deutlich einfacher, als man zunächst vermuten würde.

👉 Bereits mit wenigen Zeilen Code lässt sich eine eigene Ausgabe auf dem Display realisieren.

Besonders positiv fällt dabei auf:

- LVGL ermöglicht eine sehr flexible Darstellung von Inhalten - das RLCD-Display reagiert schnell und ohne störendes Flackern - die Kombination aus ESP32-S3 und Display bietet eine starke Basis für eigene Projekte

Natürlich gibt es auch ein paar Stolpersteine – insbesondere bei der Boardkonfiguration und den benötigten Fonts. Hat man diese Hürden jedoch einmal genommen, steht eigenen Projekten nichts mehr im Weg.

👉 Genau hier wird es jetzt interessant.

Ausblick: Vom „Hello World“ zum echten Projekt

Im nächsten Schritt reicht ein statischer Text natürlich nicht mehr aus.

👉 Deshalb zeige ich dir im nächsten Beitrag ein konkretes Praxisprojekt:

- Daten aus einer öffentlichen API abrufen - Darstellung als Newsticker - Kombination aus Text und Bildern mit LVGL - Dynamische Aktualisierung der Inhalte

👉 Ziel: Ein echtes, praxisnahes Dashboard auf dem RLCD-Display.

Quellen & weiterführende Links

Für diesen Beitrag habe ich auf die offiziellen Dokumentationen und Beispiele von Waveshare zurückgegriffen. Wenn du tiefer in das Thema einsteigen möchtest, findest du hier die wichtigsten Ressourcen:

In diesem Tutorial zeige ich dir Schritt für Schritt, wie du den MAX30102 Sensor anschließt, programmierst und die Messwerte visualisierst.

Den MAX30100 habe ich bereits im Beitrag „MAX30100 am Arduino: Blutsauerstoff und Herzfrequenz messen leicht gemacht“ ausführlich vorgestellt. In diesem Beitrag gehen wir einen Schritt weiter und schauen uns den Nachfolger, den MAX30102, genauer an.

Du lernst dabei nicht nur, wie du die Werte für Herzfrequenz und Blutsauerstoff ausliest, sondern auch, wie du diese einfach und anschaulich darstellen kannst.

Außerdem werfen wir einen Blick darauf, welche Verbesserungen der MAX30102 gegenüber dem MAX30100 bietet und wie genau die gemessenen Werte in der Praxis sind.

https://youtu.be/rsCE1cKhRQk

Hinweis: Die Idee, mir den MAX30102 genauer anzuschauen, kam übrigens aus einem Kommentar unter meinem Beitrag zum MAX30100. Dort wurde ich gefragt, wie sich der neuere Sensor auslesen lässt.

Ein wichtiger Punkt dabei: Viele Bibliotheken, die für den MAX30100 gedacht sind, sind nicht ohne Weiteres mit dem MAX30102 kompatibel. Deshalb muss man zunächst eine passende Library finden und den Code entsprechend anpassen.

Solltest auch du Fragen, Probleme oder konkrete Wünsche zu einem Projekt haben, kannst du dich jederzeit gerne per E-Mail oder über mein Ticketsystem bei mir melden.

Was ist der MAX30102?

Der MAX30102 ist ein kompakter Sensor zur Messung der Herzfrequenz (Puls) und der Sauerstoffsättigung im Blut (SpO2). Solche Sensoren kommen häufig in Fitness-Trackern oder Smartwatches zum Einsatz und eignen sich auch hervorragend für eigene Mikrocontroller-Projekte mit Arduino oder ESP32.

Die Messung basiert auf dem Prinzip der sogenannten Pulsoximetrie. Dabei wird ausgenutzt, dass sauerstoffreiches und sauerstoffarmes Blut Licht unterschiedlich stark absorbieren.

Im Detail funktioniert das so: Der Sensor verfügt über eine rote und eine infrarote LED sowie eine Photodiode. Diese LEDs senden abwechselnd Licht durch das Gewebe (z. B. deinen Finger). Ein Teil des Lichts wird vom Blut absorbiert, während der Rest von der Photodiode erfasst wird.

👉 Der entscheidende Punkt:

- Sauerstoffreiches Blut absorbiert mehr Infrarotlicht - Sauerstoffarmes Blut absorbiert mehr rotes Licht

Aus dem Verhältnis dieser beiden Messungen kann der Sensor die Sauerstoffsättigung (SpO2) berechnen.

Zusätzlich nutzt der MAX30102 die kleinen Schwankungen im Blutfluss, die durch den Herzschlag entstehen. Dadurch lässt sich gleichzeitig die Herzfrequenz (BPM) bestimmen.

Technische Daten des MAX30102 Moduls

Bevor wir mit der Programmierung starten, werfen wir einen kurzen Blick auf die wichtigsten technischen Daten des MAX30102. Diese geben dir ein gutes Gefühl dafür, was der Sensor leisten kann und worauf du beim Einsatz achten solltest.

EigenschaftWertVersorgungsspannung3.3 – 5 VoltStromaufnahmemax. 20 mA (kontinuierlich)ADC Auflösung14 BitSchnittstelleI2CLogiklevel3.3VI2C Taktfrequenz0 – 400 kHzI2C Adresse (Write)0xAEI2C Adresse (Read)0xAFIR LED Wellenlänge870 – 900 nm (Peak: 880 nm)Red LED Wellenlänge650 – 670 nm (Peak: 660 nm)Temperatursensor Genauigkeit±1 °C bei 25 °CTemperaturbereich-40 °C bis +85 °CTemperatur Messdauerca. 29 msAbmessungen14 x 14 mm

Preis & Beschaffung

Den MAX30102 Sensor gibt es in unterschiedlichen Ausführungen. Häufig findet man Module mit der Aufschrift „MAX3010x“, die sowohl für den MAX30100 als auch den MAX30102 beworben werden.

MAX3010x und MAX30102 Sensor - Vergleich

Mit genau so einem Modul habe ich ebenfalls gestartet – allerdings ohne Erfolg. Der Sensor ließ sich nicht zuverlässig betreiben. Bei der Recherche in verschiedenen Foren bin ich auf ähnliche Erfahrungen gestoßen: Offenbar gibt es Varianten, bei denen die Beschaltung bzw. Spannungsversorgung nicht sauber umgesetzt ist.

Aus diesem Grund bin ich auf ein Modul mit der eindeutigen Bezeichnung MAX30102 gewechselt. Dieses habe ich bei https://www.androegg.de/shop/max30100-max30102-herzfrequenz-haemoglobin-sensor/ bezogen – und hier funktionierte der Sensor direkt ohne Probleme.

Preislich liegt das Modul bei rund 5 €. Damit ist es zwar kein absoluter „China-Billig-Sensor“, aber für Experimente und eigene Projekte definitiv eine solide Wahl.

Anschluss des MAX30102 am Arduino Nano

Der Anschluss des MAX30102 ist denkbar einfach, da der Sensor über die I2C-Schnittstelle kommuniziert.

Schaltung - MAX30102 Sensor am Arduino

Folgende Pins werden benötigt:

MAX30102Arduino NanoVIN3.3VGNDGNDSDAA4SCLA5INToptional Benötige Bauteile für den Aufbau der Schaltung

Im Grunde benötigst du für den Anschluss an einen Mikrocontroller lediglich:

- einen Mikrocontroller (zbsp. Arduino Nano, Arduino UNO), - vier Breadboardkabel, männlich-männlich, 10cm - ein 400 Pin Breadboard

Im späteren verlauf zeige ich dir noch wie man die Werte visualisiert, hier verwende ich dann:

- eine 8x8 LED Punkt Matrix, - fünf Breadboardkabel, männlich-weiblich, 10cm, sowie - einen Buzzer für den typischen Ton bei einem Herzschlag

Hinweis von mir: Die mit einem Sternchen (*) markierten Links sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision, die dazu beiträgt, diesen Blog zu unterstützen. Der Preis für dich bleibt dabei unverändert. Vielen Dank für deine Unterstützung!

Benötigte Bibliothek zum auslesen des MAX30102 Sensors in der Arduino IDE

Für den MAX30102 Sensor gibt es diverse Bibliotheken, am zuverlässigsten hat bei mir die MAX3010x-Sensor-Library von Daniel Weise funktioniert welche du entweder über den internen Bibliotheksverwalter der Arduino IDE installieren, oder vom GitHub Repository devxplained/MAX3010x-Sensor-Library als ZIP-Datei laden kannst.

Arduino IDE - MAX30102 Bibliothek installieren

Beispiel - visualisieren des Herzschlags sowie des Blutsauerstoffs im seriellen Plotter der Arduino IDE

Um die beiden Werte für Herzschlag und Blutsauerstoff im seriellen Plotter anzeigen zu lassen müssen wir die Werte für den seriellen Monitor leicht anpassen denn wir möchten zwei Linien im Plotter anzeigen lassen was ein definiertes Format benötigt.

Messwerte vom MAX30102 Sensor im seriellen Plotter der Arduino IDE

Vorher:

Serial.print("Heart Rate:"); Serial.println(average_bpm); Serial.print("SpO2: "); Serial.println(average_spo2);

Nachher:

Serial.print("HeartRate:"); Serial.println(average_bpm); Serial.print("SpO2:"); Serial.println(average_spo2);

Zusätzlich müssen wir noch im Setup die If-Bedingung anpassen damit die Ausgabe "Sensor initialized" nicht mehr erscheint, denn diese würde als zusätzliche Linie (jedoch ohne Werte) erscheinen.

Mit dem Unit CardKB2 bringt M5Stack eine spannende Weiterentwicklung seiner kompakten Mini-Tastatur auf den Markt. Während die Vorgängerversion noch als einfache I2C-Tastatur diente, steckt im neuen Modell nun ein vollwertiger ESP32-C61 Mikrocontroller.

Die typische Bauform im Checkkartenformat ist dabei erhalten geblieben – doch unter der Haube hat sich einiges getan. Das CardKB2 verspricht erstmals einen echten Standalone-Betrieb und eröffnet damit völlig neue Einsatzmöglichkeiten – von einfachen Eingabegeräten bis hin zu kleinen IoT-Projekten.

Dank integrierter Shortcuts lässt sich das Modul zudem direkt „out of the box“ als Bluetooth-Keyboard nutzen. Alles, was du dafür benötigst, ist eine passende Stromquelle.

Doch wie viel Potenzial steckt wirklich in dieser kleinen Tastatur – und wie sieht es in der Praxis mit der Programmierung aus?

Genau das zeige ich dir in diesem Beitrag.

https://youtu.be/n_-So8hmG9E

Transparenzhinweis: Das M5Stack Unit CardKB2 habe ich selbst gekauft. Es besteht keine Kooperation mit dem Hersteller.

Was ist neu – und warum ist das spannend?

Was auf den ersten Blick wie eine einfache Weiterentwicklung wirkt, ist in Wirklichkeit ein ziemlich großer Schritt.

Beim ursprünglichen CardKB handelte es sich um eine reine I2C-Tastatur. Die Eingaben wurden an einen Mikrocontroller weitergereicht – das Modul selbst war dabei eher „dumm“ und hatte keine eigene Logik.

M5Stack Unit CardKB2 - kleines QWERTY Keyboard mit ESP32-C61 Chip

M5Stack Unit CardKB2 - Rückseite mit Pinout und Layout

M5Stack Unit CardKB2 - Verpackt

Beim CardKB2 sieht das komplett anders aus.

Hier sitzt nun ein vollwertiger ESP32-C61 direkt auf dem Board. Damit kann das Modul nicht nur Eingaben erfassen, sondern diese auch selbst verarbeiten, speichern oder über verschiedene Schnittstellen weiterleiten.

Aus einer einfachen Tastatur wird damit ein eigenständiges System.

Genau das macht das CardKB2 so spannend: Es ist nicht mehr nur ein Zubehör für ein Projekt, sondern kann selbst zum zentralen Bestandteil werden.

Ob als Eingabegerät für ein IoT-System, als kleines Steuer-Interface oder sogar als eigenständiges Bluetooth-Keyboard – die Einsatzmöglichkeiten sind deutlich vielseitiger als beim Vorgänger.

Erster Eindruck & Verarbeitung

Auf den ersten Blick bleibt sich M5Stack treu: Das CardKB2 kommt weiterhin im kompakten Checkkartenformat daher und wirkt insgesamt sauber verarbeitet.

Auffällig ist jedoch direkt die überarbeitete Tastatur. Im Vergleich zum Vorgänger sind die Tasten etwas größer ausgefallen, was die Bedienung deutlich angenehmer macht – gerade wenn man das Modul tatsächlich zum Tippen nutzt und nicht nur einzelne Eingaben ausführt.

Abmasse neue CardKB2 Unit von M5Stack

Abmasse alte CardKB I2C Unit von M5Stack

Das Layout entspricht einem klassischen QWERTY-Keyboard, also der amerikanischen Variante. Für viele Anwendungen ist das kein Problem, im Alltag muss man sich jedoch unter Umständen kurz umgewöhnen.

Eine Änderung fällt allerdings eher negativ auf: Die Navigationstasten sind nicht mehr separat vorhanden, sondern nur noch über die FN-Taste erreichbar. Das spart zwar Platz, macht die Bedienung in bestimmten Situationen aber etwas umständlicher.

Insgesamt hinterlässt das CardKB2 dennoch einen soliden ersten Eindruck – vor allem durch die verbesserten Tasten, die im direkten Vergleich zum Vorgänger ein echtes Upgrade darstellen.

Betriebsmodi des CardKB2

Bevor wir uns die Programmierung anschauen, lohnt sich ein Blick auf die verschiedenen Betriebsmodi des CardKB2. Denn im Gegensatz zur Vorgängerversion ist das Modul nicht mehr nur auf eine einzige Funktion beschränkt.

Die Umschaltung zwischen den Modi erfolgt direkt über Tastenkombinationen auf dem Gerät – ein erneutes Flashen ist dafür nicht notwendig.

Verfügbare Modi

Wichtig: Für die Nutzung dieser Modi muss das CardKB2 selbst nicht neu programmiert werden. Die Funktionen sind bereits in der vorhandenen Firmware enthalten. Du wählst lediglich den gewünschten Modus über die entsprechende Tastenkombination aus.

ModusTastenkombinationEinsatzI2CFn + Sym + 1Klassische Mikrocontroller-AnbindungUARTFn + Sym + 2Serielle Tastenevents über GroveESP-NOWFn + Sym + 3Drahtlose Verbindung zu ESP32-GerätenBluetooth HIDFn + Sym + 4Nutzung als Bluetooth-Tastatur

Die eigentliche Verarbeitung der Daten erfolgt anschließend auf dem verbundenen Gerät – also zum Beispiel auf dem Smartphone, einem Arduino oder einem ESP32.

Bluetooth-Keyboard Modus

Der wohl coolste Modus ist die Nutzung als Bluetooth-Tastatur. Dafür benötigt man unterwegs lediglich eine Powerbank – und idealerweise noch ein kleines Gehäuse, das das Board vor Stößen schützt.

- Das CardKB2 verhält sich wie ein klassisches Bluetooth-Keyboard - Verbindung mit: - Smartphone - Tablet - PC - keine zusätzliche Hardware notwendig - Stromversorgung über USB-C reicht aus

👉 Einstellung:

- über definierte Tastenkombination > Fn + Sym + 4 - anschließend Gerät per Bluetooth koppeln

M5Stack CardKB2 als Bluetooth Tastatur am Android Gerät I2C-Keyboard Modus

Den I2C-Modus habe ich in diesem Beitrag bewusst nur kurz eingeordnet, da er am ehesten dem Verhalten des ursprünglichen CardKB entspricht. Der Fokus liegt hier auf den neuen Möglichkeiten durch Bluetooth, UART und ESP-NOW.

- klassischer Modus wie beim alten CardKB - Tastenanschläge werden per I2C an einen Mikrocontroller gesendet - ideal für: - Arduino - ESP32 Projekte

👉 Einstellung:

- per Tastenkombination aktivieren > Fn + Sym + 1 - anschließend über I2C ansprechen Serial / UART Modus - Ausgabe der Tasteneingaben über serielle Schnittstelle - ideal für: - Debugging - einfache Terminal-Anwendungen

👉 Einstellung:

- per Tastenkombination wechseln > Fn + Sym + 2 - Daten über UART auslesen

M5Stack CardKB2 via serial mit dem Arduino verbunden - UART Modus ESP-NOW Modus - drahtlose Kommunikation ohne WLAN-Router - direkte Verbindung zu einem anderen ESP32-Gerät - sehr geringe Latenz - ideal für: - Fernsteuerungen - einfache Eingabesysteme - IoT-Projekte ohne Netzwerk

👉 Einstellung:

- per Tastenkombination aktivieren > Fn + Sym + 3 - Gegenstelle (z. B. ESP32) muss entsprechend vorbereitet sein

M5Stack CardKB2 und ESP32-C3 mit OLED Display - ESP-NOW Modus

Praxisbeispiel: CardKB2 per ESP-NOW mit einem ESP32-C3 verbinden

Nachdem die Betriebsmodi geklärt sind, wird es nun praktisch. Für mein erstes Beispiel nutze ich den ESP-NOW Modus des CardKB2. Dabei wird das Keyboard nicht per Kabel mit dem Empfänger verbunden, sondern sendet die Tasteneingaben drahtlos an einen anderen ESP32.

Programm: M5Stack Unit CardKB2 sendet Daten via ESP-NOW an ESP32-C3 Super MiniHerunterladen

In meinem Aufbau kommt ein ESP32-C3 Super Mini mit einem kleinen OLED-Display zum Einsatz. Das CardKB2 dient dabei als drahtlose Eingabeeinheit, während der ESP32-C3 die empfangenen Daten auswertet und auf dem Display darstellt.

Aufbau - M5Stack CardKB2 via ESP-NOW am ESP32-C3 Super Mini mit OLED Display

Das Spannende daran: Auf dem CardKB2 selbst muss dafür nichts programmiert werden. Es reicht aus, den passenden Modus über die Tastatur zu aktivieren.

Fn + Sym + 3

Danach sendet das CardKB2 seine Tastenevents automatisch per ESP-NOW als Broadcast. Der Empfänger muss lediglich so programmiert werden, dass er diese Pakete empfängt und auswertet.

Aufbau des Praxisbeispiels

Für dieses Beispiel verwende ich folgende Komponenten:

- M5Stack Unit CardKB2 - ESP32-C3 Super Mini - OLED-Display via I2C - USB-Kabel zur Stromversorgung und Programmierung des ESP32-C3

Das CardKB2 benötigt lediglich eine Stromversorgung über USB-C. Eine direkte Verbindung zwischen CardKB2 und ESP32-C3 ist nicht notwendig.

Schaltung - ESP32-C3 mit OLED Display

Für die Schaltung ESP32-C3 mit OLED Display benötigst du:

- 1x ESP32-C3 Super Mini*, - 1x 1,3" OLED Display* (I2C), - 1x 400 Pin Breadboard*, - 4x Breadboardkabel*, 10cm, männlich-männlich

Schaltung - ESP32 mit OLED Display via I2C

Hinweis von mir: Die mit einem Sternchen (*) markierten Links sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision, die dazu beiträgt, diesen Blog zu unterstützen. Der Preis für dich bleibt dabei unverändert. Vielen Dank für deine Unterstützung!

Was wird übertragen?

Im ESP-NOW Modus werden keine fertigen Buchstaben übertragen. Stattdessen sendet das CardKB2 strukturierte Datenpakete. Das Format entspricht dabei dem UART-Modus:

AA

Die einzelnen Werte bedeuten:

WertBedeutungAAStartbyte des DatenpaketsDATA_LENDatenlänge, fest auf 0x03KEY_IDID der gedrückten TasteKEY_STATEZustand der Taste: gedrückt oder losgelassenCHECKSUMPrüfsumme zur Kontrolle des Pakets

Gerade dieser Punkt ist wichtig: Das CardKB2 sendet im ESP-NOW Modus also nicht einfach ein a, b oder c, sondern die Position der gedrückten Taste auf der Tastaturmatrix.

Die eigentliche Übersetzung von KEY_ID zu einem lesbaren Zeichen erfolgt daher im Code des Empfängers.

Warum ein eigenes Key-Mapping notwendig ist

Damit aus einer empfangenen KEY_ID wieder ein echter Buchstabe wird, habe ich mir eine eigene Keymap erstellt. Diese ordnet jeder Taste den passenden Wert zu.

Zusätzlich müssen Sonderfunktionen wie Aa für Großbuchstaben oder Sym für Sonderzeichen im Code behandelt werden. Das CardKB2 übernimmt diese Logik im ESP-NOW Modus nicht automatisch.

Das klingt zunächst etwas aufwendiger, hat aber auch einen Vorteil: Man kann selbst bestimmen, was bei welcher Taste passieren soll. Dadurch eignet sich das CardKB2 nicht nur als Tastatur, sondern auch als frei definierbare Fernbedienung für eigene Projekte.

Wichtig: Die KEY_ID entspricht nicht automatisch dem sichtbaren Zeichen auf der Taste. Sie basiert auf der Position in der Tastaturmatrix. Da nicht jede Position belegt ist, ist in meiner Keymap auch ein leerer Platzhalter enthalten. Ohne diesen Platzhalter wären die folgenden Tasten verschoben.

Den Shelly Plus 1PM habe ich auf meinem Blog bereits in mehreren Beiträgen vorgestellt. In meinem Fall ist das Gerät an meinem Balkonkraftwerk (BKW) angeschlossen, sodass ich darüber jederzeit die aktuelle Leistung sowie den Energieverbrauch ablesen kann.

Über die App Shelly Smart Control oder die Cloudlösung von Shelly funktioniert das grundsätzlich sehr einfach. Sobald man jedoch mehrere Werte gleichzeitig auswerten oder übersichtlich darstellen möchte, stößt die App schnell an ihre Grenzen.

Shelly selbst bietet mit dem Shelly Wall Display zwar eine Lösung an, allerdings ist dieses mit aktuell über 130 € nicht gerade günstig.

In dieser Beitragsreihe zeige ich dir daher eine deutlich flexiblere und kostengünstigere Alternative. Mit Node-RED und der gut dokumentierten Shelly API bauen wir uns Schritt für Schritt ein eigenes Energie-Dashboard, über das sich Leistungsdaten speichern, auswerten und später auch grafisch darstellen lassen.

https://youtu.be/fD2mbJ2gjpI

Im ersten Teil legen wir dafür die Grundlage: Wir erstellen eine SQLite-Datenbank, importieren vorhandene Daten und lernen, wie sich diese anschließend wieder abrufen lassen.

Node-RED Flows zum erstellen eines Shelly Dashboards

Aufbau der Lösung

Damit wir ein eigenes Energie-Dashboard erstellen können, benötigen wir zunächst eine Möglichkeit, die Leistungsdaten des Shelly dauerhaft zu speichern. Über die API lassen sich bei vielen Shelly-Geräten aktuelle Werte direkt abrufen. Eine Schnittstelle für historische Energiedaten ist jedoch nicht bei allen Modellen verfügbar.

Geräte wie der Shelly EM (Mini) oder Shelly Pro 3EM sind für Energie-Monitoring ausgelegt und bieten dafür deutlich mehr Möglichkeiten. Diese Modelle sind allerdings – je nach Ausführung – auch spürbar teurer. Beim Shelly Plus 1PM, den ich an meinem Balkonkraftwerk einsetze, lassen sich die bereits gesammelten historischen Daten nicht einfach per API abrufen.

Aus diesem Grund verfolgen wir in dieser Reihe folgenden Ansatz:

- Bereits vorhandene Daten werden zunächst einmalig als CSV-Datei exportiert. - Diese Daten importieren wir anschließend in eine lokale SQLite-Datenbank. - Über Node-RED können wir die gespeicherten Daten später wieder abrufen und für Auswertungen oder Diagramme verwenden.

Die Architektur unseres Projekts sieht daher wie folgt aus:

Schemata der Architektur - Shelly & Node-RED

Der große Vorteil dieses Ansatzes ist, dass alle Daten lokal im eigenen Netzwerk gespeichert werden. Es ist keine Cloud-Anbindung notwendig und du behältst jederzeit die volle Kontrolle über deine Messwerte.

Im nächsten Schritt installieren wir die benötigten SQLite-Nodes für Node-RED und erstellen anschließend unsere erste Datenbank.

SQLite auf dem Raspberry Pi installieren

Damit Node-RED die Energiedaten speichern kann, benötigen wir zunächst eine lokale Datenbank. Für dieses Projekt verwende ich SQLite, da diese Datenbank besonders leichtgewichtig ist und ohne zusätzlichen Server direkt auf dem Raspberry Pi betrieben werden kann.

SQLite eignet sich hervorragend für kleinere Projekte oder Zeitreihen wie Energie- und Leistungsdaten, da die komplette Datenbank einfach in einer Datei gespeichert wird.

Zuerst aktualisieren wir das System:

sudo apt update sudo apt upgrade

Anschließend installieren wir SQLite:

sudo apt install sqlite3

Nach der Installation können wir prüfen, ob SQLite korrekt installiert wurde:

sqlite3 --version

Die Ausgabe sollte ungefähr so aussehen:

Ausgabe SQLite Versionsnummer

Damit ist SQLite erfolgreich auf dem Raspberry Pi installiert und einsatzbereit.

SQLite Datenbank erstellen

Nun erstellen wir eine erste Datenbank für unsere Energiedaten. Dazu wechseln wir zunächst in das Node-RED Verzeichnis:

cd ~/.node-red

Jetzt können wir eine neue Datenbank erstellen:

sqlite3 shelly-energy.db

SQLite erstellt die Datei automatisch, falls sie noch nicht existiert. Wir befinden uns nun in der SQLite Konsole, in der wir SQL-Befehle ausführen können.

Die Eingabeaufforderung sieht dann so aus:

SQLite Datenbank anlegen

m nächsten Schritt legen wir eine Tabelle an, in der später die Leistungsdaten des Shelly gespeichert werden.

Tabelle für den CSV-Import anlegen

Da der CSV-Export des Shelly in meinem Fall einen Zeitstempel sowie den Energieverbrauch in Wh enthält, lege ich dafür zunächst eine eigene Tabelle in der SQLite-Datenbank an.

Innerhalb der SQLite-Konsole führe ich dazu folgenden SQL-Befehl aus:

CREATE TABLE shelly_energy_monthly ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, energy_wh REAL NOT NULL );

Exportieren der historischen Daten aus der Shelly Cloud

Zunächst exportieren wir die historischen Energiedaten aus der Shelly Cloud. Diese Daten dienen als Grundlage für unsere Datenbank, damit wir nicht bei Null beginnen müssen. In meinem Beispiel exportiere ich die Daten der letzten 12 Monate im CSV-Format.

Mit etwas zusätzlichem Aufwand lassen sich auch Daten über einen längeren Zeitraum exportieren. Der grundlegende Ablauf bleibt jedoch identisch.

Schritt 1: Anmeldung in der Shelly Cloud

Melde dich zunächst in der Shelly Cloud unter folgendem Link an: https://control.shelly.cloud/

Nach der Anmeldung erscheint die Übersicht deiner Geräte. Wähle dort das entsprechende Gerät aus. In meinem Fall ist der Shelly Plus 1PM, der an meinem Balkonkraftwerk angeschlossen ist und daher auch entsprechend als „Balkonkraftwerk“ bezeichnet wurde.

Schritt 2: Energieverbrauch öffnen

Auf der rechten Seite der Geräteübersicht findest du ein kleines Liniendiagramm, das den Energieverbrauch visualisiert. Klicke auf dieses Diagramm, um die detaillierte Verbrauchsansicht zu öffnen.

Anschließend aus der Auswahlliste den Eintrag "Letzte 12 Monate" auswählen.

Schritt 3: CSV-Export starten

Oben im Diagramm befindet sich neben der Beschriftung „Verbrauch“ ein Menü mit drei Punkten.

Öffnest du dieses Menü, findest du dort die Option:

„CSV exportieren“

Mit einem Klick darauf wird der Download der CSV-Datei gestartet.

Damit liegen dir nun die historischen Verbrauchsdaten vor, die wir im nächsten Schritt in unsere SQLite-Datenbank importieren werden.

CSV-Daten importieren

Nachdem wir die historischen Daten aus der Shelly Cloud exportiert haben, können wir diese nun in unsere SQLite-Datenbank importieren. Bevor wir den Import in Node-RED umsetzen, lohnt sich jedoch ein kurzer Blick in die CSV-Datei.

Öffnet man die Datei beispielsweise mit einem Editor wie Notepad++, fällt auf, dass diese zwei Datenblöcke enthält:

- Verbrauchsdaten - Einspeisedaten

Diese beiden Abschnitte stehen untereinander in der CSV-Datei.

In meinem Fall ist der Shelly Plus 1PM an einem Balkonkraftwerk angeschlossen. Da der Shelly jedoch nicht erkennt, dass Energie in das Netz eingespeist wird, werden die relevanten Werte im Abschnitt „Verbrauch“ gespeichert. Der darunter liegende Block zur Einspeisung ist für unser Projekt daher nicht relevant.

Möglichkeit 1: CSV-Datei vorher bereinigen (empfohlen)

Der einfachste Weg besteht darin, die CSV-Datei mit einem Editor wie Notepad++ zu öffnen und den unteren Block mit den Einspeisedaten zu entfernen. Sowie entfernen wir noch die Leerzeichen um die Spaltenüberschriften Zeit und Wh sowie vor den Datenzeilen. Die Datei enthält danach nur noch die benötigten Verbrauchsdaten.

Der Vorteil dieser Variante ist, dass der Node-RED Flow deutlich einfacher bleibt, da wir nur noch einen einheitlichen Datensatz importieren müssen.

Möglichkeit 2: Aufbereitung direkt in Node-RED

Alternativ könnte man die CSV-Datei auch komplett importieren und anschließend im Node-RED Flow nur die relevanten Datensätze herausfiltern. Diese Variante funktioniert ebenfalls, erhöht jedoch die Komplexität des Flows, da zusätzliche Filter- oder Function-Nodes benötigt werden.

Da es sich in diesem Beitrag um einen einmaligen Import historischer Daten handelt, entscheide ich mich für die erste Variante und bereinige die CSV-Datei vor dem Import.

Node-RED Palette erweitern

Damit Node-RED Daten in unsere SQLite-Datenbank schreiben kann, benötigen wir zunächst eine passende Node. Standardmäßig bringt Node-RED keine direkte Unterstützung für SQLite mit, diese kann jedoch sehr einfach über den Palette Manager nachinstalliert werden.

Öffne dazu zunächst das Menü in der Node-RED Oberfläche. Dieses findest du oben rechts hinter dem Symbol mit den drei horizontalen Strichen.

In dem sich öffnenden Menü wählst du anschließend den Eintrag „Palette erweitern“ aus.

Über diesen Dialog lassen sich zusätzliche Nodes installieren, die den Funktionsumfang von Node-RED erweitern. In unserem Fall benötigen wir eine Node, mit der sich SQL-Abfragen an eine SQLite-Datenbank senden lassen.

Im neu geöffneten Dialog wählst du nun den Reiter „Installation“ aus. In diesem Bereich lassen sich zusätzliche Erweiterungen für Node-RED suchen und direkt installieren.

Im Reiter „Installation“ suchen wir nun nach dem Paket node-red-node-sqlite. Sobald das Paket in der Liste erscheint, klicken wir auf „Installieren“, um die Erweiterung zu Node-RED hinzuzufügen.

Im nun erscheinenden Bestätigungsdialog klicken wir erneut auf „Installieren“, um die Installation des Pakets zu starten.

Sobald die Installation abgeschlossen ist, steht im Node-RED Editor eine neue Node mit der Bezeichnung „sqlite“ zur Verfügung. Diese findest du in der linken Node-Auswahl im Bereich „Speicher“.

Node-RED - SQLite Node

Kommunikation mit der SQLite-Datenbank testen

Bevor wir die CSV-Daten importieren, prüfen wir zunächst, ob die Kommunikation zwischen Node-RED und der SQLite-Datenbank korrekt funktioniert.

Dazu erstellen wir einen kleinen Test-Flow. Wir verwenden eine Inject Node, um ein einfaches SQL-Statement an die SQLite-Node zu übergeben. Dieses Statement liefert den aktuellen Zeitstempel der Datenbank zurück.

In der Inject Node tragen wir dazu folgenden Wert für msg.topic ein:

SELECT datetime('now');

Die Inject Node wird anschließend mit der sqlite Node verbunden. Zusätzlich verbinden wir die sqlite Node mit einer Debug Node, um das Ergebnis anzeigen zu lassen.

SQLite-Node konfigurieren

Bevor wir das SQL-Statement ausführen können, muss die sqlite Node noch konfiguriert werden. Da SQLite-Datenbanken direkt in Dateien gespeichert werden, müssen wir der Node zunächst mitteilen, wo sich unsere Datenbank befindet.

Öffne dazu die sqlite Node per Doppelklick und trage im Feld Datenbank den Pfad zur Datenbankdatei ein.

In meinem Fall lautet der Pfad:

/root/.node-red/shelly-energy.db

Dieser Pfad zeigt auf die SQLite-Datenbank, die wir zuvor auf dem Raspberry Pi erstellt haben. Sobald der Pfad eingetragen ist, kann die sqlite Node SQL-Abfragen an diese Datenbank senden und die Ergebnisse wieder an den Flow zurückgeben.

Nach dem Speichern der Einstellungen ist die sqlite Node bereit, um das zuvor erstellte Test-Statement auszuführen.

Der Test-Flow sieht damit so aus:

Flow zum abrufen eines Zeitstempels aus der SQLite Datenbank via SQL Statement

Im letzten Beitrag habe ich dir gezeigt, wie du in Node-RED unter Docker eine SQLite-Datenbank anbindest und über ein Formular erste Daten bequem in die Datenbank schreiben kannst. Genau auf diesem Aufbau setzen wir nun auf und erweitern den bestehenden Flow um eine praktische Funktion: den Versand eines Newsletters.

Dafür lesen wir Daten aus einer CSV-Datei ein, speichern diese in der Datenbank und nutzen die hinterlegten Informationen anschließend, um E-Mails gezielt an Empfänger zu versenden. Damit das sauber funktioniert, muss unsere bestehende Tabelle zunächst um zwei zusätzliche Spalten erweitert werden: eine für die E-Mail-Adresse und eine weitere, um festzuhalten, ob der Newsletter für diesen Kontakt aktiv ist.

So schaffen wir die Grundlage, um in Node-RED einen einfachen Newsletter-Workflow aufzubauen, der auf bereits vorhandenen Daten aufsetzt und sich gut erweitern lässt.

https://youtu.be/J_ZCMELdAkA

So funktioniert der Newsletter-Flow in Node-RED

Ziel dieses Beitrags ist es, einen einfachen Newsletterversand mit Node-RED umzusetzen. Der große Vorteil dabei: Du musst keine klassische Programmierung beherrschen, da wir ausschließlich mit visuellen Funktionsblöcken arbeiten und diese zu einem funktionierenden Flow verbinden.

Node-RED Flow zum absenden eines Newsletters mit Daten aus einer Datenbank

Das Szenario ist bewusst praxisnah gewählt: Du erhältst beispielsweise eine Excel-Liste mit Kontaktdaten (z. B. aus dem Vertrieb) sowie einen vorbereiteten Newsletter-Text mit Platzhaltern wie Vorname, Nachname oder Anrede.

Der Ablauf des Workflows sieht dabei wie folgt aus:

- Die Excel-Datei wird als CSV exportiert und in Node-RED importiert - Die enthaltenen Daten werden in einer SQLite-Datenbank gespeichert - Per Knopfdruck wird der Newsletter-Versand gestartet - Es werden nur Kontakte berücksichtigt, bei denen der Newsletter aktiv ist - Der Newsletter wird personalisiert (z. B. „Hallo Max“) versendet

Ein wichtiger Bestandteil eines jeden Newsletters ist außerdem die Möglichkeit zur Abmeldung. Daher enthält jede E-Mail einen Abmelde-Link, über den sich Empfänger einfach aus dem Verteiler austragen können. Im Hintergrund wird dabei der entsprechende Datensatz automatisch deaktiviert.

Mit diesem Ansatz entsteht ein einfacher, aber flexibler Newsletter-Workflow, der sich beliebig erweitern lässt und komplett lokal betrieben werden kann.

Flow zum absenden eines NewslettersHerunterladen

Datenbasis vorbereiten

Als Grundlage für unseren Newsletter benötigen wir zunächst eine einfache Liste mit Kontaktdaten. In der Praxis erhält man diese häufig als Excel-Datei (XLSX), zum Beispiel aus dem Vertrieb oder einem CRM-System.

Da Node-RED CSV-Dateien sehr gut verarbeiten kann, wird die Excel-Datei im ersten Schritt als CSV-Datei exportiert. Das funktioniert in Excel mit wenigen Klicks („Speichern unter“ → CSV-Format).

Unsere CSV-Datei enthält folgende Spalten:

Vorname;Nachname;Anrede;Strasse;Postleitzahl;Ort;E-Mail Adresse;Newsletter aktiv

Diese Struktur bildet die Grundlage für unseren späteren Newsletter-Versand.

- Vorname / Nachname → für die Personalisierung - Anrede → z. B. „Herr“ oder „Frau“ - E-Mail Adresse → Zieladresse für den Versand - Newsletter aktiv → steuert, ob ein Kontakt angeschrieben wird (1 = aktiv, 0 = deaktiviert) Vorname;Nachname;Anrede;Strasse;Postleitzahl;Ort;E-Mail Adresse;Newsletter aktiv Max;Mustermann;Herr;Musterstraße 1;10115;Berlin;[email protected];1 Anna;Schmidt;Frau;Hauptstraße 12;20095;Hamburg;[email protected];1 Peter;Müller;Herr;Gartenweg 5;80331;München;[email protected];0 Lisa;Fischer;Frau;Bahnhofstraße 22;50667;Köln;[email protected];1 Thomas;Weber;Herr;Schillerstraße 8;70173;Stuttgart;[email protected];0

Wichtig: Die CSV-Datei verwendet in unserem Fall ein Semikolon (;) als Trennzeichen, was insbesondere im deutschen Excel-Umfeld üblich ist.

Im nächsten Abschnitt werden wir die Datenbank entsprechend vorbereiten. Dabei fügen wir die benötigten Felder für Anrede, E-Mail-Adresse und den Newsletter-Status hinzu, damit diese Informationen später im Flow verarbeitet werden können.

Datenbank erweitern

Damit wir die zusätzlichen Informationen aus der CSV-Datei verarbeiten können, müssen wir unsere bestehende Tabelle in der SQLite-Datenbank erweitern. Konkret fügen wir drei neue Spalten hinzu:

- Anrede - E-Mail Adresse - Newsletter aktiv

Dies kann entweder direkt über die Bash erfolgen oder alternativ einmalig über einen Node-RED Flow.

Variante 1: Erweiterung per SQL (Bash)

Die einfachste Möglichkeit ist, die Tabelle über ein ALTER TABLE Statement zu erweitern:

ALTER TABLE personen ADD COLUMN anrede TEXT; ALTER TABLE personen ADD COLUMN email TEXT; ALTER TABLE personen ADD COLUMN newsletter_active INTEGER DEFAULT 0;

Hinweis:

- newsletter_active wird als Integer gespeichert (0 = deaktiviert, 1 = aktiv) - Ein Default-Wert verhindert Probleme bei bestehenden Datensätzen

SQLite ALTER TABLE Statements für die Tabelle personen für den Newsletterversand Variante 2: Erweiterung über Node-RED

Alternativ kannst du die SQL-Statements auch über einen kleinen Flow in Node-RED ausführen:

- Inject-Node (einmalig auslösen) - Function-Node (setzt das SQL Statement in msg.topic) - SQLite-Node (führt das Statement aus)

Node-RED - Flow zum ändern der Tabelle in der SQLite Datenbank Node-RED Flow zum ausführen eines Statements auf der SQLite DatenbankHerunterladen Variante 3: Tabelle neu erstellen (CREATE TABLE)

Falls du direkt mit diesem Beitrag startest, kannst du die Tabelle auch komplett neu anlegen:

DROP TABLE IF EXISTS personen; CREATE TABLE personen ( id INTEGER PRIMARY KEY AUTOINCREMENT, vorname TEXT, nachname TEXT, anrede TEXT, strasse TEXT, postleitzahl TEXT, ort TEXT, email TEXT, newsletter_active INTEGER DEFAULT 0 );

Damit hast du direkt die komplette Struktur für unseren Newsletter-Flow vorbereitet.

SQLite Bash - ersetzen der Tabelle personen

CSV in Node-RED einlesen

Da ein Newsletter in der Regel nicht nur einmal versendet wird, sondern regelmäßig neue Empfängerlisten eingelesen werden sollen, bietet sich für diesen Schritt eine möglichst einfache und flexible Lösung an. Besonders praktisch ist hier ein Formular im Node-RED Dashboard, über das die CSV-Datei bequem hochgeladen werden kann.

Der große Vorteil: Die Datei kann direkt über die Oberfläche bereitgestellt werden, ohne dass man sich mit dem Dateisystem des Hosts oder des Docker-Containers beschäftigen muss. Das macht den Workflow nicht nur komfortabler, sondern auch deutlich flexibler im täglichen Einsatz.

Flow zum speichern einer hochgeladenen Datei mit Call eines Subflows Schritt 1 - File Input Node für den Dateiupload

Der Start für den Flow ist eine file input Node welche nur CSV Dateien akzeptiert. Der Inhalt der Datei wird im Feld msg.payload ablegt.

Schritt 2 - ablegen der CSV-Datei auf den Raspberry Pi

Die hochgeladene Datei wird aus dem Formular entnommen und anschließend auf dem Raspberry Pi gespeichert. In meinem Fall erfolgt die Ablage im Verzeichnis _data innerhalb des Docker-Containers.

Schritt 3 - lesen der CSV-Datei

Die gespeicherte Datei kann nun mit einer Read File Node erneut eingelesen werden. Dadurch stellen wir sicher, dass immer der zuletzt hochgeladene Datenstand verfügbar ist.

Zusätzlich dient die abgelegte CSV-Datei als einfache Sicherung auf dem Raspberry Pi, sodass die Daten auch unabhängig vom aktuellen Flow erhalten bleiben.

Schritt 4 - Transformieren der Daten in das CSV-Format

Die eingelesenen Daten müssen anschließend in ein strukturiertes Format überführt werden. Dafür verwenden wir die CSV-Node in Node-RED.

In der Konfiguration definieren wir zunächst die Spaltennamen (kommagetrennt), sodass die Daten korrekt den jeweiligen Feldern zugeordnet werden können. Zusätzlich geben wir an, dass die Werte in der Datei durch ein Semikolon (;) getrennt sind.

Da unsere CSV-Datei eine Kopfzeile enthält, aktivieren wir außerdem die Option, dass die erste Zeile als Spaltenüberschrift interpretiert wird.

Als Ausgabeformat wählen wir ein Array von Objekten. Dadurch steht jeder Datensatz als eigenes Objekt zur Verfügung und kann im nächsten Schritt einfach über eine Loop-Node weiterverarbeitet werden.

Schritt 5 - ermitteln der Anzahl der Datensätze

Für die Statusanzeige beim Import der Daten benötigen wir die Anzahl der Datensätze. Diese lässt sich ganz einfach mit einer kleinen Function-Node ermitteln.

Da die CSV-Daten bereits als Array vorliegen, können wir die Anzahl der Elemente direkt über die Länge des Arrays bestimmen. Dafür reicht ein kurzer JavaScript-Zweizeiler:

msg.data_size = msg.payload.length; return msg; Schritt 6 - Loop über die Daten

Der Vorteil der Datenstruktur als Array ist, dass wir die einzelnen Datensätze komfortabel über eine Loop-Node nacheinander verarbeiten können.

Wichtig dabei ist, dass der Flow nach der Verarbeitung eines Datensatzes wieder an den Anfang der Loop zurückgeführt wird, damit alle Einträge vollständig abgearbeitet werden.

In meinem Beispiel baue ich zusätzlich eine Verzögerung von 500 ms zwischen den einzelnen Durchläufen ein. Dadurch wird der nachgelagerte Flow, insbesondere die Datenbankzugriffe, etwas entlastet. Gleichzeitig hat dies den positiven Effekt, dass der Fortschritt in der Balkenanzeige sichtbar und nachvollziehbar wird.

Schritt 7 - Daten für den Fortschrittsbalken berechnen

Der Fortschrittsbalken arbeitet mit Werten zwischen 0 und 100 Prozent. Da wir zuvor bereits die Gesamtanzahl der Datensätze ermittelt haben, können wir den Fortschritt nun anteilig berechnen.

Dafür nutzen wir den aktuellen Index der Loop (Achtung: dieser startet bei 0) sowie die maximale Anzahl der Datensätze. Aus diesen beiden Werten lässt sich der Fortschritt pro Schritt einfach berechnen – im Grunde eine klassische Prozentrechnung.

Das berechnete Ergebnis wird anschließend in msg.payload geschrieben und steuert damit den Fortschrittsbalken. Zusätzlich definieren wir über msg.ui_update das Erscheinungsbild, beispielsweise den Text und die Farbe der Anzeige.

let steps = 100 / msg.data_size; // Fortschritt berechnen (index startet meist bei 0!) msg.payload = (msg.loop.index + 1) * steps; msg.ui_update = { label: "importiere Daten", color: "info" }; return msg;

Schritt 8 - Fortschrittsbalken

Der Fortschrittsbalken selbst benötigt keine weitere Konfiguration. Er erwartet lediglich einen Wert zwischen 0 und 100 im Feld msg.payload, der den aktuellen Fortschritt repräsentiert.

Sobald dieser Wert gesetzt wird, aktualisiert sich die Anzeige automatisch im Dashboard.

Schritt 9 - Starten eines Subflows

Der eigentliche Import der Daten wird in einen Subflow ausgelagert. Dadurch bleibt der aktuelle Flow übersichtlich und die einzelnen Aufgaben sind klar voneinander getrennt.

Ein weiterer großer Vorteil ist die Wiederverwendbarkeit: Bestehende Logik, wie beispielsweise das spätere Aktualisieren der Tabelle, kann zentral im Subflow umgesetzt und an mehreren Stellen verwendet werden.

Möchten wir beispielsweise einen einzelnen Datensatz manuell über ein Formular hinzufügen, können wir denselben Subflow erneut nutzen, ohne die Logik doppelt implementieren zu müssen.

CSV-Daten in der SQLite Datenbank speichern

Der Flow zum Speichern der Daten in der SQLite-Datenbank ist bewusst ausgelagert. Dadurch bleibt der Hauptflow übersichtlich und die Logik kann bei Bedarf an anderer Stelle wiederverwendet werden.

Wie bereits erwähnt, ermöglicht dieser Aufbau eine flexible Nutzung, sodass der gleiche Flow beispielsweise auch für das manuelle Hinzufügen von Datensätzen eingesetzt werden kann.

Schritt 1 - Daten empfangen aus einem vorherigen Flow

Die Link-In-Node dient als Einstiegspunkt in den Subflow für das Einfügen neuer Datensätze. Der übergebene msg.payload enthält dabei alle benötigten Informationen eines Datensatzes, sodass dieser direkt für das Erstellen des SQL-Statements verwendet werden kann.

Schritt 2 - INSERT INTO Statement erstellen

Für das Einfügen der Daten in die Datenbank wird ein INSERT INTO Statement benötigt. Dieses erzeugen wir dynamisch in einer Function-Node.

Die Idee für diesen programmierbaren Osterhasen hatte ich schon lange im Kopf – nur die Zeit zur Umsetzung hat bisher gefehlt. Im Rahmen meiner EasyEDA-Reihe habe ich das Projekt endlich realisiert und aus einer Skizze ein echtes PCB-Design gemacht, das anschließend bei JLCPCB gefertigt wurde.

Herausgekommen ist ein Osterhase als Lötkit mit 7 LEDs, Touchfläche, Drehpoti und einem ESP32-C3 als Herzstück. Ein kleines Projekt mit erstaunlich vielen Möglichkeiten – perfekt zum Löten, Programmieren und Weiterentwickeln.

In diesem Beitrag zeige ich dir, wie aus einer Idee eine fertige Platine wurde – und vielleicht inspiriert dich das Ganze zu deinem eigenen kreativen PCB-Projekt.

https://youtu.be/fG2GFyeFG_c

Hinweis zum Projekt: Dieses Lötkit wird zu Ostern im örtlichen JFZ gemeinsam mit Kids und jung Gebliebenen aufgebaut und programmiert. Dabei können die Teilnehmer selbst entscheiden, ob sie den ESP32-C3 klassisch in C/C++ (Arduino IDE) oder mit MicroPython programmieren möchten.

Aufbau und Idee hinter dem Bausatz

Der Aufbau des Osterhasen ist bewusst einfach gehalten. Ziel war es, ein Projekt zu entwickeln, das sich gut löten lässt, überschaubar bleibt und trotzdem genug Spielraum für eigene Ideen bietet.

Im Mittelpunkt stehen sieben 3 mm LEDs, die in der Blume des Hasen platziert sind. Diese werden direkt vom ESP32-C3 angesteuert. Da wir lediglich eine Handvoll LEDs steuern möchten, ist die Schaltung entsprechend simpel aufgebaut – ohne aufwendige Treiber oder zusätzliche Logikbausteine.

Schaltung - ESP32-C3 Super Mini mit LEDs und Drehpotentiometer

Theoretisch hätte man die LED-Effekte auch mit einer festen IC-Schaltung oder einem einfachen Blink-Controller realisieren können. Technisch wäre das völlig ausreichend gewesen. Mir persönlich würde dabei jedoch der eigentliche Reiz fehlen – denn für mich gehört zum Projekt nicht nur das Löten, sondern vor allem das Programmieren.

Genau deshalb kommt hier ein ESP32-C3 zum Einsatz. Er macht das Projekt flexibel, erweiterbar und offen für eigene Ideen. Ob einfache Lauflichter, dimmbare Effekte über das Drehpoti oder sogar spätere Erweiterungen per WiFi oder Bluetooth – alles ist möglich, muss aber nicht.

Der Gedanke hinter dem Bausatz ist also klar: Ein einfaches Grundprojekt, das sofort funktioniert – aber genügend Freiheit bietet, kreativ zu werden und eigene Funktionen zu entwickeln.

Hardware im Überblick

Auch wenn der Osterhase auf den ersten Blick verspielt wirkt, steckt technisch mehr drin, als man vermuten würde. Die verwendeten Komponenten sind bewusst ausgewählt – einfach im Aufbau, aber flexibel in der Nutzung.

ESP32-C3 Super Mini

Das Herzstück der Platine ist ein ESP32-C3 Super Mini. Er übernimmt die komplette Steuerung der LEDs, verarbeitet die Touch-Eingabe und liest das Drehpotentiometer aus.

ESP32-C3 Super Mini

Der Vorteil: Genug Leistung für einfache LED-Effekte – aber auch ausreichend Reserven für spätere Erweiterungen wie WiFi- oder Bluetooth-Funktionen. Für dieses Projekt nutzen wir nur einen Bruchteil der Möglichkeiten, behalten aber volle Flexibilität.

7 × 3 mm LEDs

In der Blume des Hasen sitzen sieben klassische 3 mm LEDs. Sie werden direkt über GPIO-Pins angesteuert und jeweils mit einem passenden Vorwiderstand betrieben.

Durch die Einzelansteuerung lassen sich:

- Lauflichter - Blinkmuster - sanfte Übergänge - oder komplett eigene Animationen

realisieren.

3mm LEDs Touchfläche

Auf der Vorderseite befindet sich eine einfache Kupferfläche, die als Touchsensor dient.

Der ESP32-C3 besitzt zwar keine dedizierten kapazitiven Touch-Pins, dennoch lässt sich eine Art Touch-Funktion realisieren. Hierzu wird ein analoger Eingang (ADC) verwendet.

Berührt man die Kupferfläche mit dem Finger, verändert die körpereigene Kapazität den gemessenen Analogwert. Diese kleine Spannungsänderung wird vom Mikrocontroller erkannt und kann softwareseitig ausgewertet werden.

Auf diese Weise entsteht eine einfache, aber effektive „kapazitive“ Touchlösung – ganz ohne zusätzliche Bauteile oder spezielle Sensor-ICs.

Über diese Fläche können beispielsweise:

- Modi gewechselt - Effekte gestartet - oder Funktionen aktiviert werden

Ein Finger genügt – kein Taster, keine Mechanik.

Touchfläche auf der Platine Drehpotentiometer

Auf der Rückseite der Platine sitzt ein Drehpotentiometer. Dieses wird über einen analogen Eingang (ADC) des ESP32-C3 ausgelesen.

Damit lässt sich zum Beispiel:

- die Geschwindigkeit eines Effekts - die Helligkeit - oder ein bestimmter Modus feinjustieren

Das macht das Projekt interaktiver und lebendiger.

verschiedene Drehpotentiometer Stromversorgung

Die Platine wird bequem über USB mit Strom versorgt. Das vereinfacht den Aufbau und ermöglicht gleichzeitig eine direkte Programmierung über die Arduino IDE oder via MicroPython.

Warum dieses ESP32-C3 Lötkit perfekt für Maker ist

Dieses ESP32-C3 Lötkit eignet sich ideal für Einsteiger, da nur wenige Komponenten verbaut werden und der Aufbau übersichtlich bleibt. Man verliert sich nicht im Schaltplan – und kommt schnell zum ersten Erfolg.

Trotzdem sind die Möglichkeiten nahezu unbegrenzt.

Der ESP32-C3 kann wahlweise in C/C++ oder MicroPython programmiert werden. Von einfachen Lauflichtern bis hin zu Fade-Effekten mit PWM lässt sich hier einiges lernen. Gerade beim Dimmen der LEDs bekommt man ein gutes Verständnis für PWM-Signale.

Das Drehpotentiometer kann flexibel eingesetzt werden – etwa zur Steuerung der Effektgeschwindigkeit oder zur Anpassung der Touch-Empfindlichkeit.

Drehpoti am Osterhase PCB zum steuern der Empfindlichkeit oder der Geschwindigkeit der LEDs

Und wer noch einen Schritt weitergehen möchte, kann auf dem ESP32 sogar eine kleine Weboberfläche bereitstellen und die LED-Effekte bequem per Smartphone steuern.

Einfach im Aufbau – groß im Potenzial.

Vom Entwurf zur fertigen Platine

Wie so oft begann alles mit einer Idee im Kopf. Ein Osterhase als Platine – verspielt im Design, aber technisch sinnvoll aufgebaut.

Um aus dieser groben Vorstellung ein konkretes Konzept zu machen, habe ich mir Unterstützung geholt: Mit Hilfe von ChatGPT entstand zunächst ein passendes Motiv. Über ein gezieltes Prompt wurde ein Bild erzeugt, das als Grundlage für das spätere Platinenlayout diente.

In mehreren „Unterhaltungen“ über das Projekt reifte die Idee weiter. Welche Komponenten sind sinnvoll? Wie viele LEDs? Touch oder Taster? Reicht ein einfacher Controller oder darf es etwas flexibler sein? Durch diesen iterativen Prozess bekam das Projekt Schritt für Schritt seinen finalen Charakter.

Das eigentliche Platinenlayout habe ich anschließend in EasyEDA umgesetzt. Dort wurden die Konturen des Hasen nachgezeichnet, die LEDs sauber in der Blume platziert und Vorder- sowie Rückseite sinnvoll strukturiert.

EasyEDA - smarter Osterhase - Platinenlayout

Die Fertigung erfolgte – wie bei vielen meiner Projekte – über JLCPCB. Besonders praktisch ist die enge Verzahnung mit EasyEDA: Mit wenigen Klicks lassen sich die Gerber-Daten direkt übertragen und die Bestellung auslösen. Das spart Zeit und macht den gesamten Workflow sehr unkompliziert.

JLCPCB - Bestellung über EasyEDA auslösen

So wurde aus einer Idee, einem KI-generierten Entwurf und einem digitalen Layout schließlich eine echte Platine, die man in den Händen halten und bestücken kann.

Quellcode zum erzeugen der Effekte am smarten Osterhasen

Für die Programmierung reicht die Arduino IDE bzw. Thonny völlig aus wir benötigen keine zusätzlichen Bibliotheken oder Module.

Quellcode - C/C++ für die Arduino IDE /* ============================================================ Projekt: Programmierbarer Osterhase mit ESP32-C3 Beschreibung: Dieses Programm steuert 7 LEDs auf einem Osterhasen-PCB. Über eine Touchfläche kann zwischen verschiedenen LED-Modi gewechselt werden. Die Empfindlichkeit der Touchfläche wird über ein Drehpotentiometer eingestellt. Modi: 1 = Blume rotiert Stufe 1 2 = Blume rotiert Stufe 2 3 = Blume blinkt Autor: Stefan Draeger ============================================================ */ // ------------------------------------------------------------ // PIN-DEFINITIONEN // ------------------------------------------------------------ // Hier werden die GPIO-Pins definiert, an denen die 7 LEDs // angeschlossen sind. #define ledPin1 5 #define ledPin2 6 #define ledPin3 7 #define ledPin4 8 #define ledPin5 9 #define ledPin6 10 #define ledPin7 20 // Analoger Eingang für das Drehpotentiometer. // Darüber wird die Empfindlichkeit des Touchsensors eingestellt. #define rotaryResistorPin 3 // Analoger Eingang für die Touchfläche. // Der ESP32-C3 besitzt keine dedizierten Touch-Pins, // daher werten wir hier eine Spannungsänderung am ADC aus. #define touchPin 4 // ------------------------------------------------------------ // MODUS-VERWALTUNG // ------------------------------------------------------------ // 'modus' speichert den aktuell aktiven Effekt. // MAX_MODI legt fest, wie viele Effekte insgesamt existieren. int modus = 1; const int MAX_MODI = 3; // ------------------------------------------------------------ // LED-ARRAY // ------------------------------------------------------------ // Die LED-Pins werden in einem Array zusammengefasst. // So können wir später bequem mit Schleifen über alle LEDs gehen. const int NUM_LEDS = 7; int leds = { ledPin1, ledPin2, ledPin3, ledPin4, ledPin5, ledPin6, ledPin7 }; // ------------------------------------------------------------ // ZEITSTEUERUNG FÜR DIE ANIMATIONEN // ------------------------------------------------------------ // FLOWER_PAUSE bestimmt das Zeitintervall zwischen zwei Schritten // der LED-Animation. // flowerLastAction speichert, wann die letzte Änderung stattgefunden hat. int flowerIndex = 0; const int FLOWER_PAUSE = 250; unsigned long flowerLastAction = 0; // ------------------------------------------------------------ // HILFSVARIABLEN FÜR DEN ERSTEN EFFEKT // ------------------------------------------------------------ // stampStatus wird genutzt, um eine zusätzliche LED im Wechsel // blinken zu lassen. // STAMP_PAUSE und stampLastAction sind aktuell vorbereitet, // werden in dieser Version aber nicht aktiv verwendet. const int STAMP_PAUSE = 125; unsigned long stampLastAction = 0; bool stampStatus = false; // ------------------------------------------------------------ // SETUP // ------------------------------------------------------------ // setup() wird genau einmal beim Start des Mikrocontrollers // ausgeführt. void setup() { // Serielle Schnittstelle starten, damit wir Messwerte // im seriellen Monitor der Arduino IDE ausgeben können. Serial.begin(9600); // Alle LED-Pins als Ausgänge konfigurieren. for (int index = 0; index 1) { digitalWrite(leds, LOW); } // Die aktuelle LED einschalten. digitalWrite(leds, HIGH); // Zusätzliche LED 0 bei jedem Durchlauf umschalten. // Dadurch entsteht ein zusätzlicher Blinkeffekt. stampStatus = !stampStatus; digitalWrite(leds, stampStatus); } // ------------------------------------------------------------ // EFFEKT 2: BLUME ROTIERT STUFE 2 // ------------------------------------------------------------ // Dieser Effekt arbeitet mit einem zweiten Index. // LEDs werden der Reihe nach ein- oder ausgeschaltet. // Sobald alle LEDs durchlaufen wurden, wird der Zustand // umgedreht (HIGH LOW). int flowerRotate2Index = 0; bool flowerRotate2Status = false; void flowerRotate2() { // Aktuelle LED auf den gespeicherten Status setzen. digitalWrite(leds, flowerRotate2Status); // Zum nächsten Index wechseln. if (flowerRotate2Index < (NUM_LEDS - 1)) { flowerRotate2Index++; } else { // Wenn alle LEDs durchlaufen wurden: // wieder von vorne beginnen und Status umschalten. flowerRotate2Index = 0; flowerRotate2Status = !flowerRotate2Status; } } // ------------------------------------------------------------ // EFFEKT 3: BLUME BLINKT // ------------------------------------------------------------ // Alle LEDs werden gleichzeitig ein- und ausgeschaltet. void flowerBlink() { // Alle LEDs einschalten. for (int index = 0; index < NUM_LEDS; index++) { digitalWrite(leds, HIGH); } // Kurze Pause mit allen LEDs an. delay(FLOWER_PAUSE); // Alle LEDs ausschalten. for (int index = 0; index (touchLastAction + TOUCH_PAUSE)) { touchLastAction = currentMillis; // Wenn der gemessene Touch-Wert größer als der Potentiometer- // Wert ist, wird dies als Berührung interpretiert. if (touchValue > resistorValue) { // Wenn der letzte Modus erreicht wurde, // wieder von vorne beginnen. if (modus == MAX_MODI) { modus = 0; } // Zum nächsten Modus wechseln. modus++; } } // ---------------------------------------------------------- // LED-EFFEKT ZEITGESTEUERT AUSFÜHREN // ---------------------------------------------------------- // Statt delay() wird hier millis() verwendet, // damit das Programm weiterhin auf Touch reagieren kann. if (currentMillis > (flowerLastAction + FLOWER_PAUSE)) { flowerLastAction = currentMillis; // Je nach aktivem Modus die passende Effektfunktion aufrufen. switch (modus) { case 1: flowerRotate(); break; case 2: flowerRotate2(); break; case 3: flowerBlink(); break; default: // Falls ein ungültiger Modus gesetzt wurde, // auf den ersten Effekt zurückfallen. flowerRotate(); break; } } }

Fazit

Der programmierbare Osterhase ist ein bewusst einfach gehaltenes Projekt, das sich ideal für den Einstieg in die Welt der Mikrocontroller eignet. Durch den Einsatz des ESP32-C3 bleibt das System jedoch offen für zahlreiche Erweiterungen.

Besonders spannend ist die Kombination aus:

- einfachem Hardwareaufbau - flexibler Programmierung - und kreativen Gestaltungsmöglichkeiten

Damit eignet sich das Projekt nicht nur als Lötbausatz, sondern auch als Grundlage für eigene Ideen und Experimente.

Das Cheap Yellow Display (ESP32-2432S028) besitzt auf der Vorderseite ein kleines, oft übersehenes Bauteil: einen Fotowiderstand – kurz LDR (Light Dependent Resistor).

Ein LDR verändert seinen Widerstand abhängig von der Umgebungshelligkeit. Je heller es ist, desto geringer wird sein Widerstand – in dunkler Umgebung steigt er entsprechend an. Über einen analogen Eingang des ESP32 lässt sich diese Änderung als Messwert erfassen.

https://youtu.be/8sCQkLe3JlM

In der Praxis kann man dieses Feature sinnvoll nutzen, um das Display automatisch an die Umgebungshelligkeit anzupassen. So bleibt der Bildschirminhalt bei direkter Sonneneinstrahlung gut ablesbar, während das Display in dunkler Umgebung gedimmt werden kann – ideal für Dashboard- oder Smart-Home-Projekte.

In diesem Beitrag zeige ich dir Schritt für Schritt, wie du den LDR auf dem Cheap Yellow Display ausliest und in deinem Projekt verwendest.

Cheap Yellow Display - ESP32-2432S028 - Vorderseite

LDR am Cheap Yellow Display - ESP32-2432S028

Hinweis: Der LDR ist fest mit GPIO34 verbunden. GPIO34 und GPIO35 gehören beim ESP32 zu den reinen ADC-Eingängen und unterstützen keine OUTPUT-Funktionalität.

Was ist ein LDR überhaupt?

Ein LDR (Light Dependent Resistor) ist ein lichtabhängiger Widerstand. Er verändert seinen elektrischen Widerstand abhängig von der Helligkeit der Umgebung.

Das Prinzip ist einfach:

- Viel Licht → niedriger Widerstand - Wenig Licht → hoher Widerstand

Der LDR selbst erzeugt kein Signal. Er ist lediglich ein variabler Widerstand. Damit der ESP32 diesen Helligkeitswert erfassen kann, wird der LDR auf dem Board in einer Spannungsteiler-Schaltung betrieben.

Beim Cheap Yellow Display ist der LDR bereits fest mit GPIO34 (ADC1) verbunden. Eine zusätzliche Verdrahtung ist also nicht notwendig.

LDR am Cheap Yellow Display - ESP32-2432S028

LDR am Cheap Yellow Display auslesen

Der LDR auf dem Cheap Yellow Display (ESP32-2432S028) ist fest mit GPIO34 (ADC1) verbunden. Wir lesen den Helligkeitswert über den integrierten Analog-Digital-Wandler des ESP32 aus.

Der folgende Sketch gibt den Messwert nur dann aus, wenn sich dieser merklich ändert. Dadurch vermeiden wir unnötige serielle Ausgaben.

#define ldrPin 34 // LDR am GPIO34 // letzter gelesener Wert vom LDR int lastLDRValue = 0; // Zeitpunkt (in ms) des letzten Lesevorgangs unsigned long lastRead = 0; // Pause zwischen zwei Lesezyklen (in Millisekunden) const int PAUSE = 50; void setup() { // Start der seriellen Kommunikation mit 9600 Baud Serial.begin(9600); // ADC-Dämpfung setzen // siehe: https://docs.espressif.com/projects/arduino-esp32/en/latest/api/adc.html#analogsetattenuation analogSetAttenuation(ADC_0db); } void loop() { // aktuelle Millisekunden seit Start/Reset des Mikrocontrollers ermitteln unsigned long currentMillis = millis(); // prüfen, ob die definierte Pause abgelaufen ist if (currentMillis > (lastRead + PAUSE)) { // Zeitpunkt des letzten Lesevorgangs aktualisieren lastRead = currentMillis; // analogen Wert vom LDR (GPIO34) einlesen int currentLDRValue = analogRead(ldrPin); // nur reagieren, wenn sich der Wert deutlich verändert hat (>= 5) if (abs(currentLDRValue - lastLDRValue) >= 5) { // Ausgabe des Messwertes über die serielle Schnittstelle // kann z.B. im seriellen Plotter als Liniendiagramm dargestellt werden Serial.println(currentLDRValue); // neuen Wert als Referenz speichern lastLDRValue = currentLDRValue; } } }

Die gelesenen Werte können wir nun im seriellen Monitor der Arduino IDE auslesen oder auch im seriellen Plotter in einem Liniendiagram visualisieren lassen.

Ausgabe der Daten vom LDR im seriellen Monitor der Arduino IDE

visualisieren der Daten vom LDR im seriellen Plotter der Arduino IDE

Anzeigen des Wertes vom LDR auf dem Display des ESP32-2432S028 (CYD)

Nachdem wir den LDR über analogRead() auslesen können, soll der Messwert nun direkt auf dem Display des Cheap Yellow Display angezeigt werden.

CYD - Anzeige des Wertes vom LDR auf dem Display

CYD - Anzeige des Wertes vom LDR auf dem Display - Sensor abgedunkelt

Hierfür verwende ich LVGL in Kombination mit der TFT_eSPI-Bibliothek. Der aktuelle Helligkeitswert wird dabei:

- als numerischer Wert angezeigt - zusätzlich visuell über einen Kreis dargestellt, dessen Helligkeit sich abhängig vom LDR-Wert verändert #include #include #define TFT_HOR_RES 240 #define TFT_VER_RES 320 #define TFT_ROTATION LV_DISPLAY_ROTATION_270 #define DRAW_BUF_SIZE (TFT_HOR_RES * TFT_VER_RES / 10 * (LV_COLOR_DEPTH / 8)) uint32_t draw_buf; #define COLOR_BG lv_color_hex(0x000000) // Hintergrund: Schwarz #define COLOR_WHITE lv_color_hex(0xFFFFFF) // Weiß #define COLOR_YELLOW lv_color_hex(0xFDD835) // Gelb #define ldrPin 34 lv_obj_t *ldrValueLabel; int lastLDRValue = 0; unsigned long lastRead = 0; const int PAUSE = 250; lv_obj_t *ldrCircle; void setup() { Serial.begin(9600); analogSetAttenuation(ADC_0db); lv_init(); lv_display_t *disp = lv_tft_espi_create( TFT_HOR_RES, TFT_VER_RES, draw_buf, sizeof(draw_buf)); lv_display_set_rotation(disp, TFT_ROTATION); lv_obj_t *scr = lv_screen_active(); lv_obj_set_style_bg_color(scr, COLOR_BG, 0); lv_obj_set_style_bg_opa(scr, LV_OPA_COVER, 0); lv_obj_set_style_pad_all(scr, 12, 0); lv_obj_set_scrollbar_mode(scr, LV_SCROLLBAR_MODE_OFF); lv_obj_t *ldrDescLabel = lv_label_create(scr); lv_label_set_text(ldrDescLabel, "LDR"); lv_obj_set_style_text_color(ldrDescLabel, COLOR_YELLOW, 0); lv_obj_set_style_text_font(ldrDescLabel, &lv_font_montserrat_28, 0); lv_obj_align(ldrDescLabel, LV_ALIGN_TOP_MID, 0, 0); ldrValueLabel = lv_label_create(scr); lv_label_set_text(ldrValueLabel, "0"); lv_obj_set_style_text_color(ldrValueLabel, COLOR_WHITE, 0); lv_obj_set_style_text_font(ldrValueLabel, &lv_font_montserrat_28, 0); lv_obj_align(ldrValueLabel, LV_ALIGN_TOP_MID, 0, 50); ldrCircle = lv_obj_create(scr); lv_obj_set_size(ldrCircle, 80, 80); lv_obj_set_style_radius(ldrCircle, LV_RADIUS_CIRCLE, 0); lv_obj_set_style_bg_color(ldrCircle, COLOR_YELLOW, 0); lv_obj_set_style_border_width(ldrCircle, 0, 0); lv_obj_set_style_bg_opa(ldrCircle, LV_OPA_0, 0); lv_obj_align(ldrCircle, LV_ALIGN_CENTER, 0, 40); setOpacity(0); } void setOpacity(int currentLDRValue) { int opa = map(currentLDRValue, 0, 1023, 255, 0); opa = constrain(opa, 0, 255); lv_obj_set_style_bg_opa(ldrCircle, (lv_opa_t)opa, 0); } void loop() { lv_tick_inc(5); lv_timer_handler(); unsigned long currentMillis = millis(); if (currentMillis > (lastRead + PAUSE)) { lastRead = currentMillis; int currentLDRValue = analogRead(ldrPin); if (abs(currentLDRValue - lastLDRValue) >= 5) { lastLDRValue = currentLDRValue; Serial.println(currentLDRValue); String s = String(currentLDRValue, DEC); lv_label_set_text(ldrValueLabel, s.c_str()); setOpacity(currentLDRValue); } } delay(5); } Hinweis zur Programmierung mit LVGL

Die grundlegende Einrichtung des Cheap Yellow Display (ESP32-2432S028) in Kombination mit der LVGL-Bibliothek habe ich bereits ausführlich anhand eines kleinen Dashboards erklärt.

Dort zeige ich unter anderem:

- Einrichtung von LVGL - Einbindung der TFT_eSPI-Bibliothek - Display-Rotation und Buffer-Konfiguration - Erstellen von Labels und grafischen Elementen - Grundlegende Struktur mit lv_timer_handler() und lv_tick_inc()

Falls du neu mit LVGL auf dem CYD arbeitest, empfehle ich dir zunächst einen Blick in meine YouTube-Playlist zu diesem Thema: ESP32 CYD Display mit LVGL programmieren - Komplettkurs

In diesem Beitrag konzentrieren wir uns ausschließlich auf das Auslesen und Visualisieren des LDR-Wertes.

Dashboard-Helligkeit automatisch mit dem LDR regulieren

Nachdem wir den LDR-Wert auslesen und visualisieren können, lässt sich dieser nun verwenden, um die Helligkeit eines Dashboards automatisch anzupassen.

Dashboard am CYD mit normaler Helligkeit

Dashboard am CYD mit abgedunkelten LDR

In diesem Beispiel simulieren wir ein kleines Dashboard mit:

- Temperaturwert - Statusanzeige - Hintergrundfläche

Je nach Umgebungshelligkeit wird dabei die gesamte Display-Helligkeit bzw. die Hintergrund-Deckkraft angepasst.

#include #include #define TFT_HOR_RES 240 #define TFT_VER_RES 320 #define TFT_ROTATION LV_DISPLAY_ROTATION_270 #define DRAW_BUF_SIZE (TFT_HOR_RES * TFT_VER_RES / 10 * (LV_COLOR_DEPTH / 8)) uint32_t draw_buf; #define COLOR_BG lv_color_hex(0x000000) #define COLOR_WHITE lv_color_hex(0xFFFFFF) #define COLOR_GREEN lv_color_hex(0x4CAF50) #define COLOR_RED lv_color_hex(0xE53935) // 3 Helligkeitsstufen enum BrightnessLevel { BRIGHT, MEDIUM, DARK }; // Farben-Array: lv_color_t colorSet = { // BRIGHT { lv_color_hex(0xFFFFFF), // Weiß lv_color_hex(0xFF0000), // Rot lv_color_hex(0x00FF00) // Grün }, // MEDIUM { lv_color_hex(0xAAAAAA), // Grau lv_color_hex(0xCC4444), // Mittel-Rot lv_color_hex(0x44CC44) // Mittel-Grün }, // DARK { lv_color_hex(0x555555), // Dunkelgrau lv_color_hex(0x662222), // Dunkelrot lv_color_hex(0x226622) // Dunkelgrün } }; #define ldrPin 34 lv_obj_t *titleLabel; lv_obj_t *tempLabel; lv_obj_t *statusLabel; unsigned long lastUpdate = 0; const int UPDATE_INTERVAL = 1000; BrightnessLevel getBrightnessLevel(int ldrValue) { if (ldrValue < 10) { return BRIGHT; } else if (ldrValue UPDATE_INTERVAL) { lastUpdate = millis(); int ldrValue = analogRead(ldrPin); int temperature = random(20, 35); bool warn = temperature > 30; String tempText = String(temperature) + " °C"; lv_label_set_text(tempLabel, tempText.c_str()); lv_label_set_text(statusLabel, warn ? "WARN" : "OK"); applyColorTheme(ldrValue, warn); } delay(5); }

Fazit

Das Auslesen eines LDR – oder generell anderer analoger Sensoren, die über einen Spannungsteiler betrieben werden (z. B. ein NTC-Widerstand) – ist mit dem ESP32 denkbar einfach. Im Grunde benötigt es nur wenige Zeilen Code, um einen stabilen Messwert über den ADC einzulesen und weiterzuverarbeiten.

Der integrierte LDR auf dem Cheap Yellow Display ist daher ein kleines, aber praktisches Feature, das sich ohne zusätzliche Hardware direkt nutzen lässt. Besonders für Projekte mit automatischer Helligkeitsanpassung oder einfachen Umgebungslicht-Erkennungen bietet sich dieser Sensor an.

Deutlich umfangreicher wird der Code erst dann, wenn der Messwert grafisch auf dem Display visualisiert wird. Durch den Einsatz von LVGL wächst das Projekt spürbar an – was jedoch der Flexibilität und den Gestaltungsmöglichkeiten geschuldet ist. Mit einem einfachen OLED-Display über I2C ließe sich die reine Anzeige des Messwertes deutlich schlanker umsetzen.

Wie du eine automatische Pumpensteuerung mit einem Shelly umsetzt, zeige ich dir in diesem Beitrag.

Die Shelly-Geräte habe ich bereits in vielen Beiträgen und Videos auf meinem Blog vorgestellt. Sie sind sehr einfach einzurichten und arbeiten zuverlässig – genau diese beiden Punkte machen sie für solche Projekte besonders interessant.

Die Idee zu diesem Beitrag stammt aus meiner Community: Ein Zuschauer meines YouTube-Kanals hat mich angerufen, weil er genau so eine Lösung für seine Pumpensteuerung umsetzen wollte. Gemeinsam haben wir eine einfache und praxisnahe Lösung entwickelt, die ich dir hier Schritt für Schritt zeige.

https://youtu.be/pLcIx1egNpk

Wenn du Fragen hast oder Unterstützung brauchst, melde dich gerne per E-Mail oder über mein Ticket-System – ich helfe dir gern weiter.

Warum eine automatische Pumpensteuerung sinnvoll ist

Die Bodenplatte des Hauses befindet sich in der Nähe des Grundwassers. Dadurch kann es passieren, dass sich Wasser im Keller sammelt und aktiv abgepumpt werden muss.

Damit es hier nicht zu Schäden kommt, ist eine zuverlässige Pumpensteuerung notwendig. Fällt die Pumpe aus oder arbeitet sie nicht korrekt, kann sich innerhalb kurzer Zeit Wasser ansammeln und Probleme verursachen.

Genau aus diesem Grund reicht eine einfache Lösung oft nicht aus – neben der Steuerung ist es wichtig, den Betrieb der Pumpe zu überwachen und im Fehlerfall schnell reagieren zu können.

Was soll überwacht werden und welche Fehler können auftreten?

Damit die Pumpensteuerung zuverlässig funktioniert, müssen sowohl die Sensoren als auch die Pumpe selbst überwacht werden.

Ein wichtiger Punkt ist die Funktion der Pumpe. Wird sie eingeschaltet, muss sie auch tatsächlich laufen. Mit einem Shelly Plus 1PM lässt sich das über die Leistungsaufnahme prüfen. Bleibt diese trotz aktivem Relais aus, liegt ein Fehler vor.

Auch die beiden Schwimmschalter können Probleme verursachen. Liefert einer falsche Werte oder bleibt hängen, kann die Steuerung nicht mehr korrekt reagieren.

Typische Fehlerfälle sind:

- Pumpe wird eingeschaltet, läuft aber nicht - Pumpe läuft dauerhaft - Schwimmschalter liefern falsche Zustände - Pumpe schaltet gar nicht ein

Durch die Überwachung dieser Punkte kann frühzeitig reagiert und ein Wasserschaden verhindert werden.

Aufbau und Ablauf der Pumpensteuerung

Für die Umsetzung werden zwei Schwimmschalter sowie ein Shelly mit AddOn verwendet. Die beiden Schwimmschalter erfassen den Wasserstand im Keller und bilden die Grundlage für die Steuerung der Pumpe.

- S1 (unten) → minimaler Wasserstand - S2 (oben) → maximaler Wasserstand

Der obere Schwimmschalter (S2) dient als Startsignal für die Pumpe. Sobald dieser ausgelöst wird, ist der Wasserstand zu hoch und die Pumpe wird eingeschaltet.

Schaubild - Aufbau der Schaltung - automatische Pumpensteuerung mit Shelly und Schwimmschalter

Der untere Schwimmschalter (S1) sorgt dafür, dass die Pumpe wieder abgeschaltet wird, sobald ausreichend Wasser abgepumpt wurde.

Dieses Zusammenspiel verhindert, dass die Pumpe ständig ein- und ausgeschaltet wird und sorgt für einen stabilen Betrieb.

Was wird benötigt?

Für den Aufbau der automatischen Pumpensteuerung werden nur wenige Komponenten benötigt:

- ein Shelly Plus 1PM* - ein Shelly AddOn* - eine 3fach Wago-Klemme* - etwas Draht - 18 AWG* - zwei Schwimmschalter* - eine Pumpe*

Schwimmschalter und Shelly Plus 1PM Gen3 inkl AddOn

Hinweis von mir: Die mit einem Sternchen (*) markierten Links sind Affiliate-Links. Wenn du über diese Links einkaufst, erhalte ich eine kleine Provision, die dazu beiträgt, diesen Blog zu unterstützen. Der Preis für dich bleibt dabei unverändert. Vielen Dank für deine Unterstützung!

Da es im Keller bekanntermaßen feucht werden kann, empfehle ich zusätzlich eine spritzwassergeschützte Dose* (mindestens IP44, besser IP65). Der Shelly kann darin sicher untergebracht werden. Für die Kabelzuführung eignen sich sogenannte Würgenippel*, um das Gehäuse möglichst dicht zu halten. Die Öffnungen lassen sich bei Bedarf zusätzlich mit etwas Silikon abdichten.

Für den Testaufbau verwende ich keinen echten Keller, sondern simuliere das ganze auf meiner Terrasse. Dafür nutze ich einen einfachen 10-Liter-Eimer, in dem die beiden Schwimmschalter montiert sind. So lässt sich das Verhalten der Steuerung gut nachvollziehen und testen.

Aufbau der Schaltung - automatische Pumpensteuerung mit Shelly und Schwimmschalter

Aufbau und Funktionsweise eines Schwimmschalters

Es gibt Schwimmschalter in verschiedenen Bauformen – zum Beispiel mit Kabel, als Stabmontage oder für den festen Einbau. Die grundlegende Funktion ist jedoch immer gleich.

Im Inneren eines Schwimmschalters befindet sich in der Regel ein Reed-Kontakt, der durch einen Magneten betätigt wird. Dieser Magnet sitzt im Schwimmer selbst.

Steigt oder fällt der Wasserstand, bewegt sich der Schwimmer nach oben oder unten. Dabei verändert sich die Position des Magneten zum Reed-Kontakt:

- Wird der Kontakt geschlossen → Signal EIN (HIGH) - Wird der Kontakt geöffnet → Signal AUS (LOW)

Je nach Einbaulage oder Ausrichtung des Schwimmschalters kann das Verhalten unterschiedlich sein. Manche Schalter schließen bei steigendem Wasserstand, andere öffnen.

👉 Wichtig für die Praxis: Durch einfaches Drehen des Schwimmschalters (z. B. um 180°) lässt sich die Schaltlogik oft umkehren.

unterschiedliche Schwimmschalter

Auf dem Markt gibt es eine Vielzahl an Schwimmschaltern in unterschiedlichen Bauformen. In meinem Fall verwende ich Modelle, die seitlich montiert werden. Diese eignen sich besonders gut für den Einbau in Gefäße.

Alternativ gibt es auch Schwimmschalter, die von oben in das Medium eingetaucht werden. Die grundlegende Funktion bleibt dabei jedoch identisch.

Aufbau der Schaltung

Der Shelly Plus 1PM wird in dieser Schaltung mit 230 V betrieben. Daher ist beim Aufbau besondere Vorsicht geboten.

Schaltung - automatische Pumpensteuerung mit Shelly und Schwimmschalter

⚠️ Wichtig: Beachte unbedingt die Sicherheitsregeln der Elektrotechnik, bevor du mit der Installation beginnst.

- Stromkreis spannungsfrei schalten - gegen Wiedereinschalten sichern - Spannungsfreiheit prüfen

Die Spannungsfreiheit sollte immer mit einem zweipoligen Spannungsprüfer geprüft werden, häufig auch Duspol genannt. Einfache Phasenprüfer („Lügenstift“) oder berührungslose Spannungsprüfer, die lediglich ein elektrisches Feld erkennen, sind für eine sichere Prüfung nicht geeignet.

Anschluss der Schwimmschalter

Die beiden Schwimmschalter werden am Shelly AddOn angeschlossen.

Schwimmschalter am Shelly Plus 1PM mit AddOn

Da das Shelly AddOn nur über einen digitalen Eingang verfügt, wird der zweite Schwimmschalter (S1) über den analogen Eingang ausgewertet. Dazu verbinden wir den ANALOG IN mit dem VREF+R1 OUT und führen diesen Punkt über den Schwimmschalter nach GND (siehe Schaltung).

Schwimmschalter am Shelly AddOn via AnalogIN Anschluss der Pumpe

Die Pumpe wird über den Shelly geschaltet. In meinem Aufbau erfolgt das über eine Steckdose:

- O (Shelly) → L (Steckdose) - N & PE → direkt aus der Hausinstallation zur Steckdose

Die Pumpe wird anschließend einfach über ihren Schuko-Stecker angeschlossen.

Steckdose am Shelly Plus 1PM Alternative ohne Verdrahtung

Alternativ kannst du auch einen Shelly Outdoor Plug S verwenden. In diesem Fall wird die Pumpe einfach eingesteckt und über eine Szene geschaltet.

👉 Vorteile:

- keine direkte Verdrahtung notwendig - flexibler Einsatz - besonders geeignet für Testaufbauten oder Außenbereiche

Shelly Outdoor Plug S draussen

Shelly einrichten und AddOn konfigurieren

Im nächsten Schritt richten wir den Shelly im lokalen WLAN ein. Dazu verbindest du dich zunächst mit dem vom Shelly bereitgestellten Access Point und hinterlegst anschließend deine WLAN-Zugangsdaten.

https://youtu.be/r3-TEb3K_xM

Nach erfolgreicher Verbindung ist der Shelly über dein Netzwerk erreichbar.

Das Shelly AddOn wird in der Regel automatisch erkannt, sobald es angeschlossen ist. Eine separate Installation ist nicht notwendig.

Shelly Cloud - AddOn verwalten

Anschließend müssen nur noch die Eingänge konfiguriert werden:

- Digital IN (S2) → oberer Schwimmschalter - Analog IN (S1) → unterer Schwimmschalter

Damit ist die Hardware bereits vollständig eingerichtet und bereit für die spätere Steuerung über Szenen.

Intelligente Szenen zum automatischen Steuern der Pumpe

Nachdem wir alles angeschlossen und das Shelly AddOn eingerichtet haben, können wir die Szene zum steuern der Pumpe erstellen.

Der für wichtige Zustand der Schwimmschalter ist:

- S1 - Schwimmschalter unten - EIN - S2 - Schwimmschalter oben - EIN

Eine zweite Szene soll nun dafür sorgen das die Pumpe deaktiviert wird, dafür muss der obere und untere Schwimmschalter (S1 & S2) den Status AUS haben.

Benachrichtigung beim EIN/AUS schalten der Pumpe

Wir können uns auch benachrichtigen lassen wenn die Pumpe aktiviert oder deaktiviert wird, damit haben wir auch mobil einen überblick ob die Steuerung läuft.

Überwachung im nächsten Teil

Die grundlegende Steuerung der Pumpe haben wir damit umgesetzt. In diesem Beitrag lag der Fokus bewusst auf dem Aufbau und der einfachen Automatisierung mit Shelly.

Die Überwachung der Schaltung – also das Erkennen von Fehlerzuständen, das Auswerten der Leistungsaufnahme sowie das Versenden von Benachrichtigungen – behandeln wir im zweiten Teil dieser Reihe.

Dort zeige ich dir:

- wie du erkennst, ob die Pumpe wirklich läuft - wie du unplausible Schalterzustände auswertest - und wie du automatische Benachrichtigungen einrichtest

Im dritten Teil erweitern wir das Projekt dann um ein Node-RED Dashboard. Damit erhältst du einen übersichtlichen Einblick in alle Zustände und kannst zusätzlich auswerten, wann und wie lange die Pumpe gelaufen ist.

Fazit und Ausblick

Die automatische Pumpensteuerung mit Shelly lässt sich mit wenigen Komponenten einfach und zuverlässig umsetzen. Besonders in Kombination mit zwei Schwimmschaltern entsteht eine stabile Steuerung, die ohne ständiges Ein- und Ausschalten auskommt.

In diesem ersten Teil lag der Fokus bewusst auf dem Aufbau und der grundlegenden Funktion der Steuerung. Damit hast du eine solide Basis, um die Pumpe automatisch in Abhängigkeit vom Wasserstand zu schalten.

Wer sich die Arbeit mit 230 V nicht zutraut, kann viele Shelly-Geräte auch mit 12 V oder 24 V DC betreiben. Hierfür wird jedoch ein passendes Netzteil benötigt. Ein Shelly Plug oder Shelly Outdoor Plug S kann zudem verwendet werden, um die schaltbare Steckdose für die Wasserpumpe zu ersetzen. So lässt sich die Pumpe ebenfalls komfortabel über Shelly steuern.

Im nächsten Teil erweitern wir die Steuerung um eine Überwachung der Schaltung. Dabei schauen wir uns an, wie Fehlerzustände erkannt und entsprechende Benachrichtigungen ausgelöst werden können.

Häufige Fragen zur automatischen Pumpensteuerung mit Shelly

Wie funktioniert eine automatische Pumpensteuerung mit Shelly?

Eine automatische Pumpensteuerung mit Shelly nutzt zwei Schwimmschalter zur Erkennung des Wasserstands. Wird der obere Schalter aktiviert, schaltet der Shelly die Pumpe ein. Sinkt der Wasserstand bis zum unteren Schalter, wird die Pumpe wieder ausgeschaltet. Zusätzlich kann der Shelly den Betrieb überwachen und bei Fehlern Benachrichtigungen senden.

Warum werden zwei Schwimmschalter benötigt?

Mit zwei Schwimmschaltern wird eine sogenannte Hysterese erzeugt. Dadurch wird verhindert, dass die Pumpe ständig ein- und ausgeschaltet wird. Ein Schalter definiert den Startpunkt (Wasser zu hoch), der andere den Stopppunkt (Wasser ausreichend abgepumpt).

Kann ich die Pumpensteuerung auch mit nur einem Schwimmschalter umsetzen?

Ja, technisch ist das möglich. Allerdings führt das häufig dazu, dass die Pumpe sehr oft ein- und ausschaltet (Flattern). Das kann die Lebensdauer der Pumpe deutlich reduzieren und sollte daher vermieden werden.

Welcher Shelly eignet sich für eine Pumpensteuerung?

Für dieses Projekt eignet sich besonders der Shelly Plus 1PM, da dieser zusätzlich die Leistungsaufnahme messen kann. Dadurch lässt sich erkennen, ob die Pumpe tatsächlich läuft oder ein Fehler vorliegt.

Alternativ kann auch ein Shelly Plug S oder Shelly Outdoor Plug S verwendet werden, wenn keine feste Verdrahtung gewünscht ist.

Wozu wird das Shelly AddOn benötigt?

Das Shelly AddOn ermöglicht den Anschluss externer Sensoren wie Schwimmschalter. Da es zusätzliche Ein- und Ausgänge bereitstellt, können mehrere Sensoren gleichzeitig ausgewertet werden.

Wie wird erkannt, ob die Pumpe defekt ist?

Du kennst den Raspberry Pi 5 vermutlich als kleinen, aber leistungsstarken Mini-Computer für unzählige Projekte. Doch mit dem Arduino UNO Q betritt ein spannender Hybrid die Bühne: Mikrocontroller trifft auf Linux-System.

Genau hier wird es interessant – denn beide Plattformen können auf den ersten Blick ähnliche Aufgaben übernehmen. Doch in der Praxis zeigen sich deutliche Unterschiede.

👉 Die entscheidende Frage ist also nicht: Welches Board ist besser?

👉 Sondern: Welches Board passt besser zu deinem Projekt?

In diesem Beitrag zeige ich dir anhand echter Einsatzszenarien, wo die Stärken und Schwächen liegen – und wann du besser zum Raspberry Pi 5 oder zum Arduino UNO Q greifen solltest.

Raspberry Pi 5 4GB Version

Arduino UNO Q 2GB Version

Größenvergleich - Arduino UNO Q mit Raspberry Pi 5

Technische Daten im Vergleich: Arduino UNO Q vs. Raspberry Pi 5

Bevor wir in die Praxis gehen, lohnt sich ein Blick auf die „harten Fakten“. Hier zeigt sich bereits: Der Arduino UNO Q verfolgt einen völlig anderen Ansatz als der Raspberry Pi 5.

Grundkonzept (der wichtigste Unterschied!) Arduino UNO QRaspberry Pi 5ArchitekturHybrid: MPU + MCUReiner Linux-ComputerBesonderheitKombination aus Echtzeit + LinuxMaximale Performance Prozessor & Grafik KategorieArduino UNO QRaspberry Pi 5CPUQuad-Core Cortex-A53 @ 2.0 GHzQuad-Core Cortex-A76 @ 2.4 GHzGPUAdreno 702VideoCore VIILeistungsolidedeutlich stärker

👉 Klarer Punkt für den Raspberry Pi 5 bei reiner Rechenleistung.

RAM & Speicher Arduino UNO QRaspberry Pi 5RAM2 GB / 4 GB LPDDR41–16 GB LPDDR4XSpeicher16 / 32 GB eMMC (integriert)microSD (extern)

👉 Wichtiger Unterschied:

- UNO Q → integrierter Speicher (wie SSD) - Pi 5 → SD-Karte (langsamer, aber flexibel)

💡 Das ist ein echter Praxisvorteil für den UNO Q (Zuverlässigkeit!).

Mikrocontroller (Gamechanger beim UNO Q) Arduino UNO QRaspberry Pi 5MCUSTM32U585 (Cortex-M33 @ 160 MHz)❌ keinerEchtzeitfähigkeit✅ vorhanden❌ nicht nativ

👉 Das ist DER Killer-Unterschied:

Der UNO Q kann gleichzeitig:

- Linux ausführen - UND Echtzeitsteuerung übernehmen

Der Raspberry Pi kann das nur eingeschränkt.

Schnittstellen & GPIO KategorieArduino UNO QRaspberry Pi 5GPIObis zu 47 Pins40 PinsADC✅ vorhanden❌ extern nötigDAC✅ vorhanden❌ extern nötigCAN✅ integriert❌ externSPI / I2C / UART✅ umfangreich✅ vorhanden

👉 Für Hardware-Projekte: UNO Q deutlich flexibler

Kommunikation Arduino UNO QRaspberry Pi 5WiFiWi-Fi 5 (2.4 / 5 GHz)Wi-Fi 5Bluetooth5.15.0Ethernet❌✅ Gigabit

👉 Vorteil Pi 5 bei stabilen Netzwerken (LAN!)

Multimedia & Erweiterung Arduino UNO QRaspberry Pi 5VideoUSB-C / MIPIDual HDMI 4KKameraMIPI CSI (dual)MIPI (dual)PCIe❌✅ vorhanden

👉 Hier ist der Raspberry Pi 5 klar überlegen.

Stromversorgung Arduino UNO QRaspberry Pi 5VersorgungUSB-C / VIN (7–24V)USB-C (5V)Verbrauchgeringerhöher

👉 Für IoT & Dauerbetrieb: Vorteil UNO Q

Zwischenfazit

Der Raspberry Pi 5 punktet klar bei:

- Rechenleistung - Multimedia - Erweiterbarkeit

Der Arduino UNO Q hingegen überzeugt durch:

- integrierten Speicher - echte Hardware-Schnittstellen - und vor allem durch den zusätzlichen Mikrocontroller

Benutzeroberfläche: UNO Q holt auf – aber mit Umwegen

Ein spannender Punkt, den viele beim Arduino UNO Q gar nicht auf dem Schirm haben:

Desktop - Arduino UNO Q

👉 Mit dem passenden Adapter lässt sich tatsächlich eine komplette Benutzeroberfläche betreiben.

Das bedeutet konkret:

- Monitor anschließen (über USB-C / Adapter) - Tastatur & Maus per Dongle verbinden - Stromversorgung ebenfalls über USB-C

Arduino UNO Q mit Adapter für Monitor - Maus und Tastatur

👉 Und schon kannst du den UNO Q wie einen kleinen Linux-Rechner nutzen.

Aber: Ganz so einfach ist es nicht

In der Praxis fehlen ohne Adapter einige Dinge:

- kein direkter 3,5 mm Klinkenanschluss für Sound - oft zu wenige USB-Ports für zusätzliche Geräte wie Webcam - insgesamt mehr „Bastelei“ durch Adapter nötig

👉 Genau hier merkt man: Der UNO Q kann das – ist aber nicht primär dafür gebaut.

Raspberry Pi 5: Plug & Play

Beim Raspberry Pi 5 ist das deutlich unkomplizierter:

- HDMI direkt vorhanden - mehrere USB-Ports direkt nutzbar - Audio einfacher integrierbar - Netzwerk (LAN) direkt verfügbar

👉 Anschließen, starten, fertig.

Raspberry Pi 5 im Desktopbetrieb mit HDMI und Maus-Tastatur Dongle

Desktop - Raspberry Pi 5

Und jetzt mal ehrlich: Was bedeutet das in der Praxis?

Auf dem Papier sehen viele Werte beeindruckend aus – mehr Kerne, mehr RAM, schnellere GPU. Doch in der Realität geht es selten um Benchmarks.

👉 Es geht darum, was du mit dem Board wirklich machen willst.

Denn genau hier trennen sich die Wege von Raspberry Pi 5 und Arduino UNO Q – auch wenn sie sich in manchen Bereichen inzwischen annähern.

Der Raspberry Pi 5 im Alltag

Der Raspberry Pi 5 verhält sich im Alltag wie ein kleiner Desktop-Rechner:

- Du installierst Software - startest Dienste wie Node-RED oder Docker - baust dir Dashboards - und lässt mehrere Anwendungen parallel laufen

👉 Kurz gesagt: Der Pi ist dein Mini-Server für alles, was mit Daten, Visualisierung und Logik zu tun hat.

Aufbau - Raspberry Pi 5 Der Arduino UNO Q im Alltag

Beim Arduino UNO Q ist der Ansatz ein anderer – aber vielseitiger, als man zunächst vermuten würde:

- Du arbeitest direkt mit Sensoren und Aktoren - reagierst auf Events in Echtzeit - steuerst Hardware ohne Umwege

👉 Und gleichzeitig kannst du auf der Linux-Seite Dinge wie Logging, Kommunikation oder sogar einfache Benutzeroberflächen umsetzen.

Mit dem passenden Adapter lässt sich der UNO Q sogar an Monitor, Tastatur und Maus betreiben.

👉 Allerdings merkt man hier schnell: Das funktioniert – ist aber mit mehr Aufwand verbunden als beim Raspberry Pi.

Der entscheidende Unterschied (einfach erklärt)

Ein entscheidender Vorteil des Arduino UNO Q ist die direkte Kommunikation zwischen Mikrocontroller und Linux-System.

Während beim Raspberry Pi alle Hardware-Zugriffe über das Betriebssystem laufen, kann der UNO Q zeitkritische Aufgaben unabhängig und verzögerungsfrei ausführen.

Fazit

Der Raspberry Pi 5 und der Arduino UNO Q verfolgen zwei unterschiedliche Ansätze – auch wenn sie sich auf den ersten Blick in einigen Bereichen annähern.

👉 Der Raspberry Pi 5 ist die richtige Wahl, wenn du:

- einen leistungsfähigen Mini-Server betreiben möchtest - Daten verarbeiten, speichern und visualisieren willst - mehrere Anwendungen parallel laufen lassen möchtest

👉 Der Arduino UNO Q hingegen spielt seine Stärken aus, wenn:

- du direkt mit Hardware arbeiten willst - Echtzeitverhalten entscheidend ist - du ohne großen Setup sofort loslegen möchtest

Besonders spannend wird es, wenn du beide kombinierst: Der Raspberry Pi übernimmt die Datenverarbeitung und Visualisierung, während der Arduino UNO Q Sensoren ausliest und Aktoren steuert.

👉 Und genau hier zeigt sich: Die beiden Boards sind keine direkten Konkurrenten – sondern ergänzen sich perfekt.

FAQ – Arduino UNO Q vs. Raspberry Pi 5

Was ist der Hauptunterschied zwischen Arduino UNO Q und Raspberry Pi 5?

Der wichtigste Unterschied liegt im Konzept: Der Raspberry Pi 5 ist ein vollwertiger Linux-Computer, während der Arduino UNO Q ein Hybrid-System aus Mikrocontroller und Linux-Plattform ist. Dadurch eignet sich der UNO Q besonders für hardware-nahe und echtzeitkritische Anwendungen.

Welches Board ist besser für Einsteiger geeignet?

Für klassische Elektronik- und Hardware-Projekte ist der Arduino UNO Q meist einfacher, da du direkt mit Pins und Sensoren arbeiten kannst. Der Raspberry Pi 5 eignet sich besser, wenn du bereits mit Linux arbeitest oder Software und Serverdienste nutzen möchtest.

Kann der Arduino UNO Q den Raspberry Pi 5 ersetzen?

Nicht vollständig. Der Arduino UNO Q kann viele Aufgaben übernehmen, insbesondere im Bereich IoT und Hardwaresteuerung. Für komplexe Anwendungen wie Docker, Datenbanken oder Multimedia ist der Raspberry Pi 5 jedoch deutlich besser geeignet.

Wann sollte ich den Raspberry Pi 5 verwenden?

Der Raspberry Pi 5 ist ideal für:

- Node-RED und Dashboards - MQTT-Broker und IoT-Plattformen - Datenverarbeitung und Speicherung - Webserver oder APIs Wann ist der Arduino UNO Q die bessere Wahl?

Der Arduino UNO Q ist besonders geeignet für:

- direkte Hardwaresteuerung - Sensoren und Aktoren - Echtzeitanwendungen - energieeffiziente Projekte Kann ich beide Boards zusammen verwenden?

Ja, und genau das ist oft die beste Lösung. Der Raspberry Pi 5 übernimmt dabei die Datenverarbeitung und Visualisierung, während der Arduino UNO Q für die direkte Hardwareansteuerung zuständig ist. Die Kommunikation kann z. B. über MQTT erfolgen.

Ist der Raspberry Pi 5 schwieriger zu programmieren?

Nicht unbedingt, aber anders. Beim Raspberry Pi 5 arbeitest du meist mit Programmiersprachen wie Python unter Linux, während der Arduino UNO Q klassisch mit Arduino-Code für die Hardwaresteuerung genutzt wird.

Warum ist der Arduino UNO Q für Echtzeit besser geeignet?

Auf meinem Blog habe ich bereits einige Projekte mit ePaper-Displays umgesetzt. Die Technik ist faszinierend: extrem stromsparend, perfekt ablesbar bei Sonnenlicht und ideal für IoT-Anwendungen.

Doch ein Nachteil zieht sich durch fast alle dieser Displays: sie sind oft ziemlich teuer.

Genau hier wird es spannend.

https://youtu.be/TG7722V8UGw

Mit dem Waveshare ESP32-S3 RLCD 4.2 kommt eine interessante Alternative ins Spiel. Statt eines klassischen ePaper-Displays setzt dieses Board auf ein sogenanntes RLCD (Reflective LCD) – und verspricht damit ein ähnliches „Look & Feel“, aber zu einem deutlich attraktiveren Preis.

👉 Die große Frage ist also: Kann dieses Display wirklich mit ePaper mithalten – oder ist es nur ein günstiger Kompromiss?

In diesem Beitrag starte ich mit einem Unboxing und meinem ersten Eindruck vom Board.

Transparenzhinweis: Das Gerät wurde mir von Waveshare für dieses Review kostenfrei zur Verfügung gestellt. Ich freue mich immer, wenn ich in dieser Form unterstützt werde und neue Hardware frühzeitig testen kann.

Selbstverständlich hat dies keinen Einfluss auf meine Bewertung – ich teile wie gewohnt meine ehrliche Meinung und praktische Erfahrungen mit dem Board.

Unboxing & erster Aufbau

Das Waveshare ESP32-S3 RLCD 4.2 wird in einer stabilen Verpackung geliefert, die das Board zuverlässig vor Stößen schützt. Bereits beim Auspacken macht das Ganze einen durchdachten Eindruck.

Neben dem Board selbst liegen noch ein kleiner Speaker sowie ein Kreuzschlitz-Schraubendreher bei – ein nettes Extra, das man so nicht bei jedem Entwicklerboard bekommt.

Interessant: Es gibt zwei Varianten des Boards – einmal mit und einmal ohne Akku. In meinem Fall war bereits ein LiPo-Akku (18650, 2600 mAh, 3,7 V) enthalten, was den Einstieg deutlich erleichtert und das Board direkt mobil einsetzbar macht.

Der mechanische Aufbau ist angenehm simpel gelöst. Die beiden Standfüße werden auf der Rückseite eingeklickt, und schon steht das Board stabil auf dem Schreibtisch – ganz ohne zusätzliches Zubehör oder Bastelarbeit.

Ein schönes Detail: Auf dem Board ist bereits ein Demo-Programm vorinstalliert. Dieses zeigt unter anderem:

- die aktuelle Temperatur - die relative Luftfeuchtigkeit - den Batteriestand - sowie die Anzahl erkannter WiFi- und BLE-Geräte in der Umgebung

👉 Damit bekommt man direkt nach dem Einschalten ein erstes Gefühl dafür, was mit dem Display möglich ist – ohne selbst sofort programmieren zu müssen.

Schwachstelle: Montage der Standfüße

Ein Punkt, der mir beim Aufbau negativ aufgefallen ist, betrifft die Montage der Standfüße.

Die Füße werden über kleine Kunststoffhaken auf der Rückseite befestigt. Dabei ist jedoch Vorsicht geboten:

👉 Die Haken sind relativ filigran und können bei der Montage leicht abbrechen.

In meinem Fall ist genau das passiert – die Halterung ist beim Einsetzen gebrochen, wodurch das Display nicht mehr sicher steht.

Lösung: 3D-Druck als Alternative

Ich habe mir die Standfüße kurzerhand mit Tinkercad und meinem 3D-Drucker neu erstellt und dabei direkt etwas angepasst:

- sitzen nicht mehr ganz so stramm - minimal kleiner dimensioniert - dadurch deutlich einfacher einzusetzen

einfache Ersatzfüsse für das RLCD Display von Waveshare aus dem 3D Drucker

👉 Ergebnis: Das Display steht wieder stabil – und die Montage ist deutlich entspannter.

Nachfolgend die STL-Datei als download:

3D Druckvorlage für Ersatzfuss des RLCD Device von WaveshareHerunterladen

Technische Daten im Überblick

BereichDetailsProzessorXtensa 32-bit LX7 Dual-Core, bis zu 240 MHzSpeicher512 KB SRAM, 384 KB ROM, 16 MB Flash, 8 MB PSRAMKonnektivität2,4 GHz Wi-Fi, Bluetooth 5 (LE), integrierte AntenneDisplay4,2″ RLCD (Reflective LCD), 300 × 400 Pixel, ohne HintergrundbeleuchtungAudioDual-Mikrofon-Array (Noise Reduction, Echo Cancellation)SensorenSHTC3 (Temperatur & relative Luftfeuchtigkeit)RTCPCF85063 Echtzeituhr + Anschluss für Backup-BatterieStromversorgung18650 Akkuhalter + separater RTC-BatterieanschlussSpeichermicroSD (TF) KartenslotGPIO2 × 8 Pin Header (2,54 mm Rastermaß)BedienelementeBOOT, POWER, frei programmierbarer KEY-Button

Aufbau & Anschlüsse im Detail

Werfen wir einen genaueren Blick auf den Aufbau des Waveshare ESP32-S3 RLCD 4.2.

Auf der Vorderseite dominiert ganz klar das 4,2″ große RLCD-Display mit einer Auflösung von 300 × 400 Pixeln. Dieses ist das zentrale Element des Boards und macht direkt deutlich, worauf der Fokus hier liegt: Visualisierung bei möglichst geringem Energieverbrauch.

Die Rückseite ist deutlich spannender – hier sitzt die eigentliche Technik:

Aufbau - ESP32-S3 4.2" RLCD von Waveshare

Zusätzlich befinden sich unterhalb der USB-C Buchse zwei kleine Status-LEDs:

- eine LED zeigt an, dass der Akku geladen wird - eine weitere LED dient als Schutzindikator und warnt, wenn der Akku falsch herum eingelegt wurde

👉 Gerade letzteres ist ein schönes Detail, das man nicht oft sieht und im Zweifel vor Schäden schützen kann.

👉 Insgesamt wirkt das Layout gut durchdacht: Alle wichtigen Anschlüsse sind sauber erreichbar, und das Board lässt sich ohne viel Aufwand direkt in eigene Projekte integrieren.

Hinweis zum integrierten SHTC3 Sensor

Auf dem Board ist bereits ein SHTC3 Sensor verbaut, der Temperatur und relative Luftfeuchtigkeit misst. Damit eignet sich das Board direkt für einfache Umweltmessungen – ganz ohne zusätzliche Hardware.

Die wichtigsten Spezifikationen im Überblick:

Luftfeuchtigkeit

- typische Genauigkeit: ±2 %RH - Messbereich: 0 – 100 %RH - Ansprechzeit (τ63%): ca. 8 Sekunden - werkseitig kalibriert

Temperatur

- typische Genauigkeit: ±0,2 °C - Ansprechzeit (τ63%): ca. 5 Sekunden Wichtiger Hinweis zur Messgenauigkeit

Auch wenn der integrierte SHTC3 Sensor auf dem Papier gute Werte liefert, gibt es in der Praxis einen entscheidenden Punkt zu beachten:

👉 Der Sensor ist auf der Platine hinter dem RLCD-Display verbaut und wird zusätzlich von einer etwa 3 mm starken Acrylplatte abgedeckt.

SHTC3 Sensor am ESP32-S3 Development Board von Waveshare

Das führt dazu, dass:

- der Sensor nicht direkt der Umgebungsluft ausgesetzt ist - sich Wärme vom Development Board staut - die Luftzirkulation eingeschränkt ist

👉Dadurch misst der Sensor eher die Temperatur des Boards selbst als die der Umgebung.

RLCD vs. LCD vs. ePaper – wo liegt der Unterschied?

Bevor wir das Display bewerten, lohnt sich ein kurzer Blick auf die Technik dahinter. Denn ein RLCD (Reflective LCD) ist weder ein klassisches LCD noch ein ePaper-Display – sondern liegt irgendwo dazwischen.

TFT-LCD (klassisches Farbdisplay)

Die meisten Displays, die du aus Smartphones, günstigen ESP32-Displays oder Monitoren kennst, sind sogenannte TFT-LCDs (Thin-Film-Transistor Displays).

Das bedeutet:

- jedes Pixel wird aktiv angesteuert - das Display benötigt immer eine Hintergrundbeleuchtung

ESP32 - 1.9" TFT Display - Mini-Garten Dashboard

Vorteile

- kräftige Farben und hohe Helligkeit - sehr schnelle Reaktionszeit (perfekt für Animationen & UI) - gut geeignet für interaktive Anwendungen - unabhängig vom Umgebungslicht

Nachteile

- hoher Stromverbrauch durch Hintergrundbeleuchtung - bei direkter Sonne oft schlechter ablesbar - für batteriebetriebene Projekte eher ungünstig RLCD (Reflective LCD)

Ein RLCD – wie beim Waveshare ESP32-S3 RLCD 4.2 – verzichtet komplett auf eine Hintergrundbeleuchtung.

Stattdessen nutzt es:

- Umgebungslicht zur Darstellung - ähnlich wie Papier oder ePaper

RLCD Display am ESP32-S3 Development Board

Vorteile

- deutlich stromsparender als normales LCD - sehr gut bei Tageslicht ablesbar - schnelle Reaktionszeiten (kein „Refresh-Flackern“)

Nachteile

- bei wenig Licht schlechter sichtbar - Kontrast nicht ganz so stark wie bei ePaper ePaper (E-Ink)

ePaper geht noch einen Schritt weiter:

Eigenschaften:

- Bild bleibt ohne Strom dauerhaft sichtbar - extrem hoher Kontrast - wirkt wie echtes Papier

ePaper-Display mit aktuellen Wetterdaten

Vorteile

- minimaler Stromverbrauch - perfekt für statische Inhalte - sehr gut ablesbar

Nachteile

- sehr langsamer Bildaufbau - sichtbares „Flackern“ beim Aktualisieren - meist deutlich teurer

Direkter Vergleich

FeatureTFTRLCDePaperStromverbrauch❌ hoch⚖️ mittel✅ sehr geringAblesbarkeit Sonne⚖️ mittel✅ gut✅ sehr gutHelligkeit (dunkel)✅ sehr gut❌ schlecht❌ schlechtGeschwindigkeit✅ sehr schnell✅ schnell❌ langsamDaueranzeige ohne Strom❌ nein❌ nein✅ jaPreis⚖️ mittel✅ günstig❌ teuer Erste Einordnung

Nach dem direkten Vergleich wird schnell klar:

👉 Das RLCD ist weder ein klassisches Display noch ein ePaper-Ersatz.

Stattdessen positioniert es sich genau dazwischen:

- deutlich schneller als ePaper - stromsparender als ein TFT - und vor allem: deutlich günstiger

👉 Genau diese Kombination macht das Display besonders interessant für IoT-Projekte, bei denen sich Inhalte regelmäßig ändern.

Erster Eindruck vom RLCD Display

Nach dem ersten Einschalten war ich ehrlich gesagt gespannt, wie nah das RLCD wirklich an ein ePaper-Display herankommt.

👉 Die kurze Antwort: Es ist anders – aber auf eine interessante Art.

Die Darstellung wirkt insgesamt etwas matter als bei einem klassischen TFT-Display, was aber durchaus gewollt ist. Gerade bei gutem Umgebungslicht lässt sich der Inhalt sehr angenehm ablesen.

Was sofort auffällt:

👉 Das Display reagiert deutlich schneller als ePaper.

- kein Flackern - keine langen Refresh-Zeiten - Inhalte werden direkt aktualisiert

Allerdings zeigt sich auch schnell die Kehrseite:

👉 Bei schlechten Lichtverhältnissen wird das Display schwer lesbar.

Hier fehlt schlicht die Hintergrundbeleuchtung – ein Punkt, den man bei der Projektwahl unbedingt berücksichtigen sollte.

Für wen lohnt sich das Board?

Das Waveshare ESP32-S3 RLCD 4.2 ist besonders interessant für:

- IoT Dashboards - Wetterstationen - Smart Home Anzeigen - Akkubetriebene Projekte mit regelmäßigen Updates

👉 Weniger geeignet ist es für:

- rein statische Anzeigen (hier bleibt ePaper überlegen) - dunkle Umgebungen ohne zusätzliche Beleuchtung

Fazit: ePaper Killer?

👉 Die kurze Antwort: Nein – aber das muss es auch gar nicht sein.

Das Waveshare ESP32-S3 RLCD 4.2 positioniert sich genau zwischen klassischem TFT und ePaper – und trifft damit einen sehr interessanten Sweet Spot.

ePaper bleibt unschlagbar, wenn es um:

- extrem niedrigen Stromverbrauch - und statische Inhalte

geht.

Das RLCD hingegen punktet mit:

- deutlich schnellerer Darstellung - guter Ablesbarkeit bei Tageslicht - und einem spürbar günstigeren Preis

👉 Gerade für Projekte mit regelmäßig aktualisierten Inhalten – wie Dashboards oder Smart-Home-Anzeigen – ist das ein echter Vorteil.

Natürlich gibt es auch Schwächen:

- keine Hintergrundbeleuchtung → schwierig bei wenig Licht - kleinere Verarbeitungsdetails (z. B. Standfüße)

Auf meinem Blog habe ich bereits einige Projekte mit ePaper-Displays umgesetzt. Die Technik ist faszinierend: extrem stromsparend, perfekt ablesbar bei Sonnenlicht und ideal für IoT-Anwendungen.

Doch ein Nachteil zieht sich durch fast alle dieser Displays: sie sind oft ziemlich teuer.

Genau hier wird es spannend.

https://youtu.be/TG7722V8UGw

Mit dem Waveshare ESP32-S3 RLCD 4.2 kommt eine interessante Alternative ins Spiel. Statt eines klassischen ePaper-Displays setzt dieses Board auf ein sogenanntes RLCD (Reflective LCD) – und verspricht damit ein ähnliches „Look & Feel“, aber zu einem deutlich attraktiveren Preis.

👉 Die große Frage ist also: Kann dieses Display wirklich mit ePaper mithalten – oder ist es nur ein günstiger Kompromiss?

In diesem Beitrag starte ich mit einem Unboxing und meinem ersten Eindruck vom Board.

Transparenzhinweis: Das Gerät wurde mir von Waveshare für dieses Review kostenfrei zur Verfügung gestellt. Ich freue mich immer, wenn ich in dieser Form unterstützt werde und neue Hardware frühzeitig testen kann.

Selbstverständlich hat dies keinen Einfluss auf meine Bewertung – ich teile wie gewohnt meine ehrliche Meinung und praktische Erfahrungen mit dem Board.

Unboxing & erster Aufbau

Das Waveshare ESP32-S3 RLCD 4.2 wird in einer stabilen Verpackung geliefert, die das Board zuverlässig vor Stößen schützt. Bereits beim Auspacken macht das Ganze einen durchdachten Eindruck.

Neben dem Board selbst liegen noch ein kleiner Speaker sowie ein Kreuzschlitz-Schraubendreher bei – ein nettes Extra, das man so nicht bei jedem Entwicklerboard bekommt.

Interessant: Es gibt zwei Varianten des Boards – einmal mit und einmal ohne Akku. In meinem Fall war bereits ein LiPo-Akku (18650, 2600 mAh, 3,7 V) enthalten, was den Einstieg deutlich erleichtert und das Board direkt mobil einsetzbar macht.

Der mechanische Aufbau ist angenehm simpel gelöst. Die beiden Standfüße werden auf der Rückseite eingeklickt, und schon steht das Board stabil auf dem Schreibtisch – ganz ohne zusätzliches Zubehör oder Bastelarbeit.

Ein schönes Detail: Auf dem Board ist bereits ein Demo-Programm vorinstalliert. Dieses zeigt unter anderem:

- die aktuelle Temperatur - die relative Luftfeuchtigkeit - den Batteriestand - sowie die Anzahl erkannter WiFi- und BLE-Geräte in der Umgebung

👉 Damit bekommt man direkt nach dem Einschalten ein erstes Gefühl dafür, was mit dem Display möglich ist – ohne selbst sofort programmieren zu müssen.

Schwachstelle: Montage der Standfüße

Ein Punkt, der mir beim Aufbau negativ aufgefallen ist, betrifft die Montage der Standfüße.

Die Füße werden über kleine Kunststoffhaken auf der Rückseite befestigt. Dabei ist jedoch Vorsicht geboten:

👉 Die Haken sind relativ filigran und können bei der Montage leicht abbrechen.

In meinem Fall ist genau das passiert – die Halterung ist beim Einsetzen gebrochen, wodurch das Display nicht mehr sicher steht.

Lösung: 3D-Druck als Alternative

Ich habe mir die Standfüße kurzerhand mit Tinkercad und meinem 3D-Drucker neu erstellt und dabei direkt etwas angepasst:

- sitzen nicht mehr ganz so stramm - minimal kleiner dimensioniert - dadurch deutlich einfacher einzusetzen

einfache Ersatzfüsse für das RLCD Display von Waveshare aus dem 3D Drucker

👉 Ergebnis: Das Display steht wieder stabil – und die Montage ist deutlich entspannter.

Nachfolgend die STL-Datei als download:

3D Druckvorlage für Ersatzfuss des RLCD Device von WaveshareHerunterladen

Technische Daten im Überblick

BereichDetailsProzessorXtensa 32-bit LX7 Dual-Core, bis zu 240 MHzSpeicher512 KB SRAM, 384 KB ROM, 16 MB Flash, 8 MB PSRAMKonnektivität2,4 GHz Wi-Fi, Bluetooth 5 (LE), integrierte AntenneDisplay4,2″ RLCD (Reflective LCD), 300 × 400 Pixel, ohne HintergrundbeleuchtungAudioDual-Mikrofon-Array (Noise Reduction, Echo Cancellation)SensorenSHTC3 (Temperatur & relative Luftfeuchtigkeit)RTCPCF85063 Echtzeituhr + Anschluss für Backup-BatterieStromversorgung18650 Akkuhalter + separater RTC-BatterieanschlussSpeichermicroSD (TF) KartenslotGPIO2 × 8 Pin Header (2,54 mm Rastermaß)BedienelementeBOOT, POWER, frei programmierbarer KEY-Button

Aufbau & Anschlüsse im Detail

Werfen wir einen genaueren Blick auf den Aufbau des Waveshare ESP32-S3 RLCD 4.2.

Auf der Vorderseite dominiert ganz klar das 4,2″ große RLCD-Display mit einer Auflösung von 300 × 400 Pixeln. Dieses ist das zentrale Element des Boards und macht direkt deutlich, worauf der Fokus hier liegt: Visualisierung bei möglichst geringem Energieverbrauch.

Die Rückseite ist deutlich spannender – hier sitzt die eigentliche Technik:

Aufbau - ESP32-S3 4.2" RLCD von Waveshare

Zusätzlich befinden sich unterhalb der USB-C Buchse zwei kleine Status-LEDs:

- eine LED zeigt an, dass der Akku geladen wird - eine weitere LED dient als Schutzindikator und warnt, wenn der Akku falsch herum eingelegt wurde

👉 Gerade letzteres ist ein schönes Detail, das man nicht oft sieht und im Zweifel vor Schäden schützen kann.

👉 Insgesamt wirkt das Layout gut durchdacht: Alle wichtigen Anschlüsse sind sauber erreichbar, und das Board lässt sich ohne viel Aufwand direkt in eigene Projekte integrieren.

Hinweis zum integrierten SHTC3 Sensor

Auf dem Board ist bereits ein SHTC3 Sensor verbaut, der Temperatur und relative Luftfeuchtigkeit misst. Damit eignet sich das Board direkt für einfache Umweltmessungen – ganz ohne zusätzliche Hardware.

Die wichtigsten Spezifikationen im Überblick:

Luftfeuchtigkeit

- typische Genauigkeit: ±2 %RH - Messbereich: 0 – 100 %RH - Ansprechzeit (τ63%): ca. 8 Sekunden - werkseitig kalibriert

Temperatur

- typische Genauigkeit: ±0,2 °C - Ansprechzeit (τ63%): ca. 5 Sekunden Wichtiger Hinweis zur Messgenauigkeit

Auch wenn der integrierte SHTC3 Sensor auf dem Papier gute Werte liefert, gibt es in der Praxis einen entscheidenden Punkt zu beachten:

👉 Der Sensor ist auf der Platine hinter dem RLCD-Display verbaut und wird zusätzlich von einer etwa 3 mm starken Acrylplatte abgedeckt.

SHTC3 Sensor am ESP32-S3 Development Board von Waveshare

Das führt dazu, dass:

- der Sensor nicht direkt der Umgebungsluft ausgesetzt ist - sich Wärme vom Development Board staut - die Luftzirkulation eingeschränkt ist

👉Dadurch misst der Sensor eher die Temperatur des Boards selbst als die der Umgebung.

RLCD vs. LCD vs. ePaper – wo liegt der Unterschied?

Bevor wir das Display bewerten, lohnt sich ein kurzer Blick auf die Technik dahinter. Denn ein RLCD (Reflective LCD) ist weder ein klassisches LCD noch ein ePaper-Display – sondern liegt irgendwo dazwischen.

TFT-LCD (klassisches Farbdisplay)

Die meisten Displays, die du aus Smartphones, günstigen ESP32-Displays oder Monitoren kennst, sind sogenannte TFT-LCDs (Thin-Film-Transistor Displays).

Das bedeutet:

- jedes Pixel wird aktiv angesteuert - das Display benötigt immer eine Hintergrundbeleuchtung

ESP32 - 1.9" TFT Display - Mini-Garten Dashboard

Vorteile

- kräftige Farben und hohe Helligkeit - sehr schnelle Reaktionszeit (perfekt für Animationen & UI) - gut geeignet für interaktive Anwendungen - unabhängig vom Umgebungslicht

Nachteile

- hoher Stromverbrauch durch Hintergrundbeleuchtung - bei direkter Sonne oft schlechter ablesbar - für batteriebetriebene Projekte eher ungünstig RLCD (Reflective LCD)

Ein RLCD – wie beim Waveshare ESP32-S3 RLCD 4.2 – verzichtet komplett auf eine Hintergrundbeleuchtung.

Stattdessen nutzt es:

- Umgebungslicht zur Darstellung - ähnlich wie Papier oder ePaper

RLCD Display am ESP32-S3 Development Board

Vorteile

- deutlich stromsparender als normales LCD - sehr gut bei Tageslicht ablesbar - schnelle Reaktionszeiten (kein „Refresh-Flackern“)

Nachteile

- bei wenig Licht schlechter sichtbar - Kontrast nicht ganz so stark wie bei ePaper ePaper (E-Ink)

ePaper geht noch einen Schritt weiter:

Eigenschaften:

- Bild bleibt ohne Strom dauerhaft sichtbar - extrem hoher Kontrast - wirkt wie echtes Papier

ePaper-Display mit aktuellen Wetterdaten

Vorteile

- minimaler Stromverbrauch - perfekt für statische Inhalte - sehr gut ablesbar

Nachteile

- sehr langsamer Bildaufbau - sichtbares „Flackern“ beim Aktualisieren - meist deutlich teurer

Direkter Vergleich

FeatureTFTRLCDePaperStromverbrauch❌ hoch⚖️ mittel✅ sehr geringAblesbarkeit Sonne⚖️ mittel✅ gut✅ sehr gutHelligkeit (dunkel)✅ sehr gut❌ schlecht❌ schlechtGeschwindigkeit✅ sehr schnell✅ schnell❌ langsamDaueranzeige ohne Strom❌ nein❌ nein✅ jaPreis⚖️ mittel✅ günstig❌ teuer Erste Einordnung

Nach dem direkten Vergleich wird schnell klar:

👉 Das RLCD ist weder ein klassisches Display noch ein ePaper-Ersatz.

Stattdessen positioniert es sich genau dazwischen:

- deutlich schneller als ePaper - stromsparender als ein TFT - und vor allem: deutlich günstiger

👉 Genau diese Kombination macht das Display besonders interessant für IoT-Projekte, bei denen sich Inhalte regelmäßig ändern.

Erster Eindruck vom RLCD Display

Nach dem ersten Einschalten war ich ehrlich gesagt gespannt, wie nah das RLCD wirklich an ein ePaper-Display herankommt.

👉 Die kurze Antwort: Es ist anders – aber auf eine interessante Art.

Die Darstellung wirkt insgesamt etwas matter als bei einem klassischen TFT-Display, was aber durchaus gewollt ist. Gerade bei gutem Umgebungslicht lässt sich der Inhalt sehr angenehm ablesen.

Was sofort auffällt:

👉 Das Display reagiert deutlich schneller als ePaper.

- kein Flackern - keine langen Refresh-Zeiten - Inhalte werden direkt aktualisiert

Allerdings zeigt sich auch schnell die Kehrseite:

👉 Bei schlechten Lichtverhältnissen wird das Display schwer lesbar.

Hier fehlt schlicht die Hintergrundbeleuchtung – ein Punkt, den man bei der Projektwahl unbedingt berücksichtigen sollte.

Für wen lohnt sich das Board?

Das Waveshare ESP32-S3 RLCD 4.2 ist besonders interessant für:

- IoT Dashboards - Wetterstationen - Smart Home Anzeigen - Akkubetriebene Projekte mit regelmäßigen Updates

👉 Weniger geeignet ist es für:

- rein statische Anzeigen (hier bleibt ePaper überlegen) - dunkle Umgebungen ohne zusätzliche Beleuchtung

Fazit: ePaper Killer?

👉 Die kurze Antwort: Nein – aber das muss es auch gar nicht sein.

Das Waveshare ESP32-S3 RLCD 4.2 positioniert sich genau zwischen klassischem TFT und ePaper – und trifft damit einen sehr interessanten Sweet Spot.

ePaper bleibt unschlagbar, wenn es um:

- extrem niedrigen Stromverbrauch - und statische Inhalte

geht.

Das RLCD hingegen punktet mit:

- deutlich schnellerer Darstellung - guter Ablesbarkeit bei Tageslicht - und einem spürbar günstigeren Preis

👉 Gerade für Projekte mit regelmäßig aktualisierten Inhalten – wie Dashboards oder Smart-Home-Anzeigen – ist das ein echter Vorteil.

Natürlich gibt es auch Schwächen:

- keine Hintergrundbeleuchtung → schwierig bei wenig Licht - kleinere Verarbeitungsdetails (z. B. Standfüße)

Im letzten Beitrag habe ich gezeigt, wie man mit Node-RED Wetterdaten von einer offenen API abruft und in einer CSV-Datei speichert. Damit haben wir bereits eine einfache Möglichkeit geschaffen, Messwerte dauerhaft zu protokollieren.

Doch reine Daten in einer Datei sind oft schwer zu interpretieren. Viel übersichtlicher wird es, wenn man die Werte grafisch als Diagramm darstellt.

Genau hier kommt das Node-RED Dashboard ins Spiel. Damit lassen sich mit wenigen Klicks eigene Web-Dashboards erstellen, auf denen Daten aus Flows übersichtlich angezeigt werden können – zum Beispiel als Diagramme, Anzeigen oder Statusfelder.

https://youtu.be/g5gMUChtAbE

In diesem Beitrag zeige ich dir Schritt für Schritt:

- wie du das Node-RED Dashboard installierst, - wie du deine gespeicherten Daten aus der CSV-Datei einliest, - und wie du daraus ein Diagramm im Dashboard erstellst.

Am Ende dieses Tutorials erhältst du ein kleines Dashboard, das den Temperaturverlauf aus einer gespeicherten CSV-Datei als Diagramm darstellt. Zusätzlich lassen sich die Daten später problemlos erweitern, etwa um Minimal- und Maximalwerte oder weitere Wetterparameter.

Installation des FlowFuse Dashboards

Für die Visualisierung von Daten in Node-RED gibt es verschiedene Dashboard-Lösungen. Lange Zeit war das Paket node-red-dashboard die Standardlösung. Dieses wird jedoch inzwischen nicht mehr aktiv weiterentwickelt und ist als deprecated markiert.

Node-RED Dashboard - deprecated Hinweis

Stattdessen setzen wir in diesem Beitrag auf das FlowFuse Dashboard, den modernen Nachfolger des klassischen Dashboards. Dieses wird aktiv gepflegt und bietet eine deutlich modernere Oberfläche.

Die Installation erfolgt direkt über das Webfrontend von Node-RED.

Öffne dazu das Menü oben rechts und gehe anschließend wie folgt vor:

- Menü (≡) öffnen - Palette verwalten auswählen - Zum Tab „Installation“ wechseln - Nach @flowfuse/node-red-dashboard suchen - Auf Installieren klicken

Nach der Installation erscheinen im Node-RED Editor neue Nodes für das Dashboard. Diese erkennst du an der Kategorie Dashboard 2.

Damit lassen sich verschiedene Elemente erstellen, zum Beispiel:

- Charts für Diagramme - Textfelder zur Anzeige von Werten - Buttons für Interaktionen - Statusanzeigen

Im nächsten Schritt erstellen wir ein einfaches Dashboard und zeigen dort die gespeicherten Wetterdaten aus der CSV-Datei als Diagramm an.

CSV-Datei in Node-RED einlesen

Als erstes lesen wir die Daten aus der zuvor gespeicherten CSV-Datei ein.

Node-RED - Flow zum einlesen der CSV-Daten - Ausgabe im Debug-Tab

Node-RED - Konfiguration der Read-File-Node

Node-RED - Konfiguration der Debug-Node für die Ausgabe der CSV-Daten

Die CSV-Datei liegt in meinem Fall im Homeverzeichnis auf dem Raspberry Pi.

Ablage der CSV-Datei im Homeverzeichnis

Wetterdaten aus der CSV-Datei laden

Wir haben die Daten zunächst im Debug-Tab ausgegeben, um zu prüfen, ob die CSV-Datei korrekt eingelesen wird. Für die weitere Verarbeitung reicht diese Darstellung jedoch nicht aus, da wir die Daten später als Array von Objekten benötigen, um sie im Diagramm darstellen zu können.

Im nächsten Schritt werden die Daten daher mit einem CSV-Node verarbeitet. Dabei definieren wir die Spaltenüberschriften der Datei. Diese werden kommagetrennt angegeben und dienen anschließend als Keys für die erzeugten Objekte.

Die Ausgabe im Debug-Tab ist nun ein Array (eine simple Liste) mit Objekten welche die Schlüssel-Werte Paare enthält.

Daten für das Diagramm formatieren

Die nun ermittelten Daten werden im nächsten Schritt mit einer Function-Node mithilfe von JavaScript aufbereitet. Zum einen benötigen wir aus den eingelesenen Datensätzen lediglich den Zeitstempel sowie die Temperatur. Zum anderen – und das ist der entscheidende Punkt – erwartet das Diagramm im Dashboard die Daten in einem bestimmten Format.

Damit das Diagramm den Temperaturverlauf korrekt darstellen kann, müssen die Werte als Objekte mit Zeit- und Messwert bereitgestellt werden. Zusätzlich wird der Zeitstempel in Millisekunden umgewandelt, da das Diagramm diese Form für die Darstellung der Zeitachse verwendet.

Die Function-Node übernimmt also zwei Aufgaben:

- Reduzieren der Daten auf die benötigten Werte - Umwandeln der Daten in das passende Format für das Diagramm

Node-RED - Flow - aufbereiten der Daten für das Diagramm let data = msg.payload; if (!Array.isArray(data)) { data = ; } msg.payload = data .map(row => { let ts = row.zeitstempel; let temp = parseFloat(row.temperatur); return { time: ts, temperatur: temp }; }) .filter(row => row !== null); msg.action = "replace"; return msg;

Wir haben nun ein gefiltertes Array mit nur dem Zeitstempel und der Temperatur.

Temperaturverlauf im Dashboard visualisieren

Wir haben nun die Daten aufbereitet und können diese als nächstes im Diagramm visualisieren. Dazu wählen wir die Chart-Node und konfigurieren diese wie folgt:

Node-RED - Konfiguration der Chart-Node

Node-RED - Flow - visualisieren der gespeicherten Daten aus einer CSV-Datei im FlowFuse Dashboard Formatieren der Zeitachse

Für die Formatierung der Zeitachse stehen verschiedene Möglichkeiten zur Verfügung. Welche Werte dabei verwendet werden können, ist in der offiziellen Dokumentation von Apache ECharts beschrieben.

Eine Übersicht der verfügbaren Formatierungsoptionen findest du hier: https://echarts.apache.org/en/option.html#xAxis.axisLabel.formatter

Über diese Einstellungen lässt sich beispielsweise festlegen, ob nur Stunden und Minuten, das vollständige Datum oder eine individuelle Darstellung der Zeitstempel auf der X-Achse angezeigt werden.

Starten des Flows und visualisieren der Daten

Damit die Daten im Diagramm angezeigt werden, starten wir den Flow über die Injection-Node damit wir das Diagramm mit den ausgelesenen Daten befüllt.

Node-RED - FlowFuse Dashboard mit historischen Temperaturdaten

Minimale, maximale und durchschnittliche Temperatur berechnen

Neben der minimalen und maximalen Temperatur kann es interessant sein, zusätzlich die durchschnittliche Temperatur zu berechnen. Diese gibt einen schnellen Überblick über die allgemeine Temperaturentwicklung im betrachteten Zeitraum.

Node-RED - Flow erweitert für die Ausgabe der min - max und Durschnittstemperatur

Da unsere Daten bereits als Array von Objekten vorliegen, können wir alle drei Werte in einem einzigen Durchlauf berechnen. Das ist effizienter als mehrere separate Berechnungen.

Dazu verwenden wir drei Variablen:

- minTemp für die minimale Temperatur - maxTemp für die maximale Temperatur - sumTemp für die Summe aller Temperaturwerte

Während wir das Array durchlaufen, aktualisieren wir diese Werte entsprechend. Am Ende können wir aus der Summe und der Anzahl der Messwerte die durchschnittliche Temperatur berechnen.

Eine mögliche Implementierung in der Function-Node sieht wie folgt aus:

let data = msg.payload; let minTemp = Infinity; let maxTemp = -Infinity; let sumTemp = 0; let count = 0; for (const row of data) { let temp = parseFloat(row.temperatur); if (isNaN(temp)) { continue; } if (temp maxTemp) maxTemp = temp; sumTemp += temp; count++; } let avgTemp = count > 0 ? sumTemp / count : 0; msg.minTemp = "Min. Temperatur: " + minTemp.toFixed(2) + "°C"; msg.maxTemp = "Max. Temperatur: " + maxTemp.toFixed(2) + "°C"; msg.avgTemp = "Ø Temperatur: " + avgTemp.toFixed(2) + "°C"; return msg;

Nach der Ausführung stehen uns drei Werte im msg-Objekt zur Verfügung:

- msg.minTemp – minimale Temperatur - msg.maxTemp – maximale Temperatur - msg.avgTemp – durchschnittliche Temperatur

Diese können anschließend beispielsweise mit Text-Widgets im Dashboard angezeigt werden.

Node-RED - Abschnitt zum anzeigen der min,max und durschnitts Temperatur mit ui-text-Nodes

Node-RED - Konfiguration der Text-Node für die MIN-Temperatur

Node-RED - Konfiguration der Text-Node für die MAX-Temperatur

Node-RED - Konfiguration der Text-Node für die AVG-Temperatur Node-RED - Dashboard für Temperaturverlauf aus CSV-DateiHerunterladen

Fazit

Mit wenigen Nodes lässt sich in Node-RED aus einfachen CSV-Daten ein übersichtliches Dashboard erstellen. Die gespeicherten Wetterdaten werden dabei nicht nur grafisch dargestellt, sondern können zusätzlich ausgewertet werden, etwa durch die Berechnung von Minimal-, Maximal- und Durchschnittswerten.

Wie du Node-RED in einem Docker-Container startest, habe ich dir bereits im Beitrag „Node-RED mit Docker installieren – Schritt für Schritt“ gezeigt. Nun gehen wir einen Schritt weiter und binden eine Datenbank an, damit wir die im Flow gesammelten Daten dauerhaft speichern können.

https://youtu.be/4X5efvva2I4

Gerade im Zusammenspiel node-red sqlite docker ist SQLite eine ideale Lösung für den Einstieg. Der große Vorteil: SQLite benötigt keinen eigenen Server, sondern speichert alle Daten in einer einzigen Datei. Diese Datei können wir einfach in einem eingebundenen Docker-Volume ablegen und behalten unsere Daten auch nach einem Neustart des Containers.

Damit eignet sich SQLite perfekt für:

- Logging von Sensordaten - Zwischenspeichern von API-Daten - einfache IoT-Projekte (z. B. mit Shelly oder ESP32)

In diesem Beitrag zeige ich dir Schritt für Schritt, wie du eine SQLite-Datenbank in Node-RED einbindest und erste SQL-Abfragen ausführst.

Warum SQLite für Node-RED ideal ist

Wenn du mit Node-RED arbeitest, möchtest du Daten häufig nicht nur kurzfristig im Flow verarbeiten, sondern auch dauerhaft speichern. Genau hier kommt eine Datenbank ins Spiel.

Für den Einstieg ist SQLite besonders gut geeignet, da sie im Vergleich zu klassischen Datenbanksystemen wie MySQL oder PostgreSQL deutlich einfacher aufgebaut ist.

Der größte Vorteil: SQLite benötigt keinen eigenen Server. Alle Daten werden in einer einzigen Datei gespeichert, die direkt im Dateisystem liegt. In unserem Fall bedeutet das, dass wir die Datenbank einfach im Docker-Volume von Node-RED ablegen können – zum Beispiel im Verzeichnis /data.

SQLite Datenbank im Docker Volume abgelegt

Das bringt mehrere Vorteile mit sich:

- Einfache Einrichtung Keine zusätzliche Installation oder Konfiguration eines Datenbankservers notwendig - Perfekt für Docker geeignet Die Datenbank ist nur eine Datei und kann problemlos über ein Volume persistent gespeichert werden - Ideal für kleine bis mittlere Projekte z. B. Logging von Sensordaten, API-Daten oder einfache Auswertungen - Geringer Ressourcenverbrauch SQLite ist sehr leichtgewichtig und läuft problemlos auch auf einem Raspberry Pi

Gerade im Zusammenspiel Node-RED SQLite Docker ergibt sich damit eine sehr schlanke und gleichzeitig leistungsfähige Lösung, um Daten aus deinen Flows zu speichern und später weiterzuverarbeiten.

Für größere Projekte mit vielen gleichzeitigen Zugriffen oder komplexen Abfragen kann später immer noch auf Systeme wie MySQL oder PostgreSQL gewechselt werden. Für den Einstieg und viele IoT-Anwendungen ist SQLite jedoch mehr als ausreichend.

SQLite Nodes in Node-RED installieren

Damit wir eine SQLite-Datenbank in Node-RED verwenden können, benötigen wir zunächst die passenden Nodes. Diese lassen sich ganz einfach über die integrierte Paketverwaltung nachinstallieren.

Öffne dazu im Node-RED Editor das Menü oben rechts und gehe auf:

👉 Menü → Palette verwalten → Reiter „Installieren“

Im Suchfeld gibst du anschließend sqlite ein. In der Ergebnisliste erscheint das Paket:

👉 node-red-node-sqlite

Dieses Paket stellt dir die notwendigen Nodes zur Verfügung, um SQL-Abfragen direkt innerhalb deiner Flows auszuführen.

Klicke auf Installieren und warte einen Moment, bis die Installation abgeschlossen ist. In der Regel ist kein Neustart erforderlich – die neuen Nodes stehen sofort im linken Bereich (Palette) zur Verfügung.

Nach der erfolgreichen Installation findest du die SQLite Node unter den Storage-Nodes und kannst sie per Drag & Drop in deinen Flow ziehen.

Datenbank im Container anlegen und einbinden

Für dieses Beispiel gehen wir bewusst einen einfachen und direkten Weg, um schnell eine funktionierende SQLite-Datenbank zu erhalten.

Da unser Node-RED Container ein Docker-Volume verwendet, liegt dieses auf dem Host-System im Verzeichnis:

/var/lib/docker/volumes//_data/

In meinem Fall lautet der Pfad:

sudo -i cd /var/lib/docker/volumes/stefan_node_red_data/_data/

Hier können wir direkt unsere Datenbankdatei anlegen:

sqlite3 datenbank.db

Anschließend erstellen wir direkt eine erste Tabelle:

CREATE TABLE IF NOT EXISTS personen ( id INTEGER PRIMARY KEY AUTOINCREMENT, vorname TEXT NOT NULL, nachname TEXT NOT NULL, strasse TEXT, plz TEXT, ort TEXT );

Danach verlassen wir die SQLite-Konsole mit:

.quit

Hinweis: Dieser Ansatz ist bewusst einfach gehalten und eignet sich besonders gut für Tests und kleinere Projekte. Alternativ könnte man auch direkt im Container arbeiten oder ein eigenes Docker-Image erstellen – für unseren Einstieg ist das jedoch nicht zwingend notwendig.

Setzen der Rechte für die Datenbank

Wenn du die SQLite-Datenbank manuell im Docker-Volume angelegt hast, kann es passieren, dass Node-RED später nicht in die Datenbank schreiben kann.

Typische Fehlermeldung:

SQLITE_READONLY: attempt to write a readonly database

Die Ursache liegt in den Dateirechten: Die Datenbankdatei wird häufig als root erstellt, während Node-RED im Container mit einem anderen Benutzer läuft.

Rechte im Container anpassen

Um das Problem zu beheben, wechseln wir zunächst als root in den Container:

docker exec -it --user root nodered bash

Zugriff auf den Docker Container via bash mit root Rechte

Dann setzen wir die richtigen Rechte für die Datenbankdatei und das Verzeichnis:

cd /data chown 1000:1000 datenbank.db chown 1000:1000 . chmod 664 datenbank.db chmod 755 . exit

In meinem Fall läuft der Node-RED Docker-Container mit dem „normalen“ Benutzer, der beim Einrichten des Linux-Systems erstellt wurde. Dieser Benutzer hat in der Regel die UID 1000.

👉 Daher setzen wir den Besitzer der Datei und des Verzeichnisses ebenfalls auf diese UID, sodass Node-RED Schreibzugriff auf die SQLite-Datenbank erhält.

Warum ist das notwendig?

SQLite benötigt Schreibrechte auf:

- die Datenbankdatei selbst - das Verzeichnis, in dem die Datei liegt

Nur wenn beide korrekt gesetzt sind, kann Node-RED Daten speichern.

Datum und Uhrzeit per SQL abfragen

Nachdem wir nun die SQLite Node installiert und unsere Datenbank angelegt haben, erstellen wir im nächsten Schritt unseren ersten einfachen Flow in Node-RED.

Ziel ist es, eine erste SQL-Abfrage auszuführen und das Ergebnis im Debug-Tab anzuzeigen.

Minimaler Test-Flow

Für diesen ersten Test benötigen wir lediglich drei Nodes:

- Inject Node → startet den Flow und enthält das SQL-Statement - SQLite Node → führt die Abfrage aus - Debug Node → zeigt das Ergebnis an

Node-RED Flow zum lesen eines Zeitstempels aus einer SQLite Datenbank Inject Node konfigurieren

In der Inject Node hinterlegen wir direkt unser SQL-Statement im Feld msg.topic:

SELECT date('now');

👉 Wichtig: Die SQLite Node erwartet das SQL-Statement im Feld msg.topic.

SQLite Node konfigurieren

Damit die SQLite Node auf unsere Datenbank zugreifen kann, muss diese einmalig konfiguriert werden.

- SQLite Node öffnen - Auf das Plus-Symbol (+) neben „Datenbank“ klicken - Pfad zur Datenbank eintragen: /data/datenbank.db - Mit „Hinzufügen“ und anschließend „Fertig“ bestätigen

👉 Die SQLite Node ist nun einsatzbereit und verarbeitet SQL-Statements aus msg.topic.

Debug Node

Die Debug Node muss nicht weiter konfiguriert werden.

Standardmäßig lauscht sie bereits auf das Feld:

msg.payload

👉 Genau dort liefert die SQLite Node auch das Ergebnis der SQL-Abfrage.

Daten in SQLite speichern

Nachdem wir erfolgreich eine erste SQL-Abfrage ausgeführt haben, wollen wir nun Daten in unsere Tabelle personen schreiben.

Dazu erstellen wir einen einfachen Flow mit einer zusätzlichen Function Node welche uns zufallsdaten erzeugt.

Node-RED Flow zum speichern von Daten in der SQLite Datenbank Function Node zum Erzeugen von Zufallsdaten

Die Daten für die Tabelle personen könnten natürlich auch aus einem Formular im Dashboard stammen. Der Einfachheit halber verwenden wir hier jedoch eine Function Node, die aus einer vordefinierten Liste zufällige Werte auswählt und daraus einen Datensatz erzeugt.

const vornamen = ; const nachnamen = ; const strassen = ; const plzOrte = ; function zufallEintrag(arr) { return arr; } const vorname = zufallEintrag(vornamen); const nachname = zufallEintrag(nachnamen); const strasse = zufallEintrag(strassen); const plzOrt = zufallEintrag(plzOrte); msg.topic = ` INSERT INTO personen (vorname, nachname, strasse, plz, ort) VALUES ('${vorname}', '${nachname}', '${strasse}', '${plzOrt.plz}', '${plzOrt.ort}'); `; return msg;

Dieser Ansatz ist bewusst simpel gehalten und eignet sich hervorragend für erste Tests. Für produktive Anwendungen – etwa mit Benutzereingaben oder externen Datenquellen – stößt diese Methode jedoch schnell an ihre Grenzen.

zufällige Daten erzeugt mit der Function Node

👉 Für unseren Einstieg ist sie jedoch vollkommen ausreichend, um die Funktionalität der Datenbank zu testen und erste Datensätze zu erzeugen.

selektieren von Datensätze über SQLite3

Einfaches Dashboard für die Tabelle personen

Nachdem wir nun die Tabelle personen in der Datenbank angelegt haben, erstellen wir als Nächstes ein einfaches Dashboard, über das neue Datensätze bequem erfasst werden können.

Node-RED - einfaches Dashboard für die Tabelle personen

Das Ziel ist dabei bewusst einfach gehalten: Wir möchten neue Personen über eine kleine Eingabemaske anlegen und die Daten direkt in unserer SQLite-Datenbank speichern.

Für dieses erste Beispiel konzentrieren wir uns ausschließlich auf das Hinzufügen neuer Einträge. Das Bearbeiten oder Löschen vorhandener Datensätze würde den Flow deutlich komplexer machen und wird deshalb in einem separaten Beitrag behandelt.

Node-RED Flows für das Dashboard der Tabelle personen Node-RED Flows für das Dashboard der Tabelle personenHerunterladen Flow zum speichern von Daten in der Datenbank

Der Flow zum Speichern der Daten in der Datenbank wird einmalig gestartet und stellt über das Dashboard ein Eingabeformular bereit. Die eingegebenen Daten werden anschließend in einer Function-Node zu einem INSERT INTO-Statement verarbeitet und danach in die Datenbank geschrieben.

Flow zum speichern von Daten in der Datenbank

Das Eingabeformular lässt sich über die Form-Node recht einfach konfigurieren. Hier definieren wir die einzelnen Felder mit Namen, die beim Absenden an die Function-Node übergeben und dort weiterverarbeitet werden.

konfiguration des Fomulars let vorname = msg.payload.vorname; let nachname = msg.payload.nachname; let strasse = msg.payload.strasse; let postleitzahl = msg.payload.plz; let ort = msg.payload.ort; msg.topic = ` INSERT INTO personen (vorname, nachname, strasse, plz, ort) VALUES ('${vorname}', '${nachname}', '${strasse}', '${postleitzahl}', '${ort}'); `; return msg;

Die Formulardaten befinden sich im Feld msg.payload und können dort direkt ausgelesen werden. In diesem einfachen Beispiel verzichten wir bewusst auf eine Validierung oder Prüfung auf doppelte Einträge. Die Werte werden lediglich entnommen und im INSERT INTO-Statement an die entsprechenden Stellen eingesetzt.

Am Ende des Flows wird der Prozess zum Aktualisieren der Daten angestoßen, sodass die Tabelle den neu hinzugefügten Datensatz direkt anzeigt.

Aufrufen des Flows zum aktualisieren der Tabelle Flow zum lesen der Daten aus der Datenbank und anzeigen in einer Tabelle

Der Flow zum Aktualisieren der Tabelle mit den Daten aus der Tabelle personen verfügt über zwei Eingänge: Zum einen wird er automatisch gestartet, zum anderen kann er von anderen Flows aus angestoßen werden.

Im Anschluss folgt eine Function-Node, die das SELECT-Statement erstellt und über msg.topic an die SQLite-Node übergibt.

Die Function-Node schreibt lediglich das SELECT-Statement in das Feld msg.topic. Alternativ könnte man dieses auch über eine Inject-Node realisieren. Allerdings würde das Statement dann fehlen, wenn der Flow von einem anderen Flow aus gestartet wird.

msg.topic = "SELECT * FROM personen;"; return msg;

Konfiguration der Table Node

In der Konfiguration der Table Node legen wir zunächst fest das neue Wert die vorhandenen ersetzen, sowie die Spalten NICHT automatisch erkannt werden sollen. Daraus folgt jedoch das wir im unteren Bereich dann die Spalten manuell anlegen müssen. Hier können wir uns aus einer zuvor angelegten Debug Node der Felder bedienen welche wir anlegen müssen.

Flow zum löschen aller Datensätze

In diesem Node-RED Tutorial zeige ich dir, wie du ein Shelly Dashboard erstellst und deine Energiedaten visualisierst.

Im ersten Teil dieser Reihe hast du bereits gesehen, wie du deine Energiedaten aus der Shelly Cloud exportierst und sauber in einer SQLite-Datenbank speicherst. Damit hast du die Grundlage geschaffen, um deine Daten unabhängig von der Cloud zu verwalten und langfristig auszuwerten.

Doch Daten allein sind noch nicht wirklich hilfreich – erst durch eine übersichtliche Visualisierung wird daraus ein echtes Energie-Dashboard.

In diesem zweiten Teil gehen wir genau diesen Schritt: Wir laden die gespeicherten Werte aus der SQLite-Datenbank und visualisieren sie in einem Node-RED Dashboard. Zusätzlich holen wir uns aktuelle Live-Daten direkt vom Shelly per RPC-Call, sodass du jederzeit den aktuellen Zustand im Blick hast.

https://youtu.be/eMOqjjMrM8g

Node-RED - Flows für das Shelly BKW Dashboard

Node-RED - Dashboard mit aktuellen Werten ,Diagram und Tabelle Node-RED Flows für das Shelly DashboardHerunterladen

Am Ende dieses Beitrags hast du dein eigenes, interaktives Shelly Energie-Dashboard, das nicht nur gut aussieht, sondern dir auch wirklich hilft, deinen Verbrauch besser zu verstehen.

Überblick: Was wir in diesem Beitrag bauen

Ausgabe des Inhalts export.csv in der Konsole

Im letzten Beitrag Shelly Energie-Dashboard mit Node-RED – Teil 1: SQLite & Datenimport haben wir die Energiedaten aus der Shelly Cloud exportiert und in eine SQLite-Datenbank importiert. Damit ist die Grundlage geschaffen, um die Daten unabhängig von der Cloud weiterzuverarbeiten und auszuwerten.

In diesem Beitrag gehen wir nun den nächsten Schritt und machen die Daten sichtbar. Ziel ist es, ein übersichtliches Dashboard mit Node-RED zu erstellen, das dir sowohl historische Verläufe als auch aktuelle Messwerte anzeigt.

Die gespeicherten Daten aus der Datenbank werden dabei in einem Liniendiagramm visualisiert, sodass du Entwicklungen über die Zeit direkt erkennen kannst. Zusätzlich stellen wir die Werte in einer Tabelle dar, um auch einzelne Datensätze im Detail betrachten zu können.

Dashboard in Node-RED mit Verlaufsdaten eines Shelly Plus 1PM am Balkonkraftwerk

Im oberen Bereich des Dashboards zeigen wir außerdem die aktuellen Messwerte deines Shelly Plus 1PM an – darunter Strom, Spannung, Leistung und die insgesamt gemessene Energie. Diese Daten holen wir uns live vom Gerät, sodass dein Dashboard immer auf dem neuesten Stand ist.

aktuelle Werte eines Shelly Plus 1PM

Das Beste daran: All das lässt sich mit Node-RED ohne großen Aufwand umsetzen – wie du im weiteren Verlauf sehen wirst.

Daten aus SQLite laden

Im ersten Schritt laden wir die zuvor gespeicherten Energiedaten aus der SQLite-Datenbank in Node-RED. Dafür nutzen wir eine Kombination aus einer Inject-Node und einer SQLite-Node.

Die Inject-Node dient dabei als Trigger und stößt die Abfrage manuell oder automatisiert an. Von dort aus wird die SQL-Abfrage an die SQLite-Node übergeben.

Das eigentliche SQL-Statement hinterlegen wir in der msg.topic:

SELECT id, timestamp, ROUND(energy_wh / 1000.0, 3) AS energy_kwh FROM shelly_energy_monthly;

Hier passiert bereits ein wichtiger Schritt: Wir lesen nicht nur die Daten aus der Datenbank, sondern bereiten sie direkt auf. Der gespeicherte Energieverbrauch liegt in Wattstunden (Wh) vor und wird im selben Schritt in Kilowattstunden (kWh) umgerechnet. Zusätzlich runden wir den Wert auf drei Nachkommastellen, um eine saubere Darstellung im Dashboard zu gewährleisten.

Nach der Ausführung der Abfrage liefert die SQLite-Node ein Array mit den Ergebnissen zurück. Jeder Eintrag im Array entspricht dabei einem Datensatz aus der Datenbank und besteht aus Key-Value-Paaren.

Die Keys entsprechen den Spaltennamen der Abfrage:

- id - timestamp - energy_kwh

Diese Struktur ist ideal, um die Daten im nächsten Schritt weiterzuverarbeiten und für die Visualisierung im Dashboard aufzubereiten.

Node-RED - Flow zum laden von Daten aus einer SQLite Datenbank Node-RED - Flow zum laden von Daten aus einer SQLite DatenbankHerunterladen

Diagramm erstellen

Nachdem wir die Daten erfolgreich aus der Datenbank geladen haben, können wir diese nun im Dashboard visualisieren. Dafür nutzen wir die Diagramm-Node im Node-RED Dashboard.

Zunächst platzierst du eine Chart-Node in deinem Flow und verbindest sie mit der SQLite-Node bzw. der zuvor aufbereiteten Datenquelle.

In den Einstellungen der Diagramm-Node nimmst du folgende Konfiguration vor:

Grundeinstellungen - Gruppe: Wähle eine bestehende Gruppe oder erstelle eine neue (z. B. „Energie Dashboard“) - Beschriftung: Balkonkraftwerk - Verlauf - Typ: Linie (Standard) → ideal, um zeitliche Verläufe darzustellen

Achsen konfigurieren - X-Achsen-Typ: Zeitachse (Standard) - Format: {dd}.{M}.{yyyy} → sorgt für eine saubere Darstellung der Datumswerte - X-Achsen-Beschriftung: Zeit - Y-Achsen-Beschriftung: kWh

Node-RED - Diagramm konfigurieren - Step 3 - Achsen Konfiguration Datenzuordnung (sehr wichtig!)

Damit das Diagramm korrekt funktioniert, müssen die Datenfelder richtig zugeordnet werden:

- Serien: String → kWh - X-Wert: Schlüssel: timestamp - Y-Wert: Schlüssel: energy_kwh

Node-RED - Diagramm konfigurieren - Step 3a - Zuordnung der Daten

Hier greift die Diagramm-Node direkt auf die Struktur der Daten zu, die wir zuvor aus der SQLite-Datenbank geladen haben.

Ergebnis

Nach der Konfiguration wird der Energieverlauf als Liniendiagramm im Dashboard dargestellt. Du kannst nun auf einen Blick erkennen, wie sich dein Energieverbrauch bzw. deine Einspeisung über die Zeit entwickelt hat.

Node-RED - Liniendiagramm mit Verlaufsdaten aus der Shelly Cloud

💡 Tipp: Falls im Diagramm keine Werte angezeigt werden, überprüfe mit einer Debug-Node, ob die Keys (timestamp, energy_kwh) korrekt gesetzt sind und die Daten im richtigen Format vorliegen.

Daten aus der Datenbank im Debug-Tab

Daten in einer Tabelle anzeigen

Neben dem Diagramm bietet es sich an, die Daten zusätzlich in Tabellenform darzustellen. So behältst du nicht nur den Verlauf im Blick, sondern kannst auch einzelne Werte direkt und übersichtlich ablesen.

In meinem Fall wird unter dem Diagramm eine Tabelle angezeigt, die die zuvor selektierten Daten aus der SQLite-Datenbank ausgibt. Dafür kannst du einfach eine Table-Node aus dem Dashboard verwenden und diese mit den gleichen Daten verbinden, die auch in das Diagramm fließen.

Node-RED - Tabelle mit Verlaufsdaten aus der Shelly Cloud

Der Vorteil dieser Kombination liegt auf der Hand: Während das Liniendiagramm dir einen schnellen visuellen Überblick über den Verlauf gibt, ermöglicht die Tabelle einen genaueren Blick auf die einzelnen Datensätze – inklusive der jeweiligen Zeitstempel und Werte.

Zwar kannst du im Diagramm durch das Hover über die einzelnen Punkte ebenfalls Details einsehen, jedoch ist die tabellarische Darstellung deutlich komfortabler, wenn du gezielt Werte vergleichen oder nach bestimmten Zeitpunkten suchen möchtest.

Einstellungen für das Diagramm

Die Tabelle wird der Gruppe " Shelly Dashboard" hinzugefügt und hat eine Größe von "auto".

Node-RED - Konfiguration der Tabelle

Im unteren Bereich müssen wir nun die Spalten definieren, Standardmäßig würden sonst die Spaltenüberschriften aus der Datenbank übernommen. Die erste Spalte ist die ID welche fortlaufend ist: - Beschriftung: ID - Typ: Row Number Die zweite und dritte Spalte sind der Zeitstempel sowie die Werte in kWh: - Beschriftung: Zeitstempel / Monatswerte (kWh) - Typ: Text

Node-RED - Konfiguration der Tabellenspalten

Abrufen der Live-Daten vom Shelly

Über einen RPC-Call zum Shelly Plus 1PM kann man die aktuellen Daten vom angeschlossenen Verbraucher abrufen.

http:///rpc/Shelly.GetStatus

Das Datenformat ist JSON dieses lässt sich wie bereits mehrfach erwähnt in Node-RED sehr einfach verarbeiten.

Folgende Werte sind für uns interessant:

- apower: Leistungsaufnahme in Watt - voltage: Netzspannung in Volt - current: Spannungsaufnahme in Ampere - aenergy.total: gesamt pro Monat

Zusätzlich können wir auch die letzten Werte der Leistungsaufnahme der letzten drei Minuten auslesen, diese sind im Array "by_minute" abgelegt.

"switch:0": { "id": 0, "source": "HTTP_in", "output": true, "apower": 17.4, "voltage": 227.6, "current": 0.181, "aenergy": { "total": 91102.133, "by_minute": , "minute_ts": 1774425735 } Flow zum abrufen der Daten

Der Flow zum abrufen der Daten startet erstmal manuell kann aber später mit wenigen klicks auf ein Intervall umgestellt werden.

Node-RED - Flow zum abrufen der aktuellen Daten vom Shelly via RPC-Call Node-RED - Flow zum abrufen der aktuellen Daten vom Shelly via RPC-CallHerunterladen extrahieren der Daten via JavaScript

Mit der Function-Node extrahieren wir die Daten aus dem JSON. Da uns wie erwähnt nur die Werte von apower, voltage, current und aenergy.total interessieren fassen wir diese in ein JSON zusammen.

const data = msg.payload; const apower = data.apower; const voltage = data.voltage; const current = data.current; const aenergy_total = data.aenergy.total / 1000; msg.payload = { apower: apower, apower_total: aenergy_total.toFixed(3), voltage: voltage, current: current, }; return msg;

darstellen der Daten in Kacheln

Die Daten möchte ich nicht einfach nur als Text anzeigen sondern grafisch in einer Kachel (deutlich ansehnlicher). Hier verwende ich die Node template in welche HTML, CSS und auch JavaScript ausführen/anzeigen kann.

Node-RED - template Node

aktuelle Leistungsdaten des Shellys ⚡ Aktuelle Werte Strom {{msg.payload.current}} A Spannung {{msg.payload.voltage}} V Leistung {{msg.payload.apower}} W Energie gesamt {{msg.payload.apower_total}} kWh

Fazit

Mit Node-RED lässt sich mit wenigen Nodes ein leistungsfähiges und übersichtliches Energie-Dashboard für deine Shelly Geräte aufbauen. Durch die Kombination aus historischen Daten aus der SQLite-Datenbank und der Visualisierung im Dashboard erhältst du einen klaren Überblick über deinen Energieverbrauch bzw. deine Einspeisung.

Besonders praktisch ist dabei die grafische Darstellung im Liniendiagramm sowie die ergänzende Tabelle, die dir einen detaillierten Blick auf einzelne Zeitpunkte ermöglicht. So kannst du Trends erkennen, Werte vergleichen und deine Daten deutlich besser verstehen als in einer reinen CSV-Datei.

Ausblick

Im nächsten Teil der Reihe gehen wir noch einen Schritt weiter: Wir erweitern unser Dashboard und kümmern uns darum, die aktuellen Daten direkt vom Shelly auszulesen und automatisch in der SQLite-Datenbank zu speichern.

Im ersten Beitrag dieser Reihe haben wir Node-RED auf einem Raspberry Pi installiert, eingerichtet und abgesichert. Der Dienst läuft nun als Systemservice im Hintergrund und startet automatisch beim Hochfahren des Systems. Dadurch steht die Oberfläche jederzeit zur Verfügung und kann bequem von jedem Rechner im Netzwerk aufgerufen werden – du benötigst lediglich die URL, deinen Benutzernamen und das Passwort.

Nachdem die Grundlage geschaffen ist, wird es nun praktisch.

In diesem Beitrag zeige ich dir, wie du Wetterdaten über eine externe API abrufen kannst. Viele moderne Schnittstellen stellen ihre Daten im JSON-Format bereit. Dieses Format eignet sich besonders gut für Automatisierungen, da es strukturiert aufgebaut und leicht weiterzuverarbeiten ist.

https://youtu.be/xSQn-ZKqFiI

Genau hier spielt Node-RED seine Stärken aus: Die Plattform kann JSON-Daten direkt verarbeiten und innerhalb eines Flows weiterverwenden.

Am Ende dieses Tutorials wirst du wissen, wie du:

- einen HTTP-Request an eine API sendest - die JSON-Antwort auswertest - und die Daten innerhalb eines Node-RED Flows weiterverarbeitest

Damit hast du die Grundlage geschaffen, um später eigene Automatisierungen mit externen Datenquellen umzusetzen – zum Beispiel für Smart-Home-Projekte, Wetterstationen oder IoT-Anwendungen.

Welche Wetter API verwenden wir?

Für dieses Tutorial verwenden wir die Wetter-API von Open-Meteo. Diese Schnittstelle eignet sich besonders gut für erste Experimente mit Node-RED, da sie ohne Registrierung und ohne API-Key genutzt werden kann. Dadurch kannst du sofort mit dem Testen beginnen, ohne zunächst Zugangsdaten anlegen zu müssen.

Die API stellt Wetterdaten über einfache HTTP-Requests bereit und liefert die Ergebnisse im JSON-Format zurück. Genau dieses Format lässt sich in Node-RED besonders gut verarbeiten, da JSON-Daten direkt als Objekte innerhalb eines Flows weiterverwendet werden können.

Für unser Beispiel rufen wir die aktuellen Wetterdaten für einen bestimmten Standort ab. Dazu benötigt die API lediglich die geografischen Koordinaten des gewünschten Ortes.

Ein Beispiel für einen solchen Request sieht so aus:

https://api.open-meteo.com/v1/forecast?latitude=52.14619&longitude=10.96095¤t_weather=true

In diesem Beispiel werden die aktuellen Wetterdaten für einen bestimmten Standort abgefragt. Die API liefert daraufhin eine Antwort im JSON-Format zurück, die unter anderem Informationen wie Temperatur, Windgeschwindigkeit oder Windrichtung enthält.

{ "latitude": 52.14, "longitude": 10.959999, "generationtime_ms": 0.0560283660888672, "utc_offset_seconds": 0, "timezone": "GMT", "timezone_abbreviation": "GMT", "elevation": 158, "current_weather_units": { "time": "iso8601", "interval": "seconds", "temperature": "°C", "windspeed": "km/h", "winddirection": "°", "is_day": "", "weathercode": "wmo code" }, "current_weather": { "time": "2026-03-13T08:45", "interval": 900, "temperature": 10.4, "windspeed": 15.5, "winddirection": 198, "is_day": 1, "weathercode": 0 } }

Diese Daten werden wir im nächsten Schritt mit Node-RED abrufen und im Flow auswerten.

Hinweis: Laut Anbieter ist die Nutzung der API für nicht-kommerzielle Anwendungen kostenlos. Für produktive oder kommerzielle Projekte solltest du daher unbedingt die aktuellen Nutzungsbedingungen auf der Website des Anbieters prüfen.

Bedeutung des Weather Codes

Neben klassischen Wetterwerten wie Temperatur, Windgeschwindigkeit oder Windrichtung liefert die API auch einen sogenannten Weather Code. Dabei handelt es sich um einen numerischen Wert, der den aktuellen Wetterzustand beschreibt.

Die Codes basieren auf dem Standard der World Meteorological Organization und werden international verwendet, um Wetterbedingungen eindeutig zu klassifizieren.

Eine vollständige Übersicht dieser Codes findet sich beispielsweise beim National Centers for Environmental Information. Dort ist die offizielle Tabelle der WMO Weather Interpretation Codes (WMO 4677) dokumentiert.

Typische Beispiele sind:

CodeBedeutung0Klarer Himmel1Überwiegend klar2Teilweise bewölkt3Bewölkt45Nebel61Leichter Regen63Regen71Schneefall

Der Vorteil dieser Codes ist, dass sie sich sehr einfach in Automationen verwenden lassen. In Node-RED können wir beispielsweise prüfen, ob ein bestimmter Wettercode vorliegt und darauf reagieren – etwa eine Bewässerung pausieren, wenn Regen erkannt wird, oder eine Benachrichtigung bei schlechtem Wetter senden.

Im nächsten Schritt schauen wir uns an, wie wir die Daten über einen HTTP-Request in Node-RED abrufen und im Flow sichtbar machen.

Wetterdaten in Node-RED per HTTP Request abrufen

Nachdem wir uns angeschaut haben, welche Wetter-API wir verwenden, geht es nun an den eigentlichen Abruf der Daten in Node-RED. Dafür nutzen wir den HTTP Request-Node. Mit diesem Node lässt sich eine externe URL aufrufen, um Daten aus einer API zu laden.

Für unser erstes Beispiel reicht bereits ein sehr einfacher Flow aus:

Flow zum abrufen von Wetterdaten in Node-RED

Der Inject-Node dient dabei als Auslöser. Mit einem Klick auf den Button wird der Flow gestartet. Der HTTP Request-Node sendet anschließend eine Anfrage an die Wetter-API und lädt die Antwort. Da viele APIs ihre Daten als JSON-Text zurückgeben, übernimmt die JSON-Node im nächsten Schritt das Umwandeln der Antwort in ein strukturiertes Objekt. Über den Debug-Node können wir uns die aufbereiteten Daten anschließend direkt in der Debug-Ansicht von Node-RED anzeigen lassen.

abrufen der Wetterdaten - einfachHerunterladen

Einzelne Wetterdaten aus dem JSON auslesen

Nachdem die Antwort der Wetter-API mit der JSON-Node verarbeitet wurde, liegen die Daten als strukturiertes Objekt vor. Dadurch können wir nun gezielt auf einzelne Elemente zugreifen.

Node-RED - JSON Daten parsen und ausgeben

Für unser Beispiel interessieren uns drei Werte aus dem Bereich current_weather:

- current_weather.time - current_weather.temperature - current_weather.weathercode

Diese Felder enthalten den Zeitstempel der Messung, die aktuelle Temperatur sowie den Wettercode.

"current_weather": { "time": "2026-03-13T08:45", "interval": 900, "temperature": 10.4, "windspeed": 15.5, "winddirection": 198, "is_day": 1, "weathercode": 0 } Zugriff auf die Werte

Da sich die Daten im payload der Nachricht befinden, lauten die vollständigen Pfade in Node-RED:

- payload.current_weather.time - payload.current_weather.temperature - payload.current_weather.weathercode

extrahieren von Daten aus einem JSON Objekt in Node-RED abrufen und parsen der Wetterdaten - Ausgeben von Zeitstempel-Temperatur-WetterCodeHerunterladen

Wetterdaten in eine CSV-Datei speichern

Nachdem wir die gewünschten Werte aus der API-Antwort extrahiert haben, möchten wir diese nun dauerhaft speichern. Eine einfache und weit verbreitete Möglichkeit dafür ist das Schreiben der Daten in eine CSV-Datei. Dieses Format eignet sich besonders gut, da es sich später problemlos mit Programmen wie Excel, LibreOffice Calc oder Python weiterverarbeiten lässt.

Dazu erweitern wir unseren bisherigen Flow um einige zusätzliche Nodes. Zunächst verwenden wir eine Change-Node, um die relevanten Werte aus der API-Antwort zu übernehmen und in ein eigenes Datenobjekt zu überführen. Anschließend sorgt eine CSV-Node dafür, dass diese Daten in das CSV-Format umgewandelt werden.

Zum Abschluss übernimmt eine File-Node das Schreiben der erzeugten Daten in eine Datei auf dem Raspberry Pi. Bei jedem Durchlauf unseres Flows wird somit eine neue Zeile mit den aktuellen Wetterdaten in der Datei gespeichert.

Der erweiterte Flow sieht damit beispielsweise so aus:

Node-RED - Flow zum abrufen von Wetterdaten und speichern in einer CSV-Datei

In der erzeugten CSV-Datei werden anschließend Zeilen wie diese gespeichert:

2026-03-13T14:00,18.7,3 abrufen und speichern von Wetterdaten in einer CSV-DateiHerunterladen

Damit haben wir eine einfache Möglichkeit geschaffen, Wetterdaten über einen längeren Zeitraum zu sammeln. Diese Daten können später analysiert oder grafisch dargestellt werden, beispielsweise in einem separaten Dashboard oder in einer Tabellenkalkulation.

Hinweis: Beim Schreiben der Daten kann es vorkommen, dass in der CSV-Datei zusätzliche Leerzeilen erscheinen. Dieses Verhalten ist in Node-RED normal, da die CSV-Node automatisch einen Zeilenumbruch an jede erzeugte Datensatzzeile anhängt.

Optisch wirkt das in der Datei zunächst etwas ungewohnt, stellt jedoch kein Problem dar. Beim Import der CSV-Datei in Programme wie Microsoft Excel oder LibreOffice Calc lassen sich solche Leerzeilen problemlos herausfiltern oder ignorieren.

Fazit und Ausblick

Das Abrufen von Daten über eine offene API mit Node-RED ist erstaunlich einfach umzusetzen. Mit nur wenigen Nodes lässt sich ein HTTP-Request an eine externe Schnittstelle senden, die Antwort im JSON-Format verarbeiten und anschließend gezielt einzelne Werte extrahieren.

Auch das Speichern der Daten in einer Datei ist schnell realisiert, sobald man den grundlegenden Aufbau eines Flows verstanden hat. Mit der Kombination aus Change-, CSV- und File-Node können die Wetterdaten strukturiert abgelegt und später problemlos weiterverarbeitet werden.

Damit haben wir nun eine Grundlage geschaffen, um über einen längeren Zeitraum Wetterdaten zu sammeln und auszuwerten.