Bauanleitung für eine ESP32 Wetterstation & Umwelt-Monitor

Vor fast genau zwei Jahren habe ich den Artikel über die Wetterstation 2.0 veröffentlicht. Höchste Zeit also für ein Update. In diesem Artikel möchte ich euch die Version 3.0 vorstellen. Die Vorarbeiten haben schon vor einigen Monaten begonnen, als ich mich mit dem Thema LoRa und größeren Displays beschäftigt habe. Das Projekt ist inzwischen recht komplex geworden, aber ich werde versuchen, den Aufbau und die Funktionsweise so genau wie möglich zu beschreiben, so dass ein Nachbau grundsätzlich möglich ist.

Dieser Artikel ist aber nur eine Momentaufnahme des Projekts, denn die Wetterstation entwickelt sich laufend weiter. Bei wirklich wichtigen Veränderungen werde ich den Artikel entsprechend aktualisieren, aber ansonsten bitte nicht wundern, wenn es an der einen oder anderen Stelle kleine Unterschiede zwischen der Beschreibung hier und dem aktuellen Stand auf GitHub gibt.

Beginnen möchte ich mit einer Liste, was die ESP32 Wetterstation & Umwelt-Monitor so alles kann.

Basisstation

ESP32-P4 mit 10,1 Zoll IPS-Display
Gehäuse aus dem 3D-Drucker
Helligkeit des Displays passt sich automatisch an die Umgebung an
Display dunkelt automatisch ab, wenn sich niemand in der Nähe befindet
Sensirion Luftqualitätssensor liefert Temperatur, Luftfeuchtigkeit, VOC-Index, Feinstaub-, NO_X- und CO_2-Werte
Layout unterstützt bis zu 6 Sensoren gleichzeitig
24h-Verlaufscharts für alle Luftqualitätswerte

Funksensoren

ESP32-basiert, unterstützt ESP-NOW und LoRa Funkprotokolle
ESP-NOW-Sensoren verbinden sich vollautomatisch mit der Basisstation
Sehr niedriger Stromverbrauch durch Deep-Sleep-Modus
Akku kann optional über Solarzellen geladen werden
Jeder Sensor kann unterschiedliche Daten senden (Temperatur/Feuchte, Luftdruck, auch ein Geigerzähler für Radioaktivität). Neue Sensor-Typen können leicht eingebunden werden.
Jeder Sensor-Slot lässt sich im Setup mit Name und Icon aus einem Katalog individuell beschriften (Küche, Schlafzimmer, Balkon, ...)
Offline-Erkennung: ein Sensor-Slot wird rot markiert, wenn längere Zeit kein Signal gesendet wird

Wettervorhersage

Detaillierte Vorhersage für die kommenden 48 Stunden bzw. 7 Tage
Drei Wetter-APIs zur Auswahl: Open-Meteo, OpenWeatherMap und Visual Crossing

Software & Bedienung

Setup-Screen zur Konfiguration der Wetterstation
Sprache umschaltbar, aktuell Deutsch und Englisch
Automatische OTA-Updates über GitHub Releases, mit Rollback-Absicherung falls ein Update fehlschlägt

Was ich ganz bewusst nicht integriert habe, sind irgendwelche Cloud Dienste oder eine Mesh-Funktionalität. Die Wetterstation arbeitet rein lokal (abgesehen von den Wetterdaten natürlich) und ist somit von keinen weiteren Diensten abhängig.

Die Bauanleitung gliedert sich in die folgenden Punkte:

Grundlegender Aufbau
Softwarearchitektur
Applikation-Screens
Umwelt-Sensoren
Display-Sensoren
Neuen Sensortyp einbinden
Wetter-APIs
Hardware Basisstation
Gehäuse und Zusammenbau Basisstation
Funkmodule
Kosten
Fazit

Der grundlegende Aufbau der ESP32 Wetterstation

Die zentrale Komponente dieser Wetterstation ist das 10,1 Zoll Display von Waveshare. Mit seinem ESP32-P4 Mikrocontroller sind bei diesem Display Flackern und verschobene Pixel wie bei den früheren ESP32-S3 Boards endgültig Geschichte, da der ESP32-P4 sowohl über eine schnelle 2-Lane MIPI-DSI Schnittstelle verfügt als auch die nötige Leistung hat, die Daten schnell genug an das Display zu schicken.

Allerdings verfügt der ESP32-P4 über keinerlei Hardware für Bluetooth oder WLAN. Daher wird ihm in der Regel ein weiterer Mikrocontroller wie der ESP32-C6 zur Seite gestellt. Da dies die Softwareentwicklung aber deutlich erschweren würde, hat Espressif eine spezielle Softwarekomponente namens esp-hosted-mcu entwickelt, die die Kommunikation zwischen den beiden Mikrocontrollern im Hintergrund übernimmt und der Entwickler weiterhin die üblichen API Aufrufe des ESP-IDF Frameworks verwenden kann. Bis auf eine Ausnahme. ESP-NOW wird von esp-hosted bis heute nicht unterstützt. Dieses Protokoll ist aber essentiell für die Sensoren, daher gibt es jetzt einen eigenen Receiver, der auf einem Heltec LoRa 32 V4 basiert. Dadurch unterstützt der Receiver sowohl das ESP-NOW Protokoll als auch das LoRa Funkprotokoll. Der ESP32-C6 auf dem Display-Board übernimmt den Zugriff auf das WLAN, um die Daten der Wetter-APIs abzurufen oder eine neue Firmware zu laden.

Die Helligkeit des Displays wird über einen BH1750 Lichtsensor und einen C4001 Radarsensor gesteuert. Der Radarsensor stellt fest, ob sich überhaupt jemand in der Nähe befindet und schaltet das Display dunkel, wenn nicht. Bei menschlicher Präsenz steuert der BH1750 die Helligkeit des Displays abhängig von der Umgebung. Auch diese beiden Sensoren kommunizieren über die I²C Schnittstelle mit dem ESP32-P4.

Die Messung der Luftqualität erfolgt durch den neuen SEN66 von Sensirion. Dieser Sensor kann neben Temperatur und Luftfeuchtigkeit auch Feinstaub, Kohlendioxid, Stickoxide und VOC messen. Das Design vereinfacht sich dadurch ein wenig, weil nicht mehr wie früher zwei Sensoren notwendig sind. Auch dieser Sensor kommuniziert über die I²C Schnittstelle mit dem ESP32-P4.

Softwarearchitektur

Das Projekt ist mit dem aktuellen ESP-IDF Framework Version 6.x entwickelt worden. Die grafische Ausgabe basiert auf LVGL 9.5. Das Design des Layouts wurde mit EEZ-Studio erstellt.

