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.

Ich bin Softwarearchitekt. Seit vielen Jahren. Und ich habe mich vor einiger Zeit auch mal in Richtung Business Analyse bewegt — bewusst, mit einem klaren Grund. Aus dieser Kombination heraus habe ich eine ziemlich konkrete Meinung zu der Frage. Hier ist sie.

Warum ich überhaupt in Richtung Business Analyse gegangen bin

Projekte scheitern nicht, weil Entwickler schlecht sind. Das ist meine feste Überzeugung. Sie scheitern, weil zwei Welten aneinander vorbeireden: der Fachbereich und die IT. Beide sprechen unterschiedliche Sprachen, beide meinen es gut, und am Ende entsteht Software, die niemanden wirklich glücklich macht.

Ich glaube, ich kann einem Fachbereich komplexe Dinge einfach erklären. Und ich kann durch die richtigen Fragen helfen, die richtige Lösung zu finden — oder zumindest die Basis dafür. Das wollte ich mit der Business Analyse nutzen. Raus aus dem reinen Entwicklerdenken, rein in die fachliche Welt, um genau an dieser Schnittstelle besser zu werden.

Das ist eine Fähigkeit, die — so viel sei vorweggenommen — in einer KI-Welt nicht weniger wichtig wird. Im Gegenteil.

Was sich gerade wirklich verändert

AI leistet heute schon Erstaunliches. Das ist keine Frage mehr. Wer das bezweifelt, hat vermutlich noch keinen echten Entwicklungsalltag mit einem LLM verbracht.

Aber: AI nutzt die Freiheiten, die man ihr gibt. Vollständig. Und das ist genau das Problem.

In meinen eigenen Projekten habe ich erlebt, wie AI plötzlich veraltete Libraries eingesetzt hat, ohne mit der Wimper zu zucken. Ich habe gesehen, wie Security-Themen einfach ignoriert wurden — Software offen wie ein Scheunenohr. Dokumentation? Fehlanzeige, wenn man nicht explizit danach fragt. Und Architekturentscheidungen trifft die AI eben auch selbst, wenn man ihr keinen Rahmen vorgibt.

Das bedeutet nicht, dass AI schlecht ist. Das bedeutet, dass man wissen muss, was man ihr übergibt — und was nicht.

Der Softwareentwickler als Dompteur

Mein Bild für die Zukunft des Entwicklers ist das des Dompteurs. Nicht der, der die Tiere besiegt. Sondern der, der weiß, wie sie ticken, und der die Richtung vorgibt.

Was braucht es dafür konkret?

Fachlichkeit. Der zukünftige Entwickler muss verstehen, was ein Fachbereich wirklich braucht. Nicht um es selbst zu bauen, sondern um es der AI so aufzubereiten, dass die AI es sauber umsetzen kann. Wer nur Code schreibt, aber keine Anforderungen versteht, hat ein Problem.

Architekturkompetenz. Welches Framework? Welche Architektur? Wie wird das System betrieben? Diese Entscheidungen kann die AI nicht alleine treffen — zumindest nicht sinnvoll. Hier braucht es Erfahrung.

Review und Qualitätssicherung. Prüfen, ob das was die AI gebaut hat, auch wirklich zur Fachlichkeit passt. Ob es sicher ist. Ob es wartbar ist. Das ist kein Nice-to-have, das ist Kernaufgabe.

Guidelines setzen. Rahmenbedingungen für AI-Entwicklung definieren: Security-Standards, Coding-Guidelines, Testabdeckung. Wer das nicht einfordert, bekommt einen Jenga-Turm — von außen stabil, innen wackelig.

Macht mir das Angst?

Ehrlich gesagt: Nein.

Ich sehe AI als Werkzeug. Wie den Akkuschrauber. Als der auf den Markt kam, ist kein einziger Handwerker pleite gegangen. Sie wurden schneller, effizienter, konnten mehr liefern. Nur weil man jetzt einen Hammer hat, ist ja nicht alles gleich ein Nagel.

Wir müssen wissen, welches Werkzeug wir wann einsetzen. Wir müssen lernen, wie es funktioniert. Wer heute sagt „KI macht mich arbeitslos, also ignoriere ich sie“ — der hat das falsch verstanden. Wer heute sagt „KI macht alles, ich muss nichts mehr können“ — der auch.

Die Industrie hat das schon einmal erlebt. Neue Maschinen, neue Techniken, neue Produktivität. Die Arbeitswelt hat sich verschoben, nicht aufgehört.

Was heute schon klar ist

Einen Junior-Entwickler zu beraten, was er in Zukunft tun soll? Ehrlich — ich hab da keine perfekte Antwort. Die Welt verändert sich gerade schnell genug, dass langfristige Karriereratschläge mit Vorsicht zu genießen sind.

Was ich sagen kann: Fachlichkeit, Kommunikationsfähigkeit und der Wille, neue Werkzeuge zu verstehen und zu nutzen — das wird nicht weniger gefragt sein. Wer diese Kombination mitbringt, hat auch in einer KI-getriebenen Entwicklungswelt seinen Platz.

Und wer jetzt anfängt, mit AI zu entwickeln, zu experimentieren und zu lernen wo die Grenzen liegen — der ist schlicht besser aufgestellt als jemand, der abwartet.

Wie seht ihr das? Ich bin gespannt auf eure Perspektive — schreibt’s in die Kommentare.

Der Beitrag Softwareentwickler und KI – wer hat morgen noch einen Job? erschien zuerst auf Das ist die Welt von Thomas.

War es nicht.

