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.

Der Beitrag Blue Connect GO in Home Assistant integrieren — Pool-Werte komplett lokal überwachen erschien zuerst auf Das ist die Welt von Thomas.

technisches Grundsetup

Auf dem Dach des Hauses befindet sich eine PV-Anlage mit Fronius Wechselrichtern und einem Akku. Für die Heimautomatisierung läuft HomeAssistant auf einem Raspberry Pi 5*. Der Antminer S19 J Pro ist über einen SONOFF POW320D Elite Smart Schalter* an das Stromnetz angeschlossen und per Wlan mit dem Heimnetzwerk verbunden. Der Antminer selbst wurde mit dem Braiins OS bespielt, welches seinerseits die notwendigen Schnittstellen bereitstellt um den Miner steuern zu können.

Durch dieses Setup lässt sich das gesamte System recht einfach und effektiv steuern, vom Ein- oder Ausschalten bei PV-Strom bis zur automatisierten Regelung der nutzbaren Energie des Miners. Alles was dafür notwendig ist, sind ein paar Konfigurationen in HomeAssistant.

Bitcoin Miner automatisiert regeln – die Grundkonfiguration

Bevor wir uns in die Automatisierung stürzen benötigen wir ein paar kleine Grundkonfigurationen. Als erstes kümmern wir uns um die Darstellung der Stromflüsse indem wir den Wechselrichter an HomeAssistant anbinden. Je nach Wechselrichter existieren unterschiedliche Bindings welche konfiguriert werden können. Wichtig ist, dass wir nach der Einrichtung Sensoren für die folgenden Werte vorliegen haben:

• aktuelle PV-Gesamtleistung (Was bringt die PV-Anlage gerade)
• aktueller Netzbezug (was beziehe ich gerade)
• aktuelle Netzeinspeisung (was speise ich gerade ein)
• aktuelle Ladeleistung (was lade ich gerade in den Akku)
• aktuelle Endladeleistung (was ziehe ich gerade aus dem Akku)

Auf dem Screenshot ist zu sehen, wie diese Werte in meinem Dashboard in der Energieübersicht dargestellt werden. Auf Basis dieser Sensoren lässt sich nun der Bitcoin Miner automatisiert regeln. Schauen wir uns das nun mal an.

Antminer mit PV Überschuss über Homeassistant steuern

Um den Antminer in Homeassistant anzubinden benötigen wir ein HACS Plugin namens „Miner„. Ist dieses Plugin installiert lässt sich der Miner über die entsprechende Integration hinzufügen. Das Gerät liefert direkt alle notwendigen Komponenten um die Steuerung des Miners durchzuführen. Ich habe mir ein eigenes kleines Dashboard gebaut, über welches ich die wichtigsten Informationen einsehen, die Automatisierung deaktivieren und die Steuerung manuell vornehmen kann. Selbiges ist auf der rechten Seite zu sehen.

Um die Steuerung nun zu automatisieren habe ich 4 Regeln eingeführt. 2 Schalten den Miner Ein und Aus (er muss ja nachts nicht laufen), 2 weitere sorgen für die dynamische Anpassung der Limits (Erhöhung und Reduzierung).

Automatisierte Leistungserhöhung bei PV-Überschuss

Die Leistungserhöhung ist relativ einfach umgesetzt und basiert im Kern auf dem Wert der aktuellen Netzeinspeisung. Strom, welcher ins Netz eingespeist wird, soll genutzt werden um Bitcoins zu minen.

Hierbei ist die folgende Automatisierung umgesetzt:

Automatisierte Leistungsreduzierung bei fehlender PV-Energie

Die Reduzierung der für den Miner genutzte Leistung ist etwas komplexer als die Erhöhung da die Berechnung etwas abstrakter ist. Meine Berechnung stützt sich hierbei nicht alleine auf die ins Netz eingespeiste Energie sondern bezieht auch die aktuelle Akku Ladung / Entladung ein um diesen nicht unnötig zu belasten / leer zu saugen. Inzwischen ist die Steuerung jedoch „rund“ und läuft seit mehreren Wochen automatisiert.

Folgende Automatisierung ist zur Leistungsreduzierung umgesetzt:

Bitcoin Miner automatisiert regeln – warum so selten?

Die hier gezeigten Automatisierungsregeln reagieren relativ „langsam“ und haben lange Pufferzeiten (5 bis 10 Minuten) bevor eine Regelung durchgeführt wird. So reagieren diese nicht auf jede Wolke oder jedes Einschalten der Kaffee-Maschine. Der Akku puffert kurzzeitig einige Watt, um kurzfristige Engpässe auszugleichen, und bleibt dabei weitgehend unbelastet.