Die Applikation besteht aus zwei Screens. Nach dem Start wird zunächst das Setup geladen. Nach dem Setup wird die eigentliche Applikation gestartet. Sobald dieser Screen geladen wurde, werden die einzelnen Tasks gestartet. Jeder Aufgabenbereich der Applikation bekommt dabei seinen eigenen Task.

Das folgende Diagramm gibt einen Überblick über die einzelnen Komponenten der Basisstation:

Der Receiver übernimmt die Aufgabe, Datenpakete der einzelnen Sensoren via ESP-NOW und LoRa zu empfangen und auf einem Stack abzulegen. Gegenüber dem ESP32-P4 verhält er sich dabei wie ein I²C Gerät, das über spezielle Register ausgelesen werden kann. Dadurch wird der Empfang der Sensordaten völlig von der Basisstation entkoppelt.

Sensoren, Receiver und Basisstation verständigen sich über ein gemeinsames Paketformat, das aus einem Header (Nachrichtentyp, Sensor-Nummer, Sensortyp, Länge) und der eigentlichen Payload-Struktur besteht, die je nach Sensortyp unterschiedliche Felder haben kann. Der Receiver ergänzt RSSI und SNR und reicht alles per I²C weiter. Ausgewertet wird die Payload erst auf der Basisstation, die anhand des Headers weiß, welcher Sensor-Slot und welche Struktur gemeint sind.

Beide Boards aktualisieren sich selbstständig über GitHub Releases. Jede Release triggert eine Action, in der die Firmware für die Basisstation und den Receiver erstellt wird. Die Basisstation prüft regelmäßig, ob eine neue Firmware-Version verfügbar ist. Bei einer neuen Version aktualisiert sich zunächst die Basisstation und anschließend der Receiver.

User Interface

Die Applikation ist recht einfach aufgebaut und besteht nur aus zwei Screens. Der Setup-Screen und der eigentliche Wetterstation-Screen. Es gibt keine Navigation zurück in das Setup. Falls man etwas ändern will, einfach kurz den Stecker ziehen, dann startet das Gerät wieder mit dem Setup-Screen.

Setup

Nach dem Einschalten der Wetterstation erscheint der Setup-Screen. Hier kann zunächst der WLAN-Zugang konfiguriert werden. Der Scan-Button sucht nach den verfügbaren Netzwerken. In der Dropdown List kann dann das eigene Netzwerk ausgewählt werden. Hat man das dazugehörige Passwort eingegeben, kann mit dem Verbinden-Button geprüft werden, ob eine Verbindung aufgebaut werden kann. Sollte schon ein WLAN-Zugang hinterlegt sein, wird beim Start automatisch geprüft, ob eine Verbindung aufgebaut werden kann.

Unter API wählt man den API-Provider aus. AppId ist der jeweilige Schlüssel des Wetter-APIs, das man verwenden möchte. Dieser Schlüssel wird nur für OpenWeatherMap und Visual Crossing benötigt. Open-Meteo funktioniert ganz ohne einen Schlüssel.

Latitude, Longitude und Höhe werden für die Wetter-APIs benötigt bzw. zur richtigen Umrechnung des Luftdrucks.

Die Zeitzone ist für die richtige Uhrzeit wichtig. Darüber wird auch die Sommerzeit gesteuert. Eventuell werde ich hier später noch einen Service integrieren, der die Zeitzone anhand der Latitude/Longitude Felder automatisch bestimmen kann.

Die letzten Felder sind die Beschriftungen der jeweiligen Sensoren bzw. der Wetterstation selbst. Der Typ des Sensors muss im Moment noch in EEZ-Studio direkt im Layout eingestellt werden. Das liegt an der Art und Weise, wie EEZ-Studio Code generiert: Alle Widgets eines Layouts werden einmalig beim Start in einem statischen struct angelegt. Der Widget-Aufbau und damit auch der Sensortyp kann daher zur Laufzeit nicht mehr geändert werden. Die einzige Option innerhalb dieses Workflows wäre, in jedem Slot von vornherein alle möglichen Sensortypen anzulegen und zur Laufzeit nur den passenden sichtbar zu machen. Das ist allerdings sehr umständlich und daher habe ich das nicht implementiert. Sobald ich aber eine Lösung für dieses Problem habe, werde ich das Setup entsprechend anpassen.

Zuletzt klickt man auf Starten, dann wird zum Screen mit den Wetter- und Sensordaten gewechselt.

Wetterstation

Mein Ziel war es, möglichst viele Informationen auf dem Display anzuzeigen und dabei trotzdem übersichtlich zu bleiben. Durch den Wechsel auf ein 10 Zoll Display können jetzt die Werte von sechs Sensoren angezeigt werden. Das folgende Bild zeigt alle Informationen, die am Display angezeigt werden.

Oben links und die beiden Diagramme unten sind die Daten des Wetter-APIs. Hier werden aktuelle Werte, eine stündliche Vorhersage für 48 Stunden und eine tägliche Vorhersage für 7 Tage angezeigt. Oben neben den aktuellen Werten werden die Daten der Basisstation und daneben die Werte der Sensoren angezeigt. Die folgenden Diagramme zeigen die Bereiche noch einmal mit einer Beschriftung der Daten.

Aktuelle Wetterdaten

Vorhersage für die nächsten 48 Stunden

Die Temperaturkurve zeigt farblich den Taupunkt an. Der Taupunkt ist die Temperatur, bei der die Luft gesättigt ist und Wasserdampf zu kondensieren beginnt. In Bezug auf das Temperaturempfinden, insbesondere auf Schwüle, spielt der Taupunkt eine entscheidende Rolle:

Hoher Taupunkt (über 18°C): Die Luft enthält viel Feuchtigkeit, und Schweiß verdunstet schlechter. Dadurch fühlt sich die Temperatur deutlich wärmer und unangenehm schwül an. Ab etwa 21°C wird es für viele drückend und belastend.
Niedriger Taupunkt (unter 13°C): Die Luft ist trockener, der Schweiß kann gut verdunsten, und es fühlt sich angenehmer an, selbst bei hohen Temperaturen.

Natürlich sind diese Werte sehr subjektiv und entsprechen eher meinem persönlichen Temperaturempfinden.

Vorhersage für die nächsten 7 Tage

Die Temperaturskala passt sich dynamisch an die höchsten und niedrigsten Werte an. Die Niederschlagsmenge wird dagegen auf einer festen Skala dargestellt, um auf einen Blick erkennen zu können, ob es viel oder wenig regnet. Bei der stündlichen Vorhersage habe ich den Maximalwert auf 5 mm festgelegt, während er bei der täglichen Vorhersage 20 mm beträgt, da es selten mehr regnet oder schneit. Zukünftig könnte ich diese Werte möglicherweise im Setup konfigurierbar machen.

