Es gibt einen Moment, den fast jeder ESP32-Einsteiger kennt. Du hast zwölf Euro für ein Entwicklerboard ausgegeben, drei Stunden in Foren verbracht, den ersten Sensor per USB geflasht — und dann taucht das Gerät plötzlich in Home Assistant auf. Einfach so. Kein Cloud-Account, kein Passwort, keine App aus dem App Store. Dein selbst gebautes Ding sendet Daten direkt in dein lokales Smart Home.

Für Leute ohne Bastelerfahrung klingt das nach einem Hobbyprojekt für Nerds mit zu viel Freizeit. Ich verstehe das. Ich hatte das gleiche Vorurteil. Aber der Aufwand ist weniger als erwartet, und was dabei rauskommt, ist erstaunlich nützlich.

Das Tool dahinter heißt ESPHome.

Was ESPHome ist

ESPHome ist ein Open-Source-Projekt, das 2018 von Otto Winter gestartet wurde und heute unter dem Dach der Open Home Foundation läuft — der gemeinnützigen Organisation, die auch Home Assistant trägt. Das macht ESPHome zu etwas anderem als einem Community-Side-Projekt: Es gibt bezahlte Entwickler, monatliche Release-Zyklen, und eine klare Richtung.

Technisch ist ESPHome ein Firmware-Builder. Du schreibst eine YAML-Datei, die beschreibt, was dein Mikrocontroller tun soll: welche Sensoren angeschlossen sind, welche Pins sie verwenden, wie Knöpfe reagieren, wie oft Messwerte übertragen werden. ESPHome übersetzt das in kompilierten C++-Code und flasht ihn auf das Board.

Kein Programmieren. Keine IDE. Kein Compile-Fehler wegen fehlender Semikolons.

Das klingt nach einer Vereinfachung, die irgendwo Flexibilität kostet. Tut sie nicht. Ein ESP32 mit ESPHome kann Temperatur und Luftfeuchtigkeit messen (DHT22, BME280, SHT31), PIR- und mmWave-Bewegungssensoren auslesen, Relais schalten, RGB-Streifen steuern (WS2812B), Bluetooth-Geräte in der Nähe tracken, als Bluetooth-Proxy für Home Assistant fungieren, Wakeword-Erkennung lokal ausführen, E-Paper- und OLED-Displays ansteuern, und Impulszähler für Stromzähler auslesen. Alles mit einem Board, das fünf bis acht Euro kostet.

Was in letzter Zeit dazugekommen ist

ESPHome veröffentlicht monatlich Hauptversionen und wöchentlich Bugfixes. Der GitHub-Stand im April 2026: über 11.000 Stars, 5.000 Forks, 500+ offene Issues. Das ist kein Projekt, das einschläft.

Das Release 2025.12.0 brachte bidirektionale API-Kommunikation: ESPHome-Geräte können seitdem auf Anfragen von Home Assistant reagieren und strukturierte JSON-Daten zurückgeben, nicht nur Sensorwerte pushen. Klingt abstrakt, ist aber praktisch nützlich für Diagnoseanfragen oder gerätespezifische Abfragen. Gleichzeitig wurden Speicheroptimierungen eingebaut, die auf ESP32-Geräten bis zu 10 Kilobyte IRAM freiräumen. Zehn Kilobyte klingt nach nichts. Bei ressourcenbeschränkten Boards ist das der Unterschied zwischen "läuft stabil" und "stürzt nach drei Stunden ab".

Der ESP32-S3 ist seit diesem Release ein vollwertig unterstützter Chip, mit Support für LCD-CAM-Controller und GDMA. Wer einen lokalen Sprachassistenten mit Wakeword-Erkennung bauen will, braucht den S3 sowieso: Das micro_wake_word-Feature läuft auf dem S3 nativ und erkennt "Okay Nabu", "Hey Jarvis" oder "Hey Mycroft" direkt auf dem Chip, ohne Cloud, ohne externe API.

