Aufbau eines eigenen ESPHome-Bluetooth-Proxys

Ein ESPHome-Bluetooth-Proxy klingt erstmal nach einem Nice-to-have – bis man selbst erlebt, wie unzuverlässig lokale Bluetooth-Verbindungen in Home Assistant ohne ausreichende Abdeckung im Haus sein können. Bei mir war der Auslöser eine einzelne SwitchBot-Steckdose in der Küche, die partout nicht stabil verbunden bleiben wollte. Am Ende bin ich über drei Etagen und mehrere ESP32-Varianten gegangen, bis ich eine wirklich zuverlässige Bluetooth-Abdeckung fürs ganze Haus hatte. In diesem Artikel zeige ich den kompletten Weg dorthin – inklusive der Umwege.

Der Auslöser: Eine störrische SwitchBot-Steckdose

Ich steuere mehrere Geräte in der Küche über SwitchBot Plug Mini Steckdosen, migriert von der SwitchBot-Cloud-Integration auf die lokale Bluetooth-Anbindung. Bei den meisten Steckdosen lief das reibungslos – nur die Steckdose an der Spülmaschine (MAC 90:E5:B1:xx:xx:xx) wollte einfach nicht zuverlässig verbunden bleiben. Die Verbindung brach immer wieder ab, obwohl die Steckdose selbst einwandfrei funktionierte.

Von mir verwendet: SwitchBot Plug Mini mit Leistungsmessung bei Amazon ansehen*

* Affiliate-Link: Wenn du über einen entsprechend gekennzeichneten Link etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich ändert sich der Preis dadurch nicht. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.

Proxy Nummer 1: Die Küche

Warum ein „aktiver“ Proxy nötig ist

ESPHome unterstützt zwei Betriebsarten für Bluetooth-Proxys: passiv (nur Advertisements mitlesen, z. B. für Sensoren wie Thermometer oder Präsenz-Tags) und aktiv (active: true), was zusätzlich echte GATT-Verbindungen erlaubt – also das, was man für die Steuerung von SwitchBot-Geräten braucht. Der Unterschied ist technisch relevant: Ein aktiver Proxy hält eine tatsächliche Verbindung zum Zielgerät, kann Befehle senden und Antworten empfangen, während ein passiver Proxy nur zuhört. Für meine Steckdosen-Steuerung war also von Anfang an klar: Es muss ein echter ESP32 mit active: true sein.

Ich hatte glücklicherweise noch einen unbenutzten, original verpackten ESP32 (ESP32-WROOM-Modul mit USB-C) in der Schublade liegen. Geflasht habe ich ihn über das offizielle ESPHome-Bluetooth-Proxy-Package – der einfachste Weg, ohne eigene YAML-Konfiguration von Grund auf zu schreiben:

Passendes ESP32-Board: ESP32 NodeMCU Development Board mit WROOM-32 bei Amazon ansehen*

substitutions:
  name: bluetooth-proxy-test

packages:
  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/simple.yaml@main

esphome:
  name: ${name}

esp32:
  board: esp32dev
  framework:
    type: arduino

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

api:

ota:
  platform: esphomeCode-Sprache: JavaScript (javascript)

Das Package bringt bereits alle nötigen Bluetooth-Proxy-Einstellungen inklusive active: true mit, sodass man sich nicht selbst um die BLE-Stack-Konfiguration kümmern muss. Nach dem Flashen war das Gerät unter dem Namen „bluetooth-proxy-test“ online und ließ sich in Home Assistant als Integration einbinden.

proxy

Foto: ESP32-WROOM-Board mit USB-C, geflasht als „bluetooth-proxy-test“

Platzierung und erste Stabilisierung

Platziert habe ich den Proxy rund 3 Meter von der Steckdose Spülmaschine entfernt in der Küche – nah genug für stabiles Signal, aber weit genug weg von Metallgehäusen und der Spülmaschine selbst, die als Störquelle für 2,4-GHz-Funk bekannt ist. Trotzdem blieb die Verbindung anfangs noch unzuverlässig. Erst nachdem ich den Proxy einmal komplett vom Strom getrennt und neu gestartet sowie anschließend Home Assistant selbst komplett neu gestartet hatte, wurde die Verbindung spürbar stabiler. Das ist ein Punkt, der in vielen Anleitungen untergeht: Der Bluetooth-Stack von Home Assistant cached offenbar Verbindungszustände, die nach Änderungen an der Proxy-Konfiguration nicht immer sauber neu aufgebaut werden – ein Neustart beider Seiten schafft hier oft Abhilfe.