Daten der Basisstation

Der SEN66 kann vier unterschiedliche Partikelgrößen messen, daher ist der obere Balken noch einmal in vier kleine Balken aufgeteilt. Der unterste Balken entspricht PM1 und ganz oben ist PM10.

Neben dem aktuellen Wert wird auch der Verlauf über die letzten 24 Stunden angezeigt. Da PM eigentlich vier Werte hat verwende ich für den Verlauf den PM2.5 Wert.

Daten der Sensoren

Im Moment gibt es drei unterschiedliche Sensortypen. Für jeden Typ ist in EEZ-Studio ein eigenes User-Widget implementiert. Im Code der Basisstation wird definiert, welcher Sensortyp mit welchem User-Widget angezeigt wird. Die Kopfzeile ist bei allen Sensortypen identisch aufgebaut und zeigt Icon, Name, Akkustatus und Signalstärke an. Die Farbe der Kopfzeile zeigt an, ob ein Sensor offline ist. Dazu speichert der Receiver für jeden Sensor die Zeitdauer zwischen den Datenpaketen und markiert den Sensor als offline, wenn die Zeitdauer mehr als das Dreifache der üblichen Zeit ist.

Es ist auch möglich, mehrere User-Widgets pro Sensortyp zu verwenden. Beispielsweise ein Widget für den BME280, das nur Temperatur und Luftfeuchtigkeit anzeigt oder ein größeres Widget, das Luftfeuchtigkeit und Luftdruck untereinander anzeigt. Hier sind der Phantasie kaum Grenzen gesetzt.

Softwareupdate

Jede Stunde wird geprüft, ob es auf GitHub eine neue Version gibt und gegebenenfalls ein entsprechendes Popup Fenster angezeigt.

Nach dem Download wird zunächst die Firmware der Basisstation aktualisiert und anschließend die Firmware des Receivers. Sollte bei dem Update etwas nicht funktionieren, wird automatisch wieder auf die vorherige Firmware gewechselt.

Die verwendeten Umweltsensoren

In der Wetterstation kommen ausschließlich hochwertige Sensoren zum Einsatz, da es bei dem ganzen Aufwand nicht sehr schlau wäre, hier am falschen Ende zu sparen. Primär setze ich dabei auf die hochpräzisen Sensoren des Schweizer Herstellers Sensirion. Ergänzt wird das Setup durch die bewährten BME280-Sensoren, die ich auf meinem selbst entworfenen Sensor-Board verwendet habe.

Sensirion SEN66

Der SEN66 ist ein neuer Umweltsensor von Sensirion zur Erfassung von Feinstaub (Partikel), flüchtigen organischen Verbindungen (VOC), Stickoxiden (NO_X), Kohlendioxid (CO₂), relativer Luftfeuchtigkeit und Temperatur. Der laserbasierte Partikelsensor misst Feinstaub der Kategorien PM1.0, PM2.5, PM4.0 und PM10.0. Die NO_X- und VOC-Messung erfolgt über Metalloxid-Gassensoren (MOX), die CO2-Konzentration über ein photoakustisches Sensormodul. Die Kommunikation mit dem Mikrocontroller läuft über I²C. Eine für mich ganz wesentliche Verbesserung ist die Versorgungsspannung von 3,3 V im Gegensatz zu den früheren 5 V beim SEN55. Daher muss jetzt kein zusätzlicher Draht mehr auf das Display gelötet werden wie bei den vorherigen Wetterstationen.

Neben den Massenkonzentrationen gibt der Sensor auch die Partikelanzahlkonzentration aus, im Bereich von PM0.5 bis PM10.0. Dank Sensirions patentierter Sheath-Flow-Technologie bleibt der Partikelsensor über 10 Jahre hinweg wartungsfrei und vor Staubablagerungen geschützt. Eine chip-interne Temperaturkompensation gleicht die Abwärme des Displays und der Mikrocontroller in Echtzeit aus.

Durch die Kombination von sechs verschiedenen Parametern in einem einzigen Gerät eignet sich der SEN66 daher hervorragend für die Wetterstation, um die Raumluftqualität zu überwachen. Speziell der breite Bereich der Feinstaubmessung kann eine Vielzahl von Partikeln in der Umgebungsluft registrieren. Die folgende Übersicht zeigt einige Beispiele von Feinstaub-Partikel und ihrer Größe:

Einige wichtige Eckdaten des SEN66:

Versorgungsspannung: 3,15 V bis 3,6 V
Stromverbrauch:
- Idle-Modus: ca. 3,3 mA
- Messmodus: Durchschnittlich 90 mA (maximal 110 mA)
- Peak-Strom: Bis zu 350 mA (während der kurzen Pulsphasen)
Messbereiche:
- Temperatur: +10 °C bis +40 °C empfohlener Betriebsbereich (typische Genauigkeit ±0,45 °C)
- Luftfeuchtigkeit: 20 % bis 80 % RH empfohlener Betriebsbereich (typische Genauigkeit ±4,5 % RH)
- Feinstaub: 0 bis 1000 μg/m³
- CO₂: 0 bis 40.000 ppm
- VOC- / NO_X-Index: 1 bis 500 Index-Punkte
Lebensdauer: > 10 Jahre im kontinuierlichen Betrieb

Sensirion SHT45

Der SHT45 ist ein Temperatur- und Luftfeuchtigkeitssensor der SHT4x-Serie von Sensirion. Er ist für Anwendungen konzipiert, die eine hohe Messgenauigkeit bei gleichzeitig geringem Energiebedarf erfordern. Der Sensor basiert auf der CMOSens-Technologie von Sensirion. Das physikalische Sensorelement und die digitale Signalverarbeitung (A/D-Wandler, Kalibrierungsspeicher und I²C-Schnittstelle) sind dabei auf einem einzigen Siliziumchip (CMOS/MEMS) integriert.

Die Feuchtigkeitsmessung erfolgt nach dem kapazitiven Prinzip. Als Sensorelement dient ein dielektrisches Polymer, das proportional zur relativen Umgebungsfeuchte Wasser aus der Luft absorbiert oder wieder abgibt. Diese Veränderung der Wasserkonzentration beeinflusst die Dielektrizitätskonstante des Polymers, was elektronisch als Kapazitätsänderung erfasst wird. Die Temperaturmessung wird direkt auf dem Siliziumchip über integrierte Bipolartransistoren realisiert.

Das folgende Bild zeigt recht eindrucksvoll die Genauigkeit der SHT45 Sensoren. Das Bild wurde aufgenommen, nachdem vier Sensoren einige Stunden nebeneinander gelegen sind.