Mit Release 2026.3.2 unterstützt ESPHome inzwischen ESP32, ESP32-S2, S3, C3, C5, P4, ESP8266, BK72xx (Beken-Chips) und RP2040. Beken ist interessant: Damit werden Geräte flashbar, die keinen ESP-Chip enthalten — ein Schritt, der das Anwendungsfeld deutlich vergrößert.

ESPHome vs. Tasmota

Beide sind Open-Source-Firmware für ESP-Chips. Beide arbeiten lokal. Beide integrieren sich mit Home Assistant. Warum wechseln trotzdem gerade viele Tasmota-Nutzer zu ESPHome?

Neil Turner, der seit 2002 bloggt und seine Smart-Plugs im Oktober 2025 von Tasmota auf ESPHome umgestellt hat, hat beide Firmwares Anfang 2026 direkt verglichen. Seine Einschätzung: Tasmota gewinnt beim Einstieg, ESPHome danach.

Der Unterschied liegt im Grundprinzip. Tasmota flasht eine generische Firmware und man konfiguriert danach über eine Weboberfläche. Das ist schnell und unkompliziert — für fertige Geräte wie Sonoff-Relais oder Tuya-Stecker oft der einfachere Weg. Tasmota hat Vorlagen für fast 3.000 Geräte; ESPHome hat knapp 650 in der offiziellen Datenbank.

ESPHome dreht den Ablauf um. Zuerst beschreibst du, was das Gerät tun soll. Dann wird eine Firmware kompiliert, die genau das enthält. Mehr Aufwand beim ersten Mal. Dafür ist die Firmware kleiner und lässt sich drahtlos aktualisieren, ohne Platzmangel-Probleme — was bei ESP8266-Chips mit Tasmota ein bekanntes Problem ist, weil die aktuelle und neue Firmware gleichzeitig im Speicher liegen müssen und das oft nicht passt.

David Shanske, der seinen Wechsel auf seinem Blog Gadget Wisdom dokumentiert hat, beschreibt Tasmota als Schweizer Taschenmesser: gut für vieles, aber nicht immer das richtige Werkzeug. Was ihn zu ESPHome gebracht hat: Er wollte Lichtschalter, die direkt auf Bewegungssensoren reagieren, ohne Home Assistant als Zwischenstation. Dawn-to-Dusk-Steuerung direkt auf dem Chip, Countdown-Timer, die lokal ablaufen. Wenn Home Assistant kurz down ist, funktioniert das Licht trotzdem.

Das ist der eigentliche Unterschied zwischen den zwei Ansätzen. Tasmota-Geräte sind verlängerte Arme von Home Assistant. ESPHome-Geräte können eigenständig denken — soweit das bei einem 5-Euro-Chip möglich ist.

Was ein ESP32 kostet

Ein ESP32 DevKit kostet bei AliExpress drei bis sechs Euro, bei Amazon fünf bis acht. Ein BME280-Sensor für Temperatur, Luftfeuchtigkeit und Luftdruck kostet noch einmal vier Euro. Zusammen unter zwölf Euro.

Ein kommerzieller Aqara-Temperatursensor kostet 18 bis 25 Euro — und braucht einen Hub, der die Daten zuerst in die Cloud schickt, bevor sie in Home Assistant ankommen. Aqara hat das teilweise mit lokaler Verarbeitung verbessert, aber das Grundprinzip bleibt: Du bist darauf angewiesen, dass Aqara die Cloud-Infrastruktur weiterbetreibt.

Das ist kein Argument gegen Aqara oder kommerzielle Sensoren generell. Für Leute ohne YAML-Interesse sind sie die bequemere Wahl. Aber wenn ein Sensor acht Euro kostet statt 25, verbaut man sechs davon statt zwei. Das ändert, was man überhaupt misst.

Der Bluetooth-Proxy-Trick

Eines der weniger offensichtlichen Anwendungsfälle von ESPHome ist der Bluetooth-Proxy-Modus. Der ESP32 ist dann kein Sensor, sondern ein Empfänger-Verlängerungskabel für Home Assistant.

Bluetooth Low Energy hat in der Theorie zehn bis dreißig Meter Reichweite. In Praxis, mit Betonwänden, sind Xiaomi-Thermometer, Pflanzensensoren oder Fitness-Tracker oft einfach nicht erreichbar. Das ist einer der Hauptgründe, warum BLE-Geräte in Home Assistant unzuverlässig wirken.

