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:xx:D0:xx:xx RSSI=-67
[I][ble_scan]: BOJE: 00:A0:xx:D0:xx:xx 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}
  on_boot:
    priority: -100           # läuft ganz am Ende, wenn WiFi/BLE-Stack initialisiert sind
    then:
      - delay: 5min
      - logger.log: "Initiale Messung 5 min nach Boot wird ausgelöst"
      - button.press: btn_measure

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 Advertising-Pakete verpasst (siehe Troubleshooting)
    active: true

globals:
  # Flag für "Messung wurde angefordert, aber BLE war nicht verbunden" — wird beim
  # nächsten on_connect abgearbeitet. Kein restore_value, damit nach Reboot kein
  # Geister-Trigger hängenbleibt.
  - id: pool_measure_pending
    type: bool
    restore_value: no
    initial_value: 'false'

interval:
  # Turnusmäßige Messung alle 4h. Feuert erstmals 4h nach Boot — die erste Messung
  # kurz nach dem Start übernimmt der on_boot-Trigger (siehe esphome:-Block).
  - interval: 4h
    then:
      - logger.log: "Turnusmäßige Messung (alle 4h) wird ausgelöst"
      - button.press: btn_measure

ble_client:
  - mac_address: "00:A0:50:D0:53:0F"   # MAC der Blue Connect GO Boje
    id: ble_client_pool
    on_connect:
      then:
        - logger.log: "BLE verbunden"
        - if:
            condition:
              lambda: 'return id(pool_measure_pending);'
            then:
              - logger.log: "Gequeuter Messung-Trigger wird jetzt gesendet"
              - delay: 500ms   # GATT braucht kurz nach Connect, sonst evtl. "not connected"-Race
              - ble_client.ble_write:
                  id: ble_client_pool
                  service_uuid: 'F3300001-F0A2-9B06-0C59-1BC4763B5C00'
                  characteristic_uuid: 'F3300002-F0A2-9B06-0C59-1BC4763B5C00'
                  value: [0x01]
              - lambda: 'id(pool_measure_pending) = false;'
    on_disconnect:
      then:
        - logger.log: "BLE getrennt"

button:
  - platform: template
    name: "${friendly_name} Messung auslösen"
    id: btn_measure   # von on_boot + interval angesprochen für Auto-Messungen
    on_press:
      then:
        # Pending-Flag-Logik: wenn BLE gerade verbunden → sofort schreiben.
        # Sonst Flag setzen, ble_client erledigt es beim nächsten on_connect.
        - if:
            condition:
              lambda: 'return id(ble_client_pool).connected();'
            then:
              - logger.log: "BLE verbunden — Messung sofort triggern"
              - ble_client.ble_write:
                  id: ble_client_pool
                  service_uuid: 'F3300001-F0A2-9B06-0C59-1BC4763B5C00'
                  characteristic_uuid: 'F3300002-F0A2-9B06-0C59-1BC4763B5C00'
                  value: [0x01]
            else:
              - logger.log: "BLE nicht verbunden — Messung wird beim nächsten Connect ausgeführt"
              - lambda: 'id(pool_measure_pending) = true;'
  - 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: "00:A0:xx:D0:xx:xx"   # gleiche MAC wie ble_client oben
    name: "${friendly_name} Boje BLE Signal"
    icon: mdi:signal-variant
    filters:
      - sliding_window_moving_average:   # glättet Ausreißer, ruhigerer Dashboard-Wert
          window_size: 5
          send_every: 1
      - heartbeat: 30s                    # mind. alle 30s einen Wert publizieren, auch ohne neues Paket

binary_sensor:
  - platform: template
    name: "${friendly_name} Boje verbunden"
    icon: mdi:bluetooth-connect
    lambda: 'return id(ble_client_pool).connected();'

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“).
• Eine initiale Messung direkt nach dem Start des ESPs wurde hinzugefügt
• Der ESP initiiert alle 4 Stunden automatisiert eine Messung so dass wir in jedem Fall Tagesverlaufswerte haben
• 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.

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.

openHab Zeitsteuerung über den Google Kalender?

OpenHab ist aus meiner Sicht ein echt einfaches System zur Heimautomatisierung. Wenn es allerdings um das Thema Zeitsteuerung geht ist hier wirklich Nachholbedarf. Es existiert keine einfache Möglichkeit um flexibel Geräte zu unterschiedlichen Zeiten mit eigenen Befehlen zu versorgen.

Durch den Einsatz des iCalendar Bindings und ein paar Zeilen Code ist es mir gelungen die Steuerung der Heizung über den Kalender umzusetzen.

Das Screenshot hier zeigt, wie der aktuelle Wochenplan aussieht. Im Gegensatz zu so manch andere Lösung die man im Internet so findet habe ich mich dafür entschieden nur Statusänderungen im Kalender zu hinterlegen und auf diese Events per Script zu reagieren.

Jeder Kalendereintrag steht also für eine gewünschte Änderung der Temperatur am Thermostat. Somit können flexibel alle Räume zu unterschiedlichen Zeiten nach meinen Wünschen gesteuert werden.

eigenen Kalender anlegen

Im ersten Schritt habe ich in meinem bestehenden Kalender einen neuen Kalender nur für die Steuerung meiner Heizung angelegt. Immerhin möchte ich die Einträge zur Steuerung nicht in meinem normalen Kalender sehen und getrennt verwalten. Dies funktioniert recht einfach über diesen Link.

Wir geben dem Kalender einen Namen, die gewünschte Zeitzone und speichern diesen. Für die Einbindung in das Binding benötigen wird nur die iCal Adresse. Hierfür gibt es im unteren Bereich eine „Privatadresse im iCal-Format“ welche über das entsprechende Kopieren-Icon in die Zwischenablage kopiert werden kann.

iCalendar Binding installieren und Kalender verbinden

Nachdem wir das iCalendar Binding in openHab installiert haben legen wir ein neues Item vom Typ „Kalender“ an. Dieses Binding dient den späteren Filtern als Gateway und stellt die Verbindung zwischen openHab und dem Kalender her.

Ins Feld ‚URL‘ tragen wir die URL ein, welche wir uns im vorherigen Schritt kopiert haben. Der Aktualisierungsintervall kann ruhig etwas länger sein, in meinem Fall sind es 30 Minuten. Dies bedeutet so viel wie dass das Plugin alle 30 Minuten nach neuen Terminen im Kalender schaut und diese herunterlädt.