Das Modul verfügt über einen integrierten mikroelektronischen Heizleiter, der per I²C-Befehl in drei Leistungsstufen (20 mW, 110 mW oder 200 mW) für 0,1 oder 1 Sekunde aktiviert werden kann. Dies erfüllt primär drei Funktionen:

Entfernung von Kondenswasser: Verdampft flüssige Feuchtigkeit von der Sensoroberfläche, um die Messfähigkeit nach Tau- oder Nebelbildung wiederherzustellen.
Vermeidung von Messabweichungen: Wirkt temporären Messabweichungen entgegen, die bei kapazitiven Sensoren durch langanhaltend hohe Luftfeuchtigkeit (>90 % rF) entstehen können.
Dekontamination: Unterstützt das Ausgasen von flüchtigen organischen Verbindungen (VOCs) aus dem Sensorpolymer nach einer chemischen Kontamination.

Das folgende Blockschaltbild zeigt den Aufbau des Sensors:

Einige wichtige Eckdaten des SHT45:

Genauigkeit: Typische Toleranz von ±1,0 % rF bei der Luftfeuchtigkeit und ±0,1 °C bei der Temperatur.
Messbereich: 0 bis 100 % rF sowie −40 °C bis +125 °C.
Schnittstelle: I²C (Fast Mode Plus) mit CRC-Prüfsumme.
Versorgungsspannung: 1,08 V bis 3,6 V.
Stromverbrauch:
- Durchschnittlich: 0,4 µA (bei 1 Hz Messrate im niedrigsten Modus).
- Ruhemodus (Idle State): 80 nA.

Bosch Sensortec BME280

Der BME280 ist ein Umweltsensor, der speziell für mobile Anwendungen von der Firma Bosch Sensortec entwickelt wurde. Er dient zur Messung von Luftfeuchtigkeit, Luftdruck und Temperatur. Der Sensor basiert auf der MEMS-Technologie (Micro-Electro-Mechanical Systems), die eine hohe Präzision und Langzeitstabilität der Messungen gewährleistet.

Der BME280 kann über eine I²C- oder SPI-Schnittstelle kommunizieren, was die Integration in verschiedene Projekte erleichtert. Dank seines geringen Stromverbrauchs ist er besonders für batteriebetriebene Anwendungen geeignet. Ein Nachteil des BME280 ist, dass er sich im Dauerbetrieb etwas erwärmt, was den Temperaturwert verfälschen kann. Da er auf den Funkmodulen aber nur alle 10 Minuten einen Wert liefert, spielt das für die Wetterstation keine Rolle.

Das folgende Blockschaltbild zeigt den Aufbau des Sensors:

Einige wichtige Eckdaten des BME280:

Genauigkeit:
- Temperatur ±0.5 °C im Bereich 0…65 °C
- Luftfeuchtigkeit ±3 % rF im Bereich 20…80 % rH und 25 °C
- Luftdruck ±1.0 hPa im Bereich 300…1100 hPa und 0…65 °C
Versorgungsspannung: 1.71 V bis 3.6 V
Stromverbrauch:
- 1.8 µA @ 1 Hz Luftfeuchtigkeit und Temperatur
- 2.8 µA @ 1 Hz Luftdruck und Temperatur
- 3.6 µA @ 1 Hz Luftfeuchtigkeit, Luftdruck und Temperatur
- 0.1 µA im Sleep Mode
Messbereich:
- -40 °C bis +85 °C
- 0 bis 100 % rel. Luftfeuchtigkeit
- 300 bis 1100 hPa

RadiationD Geigerzähler

Das RadiationD-v1.1 Board habe ich schon in einem früheren Artikel vorgestellt. Es ist zwar alles andere als ein Präzisionssensor, aber da ich das Board nun mal habe, wollte ich es auch in die Wetterstation integrieren. Das verbaute Geiger-Müller-Zählrohr detektiert hauptsächlich Gamma-Strahlung und hochenergetische Beta-Strahlung. Der Umrechnungsfaktor von Impulsen pro Zeit zu µSv/h für das verwendete J321 Zählrohr (ein Nachbau der M4011 Röhre) beträgt 0,0066 µSv/h pro CPM, d.h. 151 Impulse pro Minute entsprechen etwa 1 µSv/h.

Das RadiationD Board braucht eigentlich eine Versorgungsspannung von 5 V. Auf den Mikrocontroller Boards stehen aber nur 3,3 V zur Verfügung. Ich habe es trotzdem versucht und zu meiner Überraschung funktioniert das Board auch mit den 3,3 V. Lediglich die Hochspannung musste ich mit dem Trimmpotentiometer etwas erhöhen.

Sensoren zur Displaysteuerung

Die Helligkeit des Displays soll sich automatisch an die Helligkeit der Umgebung anpassen. Das spart einerseits ein wenig Strom und andererseits ist es sehr unangenehm, in ein zu helles Display zu schauen, wenn sich die Augen schon an Dunkelheit gewöhnt haben. Umgekehrt ist es natürlich auch nicht optimal, an einem hellen Tag auf einem zu dunklen Display die Werte abzulesen. Es gibt aber noch ein weiteres Problem. Die Beleuchtung des Displays erzeugt Wärme, die die Werte des SEN66 Sensors beeinflussen kann. Sensirion hat dazu auch mehrere Mechanismen in den Sensor integriert, um diese Faktoren auszugleichen, aber das Bestimmen dieser Werte ist nicht so einfach. Ich verwende daher nur einen einfachen Korrekturfaktor, der sich auf eine ganz bestimmte Helligkeit bezieht, und zwar wenn das Display fast ganz dunkel ist. Wer das ganz genau wissen will, kann in den SEN6x Temperature acceleration and compensation instructions von Sensirion nachlesen.

BH1750 Lichtsensor

Der BH1750 ist ein digitaler Umgebungslichtsensor, der sich ideal für die Steuerung der Hintergrundbeleuchtung eignet. Er verfügt über eine I²C-Schnittstelle, einen großen Erfassungsbereich (1 - 65535 Lux) und eine genügend hohe Auflösung. Vor allem aber ist diese kleine Platine breit verfügbar und kostet nur ein paar Euro.

Allerdings würde das Display dann an einem hellen Tag die ganze Zeit recht hell leuchten und die Werte des SEN66 wären deutlich zu hoch.

C4001 24GHz mmWave Radar Sensor

Mit dem C4001 Radar Sensor von DFRobot kann man feststellen, ob sich jemand vor dem Sensor befindet und in welcher Entfernung. Damit ist es möglich, dass das Display erst dann die normale Helligkeit annimmt, wenn jemand beispielsweise in weniger als drei Meter Entfernung vor dem Display steht. Auch dieser Sensor verfügt über eine I²C-Schnittstelle.

