E-Paper-Infodisplay mit ESPHome: Wetter, Müll und Warnungen auf einen Blick

Ich wollte schon lange ein Display im Haus, auf dem man im Vorbeigehen sieht, wie das Wetter wird und welche Tonne als Nächstes rausmuss. Ein Tablet an der Wand war mir zu hell, zu stromhungrig und zu sehr „Technik“. E-Paper ist dafür perfekt: kein Leuchten, sehr gut ablesbar, und das Bild bleibt stehen, auch wenn der Controller schläft.

Herausgekommen ist ein 7,5-Zoll-Display von Waveshare an einem ESP32, programmiert mit ESPHome und gefüttert von Home Assistant. Das Ganze läuft inzwischen zuverlässig – aber der Weg dahin hatte ein paar Stolpersteine, die ich euch nicht vorenthalten will.

Die Hardware

Das Waveshare 7,5” E-Paper HAT V2 hat 800×480 Pixel in Schwarz-Weiß. In ESPHome läuft es über die Plattform waveshare_epaper mit dem Modell 7.50inv2. Ich betreibe es hochkant, also mit rotation: 90, was effektiv 480×800 Pixel ergibt. Hochkant passt an meiner Wand besser und lässt sich schön in Blöcke von oben nach unten aufteilen.

Als Controller reicht ein ganz normales ESP32-Board, zum Beispiel ein ESP32-Entwicklungsboard mit USB-C. Verbunden wird das Display per SPI.

Was auf dem Display steht

Von oben nach unten:

• Kopfzeile mit dem Zeitpunkt der letzten Aktualisierung
• Aktuell: große Außentemperatur von meiner Ecowitt-Wetterstation, dazu Regen heute
• Vorhersage: Wettericon, deutscher Text, Temperaturspanne und Niederschlag. Ab 17 Uhr zeigt dieser Block die Vorhersage für morgen – abends interessiert mich das heutige Wetter schlicht nicht mehr
• Müllabfuhr: welche Tonne als Nächstes dran ist, als „heute“, „morgen“ oder „in X Tagen“
• Warnungen: Unwetterwarnungen vom DWD und Warnungen aus der NINA-Warn-App

Das Layout ist adaptiv. Gibt es keine Warnungen, zeige ich im freien Platz Sonnenauf- und -untergang. Bei mehreren Warnungen fällt die Vorhersage weg, damit die Warnungen Platz haben. Und bei einer wirklich ernsten Warnung übernimmt ein Vollbild-Alarm das komplette Display. Hitze- und UV-Warnungen sind davon bewusst ausgenommen, sonst stünde das im Sommer wochenlang formatfüllend da.

Ein Punkt, der mir wichtig war: Das Display hängt an einer Stelle, an der es auch die Bewohner der zweiten Wohneinheit sehen. Deshalb kommen dort nur allgemeine Infos hin – keine Kalendertermine, keine Namen, keine Anwesenheit. Denkt vor dem Aufhängen kurz darüber nach, wer euer Display alles lesen kann.

Die Aufgabenteilung: Home Assistant rechnet, ESPHome zeichnet

Ich habe die ganze Aufbereitung in Home Assistant gelegt. Über ein Package mit Template-Sensoren entstehen dort fertige Texte wie „16° bis 23°“ oder „in 2 Tagen (Mo)“. Der ESP32 holt sich nur noch diese fertigen Werte und malt sie hin. Das hat zwei Vorteile: Die Logik lässt sich in Home Assistant viel einfacher testen, und ich muss für eine Textänderung nicht jedes Mal neu flashen.

Kleiner Stolperstein bei den Entity-IDs: Aus dem Namen „E-Paper“ macht Home Assistant e_paper, nicht epaper, und aus „Müll“ wird mull, nicht muell. Mein erster Versuch hat genau deshalb nichts angezeigt.

Die Icons kommen übrigens als Schrift: Die Material Design Icons gibt es als TTF-Datei, und ESPHome kann daraus einzelne Glyphen einbinden. Das ist ideal für Schwarz-Weiß und spart Bilddateien.

Echte Umlaute auf dem Display

Anfangs fehlten alle Umlaute. ESPHome bindet ohne weitere Angabe nur einen Grundsatz an Zeichen ein. Die Lösung ist die Option glyphsets bei der Schrift:

font:
  - file: "gfonts://Roboto"
    id: schrift_normal
    size: 24
    glyphsets: [GF_Latin_Core]
    glyphs: ["°", "–"]

