Mein Pool steht (fast komplett). Wasser drin, Pumpe läuft, pH-Dosierung tut ihren Job. Die Blue Connect GO* misst Temperatur, pH und ORP — alles schön. Bis du merkst: die Werte gibt’s nur über die App. Auf dem Handy. Wenn du Lust hast, gerade nachzusehen. Genau das wollte ich nicht, also habe ich angefangen, die Blue Connect GO* in Home Assistant zu integrieren.

Was am Ende rausgekommen ist: ein Dashboard, das mir zu jeder Zeit zeigt, wo der Pool steht — und auf einen Blick verrät, ob ich Chlor nachwerfen oder pH-Minus dazugeben soll. Komplett lokal, ohne Cloud-Abo, ohne App-Klickerei.

Hier ist der ganze Weg, den ich gegangen bin. Inklusive eines hässlichen Stolpersteins, an dem ich fast einen halben Tag verloren habe.

Was die Blue Connect GO eigentlich macht

Die Blue Connect GO* ist eine kleine, weiße Boje, die du einfach ins Poolwasser wirfst. Sie schwimmt da rum und misst kontinuierlich drei Werte, die für die Wasserqualität relevant sind:

• Temperatur — was du eh schon weißt, aber im Tagesverlauf interessant für die Solarheizung
• pH-Wert — entscheidend dafür, ob das Chlor seine Arbeit machen kann
• ORP (Oxidations-Reduktions-Potential) — der eigentliche Indikator dafür, ob die Desinfektion (Chlor) ausreicht

Statt einzelnen Teststreifen oder Photometer-Messungen bekommst du also dauerhaft frische Werte ohne Aufwand. Die Boje hat einen kleinen Akku (per USB ladbar), einen Bewegungssensor (Schütteln weckt sie aus dem Schlaf) und eine Bluetooth-Low-Energy-Schnittstelle zum Auslesen.

Klingt erstmal nach einem klaren Win — und das ist es auch. Aber: Der Hersteller verkauft das Ding als Teil seines App-Ökosystems. Du installierst die BlueRiiot-App, hältst dein Handy einmal pro Tag in die Nähe der Boje, und die App synchronisiert die Werte in eine Cloud.

Und genau da fängt es an, mich zu stören.

Warum ich es nicht bei der App lassen wollte

Drei Gründe, warum das App-Setup für mich nicht funktioniert:

1. Manuelles Auslesen. Ich muss aktiv mit dem Handy hinrennen. Macht in der Praxis vielleicht zweimal die Woche jemand. Eigentlich will ich aber wissen, ob heute Morgen um 8 Uhr der pH-Wert nach dem nächtlichen Regen abgesoffen ist.
2. Daten liegen in der Cloud. Wer die Werte sehen will, braucht Account, App, Verbindung. Wenn ich in Home Assistant ein Dashboard für meine Frau bauen will, geht das nicht ohne Umwege.
3. Keine Automatisierungen. Ich kann keinen Alarm bauen, der mir bei ORP unter 600 mV eine Push-Notification schickt. Ich kann nichts mit den Daten machen, was über Anzeigen hinausgeht.

Mein Anspruch: Werte sollen automatisch und ohne Cloud in Home Assistant landen, da kann ich dann alles damit machen, was ich will.

Die Lösung in einem Satz

Ein ESP32* sitzt im Pool-Häuschen, hört per Bluetooth die Boje ab und schiebt die Werte per WLAN in Home Assistant.

Funktional sieht das so aus:

[Blue Connect GO im Pool] --BLE--> [ESP32 im Pool-Häuschen] --WLAN--> [Home Assistant]

Der ESP32* läuft mit der ESPHome-Firmware. ESPHome ist ein Framework, mit dem du den ESP per YAML-Datei konfigurierst, statt selbst Firmware-Code zu schreiben. Du legst fest, welche Sensoren der ESP haben soll, welche Daten er aufnimmt, was er damit macht — fertig.

Der entscheidende Trick: ESPHome hat eine fertige Komponente, die per BLE Geräte in der Umgebung scannen und auslesen kann. Du sagst ihr „verbinde dich mit MAC XX:XX:XX:XX:XX:XX und lies UUID f3300003-… aus“, und sie macht das.

Die Bedienung der Boje (Aufwecken zur Messung) läuft per BLE-Write, das geht auch über ESPHome — sodass Home Assistant via Button die Boje aktiv zu einer Messung zwingen kann.

Hardware-Stückliste

