Im letzten Artikel ging es um den Aufbau einer flächendeckenden Bluetooth-Infrastruktur mit drei ESPHome-Proxys übers ganze Haus verteilt. Der eigentliche Auslöser dafür war die Steuerung einiger SwitchBot-Steckdosen – aber genau diese Infrastruktur ist auch die Grundlage für etwas deutlich Spannenderes: eine raumgenaue Präsenzerkennung. Nicht nur „ist jemand zuhause oder nicht“, sondern „wer befindet sich gerade in welchem Zimmer“. In diesem Artikel zeige ich, wie ich das mit Bermuda BLE Trilateration umgesetzt habe – inklusive der Stolperfalle, die mir dabei fast die ganze Zimmererkennung verzerrt hätte.
Von mir für die lokale Bluetooth-Steuerung 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.
Warum überhaupt raumgenaue Präsenz?
Eine reine Anwesenheitserkennung (zuhause/nicht zuhause) reicht für viele Automationen. Aber sobald man anfängt, Komfort und Effizienz stärker zu verzahnen, wird „wo genau im Haus“ relevant. Zwei konkrete Beispiele aus meinem eigenen Setup:
- Zirkulationspumpe an- und ausschalten, je nachdem ob jemand zuhause ist: Meine Zirkulationspumpe fürs Warmwasser läuft im Pulsbetrieb, damit im ganzen Haus zügig Warmwasser ankommt. Ist niemand zuhause, bringt der Puls keinen Nutzen, kostet aber Energie und kühlt den Speicher unnötig aus. Sind wir zuhause, läuft die Pulslogik regulär – eine zuverlässige Anwesenheitserkennung ist dafür die Grundvoraussetzung.
- Heizungsvorlauf hoch- oder runterfahren, je nach Anwesenheit: Ist niemand zuhause, kann der Vorlauf abgesenkt werden; kommt jemand zurück, fährt er wieder hoch – eine einfache, aber wirkungsvolle Logik, die nur so gut ist wie die Anwesenheitserkennung dahinter.
- Licht in ungenutzten Etagen automatisch ausschalten: Hier zahlt sich die Raumgenauigkeit erst richtig aus. Halten sich beide Personen laut Bermuda-Tracking im Obergeschoss bzw. Dach auf, kann das Licht im Erdgeschoss automatisch ausgehen – ganz ohne Bewegungsmelder in jedem Zimmer, einfach weil bekannt ist, dass sich gerade niemand dort aufhält.
Solche raumspezifischen Automationen sind ohne eine flächendeckende Bluetooth-Abdeckung praktisch nicht möglich – weshalb der Proxy-Aufbau aus dem letzten Artikel die notwendige Vorstufe war.
Warum nicht einfach GPS oder WLAN?
Klassisches Smartphone-Tracking über GPS oder WLAN-Anwesenheit in der Home-Assistant-App liefert zuverlässig ein binäres „zuhause/nicht zuhause“ – mehr aber auch nicht. Für raumgenaue Auswertung ist GPS ohnehin viel zu ungenau (mehrere Meter bis hin zu kilometerweiten Ausreißern bei reduzierter Standortgenauigkeit), und WLAN-Anwesenheit erkennt nur, ob das Gerät im Heimnetz eingebucht ist – nicht in welchem Zimmer. Beide Quellen bringen zudem ihre eigenen Zuverlässigkeitsprobleme mit (schwankende Signalgüte, verzögerte Zonenerkennung, gelegentlich hängende Tracker-Zustände) – Themen, die in einem eigenen Artikel zur klassischen Anwesenheitserkennung ausführlicher behandelt werden. Für Raumgenauigkeit braucht es einen fundamental anderen Ansatz: Bluetooth Low Energy (BLE) und die Signalstärke (RSSI) an mehreren festen Empfangspunkten im Haus.
Das Grundprinzip: BLE-Trilateration
Die Idee dahinter ist simpel, aber wirkungsvoll: Wenn mehrere Bluetooth-Empfänger fest im Haus verteilt sind und jeder davon die Signalstärke (RSSI) zu einem bestimmten BLE-Gerät (z. B. einem iPhone) misst, lässt sich daraus ableiten, welchem Empfänger das Gerät gerade am nächsten ist – und damit, in welchem Raum es sich befindet. Das ist keine exakte Trilateration im geometrischen Sinn mit Koordinaten, sondern eher eine Nearest-Sensor-Zuordnung auf Basis der relativen Signalstärke, kombiniert mit einer gewissen Glättung, um kurzfristige Ausreißer nicht sofort in einen Raumwechsel umzumünzen.
In Home Assistant übernimmt genau das die Integration Bermuda BLE Trilateration. Sie sammelt die RSSI-Werte aller im System bekannten Bluetooth-Proxys und Empfänger zu einem Zielgerät und berechnet daraus fortlaufend den wahrscheinlichsten Aufenthaltsraum.
Die Empfangs-Infrastruktur
Für eine brauchbare Trilateration braucht man mehrere räumlich verteilte Empfangsquellen – ein einzelner Empfänger kann bestenfalls „nah/fern“ unterscheiden, aber keine Räume voneinander trennen. In meinem Setup stehen dafür vier Quellen zur Verfügung:
- Der interne Bluetooth-Adapter direkt am Home-Assistant-Server
- ESPHome-Bluetooth-Proxy in der Küche (ESP32-WROOM, ursprünglich für die SwitchBot-Steckdosen eingerichtet)
- ESPHome-Bluetooth-Proxy im Wohnzimmer (ESP32-WROOM, nach dem Wechsel vom C3 Super Mini)
- ESPHome-Bluetooth-Proxy im Dachgeschoss (ESP32-WROOM, kombiniert mit der Panasonic-Klimasteuerung)
Für meine Bluetooth-Proxys verwende ich: ESP32 NodeMCU Development Board mit WROOM-32 bei Amazon ansehen*
Screenshot: Home Assistant Bluetooth-Visualisierung (Einstellungen → Geräte & Dienste → Bluetooth → Visualisierung) – zeigt Home Assistant als zentralen Knoten mit den angebundenen Scannern (Proxys + interner Adapter) und den jeweils darüber erreichbaren Geräten als Sternmuster
Zusätzlich lassen sich auch vorhandene Shelly-Gen3-Geräte als passive BLE-Empfänger einbinden, sofern sie über den passiven Bluetooth-Scanner-Modus (ble_scanner_mode) verfügen – dazu aber gleich mehr, denn genau hier lauert eine Falle.
Schritt 1: Den Identity Resolving Key (IRK) auslesen
Moderne iPhones (und die meisten aktuellen Android-Geräte) nutzen aus Datenschutzgründen randomisierte Bluetooth-MAC-Adressen, die sich alle paar Minuten ändern. Das verhindert klassisches Tracking über eine feste MAC-Adresse komplett – ein Gerät wäre nach jeder Rotation „verschwunden“ und würde als neues Gerät auftauchen. Die Lösung liegt im sogenannten Identity Resolving Key (IRK): Ein geheimer Schlüssel, mit dem sich rotierende MAC-Adressen wieder eindeutig demselben physischen Gerät zuordnen lassen, ohne dass die MAC-Adresse selbst konstant sein muss.
Um an den IRK des eigenen iPhones zu kommen, braucht es einen kurzen Kopplungsvorgang über einen speziell vorbereiteten ESP32. Ich habe dafür das Community-Package DerekSeaman/irk-capture genutzt und einen dritten, bis dahin unbenutzten ESP32 dafür eingerichtet:
Für den IRK-Capture kann dasselbe ESP32-WROOM-Board* verwendet werden, das ich auch für meine Bluetooth-Proxys einsetze.
substitutions:
name: irk-capture
packages:
irk_capture: github://DerekSeaman/irk-capture/irk-capture.yaml@main
esphome:
name: ${name}
esp32:
board: esp32dev
framework:
type: esp-idf
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
api:
ota:
platform: esphomeCode-Sprache: JavaScript (javascript)Nach dem Flashen zeigt das Gerät im ESPHome-Log eine BLE-Kopplungsanfrage an, sobald man sich am iPhone im Bluetooth-Menü mit dem ESP32 verbindet (dort taucht er unter seinem Gerätenamen auf). Bestätigt man die Kopplungsanfrage kurz am iPhone, gibt der ESP32 im Log den ausgelesenen IRK aus – diesen kopiert man sich für den nächsten Schritt.
Wichtig: Der Kopplungsvorgang selbst braucht keine dauerhafte Verbindung. Der ESP32 dient nur als einmaliges „Werkzeug“, um den IRK auszulesen – danach kann er für ein weiteres Gerät wiederverwendet oder abgeklemmt werden. Für Person 2 (weiteres iPhone im Haushalt) ist der gleiche Vorgang noch offen und für einen späteren Schritt vorgesehen.
Schritt 2: Private BLE Device einrichten
Mit dem IRK lässt sich in Home Assistant die Integration Private BLE Device einrichten. Sie nimmt den IRK entgegen und löst darüber automatisch die rotierenden MAC-Adressen des jeweiligen iPhones auf – das Ergebnis ist ein stabiler device_tracker, unabhängig davon, wie oft sich die tatsächliche Bluetooth-MAC-Adresse im Hintergrund ändert.
Die Einrichtung erfolgt über die Home-Assistant-UI (Einstellungen → Geräte & Dienste → Integration hinzufügen → Private BLE Device), wo der zuvor ausgelesene IRK eingetragen wird. Ab diesem Punkt liefert die Integration bereits ein einfaches „in Reichweite / nicht in Reichweite“-Signal sowie den letzten gemessenen RSSI-Wert – aber noch keine Rauminformation. Die kommt erst im nächsten Schritt dazu.
Schritt 3: Bermuda BLE Trilateration konfigurieren
Bermuda baut auf den von Private BLE Device bereitgestellten stabilen Geräte-Identitäten auf und wertet die RSSI-Werte aller verfügbaren Empfangsquellen (interner Adapter + drei ESPHome-Proxys + ggf. Shellys) gegeneinander aus. Nach der Installation über HACS (Repository: agittins/bermuda) und dem Hinzufügen der Integration lässt sich in der Bermuda-Konfiguration jeder Empfänger einem physischen Raum zuordnen (Küche, Wohnzimmer, Dach, Keller usw.).
Bermuda erzeugt daraufhin für jedes konfigurierte Zielgerät einen device_tracker mit einem area-Attribut, das den aktuell wahrscheinlichsten Raum enthält – dieser Wert lässt sich direkt in Automationen und aufs Dashboard nutzen. Für Person 1 ergab sich daraus:
device_tracker.person1_bermuda_tracker
state: home
attributes:
area: KuecheCode-Sprache: CSS (css)Damit war die technische Grundlage für raumgenaue Automationen gelegt.
Die Falle: Überrepräsentation im Keller
Kurz nachdem ich testweise auch mehrere Shelly-Gen3-Geräte als zusätzliche passive BLE-Empfänger aktiviert hatte, fiel eine deutliche Verzerrung auf: Die Raumerkennung driftete immer wieder fälschlich in Richtung Keller ab – selbst wenn sich die getrackte Person eindeutig im Wohnzimmer oder in der Küche aufhielt.
Die Ursache war schnell gefunden: Im Keller standen zeitgleich vier aktive Bluetooth-Empfangsquellen (der interne HA-Adapter sowie drei Shellys mit aktiviertem ble_scanner_mode: Smart Grid WW, Smart Grid 2 WW und der Pro 3EM zur Wärmepumpen-Strommessung). Durch diese Häufung an Empfängern an einem einzigen Ort hatte der Keller bei der RSSI-Auswertung ein strukturelles Übergewicht – es reichte im Grunde ein einzelner, auch nur mittelmäßig starker Messwert von einem der vier Kellergeräte, um die Trilateration in Richtung Keller zu kippen, selbst wenn die tatsächlich stärkeren Signale von den drei Etagen-Proxys kamen.
Lesson learned: Bei BLE-Trilateration zählt nicht nur, wie viele Empfänger man einbindet, sondern auch, wie gleichmäßig sie im Haus verteilt sind. Mehrere Empfänger an einem einzigen Standort verzerren die Auswertung zu Lasten der anderen Räume, selbst wenn jeder einzelne Empfänger für sich technisch korrekt misst. Eine gute Faustregel: pro Raum idealerweise nur eine Empfangsquelle.
Die Lösung war entsprechend pragmatisch: Ich habe den passiven Bluetooth-Scanner-Modus bei zwei der drei Kellergeräte (Pro 3EM und Smart Grid 2 WW) wieder deaktiviert. Aktiv im Keller blieben damit nur noch der interne HA-Adapter sowie ein einzelnes Shelly-Gerät (Smart Grid WW) – ein deutlich ausgewogeneres Verhältnis zu den jeweils einzelnen Proxys in Küche, Wohnzimmer und Dach. Nach dieser Anpassung normalisierte sich die Raumerkennung spürbar.
Praxis: Von der Raumerkennung zur Automation
Mit einer stabilen, verzerrungsfreien Raumerkennung lassen sich jetzt genau die eingangs skizzierten Anwendungsfälle umsetzen. Ein konkretes Beispiel aus meinem Setup: Hält sich Person 2 laut Bermuda-Tracking länger als 20 Minuten im Bereich Dach auf – also weit weg von den zapfnahen Räumen –, wird die Zirkulationspumpe fürs Warmwasser automatisch pausiert, um den Speicher nicht unnötig auszukühlen. Betritt sie anschließend wieder die Küche, wird die reguläre Pulslogik sofort freigegeben:
trigger:
- platform: state
entity_id: device_tracker.person2_bermuda_tracker
attribute: area
to: "Dach"
for:
minutes: 20
condition: []
action:
- service: input_boolean.turn_on
target:
entity_id: input_boolean.zirkulation_pause_dachCode-Sprache: CSS (css)Das raumgenaue Licht-Beispiel aus der Einleitung lässt sich nach demselben Prinzip umsetzen: Befinden sich beide Personen laut ihrem jeweiligen area-Attribut im Obergeschoss oder im Dach, geht das Licht im Erdgeschoss automatisch aus – da sich dort erkennbar niemand mehr aufhält:
trigger:
- platform: state
entity_id:
- device_tracker.person1_bermuda_tracker
- device_tracker.person2_bermuda_tracker
attribute: area
condition:
- condition: template
value_template: >
{{ [state_attr('device_tracker.person1_bermuda_tracker', 'area'),
state_attr('device_tracker.person2_bermuda_tracker', 'area')]
| select('in', ['Obergeschoss', 'Dach']) | list | length == 2 }}
action:
- service: light.turn_off
target:
entity_id: light.erdgeschoss_alleCode-Sprache: PHP (php)Nach demselben Prinzip lässt sich auch die Heizungsvorlauf-Logik erweitern: Statt nur pauschal „jemand ist zuhause“ als Bedingung zu nutzen, kann der Vorlauf gezielt in dem Bereich angehoben werden, in dem sich die Person laut area-Attribut aktuell aufhält, während er in den übrigen, ungenutzten Räumen abgesenkt bleibt. Die Rauminformation von Bermuda lässt sich dafür wie jeder andere Sensor als zusätzliche Bedingung in bestehende Automationen einbauen.
Fazit
Die raumgenaue Präsenzerkennung über Bermuda BLE Trilateration hat sich als deutlich mächtigeres Werkzeug erwiesen als klassisches GPS- oder WLAN-Tracking – vorausgesetzt, die Bluetooth-Infrastruktur ist gut geplant. Der IRK-Capture-Schritt für rotierende iPhone-MAC-Adressen war dabei technisch der aufwendigste Teil, aber mit dem passenden ESPHome-Package gut zu bewältigen. Die größte praktische Stolperfalle war nicht die Technik an sich, sondern die räumliche Verteilung der Empfänger: Eine Häufung mehrerer Bluetooth-Quellen an einem Standort (in meinem Fall der Keller) kann die Trilateration systematisch verzerren, auch ganze Etagen entfernt.
Als nächste Schritte stehen bei mir noch an: den IRK-Capture-Vorgang auch für Person 2 durchzuführen, damit beide Bewohner raumgenau erfasst sind, sowie die verbleibenden bluetoothfähigen Shellys (Poolpumpe, Balkonkraftwerk, Heizstab Bad Dach) kontrolliert als zusätzliche Empfangsquellen zu ergänzen – dieses Mal von Anfang an mit Blick auf eine gleichmäßige Verteilung übers Haus, statt in die gleiche Überrepräsentations-Falle wie im Keller zu laufen.
* 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.