GF_Latin_Core enthält ä, ö, ü und ß. Für die große Temperaturanzeige gebe ich dagegen nur die Ziffern und das Gradzeichen an, sonst wird die Firmware unnötig groß.

Deep Sleep und Zeitplan

Das Display muss nicht ständig aktualisiert werden. Der ESP32 schläft deshalb die meiste Zeit im Deep Sleep, wacht zu festen Zeiten auf, holt die Daten, zeichnet neu und legt sich wieder hin. Die Termine sind so gewählt, wie ich das Display nutze: morgens mehrmals, mittags und nachmittags einmal, abends stündlich und über Nacht gar nicht.

Zwei Dinge haben mich dabei überrascht:

1. Safe Mode und Deep Sleep vertragen sich nicht von selbst. ESPHome zählt einen Boot als misslungen, wenn das Gerät nicht lange genug läuft. Da meins nach wenigen Sekunden wieder schläft, wäre es nach einigen Wake-ups fälschlich im Safe Mode gelandet. Die Lösung ist safe_mode: boot_is_good_after: 5s.
2. Die Sommerzeit. Beim Berechnen des nächsten Termins lag ich plötzlich eine Stunde daneben. Die C-Funktion, die ich dafür genutzt hatte, ignoriert auf dem ESP32 die Sommerzeit, auf meinem Rechner aber nicht. Ich rechne jetzt mit Minuten seit Mitternacht und korrigiere über die lokale Zeit.

Gezeichnet wird nur, wenn wirklich alle Werte aus Home Assistant angekommen sind. Anfangs hat das Display bei jeder API-Verbindung losgelegt – auch wenn nur das Log-Fenster im ESPHome Builder geöffnet war – und dann überall „—“ über ein eigentlich gutes Bild gemalt. Mein erster Gedanke war, nur auf Verbindungen von Home Assistant zu reagieren. Das ging nach hinten los, weil sich die Verbindungen bei mir nicht zuverlässig unterscheiden ließen und dann gar nichts mehr gezeichnet wurde. Jetzt prüft das Script einfach per has_state(), ob alles da ist. Fehlt etwas, bleibt das alte Bild stehen – bei E-Paper kein Problem.

Der OTA-Modus-Schalter

Ein Gerät, das 99 % der Zeit schläft, ist schlecht zu flashen. Früher musste ich zum Update den Reset-Knopf drücken und dann schnell sein. Jetzt gibt es in Home Assistant einen Schalter „OTA-Modus“ (ein simpler input_boolean), den der ESP32 als binary_sensor mit der Plattform homeassistant einliest. Ist er an, verhindert das Gerät nach dem Zeichnen den Deep Sleep per deep_sleep.prevent und bleibt wach, bis ich fertig geflasht habe. Schalter wieder aus, und es legt sich bis zum nächsten Termin schlafen. Wichtig: Nicht vergessen, ihn auszuschalten.

Der teuerste Fehler: Der API-Schlüssel

Der Fehler, der mich am meisten Zeit gekostet hat, war eigentlich banal. Der ESPHome Builder hatte beim Anlegen des Geräts einen Verschlüsselungsschlüssel für die API erzeugt, und Home Assistant hatte ihn übernommen. Als ich meine eigene YAML-Fassung auf das Gerät gespielt habe, fehlte dieser Block:

api:
  encryption:
    key: !secret epaper_display_encryption_key

Ergebnis: Home Assistant wollte verschlüsselt sprechen, das Gerät antwortete unverschlüsselt, die Verbindung brach sofort ab. Das Display zeigte nur „—“, und im Log tauchten Lesefehler auf. Gemein: Die Zeitsynchronisation lief trotzdem, weshalb ich lange dachte, die Verbindung sei in Ordnung.

Dazu kommt, dass das Gerät nur kurz wach ist. Scheitert die Verbindung ein paar Mal, wartet Home Assistant immer länger bis zum nächsten Versuch und trifft das Wach-Fenster irgendwann gar nicht mehr. Meine Lehre: Überschreibt eine ESPHome-YAML nie blind, sondern vergleicht sie vorher mit der Version im Builder. Der trägt dort Dinge ein, die sonst verloren gehen.

Fazit

Das E-Paper-Display ist eines meiner liebsten Bastelprojekte geworden. Es macht genau eine Sache, macht sie unaufdringlich und wird tatsächlich jeden Tag angeschaut. Wer das nachbauen will: Legt die Logik in Home Assistant, lasst den ESP32 nur zeichnen, plant den Deep Sleep von Anfang an mit ein und sichert euren API-Schlüssel, bevor ihr die erste eigene YAML aufspielt.