LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Blog-Übersicht /Smart Home / ESPHome und ESP32 in der Praxis: Eigene...
Diesen Artikel in anderen Sprachen lesen:

ESPHome und ESP32 in der Praxis: Eigene Cloud-freie Umweltsensoren entwickeln

Teil 2 von 6 der Reihe Home Assistant ohne Cloud

ESPHome und ESP32 in der Praxis: Eigene Cloud-freie Umweltsensoren entwickeln
Inhalt
  1. ESPHome und ESP32 in der Praxis: Eigene Cloud-freie Umweltsensoren entwickeln
  2. 1. Messgröße auswählen und Sensor anschließen
  3. 2. Firmware konfigurieren und prüfen
  4. 3. Kalibrierung und Aufstellung
  5. 4. Lokaler Zugriff und Netzwerkgrenzen
  6. Fragen und Antworten
  7. Quellen

ESPHome und ESP32 in der Praxis: Eigene Cloud-freie Umweltsensoren entwickeln

Ein ESP32 mit SCD40 kann CO₂, Temperatur und relative Luftfeuchtigkeit direkt an Home Assistant übertragen. ESPHome erzeugt die Firmware aus einer YAML-Konfiguration. Für diesen Datenweg ist kein Herstellerkonto in der Cloud erforderlich. Die Messqualität hängt weiterhin von Sensor, Gehäuse und Kalibrierung ab; eine lokale Verbindung erzeugt keine Laborpräzision.

1. Messgröße auswählen und Sensor anschließen

Der SCD40 misst CO₂ mit fotoakustischer NDIR-Technik. Der spezifizierte Genauigkeitsbereich beträgt 400–2.000 ppm, nicht 5.000 ppm; außerhalb dieses Bereichs gilt dieselbe Genauigkeitszusage nicht. Der SCD30 ist ein anderer optischer NDIR-Baustein mit einem spezifizierten Genauigkeitsbereich von 400–10.000 ppm. Diese Bereiche sind vom digitalen Ausgabebereich zu unterscheiden.

Ein VOC-Index beschreibt Veränderungen eines Gemischs flüchtiger organischer Verbindungen, keine direkte CO₂-Konzentration. ESPHome kann mit dem Baustein sgp4x einen VOC-Index aus einem SGP40 berechnen. Die einfache BME680-Komponente liefert Gaswiderstand; ein Luftqualitätsindex benötigt zusätzliche Verarbeitung, beispielsweise BSEC. Ein SHT40 misst Temperatur und Feuchtigkeit. Diese optionalen Module benötigen eigene Konfigurationen und gehören nicht zum folgenden Beispiel.

I²C benötigt SDA und SCL sowie eine gemeinsame Masse und eine geeignete Stromversorgung: Zwei Signalleitungen versorgen kein vollständiges Gerät. Das Beispiel nutzt GPIO21 und GPIO22 auf einer klassischen ESP32-Platine mit der Boarddefinition esp32dev. Andere Platinen, insbesondere C3-/S3-Varianten, benötigen passende Boardeinstellungen und Pinzuordnungen. Die Dokumentation des Sensor-Breakouts legt Versorgung, Pull-ups und Verdrahtung fest. ESP32-Signalleitungen benötigen 3,3-V-Pegel; eine Versorgung des Breakouts mit 5 V erlaubt keine 5-V-Pull-ups an SDA/SCL. Kurze Leitungen und die gemeinsame Belastung mehrerer vorhandener Pull-ups sind beim Aufbau zu berücksichtigen.

Lokaler Datenweg: Zusätzlich zu SDA/SCL sind Versorgung und Masse erforderlich. Messwerte erreichen Home Assistant über die verschlüsselte API; Firmware-Updates nutzen eine eigene Verbindung.
Lokaler Datenweg: Zusätzlich zu SDA/SCL sind Versorgung und Masse erforderlich. Messwerte erreichen Home Assistant über die verschlüsselte API; Firmware-Updates nutzen eine eigene Verbindung.

2. Firmware konfigurieren und prüfen

Das folgende Beispiel umfasst ESP32 und SCD40. Aktuelles ESPHome trennt den Block esp32 von esphome. Zugangsdaten gehören in eine private secrets.yaml neben der Konfiguration. api_encryption_key muss 32 zufällige Bytes als Base64 kodieren; ein beschreibender Platzhalter oder ein gemeinsam genutzter Beispielschlüssel genügt nicht. Das OTA-Passwort ist vom API-Schlüssel getrennt. Die Erstinstallation erfolgt üblicherweise per USB; spätere Aktualisierungen sind über das lokale Netzwerk möglich.

esphome:
  name: env-monitor-office

esp32:
  board: esp32dev
  framework:
    type: esp-idf

logger:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

api:
  encryption:
    key: !secret api_encryption_key

ota:
  - platform: esphome
    password: !secret ota_password

i2c:
  sda: GPIO21
  scl: GPIO22
  scan: true
  frequency: 100kHz

sensor:
  - platform: scd4x
    co2:
      name: Büro CO2
    temperature:
      name: Büro Temperatur
    humidity:
      name: Büro Luftfeuchtigkeit
    measurement_mode: periodic
    update_interval: 30s
    automatic_self_calibration: false

Der Sensor misst im Modus periodic alle fünf Sekunden; die Konfiguration übermittelt Werte alle 30 Sekunden. Die physikalische Reaktion auf veränderte Raumluft dauert länger als die Netzwerkübertragung. Häufigeres Abfragen erzeugt keine verzögerungsfreie Gasmessung.