Was du brauchst:

• ESP32 — ich habe das AZDelivery NodeMCU Dev Kit C 3er-Pack bei Amazon* genommen, ca. 20 Euro. Drei Stück, damit du Ersatz hast. Modell ohne externe Antenne reicht, wenn der ESP nicht weiter als ein paar Meter von Pool und WLAN entfernt steht.
• Gehäuse — ich habe ein passendes 3D-Druck-Modell von Printables genommen. Falls du keinen Drucker hast: ein normales Universal-Plastikgehäuse für 3-4 Euro tut es auch.
• Micro-USB-Kabel + 5V-Netzteil — hast du wahrscheinlich rumliegen.
• Eine bereits eingerichtete Home-Assistant-Instanz.

Gesamtinvestition: rund 20 Euro plus etwas Zeit. Verglichen mit anderen Pool-Smarthome-Lösungen ist das ein Witz.

Phase 1: ESPHome installieren

In Home Assistant musst du das ESPHome Device Builder Add-on installieren. Achtung — nicht zu verwechseln mit der ESPHome-Integration (die brauchst du erst später, automatisch). Pfad:

Einstellungen → Add-ons → Add-on Store → "ESPHome Device Builder" → Installieren → Starten → "Im Sidebar anzeigen"

Danach hast du in der Seitenleiste einen ESPHome-Menüpunkt. Da arbeitest du jetzt.

Phase 2: Secrets pflegen

Bevor du das erste Gerät anlegst, im ESPHome-Dashboard oben rechts auf Secrets klicken und folgende Einträge ergänzen:

wifi_ssid: "DEIN_WLAN_NAME"
wifi_password: "DEIN_WLAN_PASSWORT"
ota_password: "selbst-gewähltes-Passwort-für-OTA-Updates"
pool_proxy_pool_api_key: "32-Byte-Base64-String"

Den API-Key kannst du dir generieren lassen, indem du ein Dummy-Gerät anlegst — ESPHome erzeugt da automatisch einen, den du dann kopierst.

Das Vorgehen in zwei Schritten — warum nicht direkt die große Config

Bevor wir in die YAMLs einsteigen, kurz das Vorgehen, damit du nicht in dieselbe Falle läufst wie ich am Anfang:

Du flashst den ESP zweimal. Erstmal mit einer reduzierten Discovery-Konfiguration, deren einziger Zweck es ist, die MAC-Adresse der Boje rauszufinden. Dann packst du den ESP ans Pool-Häuschen, sammelst die MAC, kommst zurück und flashst noch einmal — diesmal mit der finalen Konfiguration, die alles macht: BLE-Verbindung zur Boje, Auslesen der Werte, Button zum manuellen Triggern, alles.

Warum nicht direkt die große Config? Weil ohne MAC-Adresse die Hälfte davon ohnehin nicht funktioniert. Und weil der Discovery-Schritt ein zeitlich begrenzter Hack ist (das on_ble_advertise-Lambda aus dem nächsten Abschnitt), den du danach wieder rauswerfen willst.

Konkret:

1. Discovery-Flash per USB am Schreibtisch — ESP mit der reduzierten YAML beschreiben
2. ESP ans Pool-Häuschen bringen — Strom dran, WLAN-Reichweite zur Boje sicherstellen
3. MAC im Log auslesen — der Discovery-Lambda macht’s sichtbar
4. Zurück zum Rechner — MAC in die finale YAML eintragen
5. Finaler OTA-Flash — über WLAN, kein Kabel mehr nötig
6. ESP wieder zurück ans Pool — Werte tropfen rein

Punkte 2 und 6 fallen weg, wenn dein Schreibtisch sowieso in Reichweite des Pools ist. Bei mir liegen ca. 15 Meter dazwischen, also zwei Wege.

Phase 3: Discovery-Flash per USB

Im ESPHome-Dashboard auf New Device klicken, Namen vergeben (bei mir: pool-proxy-pool), Board ESP32 Generic auswählen. ESPHome generiert eine minimale YAML — die ersetzt du komplett durch das hier:

substitutions:
  device_name: pool-proxy-pool
  friendly_name: "Pool Proxy – Pool"

esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}

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

logger:
  level: DEBUG
  logs:
    esp32_ble_tracker: DEBUG

api:
  encryption:
    key: !secret pool_proxy_pool_api_key