Unerwarteter Nebeneffekt: Interferenz mit Hue

Kurz nach der Inbetriebnahme fiel mir auf, dass meine Hue-Zigbee-Lampen in der Küche („Lampe Arbeitsplatte 1“ und „Lampe Arbeitsplatte 2“, beide innr On/Off-Plugs) gelegentlich ins Straucheln kamen. Die Hue-Bridge selbst steht im Keller, aber die beiden Zigbee-Lampen hängen in der Küche – also genau in der Nähe des neuen Bluetooth-Proxys. Der Verdacht lag nahe: Bluetooth (2,4 GHz) und Zigbee (ebenfalls 2,4 GHz) können sich bei räumlicher Nähe gegenseitig stören, insbesondere wenn Kanäle überlappen.

Um das zu verifizieren, habe ich den Proxy testweise deaktiviert und beobachtet, ob sich die Hue-Stabilität verbessert – und anschließend wieder aktiviert, um die Ursache eindeutig einzugrenzen, statt vorschnell auf Verdacht umzubauen. Das Ergebnis hat mir gezeigt, wie wichtig es ist, Störungsverdachte systematisch statt spekulativ zu behandeln, bevor man Hardware umräumt oder Kanäle manuell fest zuweist.

Lesson learned: Wer einen Bluetooth-Proxy in der Nähe von Zigbee-Geräten platziert, sollte Interferenzen von Anfang an im Hinterkopf behalten. Ein sauberer Test (Proxy kurzzeitig deaktivieren, Auswirkung beobachten, wieder aktivieren) ist zuverlässiger als eine reine Vermutung – und verhindert, dass man am Ende die falsche Komponente verschiebt.

Proxy Nummer 2: Das Wohnzimmer

Nachdem die Küche stabil lief, wollte ich dasselbe Prinzip fürs Wohnzimmer nutzen – dort hing bereits ein ESP8266 (esp01_1m) an einem SHT31-Temperatursensor. Ein ESP8266 kann aber, wie bereits in der Küche gelernt, keinen aktiven Bluetooth-Proxy betreiben. Statt den bestehenden ESP8266 einfach zu ersetzen, habe ich mich bewusst für einen parallelen Aufbau entschieden: Der alte ESP8266 blieb unangetastet für ein späteres Projekt erhalten, und ich habe ein komplett neues Gerät eingerichtet.

Erster Versuch: ESP32-C3 Super Mini

Für das Wohnzimmer griff ich zunächst zu einem „ESP32-C3 Super Mini“ – ein sehr kompaktes Board, das nur eine PCB-Antenne besitzt und keinen Anschluss für eine externe Antenne bietet. Eingerichtet unter dem Namen „wohnzimmer-sht31-v2“, ging es zunächst problemlos online und der Bluetooth-Proxy lief.

In der Praxis zeigte sich aber schnell die Grenze dieses Boards: Die PCB-Antenne des C3 Super Mini ist deutlich schwächer als die Antenne eines „normalen“ ESP32-WROOM-Boards. Für einen reinen Temperatursensor wäre das kein Problem gewesen, aber als Bluetooth-Proxy, der möglichst viele BLE-Geräte im Raum zuverlässig erreichen soll, war die Reichweite spürbar eingeschränkt.

Der Wechsel zum „normalen“ ESP32

Die Konsequenz: Ich habe den C3 Super Mini durch ein reguläres ESP32-WROOM-Board ersetzt, eingerichtet als „wohnzimmer-sht31-v3“. Der alte C3 (v2) wurde abgeklemmt, aber bewusst vorerst nicht aus Home Assistant entfernt, für den Fall, dass ich ihn später nochmal reaktivieren möchte. Seit dem Wechsel auf das WROOM-Board läuft der Wohnzimmer-Proxy zuverlässig mit spürbar besserer Reichweite.

Das von mir bevorzugte Board für den Proxy: ESP32 WROOM-32 Development Board bei Amazon ansehen*