Was mich dabei mehr beschäftigt als das Produkt selbst: Was KI-getriebene Produktentwicklung wirklich bedeutet – und warum das größte Risiko nicht der Code ist, sondern der Moment, in dem man der AI einfach antwortet.

Das Grundproblem: Die AI will alles. Sofort. Vollständig.

Stell dir vor, du engagierst einen hochmotivierten Architekten für dein neues Haus. Noch bevor du „Hallo“ gesagt hast, fragt er: Wie viele Stockwerke? Welche Heizung? Soll die Küche offen oder geschlossen sein? Kellergarage oder nicht? Welche Fensterfront gen Süden?

Genau so verhält sich eine AI in der Anforderungserhebung.

Claude – mein Entwicklungspartner in diesem Projekt – stellte von Anfang an präzise, durchdachte Fragen. Die zielten auf eine vollständige, ganzheitliche Lösung ab. Architektonisch macht das Sinn. Produktentwicklungstechnisch ist es eine Falle.

Denn: Wer von Anfang an alles entscheidet, entwickelt am Ende perfekt an den echten Bedürfnissen vorbei.

Das klassische Wasserfallproblem – nur mit KI-Turbo.

Wasserfall 2.0: Schneller in die falsche Richtung

Das Wasserfallmodell ist nicht deshalb gescheitert, weil Menschen zu dumm waren, es umzusetzen. Es ist gescheitert, weil sich Anforderungen verändern, sobald man anfängt, sie zu konkretisieren. Weil der erste echte Nutzer immer Dinge sieht, die kein Workshop-Teilnehmer vorhergesehen hat. Weil Lernen durch Tun nicht durch Planen ersetzt werden kann.

KI-getriebene Entwicklung löst dieses Problem nicht automatisch. Im Gegenteil: Sie beschleunigt es. Man kann in wenigen Stunden ein vollständiges Konzept durchdenken, dokumentieren und in Code überführen – und dabei systematisch an den echten Nutzerbedürfnissen vorbeientwickeln.

Bei spielmit.eu hatte ich genau diesen Moment. Früh wurden UI-Entscheidungen getroffen: Welche Buttons gibt es? Welche Aktionen sind auf welchem Screen verfügbar? Das Ergebnis war ein Interface voller Funktionen – technisch korrekt umgesetzt, aber praktisch eine Zumutung. Tausend Buttons, überladene Screens, keine klare Führung. Erst nach echten Tests und vielen Iterationen kam man auf eine schlanke Lösung.

Wäre man iterativer vorgegangen, hätte das nach dem ersten echten Klick auffallen müssen. Nicht nach zwanzig Entwicklungsrunden.

Die Lösung: Aktiv bremsen, iterativ lernen

Das Gegenmittel klingt einfach. Es ist es nicht.

Als die AI begann, Fragen zu stellen, die ich noch gar nicht beantworten konnte – oder sollte –, musste ich aktiv eingreifen. Meine Standardantwort wurde:

„Damit beschäftigen wir uns später. Lass uns iterativ vorgehen und gemeinsam lernen.“

Das klingt banal. In der Praxis erfordert es diszipliniertes Zurückhalten. Die AI bietet immer eine Antwort an, die sich vollständig und plausibel anfühlt. Die Versuchung, einfach mitzumachen, ist groß.

Was konkret geholfen hat:

Interview statt Fragebogen. Statt alle Fragen auf einmal zu beantworten, habe ich Claude gebeten, sie einzeln zu stellen. Eine Frage. Meine Antwort. Nächste Frage. Das reduziert die Gefahr, sich in frühen Annahmen zu verlieren, dramatisch.

Fachlichkeit vor Technik. Bevor auch nur eine Zeile Code geschrieben wurde, haben wir stundenlang nur die fachliche Logik durchdrungen. Was ist das eigentliche Problem? Wer hat es? Was ist der kleinstmögliche Schritt, der echten Wert liefert?

Kleine, dokumentierte MD-Files statt einem Monolith. Alles landet im Projektverzeichnis – aber verteilt auf kleine, fachlich fokussierte Markdown-Dateien. Eine pro Thema, nicht eine für alles. Das hält das Kontextfenster handhabbar und vermeidet, dass die AI wichtige Anforderungen aus dem Blick verliert.

Prioritäten setzen, nicht alles gleichzeitig. Bei spielmit.eu war von Anfang an klar: Datenschutz und Security sind nicht verhandelbar, alles andere ist nachrangig. Dieses Primat musste ich aktiv verteidigen – nicht einmal, sondern immer wieder.

Nicht-Determinismus: Das unterschätzte Risiko

Eine AI ist kein deterministisches System. Das klingt technisch. Die praktischen Konsequenzen sind handfest.

Derselbe Fehler kann in zwei aufeinanderfolgenden Sessions unterschiedlich interpretiert werden. Einmal findet die AI ihn. Beim nächsten Anlauf übersieht sie ihn – weil sie zwischendurch andere Anforderungen priorisiert hat, weil der Kontext gewachsen ist, weil… nun ja, weil sie eben nicht deterministisch ist.

Man dreht sich im Kreis, ohne es zu merken.

Das erfordert eine Qualität, die kein Prompt ersetzen kann: eigene Wachheit. Als PO oder Architekt muss man verstehen, was gerade wirklich passiert. Wer das vollständig abgibt, verliert die Kontrolle – leise, ohne Drama, und oft erst dann sichtbar, wenn es teuer wird.

Was die AI einfach nicht mitdenkt

Irgendwann habe ich in den Code geschaut. Veraltete Vue-Libraries, fast überall outdated minor versions. Der anschließende Update-Marathon kostete unnötig Zeit – und funktioniert hat er nur, weil wir eine hohe Testabdeckung hatten.

