ESPHome einrichten 2026: Smart-Home-Sensoren ohne Programmieren bauen

ESPHome ist der kürzeste Weg von einem 5-Euro-Mikrocontroller zu einem fertigen Smart-Home-Gerät. Du beschreibst in einer YAML-Datei, welcher Sensor an welchem Pin hängt, ESPHome baut daraus eine komplette Firmware und flasht sie auf den Chip — ohne eine einzige Zeile C++. Wer schon einmal mit der Arduino-IDE gekämpft hat, weiß, was das bedeutet: kein Boilerplate, keine Bibliotheks-Konflikte, keine handgeschriebene MQTT-Anbindung.

Was ESPHome eigentlich macht

ESPHome ist kein Betriebssystem und keine App, sondern ein Firmware-Generator. Der Ablauf ist immer derselbe: Du legst eine YAML-Datei an, in der Hardware-Bausteine als Blöcke stehen — ein sensor-Block für den Temperaturfühler, ein switch-Block für ein Relais, ein binary_sensor-Block für einen Reed-Kontakt. Dazu kommen die Grundangaben: welcher Chip, welches WLAN, welcher Gerätename. ESPHome übersetzt das in C++-Code, kompiliert ihn mit PlatformIO und schiebt das Ergebnis auf den ESP.

Der eigentliche Charme liegt in der Integration. Ein ESPHome-Gerät spricht über eine native API direkt mit Home Assistant — kein MQTT-Broker nötig, keine manuelle Entity-Definition. Home Assistant findet das Gerät im Netz, du klickst auf „Konfigurieren“, und alle Sensoren und Schalter erscheinen automatisch als Entities mit passenden Einheiten und Icons. Ab dem zweiten Flashen läuft alles over-the-air: YAML im Browser ändern, „Install“ drücken, das Gerät zieht die neue Firmware selbst über WLAN.

Und das Wichtigste für alle, die Smart Home ohne Fremdserver wollen: Es läuft komplett lokal — kein Cloud-Account, keine Hersteller-App, keine Telemetrie. Fällt dein Internet aus, funktioniert der selbstgebaute Fensterkontakt trotzdem.

Die Hardware: welcher Chip, welches Board

Historisch war der ESP8266 der Einstiegschip — billig, klein, überall verbaut. Heute gibt es keinen guten Grund mehr, ein neues Projekt darauf zu starten. Nimm einen ESP32. Er hat zwei Kerne, deutlich mehr RAM, Bluetooth an Bord und verkraftet mehrere Sensoren gleichzeitig ohne Aussetzer. Der ESP8266 stürzt bei komplexeren Konfigurationen gern mal ab oder verliert die WLAN-Verbindung; beim ESP32 passiert das praktisch nicht.

Für den Start reicht der klassische ESP32 (oft als „ESP32-WROOM“ auf dem Board vermerkt). Der ESP32-S3 hat mehr Speicher und USB-OTG, interessant für Displays oder Kameras; der ESP32-C3 ist die sparsame Mini-Variante für batteriebetriebene Kleinstsensoren, aber mit weniger Pins. Alle drei unterstützt ESPHome, du gibst den Typ einfach in der YAML an.

Für Prototypen kaufst du ein Dev-Board, also die Platine mit USB-Buchse, Spannungsregler und aufgelöteten Stiftleisten. Die Stromversorgung läuft über ein normales USB-Netzteil, 5 Volt und ein halbes Ampere reichen dicke. Dazu ein Steckbrett und ein Satz Dupont-Kabel, dann kannst du Sensoren umstecken, ohne zu löten.

Bei der Sensorik unterstützt ESPHome über 300 Bausteine. Diese hier braucht man in der Praxis am häufigsten:

• BME280 — Temperatur, Luftfeuchte und Luftdruck in einem winzigen Baustein, angebunden per I²C. Der Klassiker für Raumklima.
• PIR-Bewegungsmelder (HC-SR501) oder mmWave-Radar (LD2410) für Präsenzerkennung. Radar merkt auch, wenn du still auf dem Sofa sitzt.
• Reed-Kontakte — zwei Cent Magnetschalter, die dir sagen, ob Fenster oder Tür offen sind.
• Relais-Module, um 230-Volt-Verbraucher zu schalten. Achtung: Netzspannung nur, wenn du weißt, was du tust, und mit ordentlichem Gehäuse.
• LED-Strips (WS2812B) kann ESPHome ebenfalls ansteuern. Wenn dir Lichteffekte wichtiger sind als Sensorik, ist WLED allerdings die spezialisiertere und komfortablere Firmware — ESPHome-LEDs lohnen sich vor allem, wenn Licht und Sensoren auf demselben Chip sitzen sollen.