ota:
  - platform: esphome
    password: !secret ota_password

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

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    interval: 320ms
    window: 300ms
    active: true
  on_ble_advertise:
    then:
      - lambda: |-
          for (auto uuid : x.get_service_uuids()) {
            if (uuid.to_string().find("f3300001") != std::string::npos) {
              ESP_LOGI("ble_scan", "BOJE: %s RSSI=%d", x.address_str().c_str(), x.get_rssi());
            }
          }

Diese Konfig macht nur ein einziges Ding: BLE-Pakete scannen und immer dann eine Log-Zeile schreiben, wenn ein Gerät mit der Blue-Connect-Service-UUID f3300001-… empfangen wurde. Mehr nicht. Keine Sensoren, keine Buttons, keine Logik — der ESP ist hier nur Lauscher.

Den ESP per USB anschließen, im ESPHome-Dashboard Install → Plug into computer running ESPHome dashboard. Beim ersten Build dauert das ein paar Minuten, weil ESPHome erstmal die Toolchain runterzieht. Danach hast du eine funktionierende Firmware drauf.

USB wieder abziehen, ESP ins Gehäuse, Netzteil dran, ab ins Pool-Häuschen.

Phase 4: Die MAC-Adresse der Boje finden

Wenn du jetzt im ESPHome-Dashboard auf Logs klickst, siehst du den Live-Log des ESP. Mit etwas Geduld (und einer aufgeweckten Boje — dazu gleich) tauchen Zeilen auf wie:

[I][ble_scan]: BOJE: 00:A0:50:D0:53:0F RSSI=-67
[I][ble_scan]: BOJE: 00:A0:50:D0:53:0F RSSI=-69

Die hexadezimale Zahl vor dem RSSI ist die MAC-Adresse deiner Boje. Notieren, kopieren, fertig. Falls nichts kommt: Boje einmal kräftig schütteln (der Beschleunigungssensor weckt sie aus dem Schlaf), wieder reinwerfen — und sicherstellen, dass die BlueRiiot-App komplett geschlossen ist. Die Boje erlaubt nämlich nur eine BLE-Verbindung gleichzeitig, eine offene App-Verbindung blockt den ESP.

Und damit zur Frage, die du dir vermutlich gerade stellst: Warum sieht die Discovery-Konfig oben so seltsam aus? Warum der ungewöhnliche on_ble_advertise-Lambda? Warum window: 300ms statt der überall im Netz herumliegenden window: 30ms?

Antwort: weil mich das einen halben Tag gekostet hat herauszufinden.

Mein Log mit der naiven Standard-Konfig aus dem Forum-Tutorial sah anfangs so aus:

[esp32_ble_tracker]: Scanner State: RUNNING
[esp32_ble_tracker]: Connecting: 0, discovered: 0

Und danach: nichts. Stundenlang. Weder die Boje, noch mein Handy welches direkt daneben lag noch sonst irgend ein Bluetooth-Device. Komplette Funkstille trotz aktivem Scanner.

Ich habe alles durchgekärrt, was man durchkärren kann: Log-Level von INFO auf DEBUG, dann auf VERBOSE. Verschiedene BLE-Submodule auf VERBOSE gesetzt. Framework von esp-idf auf arduino umgestellt. Build-Cache geleert. USB-Flash mit Erase. Alles ohne Erfolg.

Erst nach Stunden bin ich auf zwei Probleme gestoßen, die niemand in den Tutorials und Forenbeiträgen erwähnt — und die deshalb fest in die Discovery-Config oben eingebaut sind:

Problem 1: Das Default-Scan-Window ist zu kurz.

Die meisten Beispiele aus dem Netz haben window: 30ms bei interval: 320ms. Das bedeutet: Der ESP horcht 30 Millisekunden, schweigt dann 290 Millisekunden, horcht wieder. Das sind 9 Prozent aktive Hörzeit. Für ständig sendende Geräte (Beacons, Tags) reicht das. Für die Blue Connect GO, die nur sporadisch im Aufweck-Modus Pakete sendet, ist das viel zu wenig — du verpasst die meisten Sendeimpulse.

Mit window: 300ms horcht der ESP zu 94 Prozent der Zeit. Akku-Verbrauch interessiert hier nicht, der ESP hängt eh am Netzteil.

Problem 2: ESPHome verschluckt die „Found device“-Logs.

Das war der wirklich gemeine Teil. Selbst nachdem das Scan-Window vergrößert war, kam im Log immer noch nichts. Erst nach langem Recherchieren bin ich draufgekommen: In der ESPHome-Version, die ich genutzt habe (2026.6.0-dev), werden die Standard-Found device-Logs vom esp32_ble_tracker schlicht nicht mehr ausgegeben. Der Stack arbeitet, der Scanner findet Geräte — aber im Log siehst du nichts davon.