Das Ärgerliche: vollständig vermeidbar. Ein einfacher Check zu Projektbeginn hätte das verhindert. Die AI denkt nicht von alleine an Library-Hygiene, Security-Checks oder Dependency-Management.

Das sind keine Kleinigkeiten. Es sind genau die Dinge, die erfahrene Entwickler im Schlaf prüfen – und die beim KI-getriebenen Entwickeln aktiv eingefordert werden müssen. Am Anfang. Nicht nach zwanzig Iterationen.

Dasselbe gilt fürs Refactoring. Bei größeren Umstrukturierungen wurden Anforderungen vergessen, „zentralisierter“ Code tauchte trotzdem noch an alter Stelle auf. Clean Code und Testabdeckung sind keine akademischen Tugenden. Sie sind das Einzige, was einen vor dem Jenga-Turm rettet – dem Produkt, das von außen funktioniert, das man aber nicht mehr anfassen möchte.

Was AI in der Anforderungserhebung wirklich gut kann

Was KI in der Anforderungserhebung wirklich gut kann? Blinde Flecken aufdecken. Sie stellt Fragen die man selbst nicht stellt – einfach weil man zu nah am Problem dran ist. Genauso gut kann sie Perspektivwechsel erzwingen. „Wie würde ein datenschutzbewusstes Elternteil darauf reagieren?“ – solche Fragen lassen sich schnell und konsequent durchspielen. Was sie dabei aber nicht kann: entscheiden. Die Konsequenzen durchdenken ja, die Entscheidung treffen nein. Das bleibt beim Menschen – weil nur der weiß was er noch nicht weiß.

Der Trick ist, die AI aktiv zum Mitdenken anzuregen. Sie tut das nicht von alleine. Man muss fragen: „Welche Annahme, die wir gerade treffen, könnte sich als falsch herausstellen?“ Oder: „Was spricht dagegen?“

Fazit: AI First ist (noch) keine Option

KI-getriebene Entwicklung funktioniert. Mit Spielregeln, mit Disziplin, mit dem Willen, klein anzufangen und lieber öfter zu lernen als schnell zu skalieren.

AI First – also vollständige Entwicklung ohne menschliche Architektur-Entscheidungen, ohne Review, ohne iteratives Korrektiv – ist heute noch nicht möglich. Wer es trotzdem versucht, bekommt entweder ein Produkt, das die fachlichen Anforderungen nicht erfüllt. Oder, schlimmer, eines, bei dem man das glauben könnte – darunter aber ein Fundament aus technischen Schulden, das nur durch Zufall noch steht.

Die gute Nachricht: Die Kombination aus menschlicher Erfahrung und AI-Geschwindigkeit ist mächtig. Alleine hätte ich spielmit.eu nie gebaut – der Aufwand wäre zu groß gewesen für ein kostenloses Freizeitprojekt. Mit AI als Entwicklungspartner war es möglich.

AI First – also vollständig ohne menschliches Korrektiv – funktioniert heute noch nicht. Wer es trotzdem versucht, merkt das früher oder später. Ich bin froh, dass ich es in der Freizeit gelernt habe.

Der Beitrag KI-getriebene Anforderungserhebung: Warum du die AI bremsen musst, bevor du startest erschien zuerst auf Das ist die Welt von Thomas.

Kurz zur Einordnung: Im Juni 2025 habe ich mein Selbstexperiment „Bitcoin Mining mit PV-Überschuss“ gestartet. Ein Antminer S19j Pro, gesteuert über Home Assistant, betrieben mit dem Überschuss meiner 14,4 kWp PV-Anlage. Nach einem Jahr ist es Zeit für ein ehrliches Fazit. Spoiler: Es wird kein Jubelartikel.

Der Rückblick – was ist passiert?

Wer die bisherigen Artikel verfolgt hat, kennt das Setup: Antminer S19j Pro mit Braiins OS, gesteuert über Home Assistant, angeschlossen über einen SONOFF POW320D Smart Schalter. Die Fronius Wechselrichter liefern die PV-Daten, Home Assistant berechnet den Überschuss und regelt den Miner automatisch hoch und runter. Das Ganze steht in der Garage – im Haus wäre es schlicht nicht auszuhalten, sowohl von der Lautstärke als auch von der Abwärme.

Über den Sommer 2025 lief das System richtig gut. An sonnigen Tagen sprang der Miner morgens an, wurde je nach Überschuss zwischen 1.000 und 2.800 Watt geregelt und ging abends wieder in den Standby. Die Automatisierung funktionierte zuverlässig und brauchte nach der initialen Einrichtung kaum noch Pflege.

Dann kam der Herbst. Und mit ihm die ernüchternde Erkenntnis: keine Sonne, kein Mining. Im Winter ging praktisch gar nichts – die PV-Anlage lieferte gerade genug für den Eigenverbrauch, an Überschuss für den Miner war nicht zu denken. Der Antminer stand also monatelang still.

Die Technik – läuft wie eine Eins

Das muss man klar sagen: technisch ist das Projekt ein voller Erfolg. Der Antminer S19j Pro läuft seit einem Jahr ohne einen einzigen Ausfall. Das Braiins OS macht seinen Job, die Home Assistant Automatisierung regelt zuverlässig und die gesamte Kette von PV-Wechselrichter über die Automatisierung bis zum Miner funktioniert problemlos.