3. Kalibrierung und Aufstellung

Die automatische Selbstkalibrierung bleibt im Beispiel bewusst deaktiviert, bis der Aufbau die Herstellervoraussetzungen erfüllt. Zur ASC-Annahme des SCD4x gehört regelmäßige Luft mit ungefähr 400 ppm, laut verlinktem Datenblatt mindestens wöchentlich. Ein dauerhaft belegter Raum mit erhöhtem CO₂ erfüllt diese Voraussetzung möglicherweise nicht. Auch deaktiviertes ASC verhindert keine Drift: Referenzmessung und ein geeignetes Wartungsverfahren bleiben erforderlich.

Eine erzwungene Nachkalibrierung benötigt eine bekannte, stabile CO₂-Referenz und das Herstellerverfahren, einschließlich mindestens drei Minuten Betrieb unter stabilen Bedingungen vor der Kalibrierungssequenz. Außenluft darf nicht pauschal mit exakt 400 ppm angesetzt werden. Ein sinkendes Tagesminimum beweist allein noch keine Kalibrierungsdrift. Dafür ist der Vergleich mit einer verlässlichen Referenz erforderlich.

Der Sensor benötigt Abstand zu ESP32 und Spannungsregler sowie Luftaustausch im Gehäuse. Nach Erreichen des thermischen Gleichgewichts folgt ein Temperaturvergleich mit einer Referenz. temperature_offset hat in ESPHome für SCD4x den Standardwert 4 °C und benötigt eine zum tatsächlichen Aufbau passende Einstellung. Diese Korrektur betrifft Temperatur und relative Feuchtigkeit, kalibriert jedoch nicht CO₂. Die Temperatur- und Feuchtekanäle liefern nützliche Raumindikatoren; Gehäuseerwärmung kann den Messfehler allerdings maßgeblich bestimmen.

4. Lokaler Zugriff und Netzwerkgrenzen

Ein eigenes IoT-VLAN mit Firewall kann den direkten Internetzugriff des Sensors sperren. Home Assistant benötigt weiterhin Zugriff auf TCP 6053 des Sensors für die verschlüsselte native API; der freigegebene Update-Rechner benötigt TCP 3232 für ESP32-OTA sowie Rückverkehr für diese Verbindungen. Das Beispiel aktiviert API-Verschlüsselung und passwortgeschützte OTA-Updates.

mDNS-Erkennung überschreitet VLAN-Grenzen normalerweise nicht automatisch. Eine DHCP-Reservierung und die manuelle Einbindung über die IP-Adresse bieten einen berechenbaren Alternativweg; namensbasierte Erkennung benötigt eine gezielte Netzwerkkonfiguration. Die Firmware entsteht auf dem Build-Rechner, der für herunterzuladende Abhängigkeiten Internetzugriff benötigen kann. Für die gezeigten lokalen API- und OTA-Funktionen braucht der Sensor selbst keine Internetverbindung.

Die Firewall begrenzt direkte externe Verbindungen. Exporte, Cloud-Integrationen und Sicherungen von Home Assistant können Messwerte trotzdem nach außen übertragen. Die Verfügbarkeit hängt außerdem von WLAN, Stromversorgung, Firmware und Automationsrechner ab; lokaler Betrieb garantiert keinen unterbrechungsfreien Dienst.

Fragen und Antworten

Wie lässt sich die Konfiguration vor der Installation prüfen?

Vor dem Kompilieren prüft der ESPHome-Konfigurationsvalidator die tatsächliche Boardkonfiguration mit der privaten Geheimnisdatei. Ein erfolgreicher Konfigurationscheck bestätigt das Schema, jedoch weder elektrische Kompatibilität noch Messgenauigkeit. Nach der Installation folgen Prüfungen von I²C-Adresse, Protokollen, Messwerten, Updateweg und Verhalten bei WLAN- oder Home-Assistant-Ausfall. Die Kalibrierung benötigt einen separaten Messvergleich.

Bedeutet ein nicht verfügbarer Sensor null CO₂?

Nein. Ein fehlender Messwert oder eine unterbrochene Verbindung bedeutet fehlende Information, keine Konzentration von null. Automationen benötigen einen ausdrücklichen Störzustand und eine Prüfung der letzten erfolgreichen Messung. Ein unveränderter Zahlenwert allein unterscheidet stabile Raumverhältnisse nicht von einem festhängenden Sensor.

Home Assistant ohne Cloud

  1. Zigbee2MQTT und ZHA: Ein zuverlässiges Zigbee-Netz planen
  2. ESPHome und ESP32 in der Praxis: Eigene Cloud-freie Umweltsensoren entwickeln
  3. Präsenzerkennung 2.0: mmWave-Radare (LD2410/LD2450) in der Lichtautomatisierung
  4. Lokale Sprachsteuerung in Home Assistant mit Whisper & Piper
  5. WireGuard & Tailscale DMZ: Sicherer externer Zugriff auf Home Assistant und eigene Server
  6. Lokales Energiemanagement: Integration von PV-Wechselrichtern und Batteriespeichern über Modbus TCP
Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Eine Frage oder eine Idee für ein Webprojekt? Schreib mir kurz, worum es geht. Das Formular nutzt reCAPTCHA zum Schutz vor Spam.

Kommentar schreiben

Erfahrungen mit anderen Geräten oder Integrationen und Rückfragen zur Einrichtung sind hier willkommen.

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.