Fehlt die Pufferzeit, greift Home Assistant deutlich öfter ein und unterbricht das Mining unnötig – so verschenken wir wertvolle Laufzeit. Bei einer Neuregelung benötigt der Miner ca. 1 bis 2 Minuten bis er wieder brauchbar arbeitet, diese Ausfälle gilt es zu vermeiden.

Das hier angezeigte Diagram stellt einen üblichen Tagesverlauf mit überschaubarer PV-Energie dar. An diesem Tag (im August 2025) lagen viele Wolken vor und es regnete. Der Ertrag blieb insgesamt sehr gut – auch wenn Home Assistant den Miner in einigen Phasen drosselte, um keinen Netz- oder Akkustrom zu verbrauchen.

Bitcoin Mining mit PV-Überschuss – wie macht ihr das?

Ich zeige euch hier, wie ich meinen Bitcoin Miner automatisiert über Homeassistant regle um den PV Überschuss möglichst perfekt für das Mining zu nutzen. Nun würde mich interessieren, wie macht Ihr das? Nutzt Du schon Deinen PV-Überschuss zum Bitcoin-Mining oder denkst Du nur darüber nach? Hast Du hier auch eine Automatisierung umgesetzt, falls ja wie? Vielleicht kann ich ja selbst daraus lernen und meine Automatisierung weiter optimieren? Los erzählt es mir in den Kommentaren

Der Beitrag Bitcoin Miner automatisiert regeln – PV Überschuss und Home Assistant erschien zuerst auf Das ist die Welt von Thomas.

Bitcoin Mining Pool Vergleich: Was sind die wichtigsten Unterschiede?

Mining-Pools verwenden verschiedene Methoden, um die Belohnung unter den Minern aufzuteilen. Das klingt erstmal trivial, hat aber massive Auswirkungen auf deine Einnahmen. Ähnlich wie bei meinen Tests zur Effizienz des Antminer S19j Pro gibt es hier nicht „den einen“ besten Bitcoin Mining Pool für alle.

PPS vs PPLNS: Der entscheidende Unterschied

PPS (Pay Per Share) – Der Sichere Das ist die einfachste Methode: Du bekommst für jede eingereichte Share eine feste Belohnung, egal ob der Pool einen Block findet oder nicht. Der Pool trägt das Risiko von Schwankungen. Dafür sind die Auszahlungen niedriger, aber konstant.

PPLNS (Pay Per Last N Shares) – Der Risikoreiche Hier wird’s interessant: Du bekommst nur etwas, wenn der Pool einen Block findet. Die Belohnung wird dann basierend auf deinen letzten N Shares berechnet. Das kann richtig lukrativ sein, aber auch komplett ins Leere laufen.

FPPS (Full Pay Per Share) – Der Optimale Eine Weiterentwicklung von PPS, die sowohl Block-Rewards als auch Transaktionsgebühren berücksichtigt. Höhere Auszahlungen als Standard-PPS, aber der Pool trägt weiterhin das Risiko.

Bitcoin Mining Pool Test: Meine Erfahrungen mit 4 verschiedenen Pools

Basierend auf meinen Tests mit dem Antminer S19j Pro habe ich vier verschiedene Pools intensiv getestet. Dabei habe ich akribisch protokolliert, wie viel Energie ich für 0,00001 BTC bei jedem Pool benötige:

Bitcoin Mining Pool Energieeffizienz-Ranking (kWh für 0,00001 BTC):

1. Braiins Pool: 12,8 kWh Testsieger
2. NiceHash: 13,32 kWh
3. F2Pool: 13,61 kWh
4. CloverPool: Test abgebrochen (Auszahlungsgrenze zu hoch)

Das sind deutliche Unterschiede! Der Braiins Pool ist um 6% effizienter als F2Pool – bei meinem täglichen Verbrauch macht das richtig was aus.

Braiins Pool – Der Transparenz-Champion

• Methode: Hauptsächlich FPPS und Score-basierte Methoden
• Gebühren: 0% für FPPS bei Nutzung von Braiins OS
• Energieeffizienz: 12,8 kWh für 0,00001 BTC (Testsieger!)
• Mein Eindruck: Extrem transparent, perfekt für Tüftler wie mich

Braiins Pool punktet durch absolute Transparenz. Du siehst genau, was passiert und warum. Da ich bereits das Braiins OS nutze (wegen der fantastischen API-Integration für mein Home Assistant Setup), bekomme ich automatisch die 0% Gebühren für FPPS. Das ist ein klarer Vorteil gegenüber anderen Pools!

F2Pool – Der Flexible