Dadurch ist es jetzt möglich, eine echte Bildschirmschoner Funktionalität zu implementieren und das Problem mit der Erwärmung ist auch gelöst, da das Display die meiste Zeit fast aus ist und die kurzen aktiven Momente für die Erwärmung vernachlässigbar sind.

Um den Korrekturfaktor für den SEN66 zu bestimmen, habe ich zwei SHT45 Sensoren neben die Wetterstation gelegt und das Gerät mehrere Stunden mit abgedunkeltem Display arbeiten lassen. Die Differenz zwischen der Wetterstation und den SHT45 war dann 1,4 °C, die vor allem durch die Abwärme des ESP32-P4 und des ESP32-S3 im Receiver entsteht.

Einen neuen Sensortyp einbinden

Jede Sensor-Firmware, der Receiver und die Basisstation teilen sich dieselbe packet_format.h Struktur. Dazu hat jedes Projekt eine Kopie im lokalen common/-Ordner, aber der Inhalt muss identisch sein. Das Format ist in drei Schichten aufgeteilt:

typedef struct __attribute__((packed)) {
    uint8_t msg_type;     // PAIRING_REQ / PAIRING_RESP / DATA
    uint8_t sensor_nr;    // 0-254, identifiziert den Slot (0-5 im aktuellen Setup)
    uint8_t sensor_type;  // sensor_type_t
    uint8_t payload_len;  // Länge von payload[] in Byte (0-64)
} packet_header_t;         // 4 Byte, das schickt JEDER Sender per Funk

Der Header sagt nur "wer bin ich" und "wie viele Bytes folgen". Er kennt die konkrete Bedeutung der Nutzdaten nicht. Die eigentlichen Messwerte stecken in einem eigenen Struct pro Sensortyp, z.B.:

typedef struct __attribute__((packed)) {
    uint32_t voltage;      // mV
    float    temperature;  // °C
    float    humidity;     // %RH
} sht45_payload_t;

Damit der Empfänger weiß, welches Struct er auf die rohen Bytes casten muss, gibt es sensor_type_t:

typedef enum {
    SENSOR_TYPE_BME280  = 1,
    SENSOR_TYPE_SHT45   = 2,
    SENSOR_TYPE_GEIGER  = 3,
    SENSOR_TYPE_CUSTOM  = 255
} sensor_type_t;

Der Weg eines Pakets sieht folgendermaßen aus:

Sensor-Board misst, baut packet_header_t + Payload zusammen und schickt die Daten per LoRa oder ESP-NOW.
Der Receiver (ESP32-S3) empfängt die Daten, hängt intern noch link_metadata_t (RSSI, SNR, Timestamp) an und legt das komplette Paket in einen Stack mit einem Slot pro sensor_nr.
Die Basisstation (ESP32-P4) fragt den Receiver alle 2 Sekunden über I²C ab und bekommt die rohen Bytes zurück.

Der Receiver interessiert sich nicht für sensor_type sondern reicht die Bytes unverändert durch. Die Interpretation erfolgt ausschließlich auf der Basisstation. Das bedeutet, ein neuer Sensortyp erfordert keine Änderung am Receiver-Projekt.

Auf der Basisstation läuft die Interpretation in gui_sensors.c. Für jeden der 6 Sensor-Slots gibt es einen Eintrag, der Sensortyp, Anzeige-Widget und die zugehörigen LVGL-Label-Felder verknüpft:

static const sensor_slot_t sensor_slots[SENSOR_SLOT_COUNT] = {
    { SENSOR_TYPE_SHT45,  render_temp_hum, &objects.sensor_0__name, ...,
      &objects.sensor_0__header, { &objects.sensor_0__temp, &objects.sensor_0__humidity, NULL, NULL, NULL } },
    ...
};

render_temp_hum() selbst prüft per switch (type), ob es sich um SHT45 oder BME280 handelt und castet entsprechend. Dasselbe Anzeige-Widget funktioniert also für mehrere Hardware-Sensoren mit gleicher "Form" der Messwerte (zum Beispiel Temperatur & Luftfeuchtigkeit).

Praxisbeispiel: Windmesser (Richtung + Geschwindigkeit)

Da dieses Thema für eigene Erweiterungen besonders wichtig ist, möchte ich das Prinzip am Beispiel eines Windmessers verdeutlichen, der Windgeschwindigkeit und Richtung liefert.

1. packet_format.h erweitern (in jeder Kopie: BaseStation, Sensor-Receiver, und dem neuen Sensor-Projekt selbst):

typedef enum {
    SENSOR_TYPE_BME280  = 1,
    SENSOR_TYPE_SHT45   = 2,
    SENSOR_TYPE_GEIGER  = 3,
    SENSOR_TYPE_WIND    = 4,   // neu
    SENSOR_TYPE_CUSTOM  = 255
} sensor_type_t;

typedef struct __attribute__((packed)) {
    uint32_t voltage;         // mV
    float    wind_speed;      // km/h
    float    wind_direction;  // Grad, 0-359 (0 = Nord)
} wind_payload_t;             // 12 Byte

2. Sender-Firmware Struktur ist analog zum bestehenden LoRa-SHT45-Sensor (Sensor-LORA-SHT45/main/main.c): Board aufwachen, messen, Paket bauen, per LoRa senden, wieder schlafen legen. Nur der Mess- und Payload-Teil ändert sich:

float speed_kmh, direction_deg;
wind_sensor_read(&speed_kmh, &direction_deg);   // eigener Treiber

lora_sensor_packet_t packet;
memset(&packet, 0, sizeof(packet));
packet.header.msg_type    = DATA;
packet.header.sensor_nr   = cfg.sensor_nr;      // Slot, im Konfigmenü am Gerät eingestellt
packet.header.sensor_type = SENSOR_TYPE_WIND;

wind_payload_t wind_payload = {
    .voltage        = voltage,
    .wind_speed     = speed_kmh,
    .wind_direction = direction_deg,
};
memcpy(packet.payload, &wind_payload, sizeof(wind_payload_t));
packet.header.payload_len = sizeof(wind_payload_t);

sx1262_send((uint8_t *)&packet, sizeof(packet_header_t) + packet.header.payload_len);

3. Im Receiver-Projekt gibt es keine Änderung. Er kennt SENSOR_TYPE_WIND gar nicht und muss es auch nicht kennen, er transportiert nur Bytes.

4. In der Basisstation in gui_sensors.c wird eine neue Render-Funktion implementiert, die weiß, wie ein wind_payload_t aussieht:

static void render_wind(sensor_type_t type, const sensor_values_t *v, const void *payload)
{
  if (type != SENSOR_TYPE_WIND) return;
  const wind_payload_t *d = (const wind_payload_t *)payload;

  char buf[16];
  sprintf(buf, "%.1f", d->wind_speed);
  lv_label_set_text(*v->value1, buf);

  // Kompassnadel drehen - gleiches Prinzip wie beim Wind-Icon im Wetter-Widget
  // (siehe gui_weather.c: lv_img_set_angle(objects.current__wind_direction, ...))
  lv_image_set_rotation(*v->value2, (int32_t)(d->wind_direction * 10));
}

Und der Slot-Tabellen-Eintrag, z.B. wenn Sensor 3 künftig der Windmesser ist:

// Windmesser
{ SENSOR_TYPE_WIND, render_wind, &objects.sensor_3__name, &objects.sensor_3__icon,
  &objects.sensor_3__battery, &objects.sensor_3__wifi, &objects.sensor_3__header,
  { &objects.sensor_3__speed, &objects.sensor_3__direction_icon, NULL, NULL, NULL } },

5. Zuletzt muss in EEZ Studio ein neues Sensor_Wind User-Widget für Slot 3 angelegt werden (mit den passenden benannten Feldern für Geschwindigkeit und Richtungsanzeige). Das ist der Schritt, den ich weiter oben zum Thema statischen struct beschrieben habe. Der Widget-Typ pro Slot wird schon im Layout festgelegt. Wie die Daten angezeigt werden ist ganz der eigenen Kreativität überlassen. Es können einfach zwei Zahlen sein, oder ein drehendes Icon oder auch ein Verlauf der letzten 24 Stunden wie beim Geigerzähler.

Die verwendeten Wetter-APIs

Die Wetterstation zeigt Vorhersagen für die nächsten 48 Stunden und die kommenden 8 Tage an. Damit ich nicht von einem einzelnen Anbieter abhängig bin, unterstützt die Software jetzt drei verschiedene Wetter-APIs, zwischen denen man im Setup per Dropdown umschalten kann.

Open-Meteo

Open-Meteo ist kein klassisches Unternehmen, sondern in erster Linie ein Open-Source-Projekt von Patrick Zippenfenig. Der komplette Quellcode liegt öffentlich auf GitHub, alle verwendeten Datenquellen sind offen gelegt, und wer möchte, kann sich die API sogar selbst hosten. Die Haltung dahinter ist erklärtermaßen, dass gute Wetterdaten für jeden frei verfügbar sein sollten, und das merkt man auch beim Einstieg:

Keine Registrierung, kein Account, kein API-Key
Täglich über 2 TB verarbeitete Daten aus Modellen nationaler Wetterdienste wie DWD, NOAA oder ECMWF
Kostenlos für nicht-kommerzielle Nutzung
Aktuelle Werte, Stunden- und Tagesvorhersage kommen nicht gemeinsam, sondern erfordern drei getrennte API-Aufrufe

VisualCrossing

Das Unternehmen hinter VisualCrossing, die Visual Crossing Corporation mit Sitz in Reston, Virginia, wurde 2003 von Sean McCafferty und Andrew Wigmore gegründet und hat sich auf historische Wetterdaten, Vorhersagen und Klimazusammenfassungen spezialisiert. Der erklärte Anspruch ist, Wetterdaten einfacher und günstiger zugänglich zu machen als viele andere Anbieter:

Kostenloser Account, API-Key als Parameter, keine Kreditkarte nötig
Ein einziger Aufruf liefert aktuelle Werte, Stunden- und Tagesvorhersage gemeinsam
Abrechnung nach Records, aber ein kompletter Vorhersage-Abruf zählt pauschal als ein Record, egal wie viele Tage oder Stunden angefragt werden
1.000 Records pro Tag kostenlos, das reicht leicht für einen Aufruf alle 15 Minuten.

OpenWeatherMap

OpenWeatherMap wird von der 2012 gegründeten OpenWeather Ltd. mit Sitz in London betrieben. Das Unternehmen kombiniert klassische Wettermodelle mit eigenen KI- und Machine-Learning-Verfahren zur Datenaufbereitung und beliefert nach eigenen Angaben über sechs Millionen Nutzer mit mehr als zwei Milliarden Vorhersagen täglich. Für die One Call API in der aktuellen Version 4.0, die auch die Wetterstation nutzt, gilt:

Kreditkarte zwingend erforderlich, auch innerhalb des kostenlosen Kontingents
1.000 kostenlose Aufrufe pro Tag, danach kostenpflichtig
Höchster Registrierungsaufwand der drei Anbieter, dafür detaillierteste Rohdaten

Den Registrierungsprozess habe ich in dem Artikel über die alte Raspberry-Pi Wetterstation beschrieben, aber ich kann nicht garantieren, dass sich inzwischen nichts verändert hat.

Technische Eigenheiten der drei APIs

Neben dem reinen Registrierungsaufwand unterscheiden sich die drei APIs auch technisch deutlich voneinander.

Bei Open-Meteo lässt sich für jeden der drei Endpunkte exakt festlegen, welche Felder man haben möchte, was die Antworten schlank hält, aber auch drei getrennte Anfragen benötigt. Die Wettercodes folgen dem WMO-Standard und auch meine Icons halten sich an diesen Standard.

VisualCrossing punktet mit dem bereits erwähnten einzigen Aufruf für alle drei Zeiträume. Statt eines numerischen Wettercodes liefert die API einen beschreibenden String wie partly cloudy day, den man selbst auf ein Icon-Set abbilden muss.

OpenWeatherMap ist in der Version 4.0 auf drei komplett getrennte Endpunkte aufgeteilt, anders als in älteren Versionen der API. Stundendaten sind pro Antwort auf 20 Einträge gedeckelt, sodass es für 48 Stunden Vorschau mehrere Aufrufe mit Pagination braucht.

Da alle drei APIs strukturell unterschiedliche Antworten, unterschiedliche Maßeinheiten und unterschiedliche Wettercode-Systeme mitbringen, gibt es in der Firmware ein gemeinsames, neutrales Zielformat für Wetterdaten. Jeder der drei Anbieter hat dafür ein eigenes Mapping, das die jeweiligen Rohdaten auf dieses gemeinsame Format abbildet. Die eigentliche Anzeige, also Displaywerte und die Diagramme für Stunden- und Tagesverlauf, kennt nur dieses Zielformat und muss nicht wissen, ob die Daten gerade von Open-Meteo, VisualCrossing oder OpenWeatherMap stammen. Auch die drei unterschiedlichen Wettercode-Systeme werden dabei jeweils auf dasselbe Set von 28 Wetter-Icons abgebildet.