Nach dem Speichern ist das Plugin auch schon fertig konfiguriert und die Kalendereinträge werden heruntergeladen.

Schön, doch was nun? Wir haben nun einen Google Kalender in welchen wir Termine einstellen können. Dazu ein Binding welches dafür sorgt, dass diese Termine nach openHab geladen werden. Damit nun die einzelnen Räume gesteuert werden müssen benötigen wir noch ein wenig Konfiguration für jeden einzelnen Raum …

openHab iCalendar Filter verwenden um Räume zu steuern

Um die Heizungssteuerung mit openHab umzusetzen habe ich mir im ersten Schritt Überlegt, wie ich meine Kalendereinträge gestalten möchte. Um es möglichst einfach zu halten habe ich mich dazu entschieden, je Verändungsevent einen Kalendereintrag zu erstellen. Wenn ich also z.B. im Büro die Heizung morgens um 6:30 Uhr auf 21 Grad stellen möchte und am Nachmittag um 17 Uhr wieder auf 17 Grad dann benötige ich hierfür 2 Kalendereinträge. Ich nutze hierbei den Titel des Kalendereintrages und hinterlege hier den Raum sowie die gewünschte Temperatur. Ein Eintrag mit dem Titel ‚Büro: 21‘ sorgt dafür, dass das Thermostat im Büro auf 21 Grad, ein Titel ‚Büro: 17‘ dass das Büro auf 17 Grad geändert wird.

Um die Kalendereinträge des eines Raumes in openHab verfügbar zu haben, habe ich mir je Raum ein Item vom Typ icalendar:eventfilter angelegt.

Der Filter selbst nutzt als Bridge das zuvor angelegte Item vom Typ „Kalender“. Die Anzahl Kalendereinträge habe ich mit 1 und den Aktualisierungsinterval mit 15 Minuten definiert. Der Filter selbst wurde als Textbasierter Filter auf Basis des Betreff / Title angelegt. Der Suchausdruck entspricht in meinem Fall dem Raumname, hier also ‚Büro‘ als Text.

Diese Konfiguration sorgt dafür, dass im neu angelegten Item 3 Channels angelegt werden. Diese Channels beinhalten die Daten des nächsten Kalendereintrages mit den Werte Startzeit, Endezeit und Titel.

Diese Channels lege ich mir als Points in meinem Model in den jeweiligen Raum. Das ist zwar nicht zwingend notwendig, erleichtert mir aber die Übersicht und die mögliche Fehlersuche.

Wichtig: An dieser Stelle unbedingt auf die Namensnotation achten. Das Script erwartet den Prefix ‚Calendar_Events__‘ gefolgt vom Raumname mit dem Suffix ‚_Titel‘ und ‚_Start‘.

Dieses Vorgehen muss nun für jeden Raum den ich steuern möchte dupliziert werden. Sprich für jeden Raum benötige ich einen eventfilter und die entsprechenden Points im Model damit das nachfolgende Script funktioniert.

Heizungssteuerung mit openHab – das Script

Nachdem die Vorarbeiten nun erledigt sind benötigt es noch ein kleines Script (Rule) welches die Werte der jeweiligen Räume abruft und die Änderungen an den Thermostaten durchführt. Ich habe mich hierbei für einen cronjob entschieden welcher jede Minute läuft und die Werte überprüft:

import java.time.format.DateTimeFormatter
import org.openhab.core.model.script.ScriptServiceUtil

rule "Heizungssteuerung - cron"
	when
		Time cron "5 * * * * ?"
	then
		val roomList = newArrayList('Buro', 'Wohnzimmer', 'Bad_EG', 'Kinderzimmer', 'Schlafzimmer', 'Kueche')
			
		roomList.forEach[ itemName |
			if (itemName != "") {
				var itemToManage = "Heizung__" + itemName + "_Set_Temperature"
				
				var calValue = "Calendar_Events__" + itemName + "_Titel"
				var calStart = "Calendar_Events__" + itemName + "_Start"
				
				var newValue = ScriptServiceUtil.getItemRegistry.getItem(calValue).getState.toString
				
				if (newValue != "UNDEF") {
					newValue = newValue.substring(newValue.indexOf(" ")).trim
					
					var currentValue = ScriptServiceUtil.getItemRegistry.getItem(itemToManage).getState.toString
					currentValue = currentValue.substring(0, currentValue.indexOf(" "))

					var currentStart = ScriptServiceUtil.getItemRegistry.getItem(calStart).getStateAs(DateTimeType).zonedDateTime.withZoneSameInstant((new DateTimeType).zonedDateTime.getZone).format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm"))

					if (currentStart.format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm")) == now.format(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm"))) {
						logInfo("Heizungssteuerung", "neue Temperatur " + itemToManage + "= " + newValue)
						sendCommand(itemToManage, newValue)
					} 
				}
			}			
		]
end

Das Script läuft alle 5 Minuten. Hierbei durchläuft es in einer Schleife alle definierten Räume und prüft, ob eine neue Temperatur eingestellt werden soll. Wichtig ist hierbei die bereits erwähnte Namensnotation der Items. Im ersten Schritt wird geprüft, ob ein neuer Wert eingestellt werden soll. Falls dies der Fall ist prüfen wir ob die aktuelle Uhrzeit der gewünschten Uhrzeit entspricht. Falls auch dieses Kriterium zutrifft setzen wir den entsprechenden Wert am Heizkörperthermostat über den sendCommand Befehl.

Zeisteuerung in openHab mit dem Google Calendar – Fazit

Anfangs dreht ich mich ein wenig im Kreis bis ich die Funktionen der einzelnen Bindings im Detail verstanden hatte und mich langsam dem gewünschten Ziel näherte. Inzwischen läuft die Heizungssteuerung mit openHab über die Homematic IP Komponenten sehr verlässlich. Durch die Planung über meinen Kalender kann ich quasi nebenbei die Zeitpläne von überall aus bearbeiten und bin sehr flexibel geworden.

Der Beitrag Heizungssteuerung mit openHab und Google Kalender automatisieren erschien zuerst auf Das ist die Welt von Thomas.

Was ist die Ausgangssituation?

Seit vielen Jahren betreibe ich eine Online Bildagentur welche Fotografen die Möglichkeit bietet Ihren Kunden Fotos (z.B. aus einem Kindergartenshooting) anzubieten. Hierzu laden die Fotografen die Fotos in Originalgröße hoch, der Endkunde kann diese bestellen und ich kümmere mich um die Bereitstellung der Downloads oder die Produktion der Bilder. Hier fallen viele Daten an welche bei mir auf diversen NAS-Systemen gespeichert werden. Gleichzeitig müssen zu diesem Zweck diverse Aufgaben erledigt werden, wofür ich einen eigenen Server in Betrieb haben.