• Methode: PPS+ (entspricht FPPS) und PPLNS
• Gebühren: 2,5-4% je nach Methode
• Energieeffizienz: 13,61 kWh für 0,00001 BTC
• Mein Eindruck: Solide Wahl für verschiedene Strategien

F2Pool bietet die Flexibilität, zwischen verschiedenen Methoden zu wechseln. Das ist praktisch, wenn du experimentieren willst. Die Gebühren sind fair, aber die Effizienz ist am schlechtesten im Test.

CloverPool – Der Ausfall

• Methode: Hauptsächlich PPLNS
• Gebühren: 1-2%
• Energieeffizienz: Nicht getestet (zu hohe Auszahlungsgrenze)
• Mein Eindruck: Unpraktikabel für kleine Miner

CloverPool habe ich nach kurzer Zeit wieder rausgeworfen. Die Mindestauszahlungsgrenze war so hoch, dass es Wochen gedauert hätte, bis zur ersten Auszahlung zu kommen. Für Hobby-Miner wie mich völlig unpraktikabel.

NiceHash – Der Marktplatz

• Methode: Marktbasierte Hashpower-Vermietung
• Gebühren: 2% für interne Wallets
• Energieeffizienz: 13,32 kWh für 0,00001 BTC
• Mein Eindruck: Interessant, aber nicht optimal für konstante Erträge

NiceHash liegt bei der Effizienz im Mittelfeld. Die marktbasierte Vergütung schwankt stark, was für PV-Überschuss-Mining problematisch sein kann.

Wann solltest du deinen Mining Pool wechseln?

Problem Nr. 1: Häufige Leistungsänderungen beim PV-Überschuss-Mining

Wie ich in meinem Test zur PV-Überschuss-Nutzung festgestellt habe, muss mein Miner häufig die Leistung anpassen. Das hat dramatische Auswirkungen auf die Pool-Wahl:

Bei PPLNS-Pools wird jeder Neustart zum Problem. Du verlierst potentiell den Anspruch auf Blöcke, die kurz nach dem Neustart gefunden werden. Das kann richtig wehtun.

Bei PPS/FPPS-Pools ist das kein Problem. Jede Share wird einzeln bezahlt, Neustarts sind irrelevant.

Problem Nr. 2: Bitcoin Mining Pool Gebühren summieren sich

Ein oft übersehenes Problem: Die Gebührenunterschiede zwischen den Pools summieren sich erheblich. Jetzt kann man zwar sagen, dass solch geringe Gebühren kaum einen Unterschied machen aber bei der Betrachtung der Wirtschaftlichkeit ist jeder Prozentpunkt entscheidend. Am Ende können die Gebühren einen spürbaren Unterschied machen und müssen in die Betrachtung mit einbezogen werden.

Problem Nr. 3: Mindestauszahlungsgrenzen

Viele Pools haben hohe Mindestauszahlungsgrenzen. Mit meinen Erträgen dauert es bei manchen Pools Wochen bis zur ersten Auszahlung. Das bindet Kapital und ist frustrierend.

Welcher Mining Pool ist der beste? Meine Empfehlungen 2025

Bester Bitcoin Mining Pool für PV-Überschuss-Mining

Empfehlung: Braiins Pool mit FPPS

Warum: Häufige Leistungsänderungen und Neustarts sind bei PPS-Methoden unproblematisch. Da ich sowieso das Braiins OS nutze (wegen der perfekten API-Integration), bekomme ich automatisch die 0% Gebühren für FPPS. Das ist ein unschlagbarer Vorteil – andere Pools verlangen 2-4% Gebühren für vergleichbare Leistungen.

Für Experimentierfreudige und Anfänger

Empfehlung: F2Pool (mit Vorsicht bei NiceHash)

Warum: F2Pool bietet Flexibilität beim Wechsel zwischen Methoden. NiceHash ist interessant für Tests, aber die schlechtere Effizienz und schwankende Vergütung machen es weniger attraktiv.

Die Realität: Zahlen lügen nicht

Genau wie bei meinen Tests zur Effizienz-Optimierung zeigen konkrete Messwerte die Wahrheit. Die 6% bessere Energieeffizienz von Braiins Pool gegenüber F2Pool mag klein klingen, aber das summiert sich erheblich.

Warum Energieeffizienz beim PV-Überschuss-Mining wichtig ist: Auch wenn der Solarstrom „kostenlos“ ist, bedeutet bessere Effizienz höhere Bitcoin-Erträge bei gleichem Stromverbrauch. Mit Braiins Pool bekommst du für dieselben 10 kWh PV-Überschuss einfach mehr Bitcoin als mit F2Pool – 6% mehr, um genau zu sein.