Welches API das Genaueste ist, ist schwer zu sagen. Ich habe alle drei APIs eine Weile getestet und gelegentlich liegt jedes API mal daneben. Speziell was die Niederschläge betrifft, sind die Werte oft ungenau. Wirklich geschockt war ich aber bei diesen Daten von OpenWeatherMap. Glücklicherweise waren es dann doch "nur" 38 °C.

Hardware der Basisstation

Die zentrale Komponente der Wetterstation ist das Waveshare ESP32-P4-Module-DEV-KIT-C. Als Anzeige dient ein 10,1-Zoll großes IPS-Panel mit einer nativen Auflösung von 800 × 1280 Pixeln, einem Kontrastverhältnis von 800:1 und einer Helligkeit von 400 cd/m². Die Bilddatenübertragung erfolgt über eine 2-Lane-MIPI-DSI-Schnittstelle über ein 22-Pin-FPC-Kabel direkt vom Mikrocontroller-Modul. Für die kapazitive Touch-Erfassung sind die entsprechenden I²C-Signalleitungen (GPIO7 und GPIO8) direkt in die Display-Verbindung integriert.

Das Herzstück des Boards ist das von Waveshare entwickelte Modul mit dem ESP32-P4 SoC. Dieses verfügt über einen 360 MHz schnellen RISC-V-Dual-Core-Hauptprozessor mit integrierter FPU und DSP-Befehlssatzerweiterung, ergänzt durch einen Low-Power-Core mit 40 MHz sowie 32 MB intern im Package angebundenem PSRAM und 16 MB externem Flash-Speicher. Da der ESP32-P4 keine eigene Funkschnittstelle mitbringt, ist auf dem Modul zusätzlich ein ESP32-C6-MINI-1 als dedizierter Funk-Coprozessor integriert, der Wi-Fi 6 (802.11ax), Bluetooth 5.4 sowie 802.15.4 (Zigbee/Thread) bereitstellt.

Die chipinterne Kommunikation zwischen dem P4 und dem C6 erfolgt über einen SDIO-Bus unter Verwendung der ESP-Hosted-MCU-Firmware. Der ESP32-C6 fungiert dabei als transparenter Netzwerkadapter und verarbeitet den gesamten Funkstack im Hintergrund, während auf dem ESP32-P4 die regulären Wi-Fi- und Bluetooth-Treiber des ESP-IDF für die Netzwerkkommunikation genutzt werden können.

Ein Heltec WiFi LoRa 32 V4 Board übernimmt die Funktion des Receivers. Auf dem Board arbeiten ein ESP32-S3 und ein Semtech SX1262, wodurch sowohl ESP-NOW als auch das LoRa-Funkprotokoll unterstützt werden. Auf dem Display werden die empfangenen Pakete mit Empfangsstärke angezeigt. Die Kommunikation mit dem ESP32-P4 erfolgt über denselben I²C-Bus, den auch der Touch-Controller nutzt. Das Heltec-Board sowie die Steckverbindungen für die internen Sensoren sind auf einer kleinen Zusatzplatine untergebracht, die über den 40-Pin-GPIO-Header auf das ESP32-P4-Module gesteckt ist. Zwar bietet das ESP32-P4-Module auch einen dedizierten I²C-Steckverbinder, der für die reine Spannungsversorgung und die zwei Datenleitungen ausgereicht hätte, die Verbindung über den GPIO-Header sorgt jedoch gleichzeitig für eine stabile mechanische Befestigung der Platine.

Das Gehäuse und Zusammenbau

An dem Gehäuse habe ich mir ziemlich die Zähne ausgebissen. Ursprünglich war die hintere Abdeckung als ein Teil geplant, aber ich war mit dem Ergebnis nie zufrieden und außerdem wurde sehr viel Stützmaterial beim 3D-Druck gebraucht. Auch das Design des ESP32-P4-Modules hat die Sache nicht einfacher gemacht. Durch den Raspberry Pi Formfaktor liegen die USB Stecker seht weit innen, mein Ziel war es aber, auch im zusammengebauten Zustand eine neue Firmware flashen zu können. Letztendlich habe ich mich für eine Version aus zwei Teilen entschieden, was den Druck deutlich vereinfacht hat.

Der Sockel beherbergt den Licht- und Radarsensor, da ich den Rahmen des Displays so schmal wie möglich halten wollte. Auch hier habe ich mehrere Anläufe gebraucht, da das Display anfangs zu kopflastig war und die Wetterstation leicht umgekippt ist. Im Sockel sind Einschmelzgewinde für die Sensor-Platinen, was im Nachhinein nicht die beste Idee war. Beim Einschmelzen muss man sehr vorsichtig sein, um nicht die Ränder mit dem Lötkolben zu berühren und sie dürfen auch kein bisschen zu tief eingelötet werden, weil man sonst kleine Erhebungen auf der Vorderseite sieht. Ein normales Bohrloch wäre hier völlig ausreichend gewesen. Für den 3D-Druck habe ich meinen neuen Snapmaker U1 verwendet, und so das Gehäuse und das Fenster für die Sensoren in einem Ausdruck fertigen können.

Nach dem Zusammenbau von Display-Abdeckung und Sockel muss nur noch die Rückwand mit dem eingesteckten SEN66 angeschraubt werden. Für die Halterung des SEN66 habe ich das Referenzdesign von Sensirion verwendet. Es passt zwar grundsätzlich sehr gut, aber allzu oft sollte man den SEN66 nicht entfernen, weil die Führungen recht dünn sind und leicht brechen können.

Zusammengebaut sieht das Gehäuse dann so aus.

Funkmodule

Im Moment verwende ich drei unterschiedliche Funkmodule für die Wetterstation. Primär interessieren mich Temperatur und Luftfeuchtigkeit. Der Sensor am Balkon misst auch den Luftdruck, aber dieser Wert ist in der Regel identisch mit dem aktuellen Wert des Wetter-APIs. Der Geigerzähler ist reine Spielerei, aber irgendwie auch witzig.

ESP-NOW Sensor mit BME280

Diesen Sensor habe ich schon in meiner ersten ESP32 Wetterstation verwendet. Die Platine ist selbst entworfen und basiert auf einem ESP32 mit einem Bosch BME280 als Sensor. Der Akku kann über Solarzellen geladen werden. Das Gehäuse ist aber eine Neuentwicklung und deutlich stabiler als die alte Version. Es gibt eine Variante mit einer und zwei Solarzellen, wodurch der Akku praktisch nie leer wird, wenn der Sensor in der Nähe eines Fensters steht.

