IoT: der Briefkasten und Analyse der ESP-Hardware

Ich hatte bereits Pläne, den Briefkasten mit in’s Heimnetzwerk einzubinden. Allerdings war mir dazu die serielle Kommunikation von einem Arduino Nano zum ESP8266 doch etwas zu unzuverlässig und klobig. Angesichts dessen, das der ESP eigentlich auch nur eine MCU ist, die ein wenig mit WLAN gepimpt wurde wollte ich die Ansteuerung komplett auf den ESP reduzieren. Allerdings hatte ich zu wenig Zeit und Lust, mich mit weiteren Programmierumgebungen auseinanderzusetzen. Durch die Möglichkeit der Programmierung mittels Arduino IDE war aber eine schnelle und einfache Programmierung an einem Nachmittag inkl. Realisierung der Schaltung möglich.

Worum geht es bei dem Projekt überhaupt?
Ich komme nach Hause, mal leere ich den Briefkasten, oft ist er doch leer und ich enttäuscht, mal liegt die Post schon auf der Treppe oder kompostiert sich irgendwann, weil keiner nachguckt. Keine Lust mehr auf das alles, da muss es was einfacheres geben, wie ich weiß, ob Post im Briefkasten liegt. Die wohl einfachste Methode wäre da eine Waage im Briefkasten, deren Anzeige nach draußen zeigt. Ist aber zum Einen zu leicht und zum Anderen auch optisch nicht wirklich ansprechend.

Zwei restliche ESPs von meiner Großbestellung lagen hier noch rum, nur einer mal kurz [für die Testschaltung mit dem Nano] benutzt, die Anderen sind irgendwie beim Stammtisch versackt, weil die Kollegen dann doch mehr Bedarf hatten, als ich. Den Programmieradapter hatte ich mir ja direkt zum Erscheinen der IDE fertig gebaut, also war es grob genommen nur noch die Portierung des Codes auf den ESP. Zur finalen Versionen waren es allerdings einige Zwischenschritte.

Die Schaltung: ein Hall-Sensor (Magnetfeld-Sensor), alternativ wäre auch ein Reed-Kontakt gegangen, der am Briefschlitz befestigt ist und auf den Magneten an der Klappe reagiert. Gleiches dann noch mal an der Tür. Die dann mit PullUps zum ESP und fertig. So war zumindest der Plan. Ein Stromanschluss ist durch die Beleuchtung schon vorhanden gewesen.

Da ich nur die ESP-01 Ausführung hatte, waren mir nicht mehr als 4 Pins gegeben. GPIO 0 darf beim Boot nicht auf Low sein, sonst wird der Werks-Bootloader ausgeführt und man hat wieder nur einen normalen ESP. GPIO 1 (Tx) sollte beim Hochfahren ebenfalls nicht mit Peripherie verbunden sein. Der Pin kann allerdings als LED-Ausgang benutzt werden. Die blaue LED auf dem Board, die ausgehende serielle Pakete indiziert, kann mit digitalWrite(1, LOW) angeschaltet werden (seriell hat HIGH als Standardpegel). Für kleines Debugging vielleicht ganz gut. Rx (Pin 3) und GPIO 2 können hingegen mehr oder weniger unabhängig benutzt werden, wobei es nicht empfohlen wird, die Hardware Rx/Tx Pins für andere Zwecke zu missbrauchen. Da die Tür des Briefkastens 99% des Tages geschlossen ist, wie auch die Klappe, habe ich an beiden meistens einen LOW Pegel. Für Stromausfall nicht wirklich das Beste, da er dann ja das Programm nicht bootet.

Was also, wenn man nur einen Pin wirklich dafür nutzen könnte? Nachdem ich Anfangs mit I2C auf Kriegsfuß stand (es war eigentlich nur ein kaputtes Flachbandkabel, was den Ärger verursachte), ist es jetzt mein liebster Freund. Man braucht nur zwei Pins und diese sind sogar normal HIGH, also kann ich Pin 0 und 2 wieder beide nutzen und einfach einen MCP23008 dran hängen. Die Wire-Library kommt in veränderter Form für den ESP mit dem IDE-Aufsatz und wickelt die Kommunikation über das I2C-Protokoll ab. Mit dem MCP hatte ich dann 8 GPIOs zur Verfügung, die ich dann frei benutzen konnte.

Zum Initialisieren muss neben dem klassischen Wire.begin() auch noch Wire.pins(SDA, SCL) aufgerufen werden, wobei SDA GPIO 0 und SCL die 2 beim ESP-01 belegt. Die Portfrequenz schwankt dann bei der Übertragung zwischen 40 und 80kHz. Zum Vergleich: die normale Library auf einem ATmega läuft bei konstant 100kHz (Fast Mode). Zum aktuellen Zeitpunkt (12. April) ist diese Schwankung jedoch bekannt und es wird an einer Stabilisierung gearbeitet. Allerdings ist die Geschwindigkeit nicht so wichtig, da es sich im Gegensatz zur rein seriellen Übertragung (über Rx/Tx) um ein synchrones Protokoll (mit Clock) handelt.