Zusätzlicher Vorteil: Die 0% Gebühren bei Braiins Pool (dank Braiins OS) statt 2-4% bei anderen Pools. Das ist bares Geld, das bei dir bleibt.

Es hängt trotzdem von deinen Umständen ab:

• Schwankende PV-Leistung: Braiins Pool ist klar überlegen
• Konstante Mining-Zeiten: Braiins Pool bleibt beste Wahl
• Wenig Erfahrung: Braiins Pool für Transparenz und Planbarkeit
• Kleine Erträge: Hohe Auszahlungsgrenzen sind ein K.O.-Kriterium

Mein aktueller Setup

Nach wochenlangen Tests läuft mein Antminer S19j Pro aktuell auf Braiins Pool mit FPPS. Die Kombination aus 0% Gebühren (dank Braiins OS), Transparenz und der Unempfindlichkeit gegenüber meinen häufigen Leistungsanpassungen hat mich überzeugt.

Ein wichtiger Punkt: Die 0% Gebühren bei Braiins Pool gelten nur für Nutzer des Braiins OS. Da ich das OS sowieso wegen der hervorragenden API-Integration nutze, ist das ein perfektes Match. Andere Pools verlangen 2-4% Gebühren – das summiert sich über die Zeit erheblich.

Die Automatisierung über Home Assistant läuft inzwischen stabil, und ich passe die Leistung nur noch alle paar Stunden an – nicht mehr minütlich wie am Anfang. Das hat die Erträge spürbar verbessert.

Fazit: Der beste Bitcoin Mining Pool 2025

Die Wahl des richtigen Pools und der passenden Berechnungsmethode ist genauso wichtig wie die Hardware-Optimierung. Mein Bitcoin Mining Pool Test 2025 zeigt klar: Braiins Pool ist der Gewinner – sowohl bei der Energieeffizienz als auch bei den Gebühren.

Warum Braiins Pool der beste Bitcoin Mining Pool ist:

• 6% bessere Energieeffizienz als F2Pool
• 0% Gebühren bei Nutzung des Braiins OS
• Unempfindlich gegenüber häufigen Leistungsanpassungen

Wer seine Mining-Leistung häufig anpasst (wie ich beim PV-Überschuss-Mining), sollte definitiv zu PPS/FPPS-Pools greifen. Konstante Miner können mit PPLNS langfristig mehr verdienen, aber nur bei stabiler Hardware.

Mein Tipp: Teste verschiedene Pools über mehrere Wochen. Die Unterschiede werden erst über längere Zeiträume sichtbar. Und scheue dich nicht, deinen Mining Pool zu wechseln, wenn die Zahlen nicht stimmen.

Wie sind deine Erfahrungen mit verschiedenen Mining-Pools? Nutzt du auch PV-Überschuss zum Mining oder läuft dein Miner konstant? Ich bin gespannt auf deine Erfahrungen und freue mich über einen Austausch in den Kommentaren!

Der Beitrag Bitcoin Mining Pool Test 2025: Welcher Pool ist der beste für PV-Überschuss-Mining? erschien zuerst auf Das ist die Welt von Thomas.

Bitcoin Mining mit PV-Überschuss – Warum eigentlich?

Das Anfang 2025 verabschiedete Solarspitzengesetz hat krasse Folgen für neu installierte PV-Anlagen. Auch unsere PV-Anlage fällt unter dieses Gesetz da diese nach dem Stichtag installiert und in Betrieb genommen wurde. Im Kern trifft uns das Thema der Anpassung der Einspeisevergütung hier am härtesten. Zum einen ist die Einspeisevergütung rapide gesunden, zum einen erhalte ich selbige nicht mehr immer. Sobald der Strompreis an der Strompreisbörse negativ ist, erhalte ich für meinen PV-Überschuss keine Einspeisevergütung. Ganz grob kann man sagen, dass das im Mai / Juni fast jeden Tag für ein paar Stunden (teilweise 6 Stunden am Stück) zugetroffen hat.

Der Strom selbst ist aber ja da, wäre doch schade ihn zu verschenken und nicht sinnvoll zu nutzen. Also stellt sich die Frage, wie kann ich die vorliegende Energie nutzen und in etwas „Sinnvolles“ verwandeln.

Mangels Elektro-Auto, Wärmepumpe oder sonstigen Energiefressern wird also eine alternative Nutzungsmöglichkeit gesucht. Da kommt mir das Thema ‚Bitcoin Mining‚ gerade recht. Es schreit nach einem Selbstexperiment.

Selbstexperiment: die Grundidee