Daneben habe ich natürlich auch noch „private“ Daten. Diese liegen auf einem weiteren NAS-System.

Die für die Bildagentur benötigten NAS-Systeme sind heute schon die meiste Zeit aus. Diese werden vom Server per Wake on Lan aktiviert sofern diese benötigt werden (also z.B. für eine Bestellproduktion). Nach der Produktion werden die NAS-Systeme über einen Shellbefehl heruntergefahren.

Der Server und das eigene NAS-System laufen jedoch aktuell jeden Tag und rund um die Uhr.

Green-IT doch wie?

In der Regel ist es so, dass die Bildagentur sich nachts langweilt. Also muss das System hier eigentlich gar nicht laufen. Einzig die zusätzlichen System wie Jira, Gitlab etc. werden ab und an mal gebraucht, das ist aber auch zu vernachlässigen. Also entschied ich mich, den Server zwischen 22 und 5 Uhr morgens zu deaktivieren. Gleiches soll mit dem NAS für die privaten Daten passieren. Die Frage ist nur, wie stelle ich das an?

Schritt 1: rtcwake für den Debian-Server

Eher durch Zufall bin ich auf ein Systemtool namens ‚rtcwake‘ gestossen. Dieses Standardwerkzeug ermöglicht es einen Debian-Server auzuschalten und, falls gewünscht, nach einer definierten Zeit wieder einzuschalten. Das Tool ‚rtcwake‘ ist ein fester Bestandteil des Standardpaketes ‚util-linux‘ welches eigentlich auf jedem System per Default installiert ist. Durch die Ausführung des folgenden Befehles fährt der Server herunter und startet 2 Minuten (120 Sekunden) nachdem dieser ausgeschaltet ist wieder.

sudo rtcwake -m off -s 120

Der Paramenter ‚-m‘ bestimmt ‚wie Tief‘ der Server in den Schlafmodus gehen soll. In meinem Fall entscheid ich mich für den ‚tiefsten‘ Wert ‚off‘. Eine genaue Aufstellung der einzelnen Optionen ist z.B. im Ubuntu Wiki zu finden.

Ich habe mich für einen Cronjob entschieden welcher jeden Tag um 22 Uhr läuft und den Server per ‚rtcwake‘ für 6,5 Stunden (also 23400 Sekunden) schlafen legt. Das funktioniert sehr zuverlässig.

Schritt 2: NAS-Systeme zeitgesteuert starten und stoppen

Von Natur aus bin ich eher ein Fauler Mensch und mag gewisse Routinen. Dazu gehört auch, dass ich mich mit der eingesetzten Technik auskennen und damit möglichst blind interagieren können möchte. Somit kommt bei den NAS-Systemen bei mir nur 1 Hersteller zum Einsatz was es einfacher macht bei der Suche nach „besonderen“ Lösungen. Bei den NAS-Systemen setze ich voll auf die Systeme von QNAP (TS-219* und TS-231*). Die Oberfläche von QNAP bietet bereits eine Möglichkeit eine Zeitsteuerung umzusetzen.

Im Bereich ‚System > Leistung‘ ist der Energiezeitplan zu finden. Hier kann definiert werden zu welchem Zeitpunkt ein NAS-System herunterfahren und wann es wieder gestartet werden soll. In meinem Fall sieht die Konfiguration wie folgt aus:

In meinem Fall fahre ich das NAS um 22:15 Uhr herunter und starte es um 4:50 Uhr morgens wieder. Gegen 5 Uhr starten die einzelnen Synchronisierungsdienste / Datensicherungen so dass die Systeme zur Verfügung stehen wenn diese benötigt werden und ’schlafen‘ wenn diese nicht benötigt sind.

Green-IT auch kleine Schritte helfen

Das Thema Green-IT ist ein recht umfangreiches Thema und geht weit über das Thema „Energiesparen“ hinaus. Ungenutzte Ressourcen zu betreiben ist absolut unnötig und verbraucht nicht nur Energie sondern belastet hierdurch auch den eigenen Geldbeutel. Ich für meinen Teil bin jetzt erstmal froh, dass Systeme die sich „langweilen“ nicht mehr laufen sondern nur dann Energiefressen wenn diese auch benötigt sind.

Der Beitrag Green-IT auch zuhause – Stromsparen durch Zeitsteuerung erschien zuerst auf Das ist die Welt von Thomas.

Das Grundsetup

Unsere Waschmaschine und auch unser Wäschetrockner stehen im Keller im Waschkeller. Wir befinden uns irgendwo im Haus (oder Garten) und hören selbige nicht. Wir bekommen also in der Regel nicht selbst mit, ob die Geräte fertig sind. Schön wäre es doch, wenn uns das Gerät selbst bescheid sagt, wenn es fertig ist, oder?

Hierfür analysiere ich den Stromverbrauch der jeweiligen Geräte. Ist das Gerät aktiv so ist der Stromverbrauch höher als im Ruhemodus. Also messen wir „einfach“ den Stromverbrauch und prüfen, ob dieser höher ist als der Ruhemodus. Befindet sich das Gerät längere Zeit im Ruhemodus so senden wir eine Benachrichtigung und schalten das Gerät aus.

Jetzt auf Amazon ansehen *

Jetzt auf Amazon ansehen *

Hierfür wurden beide Geräte über eine eigene smarte Steckdose mit Leistungsmessung* am Stromnetz angeschlossen. Hier habe ich mich für die Steckdosen von Homematic* entschieden. Dazu betreibe ich die Homematic CCU3 Zentrale* welche über das entsprechende Binding an meine auf dem Raspberry* betriebene OpenHAB Installation angebunden ist.

Pushsafer für Waschmaschine Statusupdate versenden – Scripte

Im ersten Schritt benötigen wir in OpenHAB unsere Steckdose als „Thing“. Diese habe ich mir in mein Modell des Hauswirtschaftsraumes gezogen und mit 3 Items angelegt:

• Current -> aktueller Stromverbrauch
• Energy Counter -> gesamter Stromverbrauch
• State -> Status (ein / aus)

Für die beschriebene Umsetzung wird der aktuelle Stromverbrauch sowie der Status benötigt. Hier aber zunächst mal das umgesetzte Script:

rule "HWR Waschmaschine - Energychange"
  when
    Item Strom__HWR__Waschmaschine_Current.state changed
  then
    val Number grenze = 50

    if((Strom__HWR__Waschmaschine_Current.state.state as DecimalType).intValue < grenze) {
      if (timerHwrWaschmaschine === null) {
        timerHwrWaschmaschine = createTimer(now.plusMinutes(2), [
          if((Strom__HWR__Waschmaschine_Current.state.state as DecimalType).intValue < grenze && Strom__HWR__Waschmaschine_State.state.toString == "ON") {
            logInfo("rules.automatic.hwr.wash", "Stromverbrauch länger als 2 Minuten unter Grenzwert - ausschalten")
            Strom__HWR__Waschmaschine_State.sendCommand(OFF)

            val actions = getActions("pushsafer", "pushsafer:pushsafer-account:gemeinsam")
            actions.sendPushsaferMessage("Homecontrol - HWR", "Waschmaschine ist aus")

            timerHwrWaschmaschine = null
          }
        ])
      }
    } else {
      timerHwrWaschmaschine?.cancel
      timerHwrWaschmaschine = null
    }
end

Das Rule ‚HWR Waschmaschine – Energychange‘ reagiert auf jede Änderung des Stromverbrauches des Items ‚Strom__HWR__Waschmaschine_Current‘ welches auf den aktuellen Stromverbrauch der Waschmaschine gemappt wurde. Bei jeder Änderung eines Wertes wird die Regel getriggert und führt den Code aus.

Im ersten Schritt lege ich eine Variable „grenze“ an welche den Schwellert definiert, ab wann das Gerät sich für mich im Ruhemodus befindet. Dieser Wert ist für jedes Gerät individuell und variiert. Bei meiner Waschmaschine liegt der Verbrauch im Ruhemodus unter 50 Watt. Diese Definition ist nicht zwingend notwendig, macht den Code aber einfach lesbarer.

Im nächsten Schritt prüfe ich, ob der aktuelle Stromverbrauch sich unterhalb der definierten Grenze liegt. Ist die der Fall so wird ein Timer gestartet welcher 2 Minuten lang läuft. Sind die 2 Minuten erreicht wird erneut geprüft ob der aktuelle Stromverbrauch weiterhin unterhalb der Grenze liegt und ob die Steckdose noch eingeschaltet ist. Ist dies der Fall senden wir die Pushsafer Notification über das entsprechend angelegte Binding und setzen den Timer wieder auf null.

Ist der aktuelle Stromverbrauch höher als die Grenze beenden wir eventuell laufende Timer und setzen selbige auf null.

Warum der Timer?

Die wenigsten Elektrogeräte haben über die Zeit hin immer den gleichen Stromverbrauch. In den ersten Versuchen habe ich die Waschmaschine regelmäßig während dem Betrieb ausgeschaltet da ich auf einen Timer verzichten wollte. Dummerweise ist es aber so, dass die Waschmaschine auch im normalen Betrieb irgendwann mal ansatzweise gar keinen Strom zieht. Kurz danach fährt der Stromverbrauch wieder hoch und die Maschine beginnt z.B. zu schleudern nachdem das Wasser abgepumpt wurde. Um diese Zeiten zu überbrücken wurde der Time umgesetzt. Wir warten also 2 Minuten lang bevor wir die Maschine abschalten. Springt der Stromverbrauch während dieser 2 Minuten wieder über die definierte Grenze so brechen wir den Timer ab. Nur wenn wir 2 Minuten den Stromverbrauch unterhalb der definierten Grenze haben ist die Arbeit für uns beendet und wir schalten die Maschine ab und senden die Benachrichtigung.

Pushsafer Notification für die Waschmaschine läuft verlässlich

Bei uns zuhause ist die hier beschriebene Lösung nun seit einiger Zeit im Einsatz. Sie läuft sehr verlässlich und informiert uns immer sobald die Arbeit beendet ist. Somit wissen wir wann wir die nächste Ladung Wäsche anstellen oder den Trockner befüllen können. Mit Sicherheit ist das hier keine Raketentechnik – sie erleichtert uns jedoch das Leben ein wenig

Wie sind eure Erfahrungen? Habt Ihr selbst auch eine solche Lösung umgesetzt, eine andere Lösung oder ist es euch total egal und Ihr wollt von euren Maschine nicht angeschrien werden?

Der Beitrag Pushsafer für Waschmaschine – sag mir bescheid wenn Du fertig bist erschien zuerst auf Das ist die Welt von Thomas.

Warum dieses Script?

Wie bereits aus anderen Beiträgen hier bekannt bin ich ein Freund des papierlosen Büros. Aus diesem Grund setze ich bei mir auf das DMS-System ecoDMS. Dies funktioniert auch wunderbar mit einer Ausnahme. EcoDMS bietet keinen Import von Mails an was für mich eine mittlere Katastrophe darstellt. Die meisten Rechnungen kommen inzwischen digital per PDF in meinen Posteingang. Diese möchte ich gerne an eine definierte E-Mail Adresse weiterleiten so dass der Import ins DMS automatisch erfolgen kann.

Wie funktioniert das Python 3 Script zum Downloaden von PDF-Anhängen?

Das Script selbst ist recht einfach. Es verbindet sich über die Python IMAP Library zu dem definierten Postfach. Dort wird in allen Mails geprüft, ob PDF-Anhänge vorliegen. Falls das der Fall ist wird der Anhang in das Zielverzeichnis von ecoDMS heruntergeladen. Anschliessend wird die Mail gelöscht.

In meinem Fall wird das Script mehrmals täglich über einen Cronjob ausgeführt. Die definierte Postfach-Adresse ist nur mir bekannt so kann ich Mails, welche einen Anhang beinhalten der ins DMS muss einfach dort hin weiterleiten.

E-Mail Anhänge nach ecoDMS importieren – das Script

Bevor das Script funktioniert muss noch die benötige Python-Library installiert werden. Dies erfolgt über den folgenden Befehl:

pip3 install imbox # alternativ auch pip install imbox

Anschliessen müssen noch die Parameter für den Hostname, Username und Passwort für das definierte Postfach hinterlegt werden. Schon kann das Script ausgeführt werden und tut was es soll (hoffentlich zumidnest).