Ich betreibe den Miner bewusst nicht auf Volllast, sondern maximal bei 2.800 Watt. Das schont die Hardware – die Chip-Temperatur bleibt entspannt bei rund 66 Grad – und bringt ein gutes Verhältnis aus Hashrate und Effizienz. Der Sprung auf die vollen 3.250 Watt bringt nur marginal mehr Hashrate bei deutlich höherer Temperatur und schlechterer Effizienz.

Pool-Mining – die ernüchternde Rechnung

Im Sommer 2025 lief der Miner über verschiedene Mining-Pools. Ich habe einige ausprobiert – Antpool, Braiins Pool, F2Pool, CloverPool – und die Erträge verglichen. Ein realistischer Tagesertrag lag bei rund 0,00003 BTC, wenn der Miner etwa 8 Stunden bei gutem Sonnenschein laufen konnte.

Klingt erstmal nach „immerhin etwas“. Aber rechnen wir das mal durch:

Selbst bei der durch das Solarspitzengesetz reduzierten Einspeisevergütung ist der direkte Vergleich ernüchternd. Ja, an manchen Stunden gibt es gar keine Vergütung wegen negativer Börsenpreise – da macht Mining Sinn. Aber in der Gesamtbetrachtung über den Tag ist der Vorteil gegenüber dem Einspeisen minimal bis nicht vorhanden. Und das bei einem BTC-Kurs, der seit letztem Jahr von rund 95.000 € auf aktuell rund 60.000 € gefallen ist.

Die bittere Wahrheit: Der BTC-Kurs ist im Vergleich zum Vorjahr deutlich gefallen. Was letztes Jahr schon knapp war, rechnet sich heute noch weniger. Die wenigen Satoshi, die über Pool-Mining zusammenkommen, sind in Euro umgerechnet weniger wert als die entgangene Einspeisevergütung – selbst bei den durch das Solarspitzengesetz gedrückten Sätzen.

Der Wechsel zum Solo-Mining – Lotto mit Sonnenstrom

Ende der Saison 2025 habe ich die Konsequenz gezogen und vom Pool- auf Solo-Mining umgestellt. Der Miner läuft jetzt über den CK Pool im Solo-Modus.

Die Überlegung dahinter ist simpel: Wenn sich Pool-Mining finanziell nicht rechnet, kann ich auch gleich auf das große Los setzen. Die Chance, mit meiner Hashrate einen eigenen Block zu finden, ist extrem gering – aber der Gewinn wäre mit der aktuellen Block-Belohnung von 3,125 BTC (also knapp 190.000 €) ein absoluter Gamechanger.

Wo stehe ich aktuell? Mein Miner hat bisher 40,02 Gigashares berechnet. Mein bester Share lag bei 1,56 Terashares – das klingt beeindruckend, ist aber noch ungefähr Faktor 40 vom Ziel entfernt. Es ist Lotto. Vielleicht habe ich morgen Glück, vielleicht nie. Aber der Strom ist da, der Miner steht in der Garage, und die Kosten für den Betrieb sind quasi null.

Solo-Mining mit PV-Überschuss ist im Grunde ein Lotterielos, das man mit Sonnenstrom bezahlt. Der Einsatz ist virtuell, der mögliche Gewinn real.

Würde ich den Miner nochmal kaufen?

Klare Antwort: Nein.

Die rund 700 Euro Anschaffungskosten lassen sich über Pool-Mining nur über viele Jahre wieder reinholen – wenn überhaupt. Ich hatte auch kurz überlegt, auf einen moderneren Antminer S21 Pro umzusteigen, der bei gleicher Leistungsaufnahme fast die doppelte Hashrate liefert. Aber die Anschaffungskosten sind so viel höher, dass sich die Rechnung erneut nicht aufgeht.

Mein Miner ist jetzt da, also läuft er weiter. Die Preise für gebrauchte S19-Modelle sind mittlerweile auch ziemlich am Boden – teilweise unter 600 Euro. Das sagt einiges über den Markt aus.

Mein Fazit nach einem Jahr

Was gut funktioniert: Die Technik ist absolut solide. Home Assistant mit dem Miner-Plugin, Braiins OS und die PV-Anbindung über Fronius – alles läuft stabil und wartungsfrei. Wer Spaß an Heimautomatisierung und Technik hat, bekommt hier ein tolles Projekt. Die Automatisierung des Miners über PV-Überschuss funktioniert zuverlässig und man lernt extrem viel über Mining, Hashrates, Pools und das Bitcoin-Netzwerk.

Was nicht funktioniert: Die wirtschaftliche Seite. Pool-Mining rechnet sich bei einem einzelnen S19j Pro mit PV-Überschuss nicht – schon gar nicht bei einem BTC-Kurs von 60.000 €. Der Miner steht im Winter still, und selbst im Sommer sind die Erträge in Euro geringer als das, was man über die Einspeisevergütung bekommen hätte. Solo-Mining ist ein reines Glücksspiel.

Meine Empfehlung

Wenn mich heute jemand fragt, ob er sich einen Miner für den PV-Überschuss kaufen soll, ist meine analytische Antwort klar: Nein, tu es nicht. Die Chancen sind zu gering und die Rechnung geht in den allermeisten Fällen nicht auf.

Aber – und das ist das große Aber – wenn du es als Hobby betrachtest, Spaß an der Technik hast und den Miner als eine Art Lotterielos mit Sonnenstrom siehst: why not? Der Strom ist da, die laufenden Kosten sind quasi null, und die kleine Chance auf einen Solo-Block macht das Ganze zumindest spannend.

Sollte ich morgen einen Block finden, sieht die Welt natürlich komplett anders aus. Dann schreibe ich hier einen ganz anderen Artikel. Bis dahin bleibt es bei dem, was es ist: ein spannendes Technikprojekt mit einer ernüchternden wirtschaftlichen Bilanz.