Lösung: eigene Log-Zeile per Lambda erzwingen. Genau das ist der on_ble_advertise-Block in der Discovery-Config. Er sagt: „Bei jedem empfangenen BLE-Advertising-Paket schau, ob das Gerät die Service-UUID f3300001-… mitsendet. Wenn ja, schreib mir eine Zeile ins Log mit MAC und Signalstärke.“ Die UUID f3300001-… ist der eindeutige Marker für die Blue Connect GO — andere BLE-Geräte werden also ignoriert.

Mit beiden Fixes drin fand mein ESP die Boje innerhalb von zwei Sekunden. Ohne die Fixes hätte ich vermutlich noch den nächsten Tag gesucht und wäre überzeugt gewesen, dass mein ESP einen kaputten Bluetooth-Chip hat. Hatte er nicht. Software-Problem.

Phase 5: Die finale Konfiguration aufspielen

Jetzt ersetzt du im ESPHome-Dashboard die Discovery-Konfig durch die finale. Die ist deutlich länger, weil sie alles macht, was du wirklich brauchst:

• BLE-Verbindung zur Boje aufbauen (mit deiner MAC)
• Beim Empfang von Werten die Rohdaten dekodieren (Temperatur in °C, pH, ORP in mV)
• Einen Button bereitstellen, mit dem du die Boje manuell zu einer Messung triggern kannst
• Diagnostik-Sensoren (WLAN-Signal, BLE-Signal zur Boje, Laufzeit)

Hier der komplette YAML-Block zum Copy-Paste — du musst nur an drei Stellen ran: die beiden MAC_DER_BOJE-Platzhalter durch deine echte MAC ersetzen, und die device_name-/friendly_name-Substitutionen an deinen Pool anpassen, falls du einen anderen Namen willst.

substitutions:
  device_name: pool-proxy-pool
  friendly_name: "Pool Proxy – Pool"

esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}

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

logger:
  level: DEBUG
  logs:
    esp32_ble: DEBUG
    esp32_ble_tracker: DEBUG
    esp32_ble_client: DEBUG
    ble_client: DEBUG

api:
  encryption:
    key: !secret pool_proxy_pool_api_key

ota:
  - platform: esphome
    password: !secret ota_password

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

captive_portal:

esp32_ble_tracker:
  scan_parameters:
    interval: 320ms
    window: 300ms          # Nicht 30ms — sonst werden Pakete verpasst
    active: true

ble_client:
  - mac_address: "MAC_DER_BOJE"   # z.B. "00:A0:50:D0:53:0F"
    id: ble_client_pool

button:
  - platform: template
    name: "${friendly_name} Messung auslösen"
    on_press:
      then:
        - ble_client.ble_write:
            id: ble_client_pool
            service_uuid: 'F3300001-F0A2-9B06-0C59-1BC4763B5C00'
            characteristic_uuid: 'F3300002-F0A2-9B06-0C59-1BC4763B5C00'
            value: [0x01]
  - platform: restart
    name: "${friendly_name} Neustart"
    entity_category: diagnostic
  - platform: safe_mode
    name: "${friendly_name} Safe Mode"
    entity_category: diagnostic