Ein ESP32 mit ESPHome im Bluetooth-Proxy-Modus sitzt im betroffenen Raum, empfängt die BLE-Signale und schickt sie über WLAN weiter. Keine zusätzliche Hardware, kein MQTT-Broker. Ein Board, eine kurze YAML-Konfiguration. Der Garten-Sensor, der vorher sporadisch verbunden hat, taucht plötzlich stabil auf.

Wie die YAML-Datei aussieht

Für alle, die noch kein ESPHome gesehen haben: So sieht die Konfiguration für einen BME280-Sensor aus.

esphome:
  name: wohnzimmer-sensor

esp32:
  board: esp32dev

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

api:
  encryption:
    key: !secret api_key

sensor:
  - platform: bme280_i2c
    temperature:
      name: "Wohnzimmer Temperatur"
    humidity:
      name: "Wohnzimmer Luftfeuchtigkeit"
    pressure:
      name: "Wohnzimmer Luftdruck"
    update_interval: 60s
    address: 0x76

i2c:
  sda: GPIO21
  scl: GPIO22

Siebzehn Zeilen. Ein ESP32, ein BME280-Breakout für vier Euro, drei Jumper-Kabel. Der Sensor überträgt lokal, kein Cloud-Account, keine Monatspauschale.

Der !secret-Mechanismus ist ein Detail, das zeigt, dass ESPHome für echten Einsatz gebaut ist: Zugangsdaten landen in einer separaten Datei, nicht direkt in der Konfiguration. Wer mehrere Geräte verwaltet, schätzt das.

Wann ESPHome die falsche Wahl ist

Es gibt Situationen, in denen ein ESP32 mit ESPHome nicht die beste Antwort ist.

Wer keinen WLAN-Empfang im Keller hat, schaut in die Röhre. Die Standard-ESP32-Boards sind WLAN-only. Für schlechte Empfangsbedingungen sind Zigbee-Sensoren mit einem guten Zigbee-Mesh zuverlässiger.

Wer Sensoren hinter Verkleidungen verbaut oder in Bereichen ohne Dauerstrom, braucht Batteriesensoren. ESPHome unterstützt Deep-Sleep-Modi, aber ein kommerzieller Sensor mit CR2032 und zwei Jahren Laufzeit ist praktischer.

Und wer YAML grundsätzlich nervt: Es gibt kein Gesetz, das einen dazu zwingt. Fertige Geräte kaufen ist eine vollkommen vernünftige Entscheidung.

Ob das noch Bastelprojekt ist

ESPHome-Geräte laufen in Setups, wo die Heizungssteuerung davon abhängt, ob der Sensor korrekte Werte liefert. Das ist nicht mehr Bastelkeller.

Wenn ein Open-Source-Projekt monatlich neue Releases liefert, eine bezahlte Entwicklerstruktur hat, neun verschiedene Chip-Familien unterstützt und im April 2026 bei 11.000 GitHub-Stars steht, dann stimmt die Kategorie "Hobbyprojekt" schlicht nicht mehr. ESPHome ist ein ernstes Stück Infrastruktur, das zufällig auf Chips läuft, die man für fünf Euro kaufen kann.

Quellen: ESPHome Changelog 2025.12.0 (esphome.io), GitHub ESPHome Repository (11k Stars, Stand April 2026), Neil Turner: "Comparing ESPHome and Tasmota" (Januar 2026), David Shanske / Gadget Wisdom: "Tasmota vs ESPHome" (August 2025), hausbit.de: "ESP32 mit ESPHome in Home Assistant einbinden" (Februar 2026)
Quellen: ESPHome Changelog 2025.12.0 (esphome.io), GitHub ESPHome Repository (11k Stars, April 2026), Neil Turner: "Comparing ESPHome and Tasmota" (Januar 2026), David Shanske / Gadget Wisdom: "Tasmota vs ESPHome" (August 2025), hausbit.de: "ESP32 mit ESPHome in Home Assistant einbinden" (Februar 2026)