Wir haben einen Balkon. Dort stehen ein Feigenbaum, ein paar Fliesen und Tauben. Jedes Mal, wenn ich eine entdeckte, eilte ich hinaus und wedelte mit den Armen. Zehn Minuten später waren sie wieder da. Als Tüftler dachte ich mir natürlich: Das muss automatisiert werden.
Die Idee war einfach – eine kleine Kamera, ein ESP32, Bewegung erkennen, ein Foto senden. Ein paar Abende Arbeit. Das war vor einem Jahr.
Das Batterieproblem hat alles zunichte gemacht
Die Bewegungserkennung funktionierte einwandfrei. Dann kam die Nacht. Am Morgen war die Batterie leer.
Die meisten ESP32-Entwicklungsboards sehen auf dem Papier toll aus – Deep Sleep, LiPo-Ladegerät, Energiesparmodi. Was die Spezifikationen nicht verraten: Das Kameramodul zieht auch im Deep Sleep weiterhin Strom. Ich habe es mit Transistoren versucht, um den Strom abzuschalten. Mit MOSFETs. Mit einem zweiten Mikrocontroller, um das Hauptboard auszuschalten. Jede Lösung zog entweder zu viel Standby-Strom oder fügte Komplexität hinzu, die etwas anderes kaputt machte.
Die Lösung war radikal: die Stromversorgung zwischen den Ereignissen komplett unterbrechen. Kein Deep Sleep. Die Schlüsselkomponente ist der TPS22918 – ein winziger Lastschalter-IC. Der PIR-Sensor löst ihn aus, wodurch der ESP32-S3 von Null aus neu gestartet wird. Der erste Firmware-Befehl sperrt die Stromschiene selbst. Fertig → das Board gibt die Sperre frei → völlige Dunkelheit. Standby-Strom: ~140 µA, hauptsächlich der PIR-Sensor selbst. Der ESP32 zieht nichts, da er keine Stromversorgung hat. Wenn ich Zeit habe, werde ich einen ausführlicheren Artikel zu diesem Thema schreiben – es war eine kleine Herausforderung, das richtige Bauteil zu finden und das winzige SMD-Bauteil zu löten, aber nach all meinen anderen gescheiterten Hardware-Versuchen läuft es einfach perfekt. 🙂
Ja, das ist ein Steckbrett in einem Karton. Es ist ein Prototyp.
WLAN löst den PIR aus. Im wahrsten Sinne des Wortes.
Gerade als das Problem mit der Stromversorgung gelöst schien: WiFi-Funkstörungen lösten den PIR-Sensor während des Uploads aus. Das System spielte verrückt – es blinkte, löste sich immer wieder aus, geriet in eine Spirale. Es hat lange gedauert, das zu finden. Die Lösung: den PIR-Interrupt während der WiFi-Übertragung deaktivieren, Wiederauslösungen elegant handhaben.
KI vs. Algorithmus – Der überraschende Teil
Auf dem Balkon gibt es Pflanzen, ein Geländer und den Himmel. Mittags löst die Sonne den PIR ständig aus – Wolken ziehen vorbei, Schatten huschen hin und her. Die meisten aufgenommenen Fotos waren leer.
Die naheliegende Antwort im Jahr 2025: ein neuronales Netzwerk darauf loslassen. Ich ging den anderen Weg – ein klassischer Signalverarbeitungsfilter, der auf dem ESP32 in weniger als 10 ms läuft, noch bevor das WLAN überhaupt aufwacht. Er unterteilt das Bild in ein Raster, vergleicht jede Kachel mit einem selbstgelernten, tageszeitabhängigen Hintergrund und entscheidet: echtes Ereignis oder nur Wolken?
Getestet an 147 Außenaufnahmen: 100 % Erkennung bei echten Ereignissen, 61 % der Fehlalarme unterdrückt. Keine Trainingsdaten nötig. Keine Modelldatei. Kalibriert sich selbst anhand von Live-Aufnahmen. Passt in 2 KB.
Manchmal sind die alten Werkzeuge die richtigen Werkzeuge.
Der aktuelle Stand
Die Plattform ist solide – zuverlässiges Aufwachen, Filterung von Fehlauslösungen, Foto-Upload. Was noch fehlt: Der Cloud-Check-Filter muss von Python auf C auf dem ESP32 portiert werden, und der ESP32-S3 hat genug Spielraum für ein kleines TFLite-Modell – die Hardware ist also bereits bereit für die Vogelerkennung auf dem Gerät, auch wenn das Taubenhirn noch nicht geschrieben ist.
Die Tauben sind vielleicht schon an Altersschwäche gestorben, bevor ich fertig bin. Aber ich habe bei diesem Projekt mehr über Embedded-Hardware gelernt als bei allem zuvor. Mein Respekt für Leute, die Systeme bauen, die monatelang unbeaufsichtigt im Freien laufen – dieser Respekt ist um ein Vielfaches gestiegen.