#!/usr/bin/env python
"""
importDmsMailsPy3.py

Check emails at :const:`PROVIDER` for attachments and save them to
:const:`SAVEDIR`.
"""
import os
from imbox import Imbox #pip3 install imbox
import traceback

PROVIDER = 'XXXX'
USER = 'XXXX'
PASSWORD = 'XXXX'

SAVE_DIR = '/opt/ecodms/workdir/scaninput/'

def getNotExistingFileName(saveDir, srcFileName):
    counter = 1
    if (srcFileName.endswith("pdf?=")):
        srcFileName = "scanbymail.pdf"
    while (True):
        currentName = srcFileName
        if (counter > 1):
            currentName = str(counter) + "_" + srcFileName
        if (os.path.isfile(saveDir + currentName)):
            counter = counter + 1
        else:
            return currentName

def save_attachment(attachment):
    attachmentFileName = attachment.get('filename')
    print('Handle Attachment {0!r}.'.format(attachmentFileName))
    if attachmentFileName.endswith(("pdf", "PDF", "Pdf", "PDf", "pDF", "pdF", "PdF", "pdf?=")):
        targetName = attachmentFileName.replace("/", "_")
        targetName = getNotExistingFileName(SAVE_DIR, targetName)
        download_path = f"{SAVE_DIR}/{targetName}"
        with open(download_path, "wb") as download:
            download.write(attachment.get('content').read())
            print('Found and saved attachment {0!r}.'.format(targetName))

def main():
    try:
        mailBox = Imbox (PROVIDER, username=USER, password=PASSWORD, ssl=True, ssl_context=None, starttls=False)
        mailBoxContent = mailBox.messages()

        for (mailId, mail) in mailBoxContent:
            mailBox.mark_seen(mailId)

            for idx, attachment in enumerate(mail.attachments):
                try:
                    save_attachment(attachment)
                except:
                    print(traceback.print_exc())

            mailBox.delete(mailId)
    finally:
        mailBox.logout()

if __name__ == '__main__':
    main()

Anbei das Script noch als Download:

Vorsicht

Das Script löscht bei jedem Lauf ALLE Mails in dem Postfach. Bei der Verwendung bitte auf jeden Fall darauf achten, dass für den Import ein eigenes Postfach definiert ist in welchem nur die Mails vorliegen, welche ins DMS übergeben werden sollen.

Wer möchte kann das Script natürlich gerne verwenden und auf seine Bedürfnisse anpassen. Natürlich übernehme ich keine Garantie für die Funktion des Scriptes, die Verwendung erfolgt auf eigene Gefahr

Der Beitrag E-Mail Anhänge nach ecoDMS importieren – mit Python 3 erschien zuerst auf Das ist die Welt von Thomas.

Die Rahmendaten – Temperaturen im Whirlpool

Damit hier niemand Äpfel mit Birnen vergleicht ist es wichtig zu wissen, wie wir den Whirlpool verwenden. Die Heizkosten unterscheiden sich massiv je nach Aufstellungsort und den gewählten Temperaturen. Aus diesem Grund ist bei der Betrachtung dieser Auswertung immer im Hinterkopf zu behalten, dass unser Whirlpool nicht im freien, sondern in einem Wintergarten steht. Hier ist es nie unter 0 Grad, selbst im tiefsten Winter fallen die Temperaturen nicht unter 8 Grad.

Auch ist der Whirlpool nicht das gesamte Jahr auf Betriebstemperatur, sondern nur dann, wenn wir diesen auch nutzen möchten. Im täglichen Betrieb ist die Heizung auf 25 Grad eingestellt. Entscheiden wir den Whirlpool zu nutzen so stellen wir diesen nachmittags auf die gewünschten 38 Grad und heizen diesen entsprechend hoch. Dies spart, ebenso wie der Aufstellungsort, natürlich zusätzlich Energie.

Messung des Stromverbrauchs – FHEM das Mittel der Wahl

Wie bereits in diversen anderen Artikeln zu lesen setzen wir bei uns zuhause auf eine kleine Heimautomatisierung mittels FHEM. Der Whirlpool hängt hierbei an einer Steckdose mit Leistungsmessung welche den Stromverbrauch ständig kontrolliert und protokolliert. Mehr Details hierzu findest Du im Artikel „Stromverbrauch überwachen – mit FHEM kein Problem„.

Whirlpool Stromverbrauch über 12 Monate ausgewertet

Die Verbrauchsmessung ist nun etwas mehr als 12 Monate gelaufen. Der Auswertezeitraum beginnt am 1. Januar 2020 und endet am 31. Dezember 2020 und umfasst somit ein gesamtes Jahr.

Erwartungsgemäß ist zu Erkennen, dass der Energieverbrauch des Whirlpools in direktem Zusammenhang mit den Faktoren der Außentemperaturen und der Nutzungshäufigkeit. So ist der Verbrauch in kalten Monaten um einiges höher als z.B. im Hochsommer.

Den höchsten Stromverbrauch hatten wir in den Monaten Januar und Dezember mit jeweils etwas mehr als 200 kWh. Der niedrigste Verbrauch war im Sommer in den Monaten Juli und August mit einem Verbrauch von weniger als 50 kWh.

In dem in 2020 genutzten Stromtarif zahlten wir je kWh einen Betrag von 0,2506 EUR (Grundkosten sind hier nun mal ausgenommen). Wenn wir nun also den Verbrauch der einzelnen Monate zusammen rechnen so kommen wir auf einen Gesamtverbrauch von 1.483,25 kWh oder auch 371,70 EUR im Jahr.

hohe Kosten trotz Schutz im Wintergarten

Natürlich müssen wir unseren Bekannten rechtgeben welche sagen ein Whirlpool sei ein Stromfresser. Dass diese „Spaßinvestition“ kein günstiges Thema wird war uns von Anfang an klar. Allerdings hatten wir, nachdem wir uns bei diversen Firmen haben beraten lassen schon mit niedrigeren Kosten gerechnet, zumal der Whirlpool in einem kältegeschützten Wintergarten steht. Über den Daumen kommen wir jedoch noch immer auf Kosten von ~ 1 Euro pro Tag und das ist es uns dann doch wert

Dennoch würde mich wirklich einmal interessieren wie hoch die Stromverbrauchskosten wären, wenn der Whirlpool nicht im Wintergarten sondern, wie normalerweise angeraten, draußen im Garten stehen würde. Hat hier eventuell jemand Erfahrungen / Vergleichswerte?

Der Beitrag Whirlpool Stromverbrauch – Messung über 12 Monate erschien zuerst auf Das ist die Welt von Thomas.