Die Software habe ich noch etwas optimiert, um auch das Letzte aus dem Deep-Sleep Modus herauszuholen. Der Stromverbrauch sieht jetzt so aus:

Im Vergleich zur alten Software konnte ich den durchschnittlichen Stromverbrauch also von ca. 80 auf 51 µA senken. Bei einem 2000 mAh Akku würde das 2000 mAh / 0,05107 mA = 39.162 Stunden bedeuten, also etwa 1632 Tage oder fast 4 1/2 Jahre.

LoRa Sensor mit SHT45

Für diese Sensoren verwende ich ein Heltec WiFi LoRa 32 V3 Board. Da dieses Board ein Display und eine frei verwendbare Taste hat, muss nichts mehr über DIP-Schalter eingestellt werden sondern ganz bequem über ein Setup beim Start des Sensors. Auch bei diesem Gehäuse habe ich mit dem Snapmaker U1 wieder ein kleines Sichtfenster eingebaut.

Das Heltec WiFi LoRa 32 V3 Board hat im Gegensatz zur V4 Version keinen Anschluss für Solarzellen. Wenn man sich aber den Stromverbrauch ansieht, ist das auch gar nicht nötig.

Die Zeitdauer, bis der Akku entladen ist, wäre hier 2000 mAh / 0,04193 mA = 47.699 Stunden, also etwa 1987 Tage oder fast 5 1/2 Jahre. Ich bezweifle, dass die Wetterstation überhaupt so lange in Betrieb sein wird. Und natürlich kann der Akku über den USB Anschluss wieder geladen werden.

LoRa Sensor mit RadiationD Geigerzähler

Ursprünglich habe ich diesen Sensor mit einem Heltec WiFi LoRa 32 V4 Board gebaut, da hier das Laden über Solarzellen unbedingt notwendig ist. Das Board brauche ich aber inzwischen für etwas anderes, daher bin ich auf ein günstigeres Heltec HTCC-AB01 V2 Board ausgewichen. Dieses Board basiert auf einem ARM Cortex M0+ Core und hat auch einen SX1262 integriert. Allerdings hat das Board kein Display, daher sind hier wieder DIP-Schalter notwendig, um die Nummer des Sensors einzustellen. Die Sendeleistung ist in diesem Fall fix im Code hinterlegt.

Die Herausforderung bei beiden Boards war der Stromverbrauch, da die Impulse des Geigerzählers permanent gezählt werden müssen. Der Code für das ESP32 Board basiert daher auf einem Beispiel von Espressif bei dem der Ultra Low Power (ULP) Coprocessor für das Zählen verwendet wird. Der HTCC-AB01 V2 erlaubt es hingegen, aus dem Deep Sleep heraus direkt per flankengetriggertem GPIO-Interrupt aufzuwachen, sodass jeder Impuls die CPU nur kurz weckt. Zwischen den Impulsen und den minütlichen LoRa-Übertragungen schläft sowohl der Prozessorkern als auch das Funkmodul.

Der durchschnittliche Stromverbrauch ist natürlich trotzdem sehr hoch, da der Geigerzähler relativ viel Strom verbraucht:

Ich habe dann später sogar die Power-LED aus dem Geigerzähler ausgelötet, um ein paar mA zu sparen. Das Funkmodul wird mit zwei 110 x 110 mm großen Solarzellen betrieben und jetzt im Sommer ist das kein Problem. Ob es auch im November reichen wird, wenn wochenlang keine Sonne scheint, muss sich erst noch zeigen.

Was kostet die ESP32 Wetterstation

Abschließend möchte ich noch kurz auf die Gesamtkosten der Wetterstation eingehen. Da ich wie eingangs erwähnt nur hochwertige Komponenten verwendet habe, liegen die Materialkosten deutlich über dem, was man für die üblichen Standard-Wetterstationen mit einem Außensensor zahlt.

Die Basisstation besteht im Wesentlichen aus diesen Komponenten:

Waveshare ESP32-P4-Module-DEV-KIT-C Board: Direkt bei Waveshare 67.20
Heltec V4: Bei Amazon
SOS electronic50,52
Lichtsensor BH1750: Bei Amazon
C4001 24GHz (12 Meter): Bei BerryBase für 12,90

Das ergibt insgesamt ca. 160 Euro.

Bei den Sensoren hängen die Kosten vom verwendeten Typ ab. Die selbst entworfene Sensorplatine mit dem BME280 hat etwa 200 Euro plus Zollgebühren für 10 Stück gekostet. Also ganz grob 25 Euro pro Sensor.

Bei der LoRa Variante hat man diese Kosten:

Heltec V3: Bei Amazon
Sensirion SHT45: Bei Amazon (5 Stück)
Bosch BME280: Bei Amazon
Li-Ion Akku Typ 18650: Bei Amazon

Für die Variante mit dem SHT45 kommt man hier auf über 40 Euro pro Sensor.

Dazu kommen noch Teile wie

Fazit

Die Entwicklung der neuen Wetterstation hat sich über einige Monate erstreckt. Es ist gar nicht so einfach zu bestimmen, wann ein solches Projekt wirklich fertig ist. Irgendein Detail lässt sich immer noch verbessern oder die nächste Idee wartet schon auf ihre Umsetzung. Mich stört zum Beispiel, dass der Geigerzähler einen ganzen Sensor Slot verbraucht. Der Wert interessiert mich eigentlich gar nicht und wird sich hoffentlich auch nie ändern. Eine reine Alarmfunktion würde völlig ausreichen. Dann könnte man auch noch einen Kohlenmonoxid Sensor mit Alarm integrieren, wobei ich nicht sicher bin, ob das eine gute Idee ist. Bei einem potentiell tödlichen Gas sollte man wohl bei professionellen Geräten bleiben. Aber die Idee der Alarme gefällt mir, ich muss mir nur ein stimmiges Konzept überlegen.

Den Sockel werde ich möglicherweise auch noch einmal überarbeiten. Wie oben schon beschrieben ohne Einschmelzgewinde und vielleicht auch eine etwas andere Form. Ein neigbarer Bildschirm wäre schon eine feine Sache.

Außerdem arbeite ich schon daran, die Wetterstation mit anderen Displays zu betreiben. Auf dem Foto ist das Guition JC8012P4A1C_I_W_Y zu sehen, das die gleiche Größe und Auflösung wie das Waveshare Display hat. Dazu wird es aber einen eigenen Artikel geben.

Bei Fragen könnt ihr euch wie immer gerne bei mir melden. Es gibt sicher einige Punkte, die ich nicht gut erklärt oder gar vergessen habe. Der gesamte Code des Projekts liegt wie immer auf GitHub. Über neue Ideen oder Verbesserungen würde ich mich sehr freuen.

Konversation wird geladen