sensor:
  - platform: template
    name: "${friendly_name} Temperatur"
    id: sensor_pool_temperature
    unit_of_measurement: "°C"
    state_class: measurement
    device_class: temperature
    accuracy_decimals: 2
  - platform: template
    name: "${friendly_name} pH"
    id: sensor_pool_ph
    state_class: measurement
    accuracy_decimals: 2
  - platform: template
    name: "${friendly_name} ORP"
    id: sensor_pool_orp
    unit_of_measurement: "mV"
    state_class: measurement
    accuracy_decimals: 0
  - platform: wifi_signal
    name: "${friendly_name} WLAN Signal"
    update_interval: 60s
    entity_category: diagnostic
  - platform: uptime
    name: "${friendly_name} Laufzeit"
    entity_category: diagnostic
  - platform: ble_rssi
    mac_address: "MAC_DER_BOJE"   # gleiche MAC wie ble_client oben
    name: "${friendly_name} Boje BLE Signal"

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "${friendly_name} IP"
      entity_category: diagnostic
  - platform: ble_client
    id: pool_reading_data
    name: "${friendly_name} raw data"
    internal: true
    ble_client_id: ble_client_pool
    service_uuid: 'F3300001-F0A2-9B06-0C59-1BC4763B5C00'
    characteristic_uuid: 'F3300003-F0A2-9B06-0C59-1BC4763B5C00'
    notify: true
    update_interval: never
    on_notify:
      then:
        - lambda: |-
            std::string rawhex = format_hex_pretty((uint8_t *) x.c_str(), x.size()).c_str();
            ESP_LOGD("raw_hex", "Rohdaten der Boje: %s", rawhex.c_str());

            float temperature = (float)((int16_t)(x[2]<< 8) + x[1])/100;
            id(sensor_pool_temperature).publish_state(temperature);

            float raw_ph = (float)( (int16_t) (x[4]<< 8) + x[3]);
            float ph = (float)( (int16_t) (2048 - raw_ph)) / 232  + 7;
            id(sensor_pool_ph).publish_state(ph);

            float orp = (float)( (int16_t) (x[6]<< 8) + x[5]);
            id(sensor_pool_orp).publish_state(orp/4);

Was hat sich gegenüber der Discovery-Konfig geändert?

• Der on_ble_advertise-Lambda ist weg — der war nur für die MAC-Suche da, jetzt würde er nur noch das Log spammen.
• Ein ble_client-Block sagt dem ESP: „Verbinde dich aktiv mit dieser MAC.“
• Drei sensor-Templates für Temperatur, pH und ORP — die werden vom Lambda am Ende mit den dekodierten Werten gefüttert.
• Ein button-Block, der per BLE-Write die Boje zu einer Messung triggert (das ist die UUID F3300002, „Schreibe [0x01] rein“ = „Wach auf und miss“).
• Ein text_sensor mit ble_client-Platform, der auf die UUID F3300003 lauscht (das ist die „Messwerte-Charakteristik“ der Boje) und beim Eintreffen neuer Daten die Roh-Bytes per Lambda in °C, pH und mV umrechnet. Die Formel im Lambda ist nicht von mir, sondern aus dem Forumsbeitrag von community.simon42.com, wo jemand die Boje reverse-engineered hat.

Flashen ab jetzt drahtlos. Da der ESP schon im Netz hängt (von der Discovery-Konfig), brauchst du kein USB-Kabel mehr. Install → Wirelessly im ESPHome-Dashboard reicht. Der Flash läuft über die OTA-Verbindung, dauert ca. 30 Sekunden.

Werte landen in Home Assistant

Nach dem finalen Flash erscheint dein Gerät automatisch in Home Assistant unter Einstellungen → Geräte & Dienste. Die Sensoren sind angelegt, allerdings noch leer — die Boje muss erstmal eine Messung machen.

Dafür hat ESPHome dir aus dem YAML einen Button gebaut: button.pool_proxy_pool_messung_auslosen. Wenn du den drückst, sendet der ESP einen BLE-Write an die Boje, die daraufhin eine Messung startet und die frischen Werte zurücksendet. Sekunden später hast du Temperatur, pH und ORP in Home Assistant.

Damit kannst du dir jetzt auch eine Automatisierung bauen, die den Button alle paar Stunden automatisch drückt — bei mir alle 2 Stunden zwischen 8 und 22 Uhr.

Phase 6: Das Dashboard

Reine Sensoren in der Geräte-Übersicht sind unsexy. Was du willst, ist ein Dashboard mit Gauges, die sofort zeigen, ob alles im grünen Bereich ist.

Drei Gauges nebeneinander für die schnelle Übersicht. Das Spannende dabei: pH und ORP sind keine „je höher desto besser“-Werte, sondern haben einen Optimum-Bereich in der Mitte — drunter ist schlecht (zu wenig Chlor / saurer Pool), drüber ist auch schlecht (zu viel Chlor / basischer Pool). Eine klassische Glockenkurve.

In Home Assistant kannst du das mit der segments-Eigenschaft einer Gauge-Karte abbilden:

- type: gauge
  entity: sensor.pool_proxy_pool_orp
  name: Chlor (ORP)
  unit: mV
  min: 400
  max: 1000
  needle: true
  segments:
    - from: 400
      color: '#db4437'   # rot - zu wenig
    - from: 600
      color: '#ffa600'   # gelb - niedrig
    - from: 650
      color: '#43a047'   # grün - optimal
    - from: 750
      color: '#ffa600'   # gelb - hoch
    - from: 900
      color: '#db4437'   # rot - zu viel