Lesson learned: Für einen Bluetooth-Proxy lohnt sich fast immer ein ESP32-Board mit externem Antennenanschluss oder zumindest einer ordentlichen PCB-Antenne (WROOM-Module) statt der kompaktesten verfügbaren Variante. Die Super-Mini-Boards sind super für platzsparende Sensor-Projekte, aber bei Bluetooth-Reichweite zahlt man den Preis für die kleine Bauform.

Proxy Nummer 3: Das Dach

Der dritte Standort ergab sich eigentlich aus einem ganz anderen Projekt: der lokalen Einbindung meiner Panasonic-Klimaanlage im Dachgeschoss per ESP32 und ESPHome. Da dort ohnehin ein leistungsfähiger ESP32-WROOM verbaut ist, lag es nahe, ihn zusätzlich als dritten Bluetooth-Proxy zu nutzen – WLAN und Bluetooth-Proxy liefen dort von Anfang an parallel zur Klimasteuerung, zusätzlich ergänzt um einen SHT31-Sensor für unabhängige Klimadaten.

Von mir für die zusätzlichen Klimadaten verwendet: SHT31 Temperatur- und Luftfeuchtigkeitssensor bei Amazon ansehen*

Damit deckt dieser dritte Proxy eine Etage ab, die vorher komplett ohne Bluetooth-Abdeckung war – gerade für die raumgenaue Präsenzerkennung (Bluetooth-Trilateration) war das vorher eine echte Funklücke.

Das Gesamtbild: Drei Proxys, ein Netz

Am Ende ergibt sich daraus eine kleine Bluetooth-Mesh-artige Abdeckung übers ganze Haus, auch wenn ESPHome-Proxys technisch kein echtes Mesh bilden, sondern jeder Proxy unabhängig als Empfänger/Sender für Home Assistant fungiert:

  • Küche: ESP32-WROOM, aktiver Proxy (active: true), primär für die SwitchBot-Steckdosen-Steuerung
  • Wohnzimmer: ESP32-WROOM (nach Wechsel vom C3 Super Mini), kombiniert mit SHT31-Sensor
  • Dach: ESP32-WROOM, kombiniert mit Panasonic-Klimasteuerung und SHT31-Sensor

Home Assistant wählt bei aktiven BLE-Verbindungen automatisch den Proxy mit dem besten Signal zum Zielgerät aus – dadurch profitieren nicht nur die SwitchBot-Steckdosen in der Küche von mehreren Proxys, sondern auch andere BLE-Geräte im Haus, etwa für die Präsenzerkennung.

Fazit

Was als Lösung für eine einzelne störrische Steckdose begann, ist am Ende zu einer kompletten Bluetooth-Infrastruktur fürs ganze Haus geworden – verteilt über drei Etagen, mit unterschiedlichen ESP32-Varianten und ein paar handfesten Lektionen unterwegs: Aktive GATT-Verbindungen brauchen einen echten ESP32, kompakte Super-Mini-Boards opfern Reichweite für Bauform, und Bluetooth-Proxys in Zigbee-Nähe sollten auf Interferenzen geprüft werden, bevor man voreilig Hardware umräumt.

Mein Rat für Nachbauer: Startet nicht mit dem kompaktesten oder billigsten ESP32-Board, sondern mit einem WROOM-Modul mit ordentlicher Antenne – gerade wenn der Proxy aktive Verbindungen halten soll. Und plant von Anfang an mit mehreren Proxys über die Etagen verteilt, statt zu versuchen, das ganze Haus mit einem einzigen Gerät abzudecken.

Die drei Proxys sind aber nicht nur für die SwitchBot-Steuerung nützlich: Mit dieser flächendeckenden Bluetooth-Abdeckung ist gleichzeitig die Basis für ein ganz anderes Projekt gelegt – die raumgenaue Präsenzerkennung per Bluetooth-Trilateration (Bermuda). Wie sich daraus in Home Assistant eine zuverlässige, zimmergenaue Anwesenheitsanzeige bauen lässt, zeige ich im nächsten Artikel.

* Mit * gekennzeichnete Links sind Affiliate-Links. Wenn du darüber etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich entstehen dadurch keine zusätzlichen Kosten. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.

Schreibe einen Kommentar