Waschmaschine Statusmail wenn fertig mit der Arbeit

Das Konzept ist denkbar einfach. Wie bei vielen befinden sich unsere Waschmaschine und der Wäschetrockner in einem eigenen Raum im Keller. Wer dieses Konstrukt kennt der weiß, dass es echt nervig ist wenn man auf Wäsche wartet ständig in den Keller zu rennen um zu schauen ob diese fertig ist. „Warum nicht einfach den Stromverbrauch überwachen und erst dann in den Keller rennen wenn die Waschmaschine fertig ist?“ – diese Frage stellte ich mir.

Wie bereits über andere Beiträge hier in meinem Blog bekannt setze ich bei mir zuhause eine FHEM ein um kleine Dinge zu automatisieren. Hier wurde bereits eine Funktion zur Überwachung des Stromverbrauches unseres Whirlpools umgesetzt welche die ideale Basis für das hier vorliegende „Problem“ ist. Stattdessen der Stromverbrauch nun auf einem Dashboard angezeigt wird versenden wir einfach eine Mail sobald der Stromverbrauch für eine gewisse Zeit sinkt. Diese Mail geht an das Smartphone, wird hier per Push angezeigt und benachrichtigt und also sobald die Verbraucher Ihre Arbeit getan haben.

technische Voraussetzungen

Wie schon in dem verlinkten Artikel zur Überwachung des Stromverbrauches müssen einige technischen Voraussetzungen geschaffen sein damit das, was hier beschrieben ist, funktioniert. Zum ersten benötigen wir eine lauffähige FHEM Installation. Bei mir läuft diese auf einem Raspberry PI*. Damit die FHEM nun mit den Homematic Komponenten kommunizieren kann setze ich selbst auf das HM-MOD-RPI-PCB HomeMatic Funkmodul* welches einfach auf den PI aufgesteckt wird (Konfigurationsanleitung siehe Wiki). Zu eigentlichen Steuerung und Überwachung der zu messenden Geräte setze ich auf eine schaltbare Steckdose mit Leistungsmessung von Homematic*.

Jetzt auf Amazon ansehen *

Jetzt auf Amazon ansehen *

Jetzt auf Amazon ansehen *

Konfiguration in FHEM vornehmen

rename <DEVICE_ID>.channel_02 Strom.Waschmaschine.Pwr
define Strom.Waschmaschine.State dummy
define WaschmaschineHoherVerbrauchAn notify Strom.Waschmaschine.Pwr:power:.* PLATZHALTER
define WaschmaschineAutoStandby watchdog Strom.Waschmaschine.State:off 00:05 Strom.Waschmaschine.State:on PLATZHALTER

Im ersten Schritt benennen wir wieder den „channel_02“ der HomeMatic Steckdose, an welche die Waschmaschine angeschlossen ist in einen für uns sprechenden Namen um. In meinem Fall habe ich den Namen ‚Strom.Waschmaschine.Pwr‘ gewählt.

Nun legen wir uns einen Dummy an welcher den aktuellen Status der Waschmaschine abbildet. Dazu kommt ein Notify-Event welches den angelegten Status-Dummy in Abhängigkeit zum Stromverbrauch setzt. Ein zusätzlicher Watchdog erweitert das gesamte Bild und versendet die Mails, sofern notwendig.

Notify-Event – Auf Spannungsänderung reagieren

Über den Notify WaschmaschineHoherVerbrauchAn reagieren wir auf Änderungen im Stromverbrauch der Steckdose. Anbei die Definition des Notify-Events:

Strom.Waschmaschine.Pwr:power:.* {
  if (ReadingsNum("Strom.Waschmaschine.Pwr", "power", 0) > 15 && Value("Strom.Waschmaschine.State") eq "off") {
    fhem("set Strom.Waschmaschine.State on");
    fhem("setstate WaschmaschineAutoStandby defined");
  }
  if (ReadingsNum("Strom.Waschmaschine.Pwr", "power", 0) < 15 && Value("Strom.Waschmaschine.State") eq "on") {
    fhem("set Strom.Waschmaschine.State off");
  }
}

Das Event selbst wird getriggert sobald der Stromverbrauch der Steckdose sich ändert. Liegt der aktuelle Stromverbrauch über 15 Watt und der Status der Waschmaschine ist aus so wird der Status geändert.

Watchdog um Benachrichtigung auszulösen

Über den Watchdog WaschmaschineAutoStandby reagieren wir sobald der Status der Waschmaschine auf „off“ gesetzt wird, versenden die Mail und schalten die Steckdose selbst aus. Hier die Definition:

	
Strom.Waschmaschine.State:off 00:05 Strom.Waschmaschine.State:on {
  DebianMail('<empfänger>',"Waschmaschine / Trockner fertig","Die Waschmaschine oder der Trockner sind fertig - der Strom wurde ausgeschaltet");;
  fhem("set Strom.Waschmaschine off");
}

Der Watchdog selbst reagiert sofern der Dummy „Strom.Waschmaschine.State“ auf „off“ gesetzt wurde und 5 Minuten in diesem Status verblieben ist. Sobald der Status 5 Minuten auf „off“ war wird eine Mail an den definierten Empfänger gesendet und die Steckdose ausgeschaltet.

Waschmaschine Statusmail – Erfahrungen nach 2 Jahren

Wir haben die Lösung nun bereits seit ca. 2 Jahren bei uns im Einsatz. Anfangs gab es diverse Komplikationen so dass z.B. die Mails hundertfach versendet oder die Steckdose noch im laufenden Betrieb ausgeschaltet wurde. Die Scripte welche hier genannt sind laufen nun wunderbar rund und sind, aus meiner Sicht, fehlerfrei.

Ein wenig „kompliziert“ war der Punkt des „Notify-Events“ und der Grenze ab welcher die Waschmaschine „aus“ ist oder eben nicht. Diese senkt während dem Betrieb den Verbrauch hin und wieder stark nach unten. In unserem Fall liegt der minimale Verbrauch hier immer > 15 Watt (dies kann aber von Maschine zu Maschine unterschiedlich sein). Vermutlich wäre die Wartezeit der 5 Minuten im Watchdog heute nicht mehr notwendig, diese tut aber auch nicht weh

Der Beitrag Waschmaschine Statusmail selbstgebaut erschien zuerst auf Das ist die Welt von Thomas.

technische Voraussetzungen