TL;DR: Nach einem Jahr Bitcoin Mining mit PV-Überschuss ist das Fazit klar: technisch top, wirtschaftlich flop. Pool-Mining bringt weniger als die Einspeisevergütung, Solo-Mining ist Lotto. Ich würde mir keinen Miner mehr kaufen – lasse meinen aber weiterlaufen, weil der Strom ohnehin da ist. Wer es als Hobby sieht und die ~700 € investieren will: kann man machen. Wer Geld verdienen will: Finger weg.

Wie sind Deine Erfahrungen nach einem Jahr Bitcoin Mining? Hast Du ähnliche Erfahrungen gemacht oder siehst Du das komplett anders? Ich freue mich auf den Austausch in den Kommentaren!

Der Beitrag 1 Jahr Bitcoin Mining mit Solarstrom – eine ehrliche Bilanz erschien zuerst auf Das ist die Welt von Thomas.

Vom „Vibecoding“ zur stabilen Architektur

Für spielmit.eu habe ich mich auf Neuland gewagt: Es waren meine ersten echten Gehversuche mit einer Progressive Web App (PWA) und Firebase Firestore. Die Funktionen der Anwendung sind mittlerweile extrem umfangreich – und ich gebe offen zu: Ohne KI hätte ich diesen Funktionsumfang in dieser Zeit niemals erreicht. Die KI hat mir einen enormen Teil der „Fleißarbeit“ abgenommen, von der Modellierung der Daten bis hin zu komplexen Cloud-Function-Logiken.

Doch wer heute solche Systeme baut, weiß: Wer sich blind auf die KI verlässt, erntet schnell technische Schuld. Um das Projekt nachhaltig und wartbar zu halten, habe ich die KI als hocheffizienten, aber streng geführten Assistenten eingesetzt:

• Test-Pflicht als Dogma: Sicherheit entsteht durch Transparenz. Ich habe die KI konsequent dazu gezwungen, für jede Funktion umfassende Testfälle zu schreiben. Ein Feature war erst dann „fertig“, wenn die Test-Suite – die ich selbst mit-definiert habe – komplett grün war.
• Die ARCHITECTURE.md als Anker: Um zu verhindern, dass die KI bei der Generierung vom Pfad abweicht, habe ich eine zentrale Architektur-Dokumentation erstellt. Sie dient als mein „System-Gedächtnis“. Jede Änderung der KI musste sich an dieser Architektur messen lassen.
• Sicherheit durch Disziplin: Die Firestore-Sicherheitsregeln waren mein größtes Lehrstück. Mal waren sie zu offen, mal zu restriktiv. Hier half kein „Bitten“, sondern konsequentes Testen, bis die Regeln exakt den Sicherheitsanforderungen entsprachen.

Ein enormer Lernweg

Auch wenn die KI viele Prozesse beschleunigt hat, war das Projekt für mich eine intensive Lernreise. Die Arbeit mit Firebase-Regeln, Triggern, Indizes und Laufzeitbeschränkungen hat mir tiefe Einblicke gegeben, die weit über das hinausgehen, was man in einem Tutorial lernt. Ich wollte nicht nur ein Tool „hingezaubert“ bekommen, sondern verstehen, wie man moderne Software nachhaltig aufbaut und wartbar hält.

Fazit

spielmit.eu ist heute ein lebendes System, das ich – dank der Architektur-Dokumentation und der engen Einbindung der KI – souverän weiterentwickeln kann. Mein Lernfazit: KI-gestützte Softwareentwicklung ist eine fantastische Hebelwirkung, sofern man ihr einen extrem strikten Rahmen vorgibt. Der „No-Brainer“-Moment existiert noch nicht – aber mit der richtigen Struktur wird die KI zu einem mächtigen Werkzeug für das eigene technische Verständnis.

Neugierig geworden? Wenn du auch genug vom WhatsApp-Chaos hast: Schau gerne bei spielmit.eu vorbei und probiere es aus. Ich freue mich riesig über jedes Feedback, das mir hilft, die Plattform noch besser und intuitiver zu machen!

Der Beitrag Mehr als nur ein Prompt: Warum Architektur-Dokumentation das Geheimnis meines KI-Projekts ist erschien zuerst auf Das ist die Welt von Thomas.

Was passiert in der Praxis ohne klare Methodik? Es wird gelobbyt. Es wird politisiert. Wer lauter ist oder mehr internen Rückhalt hat, setzt sich durch. Und am Ende weiß nach sechs Monaten niemand mehr, warum eigentlich Lösung A gewählt wurde – außer vielleicht: „Das wollte damals der Abteilungsleiter so.“

Ich war selbst schon auf beiden Seiten dieses Tisches. Als derjenige, der eine Lösung bewertet – und als derjenige, dessen Lösung bewertet wurde. Und ich kann sagen: Der Unterschied zwischen einer sachlichen und einer emotionsgetriebenen Entscheidung liegt nicht in den Menschen im Raum. Er liegt im Prozess.

Das eigentliche Problem: Fehlende Kriterien erzeugen Emotion

Eine Aussage wie „Lösung A ist besser als Lösung B“ ohne klare Begründung ist eine Einladung zum Streit. Sie erzeugt Ablehnung – nicht weil die Aussage falsch sein muss, sondern weil sie nicht nachvollziehbar ist.

