10 Std vor
Die meisten Sensorknoten brennen ihre Batterie nicht beim Senden leer, sondern im Schlaf dazwischen. Dabei entscheidet der gewählte Schlafmodus, wie viel Strom der ESP32 im Leerlauf zieht.
Die Verwechslung entsteht, weil alle drei Modi „Schlaf“ heißen. In Wahrheit schaltet der Chip verschieden viel ab, vom bloßen Funkteil bis zum fast kompletten Abschalten.
Modem Sleep ist der mildeste Modus: Nur das Funkteil für WLAN und Bluetooth ist stumm, die CPU läuft weiter. Das Programm arbeitet ohne Unterbrechung, gezahlt wird mit 20 bis 68 mA, je nach Takt. Das taugt für netzversorgte Geräte, die Funkspitzen vermeiden wollen, nicht für Batterien.
Light Sleep hält CPU und Speicher mit Takt-Gating versorgt: Taktsignale stocken, die Spannung bleibt an, der RAM-Inhalt bleibt erhalten. Typisch sind 0,8 mA, und das Aufwachen ist deutlich schneller als aus dem Deep Sleep. Das Programm läuft an derselben Stelle weiter, ideal, wenn ein Interrupt-Pin sofortige Reaktion verlangt.
Deep Sleep schaltet CPU, Hauptspeicher und Funk ab; nur der RTC-Controller (RTC = Real-Time Clock, Echtzeituhr), die RTC-Peripherie, der RTC-Speicher und der ULP-Coprozessor, ein kleiner Zusatzprozessor, der auch im Schlaf Sensoren auslesen kann, bleiben an. Der typische Strom liegt bei 10 µA, mit laufendem ULP-Coprozessor bei 150 µA. Nach dem Aufwachen startet das Programm neu, nur Werte mit RTC_DATA_ATTR überleben im RTC-Slow-Memory. Beispiel: ein Temperatursensor, der stündlich per RTC-Timer aufwacht und per MQTT sendet.
Je länger das Messintervall, desto mehr dominiert der Schlafstrom die Batterielaufzeit.
Faustregel: Netzteil und Dauerbetrieb verlangen Modem Sleep, schnelle Reaktion Light Sleep, langes Intervall und Batteriebetrieb Deep Sleep.
Deep Sleep heißt nicht „aus“, sondern „nur der Echtzeitbereich wacht“.
📌 Schlafmodi · Strombudget · Aufwachquellen
📚 IoT von Grund auf · Tag 5 von 30
#esp32 #iot
Die Verwechslung entsteht, weil alle drei Modi „Schlaf“ heißen. In Wahrheit schaltet der Chip verschieden viel ab, vom bloßen Funkteil bis zum fast kompletten Abschalten.
Modem Sleep ist der mildeste Modus: Nur das Funkteil für WLAN und Bluetooth ist stumm, die CPU läuft weiter. Das Programm arbeitet ohne Unterbrechung, gezahlt wird mit 20 bis 68 mA, je nach Takt. Das taugt für netzversorgte Geräte, die Funkspitzen vermeiden wollen, nicht für Batterien.
Light Sleep hält CPU und Speicher mit Takt-Gating versorgt: Taktsignale stocken, die Spannung bleibt an, der RAM-Inhalt bleibt erhalten. Typisch sind 0,8 mA, und das Aufwachen ist deutlich schneller als aus dem Deep Sleep. Das Programm läuft an derselben Stelle weiter, ideal, wenn ein Interrupt-Pin sofortige Reaktion verlangt.
Deep Sleep schaltet CPU, Hauptspeicher und Funk ab; nur der RTC-Controller (RTC = Real-Time Clock, Echtzeituhr), die RTC-Peripherie, der RTC-Speicher und der ULP-Coprozessor, ein kleiner Zusatzprozessor, der auch im Schlaf Sensoren auslesen kann, bleiben an. Der typische Strom liegt bei 10 µA, mit laufendem ULP-Coprozessor bei 150 µA. Nach dem Aufwachen startet das Programm neu, nur Werte mit RTC_DATA_ATTR überleben im RTC-Slow-Memory. Beispiel: ein Temperatursensor, der stündlich per RTC-Timer aufwacht und per MQTT sendet.
Je länger das Messintervall, desto mehr dominiert der Schlafstrom die Batterielaufzeit.
Faustregel: Netzteil und Dauerbetrieb verlangen Modem Sleep, schnelle Reaktion Light Sleep, langes Intervall und Batteriebetrieb Deep Sleep.
Deep Sleep heißt nicht „aus“, sondern „nur der Echtzeitbereich wacht“.
📌 Schlafmodi · Strombudget · Aufwachquellen
📚 IoT von Grund auf · Tag 5 von 30
#esp32 #iot
16 Std vor
Der Lichtbefehl kommt per App an, der Sensorwert aber fehlt. Beides lief über denselben Broker, doch nur eine Nachricht hat überlebt.
Ein Temperatursensor meldet Lücken im Verlauf, etwa wenn die WLAN-Verbindung kurz abbricht. Der Schaltbefehl an die Steckdose kommt dagegen zuverlässig an, manchmal sogar doppelt.
MQTT heißt das Protokoll, über das IoT-Geräte Nachrichten austauschen. Geräte senden und empfangen dabei nicht direkt untereinander, sondern immer über einen zentralen Broker, der alle Nachrichten annimmt und verteilt. Jede Nachricht bekommt eine QoS-Stufe mit: QoS steht für Quality of Service und legt fest, wie stark sich Absender und Broker um die Zustellung bemühen. Der Unterschied zwischen Sensorwert und Befehl entsteht also schon beim Senden, nicht zufällig unterwegs.
Ein Sensor veröffentlicht alle paar Minuten den Wert im Topic wohnzimmer/temperatur, etwa mit QoS 0. QoS 0 sendet die Nachricht und vergisst sie: Ohne Bestätigung bleibt eine verlorene Nachricht verloren. Weil die nächste Messung bald folgt, ist das verschmerzbar. Der Schaltbefehl an die Steckdose geht mit QoS 1: Der Broker bestätigt jede Nachricht, und fehlt die Bestätigung, sendet der Client erneut. So kommt der Befehl mindestens einmal an, Duplikate sind möglich. Damit ein Duplikat nicht doppelt schaltet, setzt der Empfänger einen Zielszustand statt eines Zählschritts. QoS 2 liefert genau einmal, braucht dafür aber einen vierstufigen Handshake mit mehr Zeit und Volumen.
So prüft man es: Im Log des Clients die QoS-Stufe neben jedem Publish und Subscribe nachsehen. Dann gezielt die Verbindung unterbrechen und zählen, welche Nachrichten ankommen.
QoS heißt nicht „besser ist immer höher“, sondern „passend zum Inhalt“. Messwerte dürfen fehlen, Befehle müssen ankommen.
📌 QoS 0/1/2 · Broker · Duplikate
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
Ein Temperatursensor meldet Lücken im Verlauf, etwa wenn die WLAN-Verbindung kurz abbricht. Der Schaltbefehl an die Steckdose kommt dagegen zuverlässig an, manchmal sogar doppelt.
MQTT heißt das Protokoll, über das IoT-Geräte Nachrichten austauschen. Geräte senden und empfangen dabei nicht direkt untereinander, sondern immer über einen zentralen Broker, der alle Nachrichten annimmt und verteilt. Jede Nachricht bekommt eine QoS-Stufe mit: QoS steht für Quality of Service und legt fest, wie stark sich Absender und Broker um die Zustellung bemühen. Der Unterschied zwischen Sensorwert und Befehl entsteht also schon beim Senden, nicht zufällig unterwegs.
Ein Sensor veröffentlicht alle paar Minuten den Wert im Topic wohnzimmer/temperatur, etwa mit QoS 0. QoS 0 sendet die Nachricht und vergisst sie: Ohne Bestätigung bleibt eine verlorene Nachricht verloren. Weil die nächste Messung bald folgt, ist das verschmerzbar. Der Schaltbefehl an die Steckdose geht mit QoS 1: Der Broker bestätigt jede Nachricht, und fehlt die Bestätigung, sendet der Client erneut. So kommt der Befehl mindestens einmal an, Duplikate sind möglich. Damit ein Duplikat nicht doppelt schaltet, setzt der Empfänger einen Zielszustand statt eines Zählschritts. QoS 2 liefert genau einmal, braucht dafür aber einen vierstufigen Handshake mit mehr Zeit und Volumen.
So prüft man es: Im Log des Clients die QoS-Stufe neben jedem Publish und Subscribe nachsehen. Dann gezielt die Verbindung unterbrechen und zählen, welche Nachrichten ankommen.
QoS heißt nicht „besser ist immer höher“, sondern „passend zum Inhalt“. Messwerte dürfen fehlen, Befehle müssen ankommen.
📌 QoS 0/1/2 · Broker · Duplikate
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
1 Tag vor
Ein Sensor schickt Temperaturwerte, und das Display zeigt trotzdem Schaltbefehle mit an. Beides landet in einem einzigen Thema, das keiner sauber abonnieren kann.
Viele denken, ein Topic sei nur eine Beschriftung und die Auswahl der Nachrichten erledigt man am besten selbst. Das klingt plausibel, weil ein flacher Name wie messwerte einfacher wirkt als eine verschachtelte Adresse.
Tatsächlich ist ein Topic die Adresse einer Nachricht im MQTT-System, dem Nachrichtenprotokoll, mit dem Geräte Daten austauschen; sie ist ähnlich aufgebaut wie ein Ordnerpfad im Dateisystem. Der Schrägstrich trennt Ebenen, und die Reihenfolge geht vom Allgemeinen zum Besonderen: haus/wohnzimmer/temperatur. Beim Abonnieren erlaubt MQTT Wildcards: das Plus steht für genau eine Ebene, die Raute für alle folgenden Ebenen und darf nur am Ende stehen.
Der Irrtum entsteht, weil Einsteiger die Hierarchie nicht gliedern und dann jede Nachricht mitlesen. Die gewünschten Werte per Textfilter selbst herauszusuchen wirkt schnell, liest dann aber jede Nachricht mit und belastet den Mikrocontroller unnötig.
Ein Sensor schreibt in haus/wohnzimmer/temperatur und haus/kueche/temperatur. Ein Display abonniert haus/+/temperatur und erhält beide Werte mit einem Abonnement. Befehle liegen getrennt in haus/wohnzimmer/relay/gesetzt, damit das Display keine Schaltbefehle empfängt.
Woran man es erkennt: Stehen Messgröße und Befehl in verschiedenen Zweigen, ist die Struktur richtig. Läuft alles durch ein flaches Topic, fehlt die Gliederung.
Topic heißt nicht eine Beschriftung für alles, sondern eine Adresse mit Ebenen. Wer gut gliedert, wählt mit Plus und Raute aus, statt selbst zu filtern.
📌 Schrägstrich als Ebene · Plus für eine Ebene · Raute für alles darunter
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
Viele denken, ein Topic sei nur eine Beschriftung und die Auswahl der Nachrichten erledigt man am besten selbst. Das klingt plausibel, weil ein flacher Name wie messwerte einfacher wirkt als eine verschachtelte Adresse.
Tatsächlich ist ein Topic die Adresse einer Nachricht im MQTT-System, dem Nachrichtenprotokoll, mit dem Geräte Daten austauschen; sie ist ähnlich aufgebaut wie ein Ordnerpfad im Dateisystem. Der Schrägstrich trennt Ebenen, und die Reihenfolge geht vom Allgemeinen zum Besonderen: haus/wohnzimmer/temperatur. Beim Abonnieren erlaubt MQTT Wildcards: das Plus steht für genau eine Ebene, die Raute für alle folgenden Ebenen und darf nur am Ende stehen.
Der Irrtum entsteht, weil Einsteiger die Hierarchie nicht gliedern und dann jede Nachricht mitlesen. Die gewünschten Werte per Textfilter selbst herauszusuchen wirkt schnell, liest dann aber jede Nachricht mit und belastet den Mikrocontroller unnötig.
Ein Sensor schreibt in haus/wohnzimmer/temperatur und haus/kueche/temperatur. Ein Display abonniert haus/+/temperatur und erhält beide Werte mit einem Abonnement. Befehle liegen getrennt in haus/wohnzimmer/relay/gesetzt, damit das Display keine Schaltbefehle empfängt.
Woran man es erkennt: Stehen Messgröße und Befehl in verschiedenen Zweigen, ist die Struktur richtig. Läuft alles durch ein flaches Topic, fehlt die Gliederung.
Topic heißt nicht eine Beschriftung für alles, sondern eine Adresse mit Ebenen. Wer gut gliedert, wählt mit Plus und Raute aus, statt selbst zu filtern.
📌 Schrägstrich als Ebene · Plus für eine Ebene · Raute für alles darunter
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot #esp32
1 Tag vor
Ein MQTT-System funktioniert wie eine Poststelle im Firmengebäude. Jeder Mitarbeiter wirft Briefe ein, und die Poststelle sorgt für die Zustellung.
Dort kennt niemand die Adresse des anderen. Man legt nur den Brief mit einem Verteilernamen ab und verlässt sich auf die Stelle hinter dem Schalter. Wer etwas erfahren will, meldet sich für einen Verteiler an. Die Poststelle behält den Überblick, wer Briefe einwirft und wer sie abholt. Und wer den Status einer Ablage wissen will, schaut ins letzte hinterlegte Blatt.
In MQTT ist diese Poststelle der Broker, ein Server, der alle Nachrichten entgegennimmt und verteilt. Geräte reden nie direkt miteinander, sondern immer über ihn. Ein Client veröffentlicht eine Nachricht per Publish an ein Topic, ein benanntes Adressfeld; Topics sind hierarchisch mit Schrägstrich getrennt, das Wildcard + steht für genau eine Ebene, # für alle folgenden Ebenen und darf nur am Ende stehen. Der Broker verwaltet offene Verbindungen, Topics und hinterlegte Nachrichten und merkt auch, wenn ein Client unvermutet abbricht.
Ein Temperatursensor veröffentlicht alle paar Minuten den Wert im Topic wohnzimmer/temperatur. Eine App abonniert dieses Topic und bekommt jeden Wert sofort. Mit einer Retained Message speichert der Broker den letzten Wert je Topic, sodass ein neu verbundenes Display sofort beim Abonnieren den Stand sieht. Auf dem Standardport 1883 lauscht der Broker unverschlüsselt, über TLS, eine verschlüsselte Verbindung, auf Port 8883.
Das Bild hat eine Grenze: Die Poststelle wartet auf Briefe, der Broker aber hält alle Verbindungen dauerhaft offen und prüft sie. Ein Sensor sendet und eine App liest gleichzeitig, ohne dass beide voneinander wissen.
MQTT heißt nicht Geräte-zu-Gerät, sondern Vermittlung über den Broker: verbinden, verteilen, hinterlegen.
📌 Publish und Subscribe · Topic und Wildcards · Broker statt Direktverbindung
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot
Dort kennt niemand die Adresse des anderen. Man legt nur den Brief mit einem Verteilernamen ab und verlässt sich auf die Stelle hinter dem Schalter. Wer etwas erfahren will, meldet sich für einen Verteiler an. Die Poststelle behält den Überblick, wer Briefe einwirft und wer sie abholt. Und wer den Status einer Ablage wissen will, schaut ins letzte hinterlegte Blatt.
In MQTT ist diese Poststelle der Broker, ein Server, der alle Nachrichten entgegennimmt und verteilt. Geräte reden nie direkt miteinander, sondern immer über ihn. Ein Client veröffentlicht eine Nachricht per Publish an ein Topic, ein benanntes Adressfeld; Topics sind hierarchisch mit Schrägstrich getrennt, das Wildcard + steht für genau eine Ebene, # für alle folgenden Ebenen und darf nur am Ende stehen. Der Broker verwaltet offene Verbindungen, Topics und hinterlegte Nachrichten und merkt auch, wenn ein Client unvermutet abbricht.
Ein Temperatursensor veröffentlicht alle paar Minuten den Wert im Topic wohnzimmer/temperatur. Eine App abonniert dieses Topic und bekommt jeden Wert sofort. Mit einer Retained Message speichert der Broker den letzten Wert je Topic, sodass ein neu verbundenes Display sofort beim Abonnieren den Stand sieht. Auf dem Standardport 1883 lauscht der Broker unverschlüsselt, über TLS, eine verschlüsselte Verbindung, auf Port 8883.
Das Bild hat eine Grenze: Die Poststelle wartet auf Briefe, der Broker aber hält alle Verbindungen dauerhaft offen und prüft sie. Ein Sensor sendet und eine App liest gleichzeitig, ohne dass beide voneinander wissen.
MQTT heißt nicht Geräte-zu-Gerät, sondern Vermittlung über den Broker: verbinden, verteilen, hinterlegen.
📌 Publish und Subscribe · Topic und Wildcards · Broker statt Direktverbindung
📚 IoT von Grund auf · Tag 5 von 30
#mqtt #iot
1 Tag vor
Zwei ESP32 sollen Daten austauschen, doch die Verbindung kommt nie zustande. Viele Einsteiger suchen dann stundenlang nach einer Direktverbindung zwischen den Geräten.
Ein Sensor sendet Messwerte, aber das andere Gerät zeigt nichts an. Im Code fehlt jede Spur eines Empfängers, weil man einen gar nicht angeben kann.
MQTT ist ein Publish-Subscribe-System, also ein Verfahren, bei dem niemand direkt miteinander redet. Jedes Gerät sendet seine Nachrichten nur an den Broker, eine zentrale Vermittlungsstelle im Netzwerk. Diese verteilt jede Nachricht an alle Geräte, die das zugehörige Topic abonniert haben. Ein Topic ist ein hierarchischer Name mit Schrägstrichen, etwa wohnzimmer/temperatur, der eine Nachricht wie eine Adresse kennzeichnet. Wer published, veröffentlicht also unter einem Topic, ohne zu wissen, wer die Nachricht liest. Wer subscribed, meldet sich für ein Topic an und erhält künftig alle Nachrichten dazu. Ohne Broker findet in MQTT keine Kommunikation statt – die gesuchte Direktverbindung existiert nicht.
Ein Temperatur-Sensor am ESP32 liest die Temperatur und veröffentlicht sie alle paar Minuten unter wohnzimmer/temperatur. Danach schläft der Mikrocontroller bis zur nächsten Messung, was den Akku schont. Ein Display abonniert genau dieses Topic und zeigt den Wert an. Beide Geräte können unabhängig voneinander neu starten, ohne dass das andere davon abhängt.
So prüft man es: Zuerst nachsehen, ob der Broker läuft und beide Geräte mit ihm verbunden sind. Dann ein Testgerät unter wohnzimmer/temperatur publishen und am Display den eintreffenden Wert beobachten.
MQTT heißt nicht, Nachrichten direkt zu verschicken, sondern unter einem Topic zu veröffentlichen und den Broker verteilen zu lassen. Wer den Broker vergisst, sucht eine Verbindung, die es nie gab.
📌 Publish · Subscribe · Broker
📚 IoT von Grund auf · Tag 4 von 30
#mqtt #iot #esp32 #Mikrocontroller
Ein Sensor sendet Messwerte, aber das andere Gerät zeigt nichts an. Im Code fehlt jede Spur eines Empfängers, weil man einen gar nicht angeben kann.
MQTT ist ein Publish-Subscribe-System, also ein Verfahren, bei dem niemand direkt miteinander redet. Jedes Gerät sendet seine Nachrichten nur an den Broker, eine zentrale Vermittlungsstelle im Netzwerk. Diese verteilt jede Nachricht an alle Geräte, die das zugehörige Topic abonniert haben. Ein Topic ist ein hierarchischer Name mit Schrägstrichen, etwa wohnzimmer/temperatur, der eine Nachricht wie eine Adresse kennzeichnet. Wer published, veröffentlicht also unter einem Topic, ohne zu wissen, wer die Nachricht liest. Wer subscribed, meldet sich für ein Topic an und erhält künftig alle Nachrichten dazu. Ohne Broker findet in MQTT keine Kommunikation statt – die gesuchte Direktverbindung existiert nicht.
Ein Temperatur-Sensor am ESP32 liest die Temperatur und veröffentlicht sie alle paar Minuten unter wohnzimmer/temperatur. Danach schläft der Mikrocontroller bis zur nächsten Messung, was den Akku schont. Ein Display abonniert genau dieses Topic und zeigt den Wert an. Beide Geräte können unabhängig voneinander neu starten, ohne dass das andere davon abhängt.
So prüft man es: Zuerst nachsehen, ob der Broker läuft und beide Geräte mit ihm verbunden sind. Dann ein Testgerät unter wohnzimmer/temperatur publishen und am Display den eintreffenden Wert beobachten.
MQTT heißt nicht, Nachrichten direkt zu verschicken, sondern unter einem Topic zu veröffentlichen und den Broker verteilen zu lassen. Wer den Broker vergisst, sucht eine Verbindung, die es nie gab.
📌 Publish · Subscribe · Broker
📚 IoT von Grund auf · Tag 4 von 30
#mqtt #iot #esp32 #Mikrocontroller
8 Monate vor
Edge AI auf dem ESP32-S3: TinyML-Modell zur Vogelarten-Erkennung direkt auf dem Mikrocontroller. Kamera löst bei Bewegung aus, Klassifizierung in 150ms, Ergebnis per MQTT ans Dashboard. Bisher 2.400 Fotos von 8 verschiedenen Vogelarten automatisch kategorisiert. Natur trifft Technik! #esp32s3 #tinyml #edgeai
8 Monate vor
14
Menschen haben abgestimmt
9 Monate vor
Automatische Bewässerung v2.0 fertig: ESP32-S3, 4 kapazitive Bodenfeuchtesensoren, Magnetventile, Solarpanel. Das System entscheidet selbst wann und wie lange bewässert wird - basierend auf Bodenfeuchte, Wettervorhersage (API-Abfrage alle 6h) und Pflanzenprofilen.
Wasserverbrauch gegenüber Zeitschaltuhr um 45% reduziert. Pflanzen sehen besser aus als je zuvor. Alles per MQTT an Home Assistant angebunden, Verlauf in Grafana. Das vollständige Tutorial kommt nächste Woche. #smarthome #esp32 #automation
Wasserverbrauch gegenüber Zeitschaltuhr um 45% reduziert. Pflanzen sehen besser aus als je zuvor. Alles per MQTT an Home Assistant angebunden, Verlauf in Grafana. Das vollständige Tutorial kommt nächste Woche. #smarthome #esp32 #automation
10 Monate vor
Mosquitto MQTT Broker auf Raspberry Pi 5: Läuft stabil mit 120+ Topics, 25 Clients, 500 Messages/Minute. Retention-Messages für Statusinformationen, QoS 1 für kritische Sensordaten. Kein Cloud-Abo nötig, alles lokal. Backup der Datenbank täglich auf NAS. Lokale IoT-Infrastruktur die zuverlässig funktioniert und 0 EUR/Monat kostet. #mqtt #raspberrypi #selfhosted