Damit das, was ich hier nun beschreibe, funktioniert, müssen einige technische Voraussetzungen erfüllt sein. Zum ersten benötigen wir eine lauffähige FHEM Installation. Bei mir läuft diese auf einem Raspberry PI*. Damit die FHEM nun mit den Homematic Komponenten kommunizieren kann setze ich selbst auf das HM-MOD-RPI-PCB HomeMatic Funkmodul* welches einfach auf den PI aufgesteckt wird (Konfigurationsanleitung siehe Wiki). Zu eigentlichen Steuerung und Überwachung der zu messenden Geräte setze ich auf eine schaltbare Steckdose mit Leistungsmessung von Homematic*.

Jetzt auf Amazon ansehen *

Jetzt auf Amazon ansehen *

Jetzt auf Amazon ansehen *

Wie man nun eine FHEM installiert beschreibe ich hier nicht, dazu gibt es eine echt gute Anleitung im FHEM-Wiki. Sobald die Installation läuft, das HomeMatic Funkmodul eingerichtet und die Steckdose angelernt ist, kann es auch schon losgehen.

Stromverbrauch überwachen – Einrichtung der Channels

Die HomeMatic Funksteckdose verfügt insgesamt über 6 Channels welche alle unterschiedliche Informationen ausliefern. Der „channel_02“ ist, für die von uns geplante Überwachtung des Stromverbrauches, der Channel der Wahl. Ich habe diesen in meinem Fall erstmal umbenannt und diesem einen für mich sprechenden Namen gegeben:

rename <DEVICE_ID>.channel_02 <Zielname>
-> rename <DEVICE_ID>.channel_02 strom.whirlpool.pwr

Als nächstes schauen wir uns einmal die Readings von unserem neuen Device an und sehen, dass alle gewünschten Parameter direkt ersichtlich sind:

In meinem Fall liegt der aktuelle Stromverbrauch bei 5,19 Watt. Die Anzeige verändert sich, sobald das Gerät an der Steckdose seinen Verbrauch ändert. Schaltet sich nun als eine Pumpe oder die Heizung des Whirlpools ein, so schnellt der Stromverbrauch hoch und wir können erkennen was hier passiert.

Stromverbrauch protokollieren – Umleiten in Logfile

Damit wir den Verbrauch nun auswerten können benötigen wir ein Protokoll. Auch dies ist mit FHEM ein absolutes Kinderspiel, wir legen einfach ein neues Logfile an und lassen die gewünschten Werte dort rein protokollieren. Auch hier gibt die Commandref von Wiki wieder Hilfestellung. Der von mir genutzte Befehl hierzu lautete wie folgt:

define FileLog_Strom.Whirlpool.Verbrauch FileLog ./log/Strom.Whirlpool.Verbrauch-%Y-%m.log strom.whirlpool.pwr:eState:.*

Der Befehl erzeugt ein neues Logfile mit dem Namen ‚Strom.Whirlpool.Verbrauch-%Y-%m.log‘ wobei das %Y durch das aktuelle Jahr und das %m durch das aktuelle Monat ersetzt wird. Sobald sich nun der Stromverbrauch an der Funksteckdose ändert wird ein Eintrag in die neu angelegte Logdatei geschrieben. Das Ergebnis sieht nun ungefähr so aus:

Verbrauchskosten in Übersicht darstellen

Das nun angelegte Protokoll ist schonmal eine schöne Sache doch so richtig bringt uns das natürlich nicht weiter. Ich selbst wollte gerne auf einen Blick sehen wie hoch mein Stromverbrauch heute und im aktuellen Monat bisher so war.

Der Aufbau dieser Anzeige war nicht ganz so trivial und benötigte neben 2 Dummys zur Anzeige auch noch einen AT-Trigger welche jede Minute in das Logfile schaut und den aktuellen Wert berechnet.

Legen wir uns zuerst einmal die benötigten Dummys und den leeren AT-Trigger an.

define WhirlpoolStromkostenTag dummy
define WhirlpoolStromkostenMonat dummy
define atWhirlpoolStromkosten at +*00:01:00 test

Nun ist noch nicht viel passiert. Wir haben 2 leere Dummys für die Stromkosten des Tages und des Monates und einen AT welcher jede Minute läuft und das Command „test“ ausführt.

Das Command ist natürlich noch absoluter Quatsch und muss „leicht“ angepasst werden. Wir öffnen selbiges, klicken auf „DEF“ und tragen hier folgendes Command ein:

+*00:01:00 {
my $oldVerbrauchVortag = (ReadingsVal("WhirlpoolStromkostenTag","VerbrauchVortag",0)); 
my $neuerVerbrauch = (ReadingsVal("strom.whirlpool.pwr","energy",0)); 
my $a = ($neuerVerbrauch / 1000) - $oldVerbrauchVortag;
fhem("setreading WhirlpoolStromkostenTag Verbrauch $a");
fhem("setreading WhirlpoolStromkostenMonat Tagesverbrauch $a");
if(($hour==0) && ($min==0)){ 
  my $neuerVortagesverbrauch = $oldVerbrauchVortag + $a; 
  fhem("setreading WhirlpoolStromkostenTag VerbrauchVortag $neuerVortagesverbrauch ");
  fhem("setreading WhirlpoolStromkostenTag Verbrauch 0")
} 
if(($hour==0) && ($min==0) && ($mday==1)){
  fhem("setreading WhirlpoolStromkostenMonat Verbrauch 0")
}
}

Stromverbrauch überwachen – was tut das Script?

Im Grunde genommen ist das Script recht einfach. Der Dummy für den Tagesverbrauch bekommt ein zusätzliches Reading für den Verbrauch des Vortages sowie den aktuellen Verbrauch. Wir lesen zuerst den Vortagesverbrauch und anschliessend den aktuellen Verbrauch aus und berechnen nun den aktuellen Verbrauch welchen wir sowohl in das Tages als auch das Monatsreading setzen.

Ist es gerade 0 Uhr so setzen wir den Vortagesverbrauch auf 0, gleiches tun wir beim Monatsreading am Start eines neuen Monates.

Stromverbrauch in lesbarer Form anzeigen

Somit verfügen die einzelnen Dummys nun also über den aktuellen Stromverbrauch (je Einheit) in KW. Was nun noch fehlt ist die Anzeige und die „Übersetzung“ in die realen Kosten. Dies kann über die Attribute der jeweiligen Dummys angepasst werden.