So bekommst du auf einen Blick eine Ampel — wenn der Zeiger im grünen Mittelteil steht, ist alles gut. Wenn er nach links oder rechts wandert, sehe ich sofort, was zu tun ist.

Das Gleiche für pH (Optimum 7,0 bis 7,4) und ein einfacheres Gauge für Temperatur (wo höher zwar nicht „schlecht“ ist, aber irgendwann unangenehm warm wird). Dazu noch ein History-Graph für die Werte der letzten 24 Stunden und ein Button-Block für die manuelle Messung — fertig ist die Übersicht.

Phase 7: Dosier-Empfehlungen aus den Werten ableiten

Das eigentliche Killer-Feature, dass mir spätestens nach drei Tagen klargemacht hat, dass sich der ganze Aufwand gelohnt hat: Eine dynamische Markdown-Karte, die mir basierend auf den aktuellen Werten konkret sagt, was ich nachdosieren muss.

Bei mir steht da dann zum Beispiel:

Chlor — Zu niedrig (635 mV) — ~50 g Calciumhypochlorit (65%) nachdosieren

pH — Im Sollbereich (7,21) — keine Korrektur nötig

Funktioniert über inline Jinja-Templates in der Markdown-Card, die die aktuellen Sensorwerte lesen und stufenbasiert eine Empfehlung ausspucken. Wichtig: ORP ist kein direkter Chlorwert, sondern ein Indikator — die Mengenempfehlungen sind also Schätzungen, basierend auf Faustregeln für mein Pool-Volumen (32 Kubikmeter). Lieber konservativ dosieren und nochmal messen, als überdosieren.

Die Logik in Kurzform:

Analog für pH mit pH-Plus (Soda) und pH-Minus (Natriumhydrogensulfat).

Die Karte zeigt mir genau das, was ich brauche, in genau dem Moment, in dem ich aufs Dashboard schaue. Statt jedes Mal selbst zu überlegen, welche Mengen für meinen Pool passen.

Was ich gelernt habe

Drei Dinge, die ich beim nächsten ESPHome-BLE-Projekt vom ersten Moment an mitnehmen werde:

Das Scan-Window großzügig auslegen. Die 30-Millisekunden-Defaults aus den Foren sind für ständig sendende Beacons gedacht — für sporadisch sendende Messgeräte brauchst du 200 bis 300 Millisekunden, sonst verpasst du sie schlicht.

Beim Debugging immer ein eigenes Log-Statement reinhauen. Wenn der ESPHome-eigene Log dir gar keine Geräte zeigt, baust du einen Lambda mit ESP_LOGI rein. Das ist 30 Sekunden Aufwand, gibt dir aber Gewissheit, dass der Stack läuft. Ohne diesen Schritt hätte ich noch deutlich länger gesucht.

Vor dem Hardware-Tausch zweimal nachprüfen. Ich war zwei Stunden lang überzeugt, dass mein ESP32 einen defekten BLE-Chip hat, und wollte schon ein anderes Board aus dem Karton holen. War alles Software. Hardware ist seltener kaputt, als man denkt.

Fazit

Die Blue Connect GO in Home Assistant zu integrieren ist machbar an einem Nachmittag — wenn man die zwei Stolpersteine kennt, die ich oben beschrieben habe. Wenn nicht, kann es schnell ein Tag werden.

Was du am Ende hast, ist aber genau das, was die Hersteller-App nicht bietet: Werte ohne Cloud, jederzeit verfügbar, kombinierbar mit anderen Home-Assistant-Daten (PV-Überschuss-Steuerung der Pumpe, Solarheizungs-Logik, Push-Notifications bei kritischen Werten). Die rund 20 Euro für den ESP32 sind verglichen mit dem Nutzen ein Witz.

Und ehrlich: Das Beste an dem Setup ist nicht die Technik, sondern das morgendliche Ritual. Kaffee in der Hand, kurzer Blick aufs Tablet — alles grün, schwimmen kann gleich losgehen. Statt früher: App aufmachen, mit dem Handy zum Pool, warten bis sich was synct, lesen, zurückgehen. Das nervt schon nach drei Tagen.

Der komplette YAML-Code steht oben in den Phasen 3 und 5 als Copy-Paste-Vorlage drin. Wer Fragen hat, einen Tipp loswerden oder eine andere Boje am Start hat — schreib mir gerne, ich freu mich über Erfahrungsaustausch.