Was ich über die Jahre gelernt habe: Wenn man sich vorher auf Kriterien einigt, verändert das die gesamte Dynamik im Raum. Plötzlich diskutiert man nicht mehr über Geschmack oder Loyalität, sondern über messbare Eigenschaften. Und – das ist das Überraschende – oft stellt man dabei fest, dass beide Lösungen gute und weniger gute Seiten haben. In einem konkreten Fall, an dem ich selbst beteiligt war, haben wir am Ende keine der beiden Lösungen gewählt. Stattdessen haben wir gemeinsam eine dritte Option identifiziert: eine Kombination der besten Bausteine aus beiden Welten. Das wäre ohne einen strukturierten Vergleich nie entstanden.

Die Antwort muss nicht „A oder B“ sein. Sie kann auch „C“ sein.

ISO 25010 als Orientierung – nicht als Dogma

Als Grundlage für meine Architekturbewertungen nutze ich die Qualitätsmerkmale der ISO/IEC 25010. Der Standard definiert acht Oberkategorien für Softwarequalität:

1. Funktionale Eignung – Tut das System das, was es soll?
2. Leistungseffizienz – Wie verhält es sich unter Last?
3. Kompatibilität – Kann es mit anderen Systemen zusammenarbeiten?
4. Gebrauchstauglichkeit – Wie gut ist die Nutzererfahrung?
5. Zuverlässigkeit – Wie stabil und ausfallsicher ist es?
6. Sicherheit – Wie gut schützt es Daten und Zugriffe?
7. Wartbarkeit – Wie leicht ist es zu ändern und zu testen?
8. Übertragbarkeit – Wie gut lässt es sich in andere Umgebungen migrieren?

Wichtig: Ich behandle diese Kategorien nicht als starres Korsett. Sie sind ein Orientierungsrahmen. In der Praxis definiere ich gemeinsam mit den Stakeholdern die konkreten Merkmale, die für den jeweiligen Kontext relevant sind – und platziere sie in die passende Oberkategorie. Manchmal braucht es auch neue Merkmale, die im Standard so nicht vorgesehen sind, etwa „Betreibbarkeit unter konzernweiten Governance-Vorgaben“ oder „Onboarding-Aufwand für neue Entwickler“.

Der Standard gibt die Sprache vor – die Stakeholder geben den Inhalt.

Die Tücke: Merkmale stehen in Spannung zueinander

Hier wird es spannend – und das ist der Punkt, den ich in der Praxis am meisten erklären muss.

Qualitätsmerkmale sind keine isolierten Checkboxen. Sie beeinflussen sich gegenseitig, manchmal sogar entgegengesetzt.

Ein klassisches Beispiel: Systemstabilität vs. Time-to-Market.

Wer ein hochstabiles System will, in dem kaum etwas schiefgehen darf, braucht intensive Testautomatisierung, kontrollierte Deploymentprozesse und gründliche Qualitätssicherung. Das kostet Zeit. Entwicklungszyklen werden länger. Das ist kein Fehler – das ist die bewusste Entscheidung für Qualität vor Geschwindigkeit.

Wer dagegen flexibel auf den Markt reagieren und schnell neue Features liefern will, muss an anderen Stellen Abstriche machen. Vielleicht ist die 80%-Lösung manchmal akzeptabel. Vielleicht nimmt man bewusst in Kauf, dass ein Bug in Produktion landet – wenn das bedeutet, zwei Wochen früher live zu sein.

Keiner dieser Ansätze ist per se falsch. Beide sind legitime Strategien – je nach Kontext. Und genau das ist die Aufgabe im Workshop mit den Stakeholdern: diese Spannungsbögen sichtbar zu machen, gemeinsam zu diskutieren und dann bewusst zu priorisieren.

Der Prozess: Wie ein Bewertungsworkshop funktioniert

In der Praxis läuft eine Architekturbewertung bei mir in mehreren Schritten ab:

1. Stakeholder identifizieren und einbinden

Wer hat ein legitimes Interesse an der Entscheidung? Das sind nicht nur die Entwicklungsteams. Das sind Fachbereichsverantwortliche, Betrieb, Security, Compliance, manchmal auch der Einkauf. Jeder bringt eine eigene Perspektive mit – und das ist gut so.

2. Kriterienkatalog gemeinsam erarbeiten

Im Workshop frage ich: Was ist euch bei dieser Entscheidung wichtig? Die Antworten kommen in der Sprache der Stakeholder – nicht in ISO-Nomenklatur. „Wir müssen das in zwei Jahren noch selbst betreiben können“ wird zu einem Merkmal unter Wartbarkeit oder Betreibbarkeit. „Das darf nie down sein“ landet unter Zuverlässigkeit. Ich übersetze – die Stakeholder entscheiden.

3. Merkmale klar definieren

Jedes Merkmal bekommt eine klare Definition. Nicht „Performance ist wichtig“, sondern: „Das System muss 95% der Anfragen unter 200ms beantworten bei 1.000 gleichzeitigen Nutzern.“ Je weniger Interpretationsspielraum, desto weniger Diskussion später.

4. Gewichten

Welche Merkmale sind kritisch, welche nice-to-have? Hier kommen die unterschiedlichen Stakeholder-Interessen an die Oberfläche. Der CFO gewichtet Kosteneffizienz anders als der CISO die Security. Das ist normal. Im besten Fall einigt man sich gemeinsam. Im schlechtesten Fall braucht es jemanden mit Entscheidungskompetenz – aber dann wenigstens auf einem sauberen Fundament.

5. Lösungen bewerten