Der Einstieg: Add-on, Gerät, erstes Flashen

Wenn Home Assistant bei dir als Home Assistant OS läuft — etwa auf einem Raspberry Pi als Homeserver — installierst du ESPHome in fünf Klicks:

1. In Home Assistant unter Einstellungen → Add-ons → Add-on Store nach „ESPHome Device Builder“ suchen und installieren.
2. „Start on boot“ und „Show in sidebar“ aktivieren, dann starten.
3. Im ESPHome-Dashboard auf New Device klicken, einen Namen vergeben (etwa wohnzimmer-klima) und den Chip-Typ wählen.
4. Beim ersten Gerät fragt ESPHome nach WLAN-Name und Passwort und legt beides in einer secrets.yaml ab. Danach greifen alle weiteren Konfigurationen per !secret wifi_ssid darauf zu — die Zugangsdaten stehen also genau an einer Stelle.
5. ESP32 per USB-Kabel an den Rechner stecken, im Dashboard auf Install → Plug into this computer gehen und den Web-Flasher im Browser bestätigen. Chrome oder Edge nötig, Firefox unterstützt die Web-Serial-API nicht.

Das erste Flashen muss über Kabel laufen, weil der nackte Chip noch keine OTA-Funktion hat. Ab dem zweiten Mal geht alles drahtlos. Wer Home Assistant im Docker-Container betreibt, nutzt statt des Add-ons das ESPHome-Image oder die CLI — funktional identisch.

Projekt 1: Raumklima-Sensor mit BME280

Der BME280 hängt an vier Kabeln: 3,3 V, GND, SDA und SCL. Beim ESP32 nimmt man üblicherweise GPIO21 für SDA und GPIO22 für SCL. Die komplette Konfiguration sieht so aus:

esphome:
name: wohnzimmer-klima
friendly_name: Wohnzimmer Klima

sensor:
- platform: bme280_i2c
address: 0x76
temperature:
name: "Temperatur"
oversampling: 16x
humidity:
name: "Luftfeuchte"
pressure:
name: "Luftdruck"
update_interval: 60s


Das ist alles. Nach dem Flashen erscheint das Gerät in Home Assistant zur Übernahme, und du hast drei fertige Entities mit korrekten Einheiten, Verlaufsgraphen und Langzeitstatistik. Das update_interval steuert, wie oft gemessen wird — 60 Sekunden reichen für Raumklima völlig, kürzere Intervalle produzieren nur Datenmüll in der Datenbank. Wenn scan: true beim Start meldet, dass an 0x77 statt 0x76 etwas gefunden wurde, trägst du die andere Adresse ein; beides ist bei BME280-Boards üblich.

Projekt 2: Fensterkontakt und Relais

Sensoren lesen ist die eine Hälfte, schalten die andere. Ein Reed-Kontakt an GPIO4 und ein Relais an GPIO5 brauchen zusammen nur wenige Zeilen — die Grundblöcke von oben bleiben unverändert:

binary_sensor:
- platform: gpio
pin:
number: GPIO4
mode: INPUT_PULLUP
inverted: true
name: "Fenster Bad"
device_class: window
filters:
- delayed_on_off: 100ms

switch:
- platform: gpio
pin: GPIO5
name: "Steckdose Werkbank"
restore_mode: RESTORE_DEFAULT_OFF


Drei Details lohnen die Aufmerksamkeit. INPUT_PULLUP aktiviert den internen Pull-up-Widerstand, sodass du den Kontakt einfach zwischen Pin und GND klemmen kannst. delayed_on_off entprellt den mechanischen Schalter, damit Home Assistant nicht bei jedem Wackeln fünf Events bekommt. Und device_class: window sorgt dafür, dass die Oberfläche „Offen/Geschlossen“ anzeigt statt „Ein/Aus“.

Fertige Geräte umflashen — mit Vorbehalt

Ein großer Teil der billigen WLAN-Steckdosen, Lichtschalter und Dimmer aus dem Fernost-Handel läuft auf ESP-Chips. Theoretisch kannst du dort die Hersteller-Firmware durch ESPHome ersetzen und das Gerät damit cloudfrei machen — keine App, keine Abhängigkeit von einem Dienst, der irgendwann abgeschaltet wird. Bei älteren Tuya-Geräten funktioniert das über tuya-convert sogar ohne Öffnen des Gehäuses, bei anderen über vier angelötete Drähte.