Weiterer Vorteil: der MCP bringt wie auch z.B. ein PCF8574 interne PullUps mit, denn der ESP hat anscheinend keine internen Widerstände, die an und ausgeschaltet werden können. Trotzdem werden externe PullUp-Widerstände von z.B. 4.7kΩ für SDA und SCL nötig.

Jetzt kann in jedem loop der Status zweier Pins am MCP abgefragt werden (für den Interrupt wollte ich dann doch nicht die serielle Schnittstelle missbrauchen). Ist der Wert HIGH, also die Tür oder Klappe offen, so wird mein Banana Pi angefragt, er möge mir doch bitte eine Nachricht senden. Die Nachricht wird mittels Pushover auf mein Handy gesandt. Die API ist mit einem einfachen POST realisiert, allerdings nur auf HTTPS. Den Handshake und die komplette Verschlüsselung zu implementieren hätte wohl deutlich länger gedauert, als ein Quick & Dirty Script auf einem Server, der eh 24/7 läuft. Abhängig von der Uhrzeit werden dann unterschiedliche Nachrichten versandt:

  • 05:00 – 07:59: Zeitung liegt zum Lesen bereit.
  • 09:00 – 12:30: Sie haben Post!
  • 12:30 – 15:59: Hat jemand DHL verpasst?
  • 22:00 – 04:59: Irgendwelche Leute finden es lustig am Briefkasten Fremder zu spielen…
  • Sonntags und zu den übrigen Zeiten: Altpapier!

Beim Öffnen der Tür werde ich kurz und knapp über die Entnahme des Postaufkommens informiert. Debouncing funktioniert sehr einfach in diesem Fall:
Wenn der Pin HIGH ist und LOW zuvor mindestens 30 Sekunden auf diesem Pin war, dann wird eine Serveranfrage gestartet. So eliminiert man eine flatternde Klappe und eventuellen Mehrfacheinwurf.

Stromversorgung im Testbetrieb über USB, im Normalfall jedoch mit 230V über das obere Schraub-Terminal. Das Untere ist der Relaisausgang.

Stromversorgung im Testbetrieb über USB, im Normalfall jedoch mit 230V über das obere Schraub-Terminal. Das Untere ist der Relaisausgang. Die Stiftleisten sind zum Anschließen der Hall-Sensoren.

Da die Beleuchtung des Hausnummernschildes über eine Zeitschaltuhr realisiert war, wäre die Stromzufuhr in der relevanten Zeit ausgeschaltet und damit der ESP ebenfalls. Eine Akku-Lösung ist nicht das Wahre. Aber wenn man eh schon einen Controller drin hat, kann man auch noch ein Solid-State-Relais einbauen, das je nach Sonnenauf-/-untergang die Beleuchtung schaltet. Somit war eine Problemquelle und ein Verbraucher aus dem Komplex entfernt. Die Stromzufuhr des ESP läuft über ein erst aus seine Gehäuse gebrochenen, dann verlötetem und schlussendlich in Heißkleber wieder isoliert eingegossenem USB-Netzteil. Bis zum Eintreffen der 3V3 LDO-Regler ist noch ein StepDown zur Spannungsreglung dazwischen geschaltet.

Im aktiven Einsatz. Die blaue ultrahelle LED signalisiert das eingeschaltete Relais (tagsüber schwer erkennbar, ob Beleuchtung an oder aus) und beleuchtet den Innenraum bei Nacht. Wenn die LDOs da sind, wird das Ganze in die Abzweigdose eingebaut.

Im aktiven Einsatz. Die blaue ultrahelle LED signalisiert das eingeschaltete Relais (tagsüber schwer erkennbar, ob Beleuchtung an oder aus) und beleuchtet den Innenraum bei Nacht. Wenn die LDOs da sind, wird das Ganze in die Abzweigdose eingebaut. Links in Pattafix eingebettet der Hall-Sensor.

Dieser Eintrag wurde veröffentlicht in ESP8266 von Luca Zimmermann. Permanenter Link des Eintrags.

Über Luca Zimmermann

Programmiere seit ich 12 bin und habe einen Hang zur Elektronik seit ich denken kann.
Studiere aktuell angewandte Informatik an der Hochschule Hannover. Hier moderiere ich das Forum, warte den Server, bin China-Zwischenhändler und kümmer mich um noch so einiges.
Beantworte alle Fragen, sofern möglich, gerne auch im Forum. Fast 24/7 erreichbar.