Jede Lösung wird auf Basis des Kriterienkatalogs bewertet – mit einer klaren Begründung, warum sie bei einem Merkmal X Punkte bekommt. Nicht nur eine Zahl, sondern ein Satz: „Lösung A bekommt hier 3 von 5, weil sie zwar eine gute Testabdeckung hat, aber keine CI/CD-Pipeline mitbringt.“

6. Entscheidung treffen und dokumentieren Architecture Decision Record

Und dann – das ist der Teil, der oft vernachlässigt wird – alles sauber in einem Architecture Decision Record (ADR) festhalten.

Das Architecture Decision Record: Gedächtnis der Architektur

Ein Architecture Decision Record (ADR) ist kein bürokratisches Dokument. Es ist das institutionelle Gedächtnis einer Entscheidung. Wer ein Jahr später fragt „Warum haben wir das damals so gemacht?“, bekommt eine Antwort – nicht ein Schulterzucken.

Meine Standard-Struktur für ein ADR:

Zum Thema Status: Verworfen ist kein Scheitern

Wenn sich Rahmenbedingungen ändern und eine alte Entscheidung überholt ist, erstelle ich keinen neuen Abschnitt im alten ADR. Ich erstelle einen neuen ADR, referenziere den alten in der Beschreibung, erkläre was sich verändert hat – und setze den alten ADR auf „Verworfen“, mit einem Link auf den Nachfolger.

So bleibt die Geschichte lesbar. Niemand stolpert versehentlich über einen veralteten ADR und hält ihn für gültig. Die Dokumentation folgt denselben Prinzipien wie gute Software: Versionierung statt Mutation.

Fazit: Der Prozess verändert das Ergebnis

Was ich nach vielen Architekturbewertungen sagen kann: Das Wertvollste an diesem Vorgehen ist nicht die Matrix am Ende. Es ist der gemeinsame Weg dorthin.

Wenn alle Beteiligten – Teams, Fachbereiche, Führung – gemeinsam Kriterien erarbeitet und gewichtet haben, dann gehört die Entscheidung allen. Nicht dem lautesten im Raum. Nicht dem ranghöchsten. Und wenn am Ende trotzdem jemand per Dekret entscheiden muss, dann zumindest auf einem sauberen, transparenten Fundament.

Das ist keine Garantie für die perfekte Entscheidung. Aber es ist die beste Grundlage, die wir haben.

Der Beitrag Architecture Decision Record & ISO 25010: Architekturbewertung ohne Bauchgefühl 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.

Was sind diese TH/s überhaupt?

TH/s steht für „Terahash pro Sekunde“ und ist die Maßeinheit für die Rechenleistung von Bitcoin-Minern. Um das zu verstehen, schauen wir uns die einzelnen Begriffe einzeln an:

Hash: Ein Hash ist das Ergebnis einer mathematischen Funktion, die eine Eingabe (wie Text oder Zahlen) in eine scheinbar zufällige Zeichenkette fester Länge umwandelt. Bitcoin-Miner müssen unzählige solcher Hash-Berechnungen durchführen, um neue Blöcke zu finden.

Tera: Das ist eine Maßeinheit für „Billion“ (1.000.000.000.000 oder 10^12). Ähnlich wie bei Gigabyte oder Terabyte bei Speicherplatz.

pro Sekunde: Wie viele dieser Hash-Berechnungen der Miner in einer Sekunde schafft.

Ein Miner mit 100 TH/s kann also 100 Billionen Hash-Berechnungen pro Sekunde durchführen. Das klingt nach unvorstellbar viel, aber Bitcoin-Mining ist so konzipiert, dass es extrem schwierig ist – selbst mit dieser enormen Rechenleistung dauert es im Durchschnitt etwa 10 Minuten, bis das gesamte Netzwerk einen neuen Block findet.

Je höher die TH/s-Zahl, desto leistungsfähiger ist der Miner und desto höher sind seine Chancen, beim Mining erfolgreich zu sein und Bitcoin als Belohnung zu erhalten. Moderne professionelle Mining-Geräte schaffen oft 100-200 TH/s oder mehr. Mein Antminer S19j Pro schafft, laut Hersteller, 104 TH/s bei 3.250 Watt …

Nicht lineare Effizienzentwicklung

Das verwendete Braiins OS bietet die Möglichkeit, die maximale Leistung, welche der Miner nutzen darf, zu begrenzen. Beim „Herumspielen“ mit den Einstellungen sind mir diverse Dinge aufgefallen. Unter anderem auch, dass die Effizenz des Miners stark von der bereitgestellten Leistung abhängig ist.

In mehreren Messreihen bestätigte sich das Bild, dass die beste Effizienz bei ca. 1.500 Watt besteht. Hierbei benötigt der Miner rund 23.5 Watt je TH/s was zu einem Ergebnis von 63,4 TH/s führt. Auch die Chip Temperatur ist hier total entspannt und mit 59 Grad absolut im grünen Bereich.

Effizienz im Bitcoin Mining – optimale Einstellung?

Neben der reinen Effizienz und dem „Jagen nach der höchsten Hashrate“ werfe ich das Thema Lebensdauer der Hardware noch mit ins Rennen. Die empfohlene Temperatur für den Antminer liegt bei 60 Grad, 70 Grad wird als hoch aber noch OK bewertet. Bei der maximalen Leistung geht die Temperatur in meinem Umfeld recht schnell an die Grenze. Dazu steigt die Leistung nur maginal.

Aus den obigen Gründen habe ich mich dazu entschieden, meine maximale Leistungseinstellung auf 2.800 Watt zu begrenzen. Hier sehe ich die optimale Balance aus Effizenz in Hinblick auf Wattverbrauch pro Hashrate sowie Schonung der Hardware.