Ehrlich muss man aber dazusagen: Die Erfolgsquote ist gesunken. Hersteller haben die OTA-Lücke geschlossen, und in aktuellen Geräten sitzen häufig gar keine ESP-Chips mehr, sondern Beken- oder Realtek-Controller, die ESPHome nicht unterstützt. Dazu kommt: Du verlierst die Garantie, du hantierst gegebenenfalls an einem Gerät, das später an Netzspannung hängt, und ein misslungener Flash-Versuch kann das Ding endgültig lahmlegen. Wer einen zuverlässigen Weg will, kauft Shelly-Geräte — die laufen von Werk aus lokal, und ESPHome ist dort eine Option, kein Rettungsversuch.

Praxis-Tipps, die dir später Arbeit sparen

Vergib von Anfang an sprechende Namen nach festem Schema, etwa raum-funktion. Nach dem zwölften Gerät willst du nicht rätseln, was esp32-test2 misst. Und halte dich an die Regel ein Gerät gleich eine YAML-Datei.

Wenn du dasselbe Gerät mehrfach baust, arbeite mit substitutions: Du definierst Variablen wie ${raum} oder ${pin_sensor} am Dateianfang und kannst den Rest per packages aus einer gemeinsamen Vorlage ziehen. Fünf Fensterkontakte brauchen dann fünf Dateien mit je vier Zeilen statt fünf Vollkonfigurationen.

Für Batteriebetrieb ist deep_sleep das Stichwort: Der ESP wacht auf, misst, sendet, schläft wieder. Damit kommt man von Stunden auf Monate Laufzeit. Der Preis ist, dass das Gerät zwischen den Weckzeiten nicht erreichbar ist — OTA-Updates brauchen dann ein Zeitfenster oder einen Reset-Knopf. Für dauerhaft erreichbare Aktoren ist Deep Sleep keine Option.

Wo ESPHome an Grenzen stößt

Jedes ESPHome-Gerät ist ein WLAN-Client. Bei fünf oder zehn Geräten merkt das kein Router; bei dreißig Sensoren, die alle im 2,4-GHz-Band funken, wird es eng — vor allem in Mehrfamilienhäusern, wo das Band ohnehin voll ist. Für viele kleine Batteriesensoren sind Zigbee oder Thread technisch die bessere Wahl: weniger Funklast, deutlich geringerer Stromverbrauch. Ein Zigbee-Netz baust du dir mit Zigbee2MQTT genauso lokal auf, und für die Thread-Seite lohnt ein Blick auf Matter. In der Praxis mischt man beides: ESPHome für alles, was Sonderwünsche hat oder eine Steckdose in der Nähe, Zigbee für die Masse an Standardsensoren.

Der zweite Punkt: Irgendwann brauchst du einen Lötkolben. Steckbrett und Dupont-Kabel sind zum Ausprobieren perfekt, aber ein Gerät, das dauerhaft hinter der Waschmaschine sitzt, darf keine Wackelkontakte haben. Und drittens ist die Dokumentation ausschließlich auf Englisch — sehr gut, aber ohne Übersetzung. Wer bei einem exotischen Sensor nachschlagen muss, sollte damit klarkommen.

Wenn es nicht klappt

Das Flashen bricht ab oder der Port erscheint nicht. Meist fehlt der USB-Seriell-Treiber (CP2102 oder CH340, je nach Board) oder das Kabel ist ein reines Ladekabel ohne Datenleitungen. Bei manchen Boards muss man beim Verbinden die BOOT-Taste gedrückt halten und kurz RESET tippen, um den Bootloader-Modus zu erzwingen. Unter Linux hilft es, den eigenen Benutzer in die Gruppe dialout aufzunehmen.

Das Gerät ist offline. Zwei Ursachen dominieren: schlechte WLAN-Abdeckung am Einbauort und eine zu schwache Stromversorgung. Der ESP32 zieht beim Senden kurze Strompeaks; billige Netzteile brechen dabei ein, und der Chip startet neu. Ein anderes Netzteil ist der schnellste Test. Zur Diagnose lohnt außerdem ein wifi_signal-Sensor in der YAML — unter etwa −80 dBm wird es unzuverlässig.