Die Idee ist recht einfach erklärt. Die Fronius Wechselrichter sind bereits im internen Netzwerk verfügbar und können über die bereitgestellten APIs ausgelesen werden. Somit liegen im Grund alle notwendigen Daten für die Berechnung des aktuellen PV-Überschusses vor. Diese Werte sollen über die Heimautomatisierung (basierend auf Homeassistent) ausgelesen und genutzt werden um den für den Miner verfügbaren Strom zu berechnen. Dieser Wert soll nun an den Miner übergeben werden, so dass nur „nicht benötigte Energie“ zum Minen genutzt wird.

Antminer S19j Pro mit Braiins OS als Basis

Nach einiger Recherche habe ich mich für ein nicht mehr ganz aktuelles Modell, den Antminer S19j Pro entschieden. Dieser ist mit einer Rate von 104 TH/s relativ performant und in der Anschaffung noch bezahlbar (rund 700 Euro hat er mich gekostet). Das neueste Modell kostet gebraucht mehr als das 5-fache und hat „nur“ die 2,5-fache Leistung. Für einen ersten Versuch dann doch übertrieben.

Das Braiins OS verfügt über APIs über welche sich der Antminer relativ gut konfigurieren lässt. Egal ob Geschwindigkeit der Lüfter oder eben auch die maximal zu nutzende Leistung, alles ist über Endpunkte verfügbar. Das passende Homeassistent-Plugin (hass-miner) bietet dazu die perfekte Integration und lässt keine Wünsche offen.

Mein Wunsch den Antminer bei Nichtgebrauch vollständig vom Netz zu trennen war leider etwas herausfordernder. Eine schaltbare Steckdose zu finden welche > 3 kW schalten kann ist gar nicht so einfach zu finden. Also habe ich mich für den SONOFF POW320D Elite Smart Schalter mit Leistungsmesser* entschieden, welcher ebenfalls über Homeassistant gesteuert werden kann.

Auswahl des richtigen Mining-Pools

Klar, man kann auf die Idee kommen alleine zu Minen und darauf hoffen, dass man irgendwann das notwendige Glück hat und einen gesamten Bitcoin auf seinem Wallet zu finden. Die Wahrscheinlichkeit hierfür ist jedoch relativ klein. Daher habe ich mich dazu entschieden mich einem Mining-Pool anzuschliessen.

Die Auswahl des passenden Pools ist hierbei gar nicht so einfach denn die Pools arbeiten nach unterschiedlichen Konzepten. Ich selbst habe mir 5 Pools sowie ein System zum Verkauf der Hashpower (NiceHash) im Detail angeschaut (Antpool, Braiins Pool, F2Pool und CloverPool (ehemals BTC.com)*). Bei meinen ersten Tests lag der CloverPool*. Die Pools selbst unterscheiden sich im Kern Berechnungsmethode der Ausschüttung. Dazu sollte man noch beachten, dass je nach Pool Mindestauszahlungsgrenzen definiert sind welche eine Auszahlung teilweise recht weit in die Ferne schieben.

Mein Antminer läuft nun erstmal je Pool ein paar Tage / Wochen. Hierbei werde ich prüfen wie sich die täglichen Erträge in Relation zu der investierten Energie entwickeln…

Bitcoin Mining mit PV-Überschuss – Lohnt es sich jetzt oder nicht?

Leider kann ich noch keine wirklich zufriedenstellende Antwort auf diese Frage geben, dazu läuft der Test noch nicht lange genug und ist von vielen Faktoren abhängig. Was ich jedoch inzwischen gelernt habe ist:

Vom aktuellen Bauchgefühl würde ich sagen, dass das Bitcoin Mining mit PV-Überschuss sich nur in sehr wenigen Fällen wirklich rechnet. Mein Antminer läuft munter weiter und ich versuche mein Glück. Natürlich werde ich sämtliche Zahlen, sofern diese nach einem längeren Test denn vorliegen, analysieren und das Ergebnis veröffentlichen.

Sobald ich eine sinnvolle und für mich als gute Automatisierung gefunden habe (wann wird welche Regelung durchgeführt) werde ich diese natürlich ebenfalls veröffentlichen

Wie sind Deine Erfahrungen zum Thema Bitcoin Mining mit PV-Überschuss. Bist Du auch am „Schürfen“, denkst Du drüber nach oder hast Du schon damit aufgehört? Ich bin sehr auf Deine Gedanken gespannt und freue mich auf einen Austausch.

Der Beitrag Bitcoin Mining mit PV-Überschuss – lohnt sich das? erschien zuerst auf Das ist die Welt von Thomas.