attr WhirlpoolStromkostenTag stateFormat {sprintf("%.2f kWh - %.2f €",ReadingsVal("WhirlpoolStromkostenTag", "Verbrauch",0), ReadingsVal("WhirlpoolStromkostenTag","Kosten",0))}
attr WhirlpoolStromkostenTag userReadings Kosten {ReadingsVal("WhirlpoolStromkostenTag","Verbrauch",0)*0.2507}

attr WhirlpoolStromkostenMonat stateFormat {sprintf("%.2f kWh - %.2f €",ReadingsVal("WhirlpoolStromkostenMonat", "Verbrauch",0), ReadingsVal("WhirlpoolStromkostenMonat","Kosten",0))}
attr WhirlpoolStromkostenMonat userReadings Verbrauch monotonic {ReadingsVal("WhirlpoolStromkostenMonat","Tagesverbrauch",0)},Kosten {ReadingsVal("WhirlpoolStromkostenMonat","Verbrauch",0)*0.2507}

Das Ergebnis ist in diesem Post bereits einmal vorweg genommen worden. Wir erhalten eine Anzeige des aktuellen Tagesverbrauches sowie des Verbrauches im aktuellen Monat. Hierbei gehen wir davon aus dass die KWh bei 0.2507 EUR liegt.

Natürlich ist es ohne weiteres Möglich diese Auswertung auch noch auf Monats- oder Jahresbasis durchzuführen oder die Verbräuche in einem Diagram anzuzeigen. Hier sind den eigenen Wünschen und Ideen fast keine Grenzen gesetzt.

Der Beitrag Stromverbrauch überwachen – mit FHEM kein Problem erschien zuerst auf Das ist die Welt von Thomas.

Archivierung von Rechnungen aus E-Mails

Egal wo man heute etwas bestellt, meist kommen die Rechnungen in elektronischer Form. Doch wie kann ich diese Rechnungen nun am Einfachsten in meinem DMS-System archivieren? Eigentlich ging ich davon aus dass ein System wie z.B. ecoDMS ein solches E-Mail Gateway automatisiert mitliefert, leider war dies jedoch nicht der Fall.

Somit musste eine eigene Lösung her. Kein Problem, ein kleines Script sollte das Problem schnell Lösen. Die Grundidee: Ich erzeuge mir ein Mailpostfach an welches ich alle E-Mails, deren PDF-Anhänge archiviert werden sollen weiterleite. Dieses Postfach wird von einem Cronjob abgeholt, die PDF-Anhänge aus den Mails heruntergeladen und in den Übergabeordner von ecoDMS gelegt.

Nach einigen Versuchen ist das folgende Python-Script entstanden welches bei mir nun schon seit über 2 Jahren produktiv im Einsatz ist und stabil seinen Dienst verrichtet.

E-Mail PDF-Anhang speichern – Python-Script

#!/usr/bin/env python
"""
importDmsMails.py

Check emails at :const:`PROVIDER` for attachments and save them to
:const:`SAVEDIR`.
"""
from __future__ import absolute_import, division, print_function
import email
import os
import poplib

PROVIDER = 'XXXX'
USER = 'XXXX'
PASSWORD = 'XXXX'

SAVE_DIR = '/opt/ecodms/workdir/scaninput/'

def getNotExistingFileName(saveDir, srcFileName):
    counter = 1
    if (srcFileName.endswith("pdf?=")):
        srcFileName = "scanbymail.pdf"
    while (True):
        currentName = srcFileName
        if (counter > 1):
            currentName = str(counter) + "_" + srcFileName
        if (os.path.isfile(saveDir + currentName)):
            counter = counter + 1
        else:
            return currentName

def save_attachments(mail_string):
    attachments = list()
    for part in email.message_from_string(mail_string).walk():
        name = part.get_filename()
        if name:
            print('Handle Attachment {0!r}.'.format(name))
            if name.lower().endswith(("pdf", "pdf?=")):
                data = part.get_payload(decode=True)
                name = name.replace("/", "_")
                targetFileName = getNotExistingFileName(SAVE_DIR, name)
                f = file(os.path.join(SAVE_DIR, targetFileName), 'wb')
                f.write(data)
                f.close()
                print('Found and saved attachment {0!r}.'.format(targetFileName))

def main():
    try:
        client = poplib.POP3_SSL(PROVIDER)
        client.user(USER)
        client.pass_(PASSWORD)
        message_numbers = (int(s.split()[0]) for s in client.list()[1])
        for message_number in message_numbers:
            save_attachments('\n'.join(client.retr(message_number)[1]))
            client.dele(message_number)
    finally:
        client.quit()


if __name__ == '__main__':
    main()

Was genau tut das Script?

Das hier aufgeführte Python-Script wird bei mir regelmäßig durch einen Cronjob ausgeführt. Das Script verbindet sich zu meinem Mailserver und lädt sich alle Mails herunter. Hängt an einer Mail ein PDF-Anhang so wird dieser Anhang im Eingangsverzeichnis von ecoDMS gesichert. Bei der Speicherung der Datei prüft das Script ob hier bereits eine Datei mit gleichem Namen vorliegt. Ist dies der Fall so wird der Dateiname durch einen Zähler erweitert so dass keine bereits existierende Datei überschrieben wird.

Wer möchte kann das Script natürlich gerne verwenden und auf seine Bedürfnisse anpassen. Natürlich übernehme ich keine Garantie für die Funktion des Scriptes, die Verwendung erfolgt auf eigene Gefahr

Update – 11. Juni 2021

Ich habe gestern eine Mail erhalten welche mich auf ein Problem hinwies. Thomas erhielt beim Ausführen des Scriptes den folgenden Fehler:

python3 importDmsMails.py
Traceback (most recent call last):

  File "importDmsMails.py", line 61, in <module>

    main()

  File "importDmsMails.py", line 54, in main

    save_attachments('\n'.join(client.retr(message_number)[1]))

TypeError: sequence item 0: expected str instance, bytes found

Bei der Analyse der Meldung stellte sich heraus, dass ich eine andere Python-Version als Thomas verwende. Bei mir läuft Python in der Version 2.7.10, bei ihm auf Python 3.

Ich habe für dieses Problem eine neue Version des Scriptes bereit gestellt. Mehr dazu findet Ihr hier:
E-Mail Anhänge nach ecoDMS importieren – mit Python 3

Der Beitrag E-Mail PDF-Anhang speichern – Python-Script für ecoDMS Übergabe erschien zuerst auf Das ist die Welt von Thomas.