Der Sensor liefert Unsinn. Konstante 0, absurde Werte oder unavailable deuten fast immer auf Verkabelung oder Adresse. Prüfe, ob der Baustein an 3,3 V und nicht an 5 V hängt, ob SDA und SCL vertauscht sind, und schau ins ESPHome-Log: Der I²C-Scan listet beim Start alle gefundenen Adressen. Steht dort nichts, ist es Hardware, nicht Konfiguration.

Das Kompilieren dauert ewig. Auf einem Raspberry Pi kann der erste Build zehn Minuten und mehr brauchen, weil die komplette Toolchain durchläuft. Folgebuilds sind schneller, solange du den Build-Cache nicht löschst. Wer viel bastelt, betreibt ESPHome besser als CLI auf einem stärkeren Rechner und flasht von dort per OTA — oder gibt dem Pi wenigstens eine SSD statt einer SD-Karte. Übrigens: Ein sensor-Block für den Verbrauch macht die eigenen Geräte selbst zum Messobjekt, mehr dazu im Beitrag zum Stromverbrauch messen.

Fazit

ESPHome ist eines der wenigen Smart-Home-Projekte, bei denen der Einstieg wirklich so einfach ist, wie die Werbung verspricht. Ein ESP32 für ein paar Euro, ein Sensor, zwölf Zeilen YAML — und du hast ein Gerät, das lokal läuft, sich selbst in Home Assistant einträgt und Updates per WLAN bekommt. Es ersetzt keine Zigbee-Flotte für dreißig Batteriesensoren, und irgendwann führt der Weg zum Lötkolben. Aber für alles, was es fertig nicht gibt oder nur mit Cloud-Zwang, ist ESPHome die Antwort. Fang mit einem Klimasensor an, den brauchst du sowieso — und rechne damit, dass es beim ersten nicht bleibt.

Häufige Fragen

Brauche ich Programmierkenntnisse für ESPHome?

Nein. YAML ist keine Programmiersprache, sondern ein Textformat mit Einrückungen — du beschreibst darin, was vorhanden ist, statt Abläufe zu programmieren. Für Standardprojekte kopierst du das passende Beispiel aus der Doku und passt Pin-Nummern und Namen an. Erst bei Sonderfällen wie eigenen Berechnungen wird es komplexer, und selbst dann bleibt es bei Lambda-Ausdrücken von wenigen Zeilen.

ESP32 oder ESP8266?

ESP32, ohne Zögern. Der Preisunterschied liegt bei ein bis zwei Euro, dafür bekommst du mehr Speicher, mehr Pins, Bluetooth und deutlich stabilere WLAN-Verbindungen. Der ESP8266 wird von ESPHome weiter unterstützt, aber bei mehreren Sensoren pro Gerät geht ihm der RAM aus. Vorhandene ESP8266-Boards kannst du natürlich für einfache Projekte weiterverwenden.

Brauche ich zwingend Home Assistant?

Nein, aber es ist der komfortabelste Weg. ESPHome kann seine Werte alternativ per MQTT veröffentlichen und funktioniert damit auch mit ioBroker, Node-RED oder openHAB. Der Automatismus, mit dem Entities erscheinen, entfällt dann. Ganz ohne Zentrale kann ein ESPHome-Gerät auch autonom arbeiten und etwa eine Lüftung nach Feuchtewert schalten — es hat dann nur keine Oberfläche.

Was kostet ein Einstiegsprojekt?

Realistisch 15 bis 25 Euro für das erste Gerät: ESP32-Board 5 bis 8 Euro, BME280 rund 5 Euro, Breadboard mit Kabelsatz 8 bis 10 Euro. Das Zubehör kaufst du nur einmal, jedes weitere Gerät kostet dann Board plus Sensor, also unter 15 Euro. Ein fertiger WLAN-Klimasensor mit App-Zwang liegt bei 25 bis 40 Euro.

Kann ich fertige Smart-Home-Geräte umflashen?

Manchmal. Ältere Tuya-Geräte mit ESP-Chip lassen sich per tuya-convert oder mit angelöteten Drähten auf ESPHome umstellen und werden damit cloudfrei. Bei neueren Modellen ist die Lücke oft geschlossen oder es sitzt gar kein ESP mehr drin. Rechne mit Garantieverlust und der Möglichkeit, dass das Gerät danach nichts mehr tut. Wenn du Verlässlichkeit brauchst, kauf Geräte, die von Haus aus lokal funktionieren.