Wie siehst Du das Thema? Wie läuft Dein Antminer und hast Du Dich bei der Einstellung mit dem Thema Effizienz beschäftigt oder geht es bei Dir nur um das Thema maximale Hashrate?

Der Beitrag Effizienz im Bitcoin Mining – wie viel Watt pro TH/s erschien zuerst auf Das ist die Welt von Thomas.

Grundausstattung – Zeitrafferkamera von Brinno

Angefangen hat alles mit der Suche nach der geeigneten Kameralösung. Wichtig war für mich, dass die Kamera möglichst wartungsfrei funktioniert und über einen langen Zeitraum Aufnahmen durchführt. Immerhin möchte ich nicht ständig bei meinem Nachbarn stehen um Batterien zu wechseln. Nach dem Lesen diverser Test- und Erfahrungsberichte habe ich mich dann für ein Modell der Firma Brinno entschieden. Ich habe die Brinno TLC200 Pro erworben, heute ist das Nachfolgermodell die Brinno TLC300 Pro eher das Modell der Wahl.

Die Kamera selbst ist sehr kompakt und steht in meinem Fall auf einem kleinen Stativ bei meinem Nachbarn auf der Fensterbank. Über eine integrierte SD Karte (in meinem Fall 32 GB) und den passenden Longlife Batterien nimmt die Kamera über einen Monat lang (zumindest in meinem Test) jeden Tag zwischen 8 und 18 Uhr alle 10 Minuten ein Foto auf. Die Aufnahmequalität habe ich, natürlich, auf die höchste Qualitätsstufe gestellt. Dazu habe ich festgelegt, dass die Kamera 1 Bild pro Sekunde für das Video verwendet. Dadurch ist das Video zwar recht lang, kann aber später immer noch schneller gemacht werden

Den monatlichen Besuch bei meinem Nachbarn (vielen Dank nochmal dafür) nutze ich, um die Daten der Speicherkarte zu sichern und neue Batterien einzusetzen.

Jetzt auf Amazon ansehen *

Problem: Einzelvideos kombinieren

Wie bereits beschrieben habe ich nun, je Wochentag, ein einzelnes Tagesvideo. Diese liegen alle in einem Ordner, die Dateinamen sind logisch aufgebaut und werden „einfach“ hochgezählt. Das heisst der erste Tag hat die Nummer 00000, der nächste 00001 usw. Nach einigen Tagen haben wir also viele Einzelvideos was erstmal schön aber nicht Sinn und Zweck der Sache ist. Um nun alle Einzelvideos zu einem zusammen schneiden zu können habe ich mich dem Tool FFMPEG bedient.

Als erstes muss FFMPEG heruntergeladen und entpackt werden. Als nächstes kopiere ich die Datei ‚ffmpeg.exe‘ in ein Verzeichnis in welches ich alle Einzelvideos lege. Um nun alle Videos zusammen fassen zu können benötige ich nun nur noch ein kleines Script welches hier mit dem Namen ‚combine.bat‘ dargestellt ist.

Im folgenden zuerst einmal das Script:

@echo off
setlocal enabledelayedexpansion

:: Ordner für beschleunigte Videos erstellen
set "FAST_FOLDER=fast_videos"
if not exist "%FAST_FOLDER%" mkdir "%FAST_FOLDER%"

:: Suche alle AVI-Dateien im aktuellen Ordner
echo Suche alle .avi-Dateien im aktuellen Verzeichnis...
for /f "delims=" %%A in ('dir /b /o:n *.avi') do (
    set "VIDEO=%%A"
    echo Verarbeitung von: !VIDEO!
    
    :: Überprüfen, ob die Datei existiert
    if exist "!VIDEO!" (
        set "BASENAME=!VIDEO:.avi=!"
        echo Ausgabe-Dateiname: %FAST_FOLDER%\!BASENAME!_fast.avi
        ffmpeg -i "!VIDEO!" -vf "setpts=PTS/5" -af "atempo=2.0,atempo=2.5" -c:v libx264 -preset slow -crf 18 "%FAST_FOLDER%\!BASENAME!_fast.avi"
    ) else (
        echo Fehler: Datei "!VIDEO!" wurde nicht gefunden. Überspringe...
    )
)

:: Schritt 2: Erstelle eine neue Liste der beschleunigten Videos
set "FAST_FILE_LIST=fast_file_list.txt"
echo Erstelle Liste der beschleunigten Videos...
if exist "%FAST_FILE_LIST%" del "%FAST_FILE_LIST%"
for %%B in ("%FAST_FOLDER%\*_fast.avi") do (
    echo file '%%~fB' >> "%FAST_FILE_LIST%"
)

:: Überprüfen, ob die Liste existiert
if not exist "%FAST_FILE_LIST%" (
    echo Fehler: Liste der beschleunigten Videos wurde nicht erstellt.
    pause
    exit /b 1
)

:: Schritt 3: Kombiniere die beschleunigten Videos
echo Kombiniere Videos...
ffmpeg -f concat -safe 0 -i "%FAST_FILE_LIST%" -c copy combined.avi

:: Überprüfen, ob die Kombination erfolgreich war
if exist "combined.avi" (
    echo Kombiniertes Video wurde erfolgreich erstellt: combined.avi
) else (
    echo Fehler beim Erstellen des kombinierten Videos.
)

pause

Das Script selbst führt folgende Schritte durch:

mehrere Videos zu einem Zusammenfassen – einfach und wiederholbar

Der Beitrag mehrere Videos zu einem Zusammenfassen – mit FFMPEG kein Problem erschien zuerst auf Das ist die Welt von Thomas.