Beta-Test: Power-Splitter zur Berechnung der Autarkie je Verbraucher

[ledermann]

Derzeitig befindet sich ein neues Feature in der Entwicklung (Details und Screenshots in #2436), das den Stromverbrauch großer Verbraucher (E-Auto, Wärmepumpe, Haus) genauer analysiert. Der gemessene Verbrauch wird aufgeteilt in den Anteil, der mit Photovoltaik-Strom gedeckt wird und den Anteil, der aus dem Netz bezogen wird. Daraus ergeben sich interessante Einblicke in die Verbrauchskosten, die bisher so nicht möglich waren.

Das Feature ist seit einiger Zeit in der Live-Demo zu sehen. Nun möchte ich interessierten Nutzern die Möglichkeit geben, das auch selbst mit den eigenen Daten auszuprobieren.

Zunächst ein paar wichtige Hinweise:

• Der Power-Splitter ergibt nur Sinn, wenn man ein E-Auto und/oder eine Wärmepumpe hat (also nicht zwingend beides) und erfolgreich an SOLECTRUS angebunden hat. Wer also beides nicht hat, für den ist es uninteressant, weil es dann nichts aufzuteilen gibt.

• Die Berechnung erfolgt für sämtliche Verbrauchswerte von Wärmepumpe und/oder E-Auto, die in der InfluxDB vorhanden sind. Das bedeutet, dass nicht nur zukünftige Messwerte, sondern auch die Messwerte der Vergangenheit berücksichtigt werden.

• Für die Berechnung kommt ein neuer Docker-Container (der eigentliche "Power-Splitter") zum Einsatz. Dieser läuft permanent im Hintergrund, berechnet die Aufteilung und schreibt sie in ein neues Measurement der InfluxDB.

• Es ist während der Testphase sinnvoll, dass Watchtower bei dir installiert ist, damit die Docker-Container automatisch aktualisiert werden. SOLECTRUS und der Power-Splitter werden in der nächsten Zeit vermutlich recht häufig aktualisiert. Es wäre mühsam, Updates manuell zu installieren.

• Ich plane, das Feature nach Fertigstellung nur für Sponsoren freizuschalten. Details hierzu folgen noch. Während des Beta-Tests steht es aber allen Testern kostenfrei zur Verfügung.

Okay, genug der Vorrede. Hier die erforderlichen Schritte zur Inbetriebnahme:

Anleitung

1. Stelle sicher, dass du ein E-Auto und/oder eine Wärmepumpe an SOLECTRUS angebunden hast. Deren Messwerte müssen also in deiner SOLECTRUS-Instanz sichtbar sein.

2. Prüfe, ob die neue Sensor-Konfiguration bei dir vorhanden ist. Das ist der Fall, wenn du zur Installation den neuen Konfigurator verwendet hast. Wenn du schon länger mit dabei ist, hast du vermutlich noch die alte Konfiguration (von Version 0.14.5 oder früher), das muss vorher angepasst werden.

   Das bedeutet: Beim Start der Docker-Container von SOLECTRUS dürfen keine Warnungen bezüglich fehlender Sensoren im Log erscheinen. Falls doch, müssen diese zunächst behoben werden. Im Log steht genau, wie das geht.

   Es müssen also folgende ENV-Variablen (mit Werten) in der .env-Datei enthalten sein:

   • INFLUX_SENSOR_GRID_IMPORT_POWER
   • INFLUX_SENSOR_HOUSE_POWER
   • INFLUX_SENSOR_WALLBOX_POWER und/oder INFLUX_SENSOR_HEATPUMP_POWER

   Üblicherweise gibt es weitere Sensoren in der .env, die sind für den Power-Splitter aber nicht relevant.

3. Wechsele in der docker-compose.yml (oder compose.yml) für das Dashboard von latest (oder develop) auf das Docker-Tag pr-3160:

   services:
     dashboard:
       image: ghcr.io/solectrus/solectrus:pr-3160
     # ...

   Ältere Installationen verwenden noch den Namen app statt dashboard.

4. Starte die App jetzt neu mit docker compose up -d. Das sollte fehlerfrei gelingen, auch wenn die Anzeige noch unverändert sein wird. Falls es Probleme geben sollte, behebe diese zuerst. Schaue dazu unbedingt ins Log:

   docker compose logs dashboard -f (kann beendet werden mit Strg+C)

5. Jetzt kommt der wichtigste Punkt: Bearbeite die docker-compose.yml (oder compose.yml) erneut und ergänze den Power-Splitter als zusätzlichen Service. Achte unbedingt (!) auf die richtige Einrückung mit Leerzeichen.

   services:
     # ...
     power-splitter:
       image: ghcr.io/solectrus/power-splitter:develop
       labels:
         - com.centurylinklabs.watchtower.scope=solectrus
       environment:
         - TZ
         - INFLUX_HOST
         - INFLUX_SCHEMA
         - INFLUX_TOKEN=${INFLUX_ADMIN_TOKEN}
         - INFLUX_PORT
         - INFLUX_ORG
         - INFLUX_BUCKET
         - INFLUX_SENSOR_GRID_IMPORT_POWER
         - INFLUX_SENSOR_HOUSE_POWER
         - INFLUX_SENSOR_WALLBOX_POWER
         - INFLUX_SENSOR_HEATPUMP_POWER
         - INFLUX_EXCLUDE_FROM_HOUSE_POWER
         - POWER_SPLITTER_INTERVAL
         - REDIS_URL=redis://redis:6379/1
       links:
         - influxdb
         - redis
       depends_on:
         influxdb:
           condition: service_healthy
         redis:
           condition: service_healthy
       restart: unless-stopped

   Der Power-Splitter liest aus der InfluxDB die Messwerte der Verbraucher sowie des Netzbezugs und schreibt die Aufteilung in ein neues Measurement mit der konstanten Bezeichnung power_splitter.

   Wichtig beim INFLUX_TOKEN ist, dass dieses sowohl zum Schreiben als auch zum Lesen berechtigt. Du kannst das Admin-Token nehmen (wie oben angegeben) oder selbst ein neues Token im InfluxDB-Frontend anlegen (letzteres lohnt sich aber nur für Security-Freaks).

   Die REDIS_URL wird benötigt, um nach dem ersten Durchlauf einmalig den Cache leeren zu können.

   Wenn du eine verteilte Installation betreibst (Lokal + Cloud), solltest du den Service auf dem Cloud-Host installieren - also da, wo die InfluxDB läuft. Das reduziert den Traffic.

6. Starte die Container erneut mit docker compose up -d, diesmal wird der Power-Splitter mit gestartet.

   Wenn sich die Container gar nicht starten lassen sollten, hast du vermutlich den Service nicht richtig in die docker-compose.yml (oder compose.yml) eingefügt. Prüfe insbesondere die Einrückung, das ist bei YAML-Dateien äußerst wichtig.

   Verfolge nun die Log-Ausgabe des neuen Containers mit folgendem Befehl:
   docker compose logs power-splitter -f (kann beendet werden mit Strg+C)

   Wenn du irgendwelche Fehlermeldungen siehst, kümmere dich zunächst darum, bevor du fortfährst.

   Wenn alles fehlerfrei läuft, wird der Power-Splitter zunächst die Daten der Vergangenheit bearbeiten, anschließend im Hintergrund weiterlaufen und jeweils den aktuellen Tag berechnen. Dies lässt sich alles genau im Log nachvollziehen. Ich empfehle sehr, das zu tun. Nach einer gewissen Zeit (abhängig von Rechenpower und Datenmenge) wird die Berechnung der Vergangenheit abgeschlossen sein.

Geschafft :-) Wenn du in SOLECTRUS jetzt einen Zeitraum auswählst (Tag/Woche/Monat/Jahr/Gesamt), siehst du bei Haus, E-Auto und Wärmepumpe (sofern vorhanden) jeweils im Tooltip die Aufteilung des Verbrauchs. Außerdem erscheinen deren Diagramme in einer gestapelten Darstellung. Viel Spaß beim Ausprobieren!

Feedback erwünscht

Falls Probleme bei der Inbetriebnahme auftreten, helfe ich gerne weiter. Da dazu vermutlich jeweils die Konfiguration der .env und der docker-compose.yml diskutiert werden muss, bitte ich in solchen Fällen darum, jeweils ein neues Issue anzulegen, also nicht einfach hier drunter zu kommentieren. Auch Fragen zur Umstellung auf die neue Sensor-Konfiguration sind in einem separaten Issue sicher gut aufgehoben.

Ansonsten bin ich gespannt auf Euer Feedback! :-)

[StevieC121176]

Super, da bin ich gespannt. Ich habe ja noch eine sehr alte Konfiguration. Ich würde ihr gerne ein komplett neues Solectrus aufsetzen über den Konfigurator um alle neuen Variablen tz haben und dann meine alte Datenbank benutzen. Wäre das möglich?

[ledermann]

Ja, grundsätzlich ist das möglich, aber knifflig, siehe zum Beispiel hier:
solectrus/mqtt-collector#204

Du kannst es versuchen, musst aber gut aufpassen, mit den Measurements und Fields nicht durcheinander zu kommen.

Meine Empfehlung ist daher, den Konfigurator nicht für Updates zu benutzen. Eine bestehende Installation sollte besser anhand der Hinweise im Log angepasst werden. Das Dashboard und der MQTT-Collector geben beim Start im Log präzise Hinweise, was man ändern muss. Das ist der einfachste und sicherste Weg zur neuen Sensor-Konfiguration.

Ansonsten nochmal der Hinweis zum Wiki-Artikel:
https://github.com/solectrus/solectrus/wiki/Umstellung-auf-neue-Sensor%E2%80%90Konfiguration

[StevieC121176]

ok, dann doch lieber die Anpassung. Ich soll laut log noch folgendes Anpassen (MQTT Collector)

mqtt-collector-1      |   MAPPING_0_TOPIC=evcc/site/gridPower
mqtt-collector-1      |   MAPPING_0_FIELD_POSITIVE=grid_power_plus
mqtt-collector-1      |   MAPPING_0_FIELD_NEGATIVE=grid_power_minus
mqtt-collector-1      |   MAPPING_0_MEASUREMENT_POSITIVE=my-pv-measurement
mqtt-collector-1      |   MAPPING_0_MEASUREMENT_NEGATIVE=my-pv-measurement
mqtt-collector-1      |   MAPPING_0_TYPE=integer
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_BAT_FUEL_CHARGE is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_1_TOPIC=evcc/site/batterySoc
mqtt-collector-1      |   MAPPING_1_FIELD=bat_fuel_charge
mqtt-collector-1      |   MAPPING_1_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_1_TYPE=float
mqtt-collector-1      | 
mqtt-collector-1      | Variables MQTT_TOPIC_BAT_POWER and MQTT_FLIP_BAT_POWER are deprecated. To remove this warning, please replace the variables by:
mqtt-collector-1      |   MAPPING_2_TOPIC=evcc/site/batteryPower
mqtt-collector-1      |   MAPPING_2_FIELD_POSITIVE=bat_power_minus
mqtt-collector-1      |   MAPPING_2_FIELD_NEGATIVE=bat_power_plus
mqtt-collector-1      |   MAPPING_2_MEASUREMENT_POSITIVE=my-pv-measurement
mqtt-collector-1      |   MAPPING_2_MEASUREMENT_NEGATIVE=my-pv-measurement
mqtt-collector-1      |   MAPPING_2_TYPE=integer
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_CASE_TEMP is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_3_TOPIC=Solectrus/bydhvs/0/State/TempBatt
mqtt-collector-1      |   MAPPING_3_FIELD=case_temp
mqtt-collector-1      |   MAPPING_3_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_3_TYPE=float
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_CURRENT_STATE is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_4_TOPIC=Solectrus/0 userdata/0/Solar/Status Wechselrichter/Status Wechselrichter
mqtt-collector-1      |   MAPPING_4_FIELD=current_state
mqtt-collector-1      |   MAPPING_4_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_4_TYPE=string
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_MPP1_POWER is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_5_TOPIC=evcc/site/pv/1/Power
mqtt-collector-1      |   MAPPING_5_FIELD=mpp1_power
mqtt-collector-1      |   MAPPING_5_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_5_TYPE=integer
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_MPP2_POWER is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_6_TOPIC=evcc/site/pv/2/Power
mqtt-collector-1      |   MAPPING_6_FIELD=mpp2_power
mqtt-collector-1      |   MAPPING_6_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_6_TYPE=integer
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_MPP3_POWER is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_7_TOPIC=evcc/site/pv/3/Power
mqtt-collector-1      |   MAPPING_7_FIELD=mpp3_power
mqtt-collector-1      |   MAPPING_7_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_7_TYPE=integer
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_INVERTER_POWER is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_8_TOPIC=evcc/site/pvPower
mqtt-collector-1      |   MAPPING_8_FIELD=inverter_power
mqtt-collector-1      |   MAPPING_8_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_8_TYPE=integer
mqtt-collector-1      | 
mqtt-collector-1      | Variable MQTT_TOPIC_WALLBOX_CHARGE_POWER is deprecated. To remove this warning, please replace the variable by:
mqtt-collector-1      |   MAPPING_9_TOPIC=evcc/loadpoints/1/chargePower
mqtt-collector-1      |   MAPPING_9_FIELD=wallbox_charge_power
mqtt-collector-1      |   MAPPING_9_MEASUREMENT=my-pv-measurement
mqtt-collector-1      |   MAPPING_9_TYPE=integer
mqtt-collector-1      | 

nach der Anpassung der .env habe ich folgenden Fehler bekommen:

mqtt-collector-1      | MQTT collector for SOLECTRUS, Version 0.2.1, built at 2024-07-28T04:38:29.111Z
mqtt-collector-1      | https://github.com/solectrus/mqtt-collector
mqtt-collector-1      | Copyright (c) 2023-2024 Georg Ledermann and contributors, released under the MIT License
mqtt-collector-1      | 
mqtt-collector-1      | Using Ruby 3.3.4 on platform aarch64-linux-musl
mqtt-collector-1      | Subscribing from MQTT broker at mqtt://192.168.178.80:1883
mqtt-collector-1      | Pushing to InfluxDB at http://influxdb:8086/, bucket solectrus
mqtt-collector-1      | 
mqtt-collector-1      | No mappings defined - exiting.
mqtt-collector-1 exited with code 1```

[ledermann]

Hier liegt es vermutlich daran, dass in der docker-compose.yml die Variablen MAPPING_* nicht unter environment aufgeführt werden, der Container also gar keinen Zugriff darauf erhält. Die (lange) Liste der Variablen musst du dort ergänzen.

Falls die Probleme anhalten, besser ein separates Issue anlegen, hier führt das sonst zu weit vom Thema ab.

[frizzle0815]

Tolle Sache! Bevor ich es in der Live Demo gesehen habe, wusste ich gar nicht, dass ich sowas brauchen könnte, aber das Ganze wertet die Auswertungen doch enorm auf!

Ich habe den Power Splitter problemlos in den zwei von mir betriebenen Instanzen zum Laufen bekommen. Alle historischen Daten wurden innerhalb kürzester Zeit abgearbeitet ohne Fehlermeldungen.

Ein Hinweis: In deiner Anleitung unter 5. fehlt glaube ich in der docker-compose.yml das Watchtower label, wenn sich der Container selbständig aktualisieren soll.

[ledermann]

Sehr gut, freut mich, dass es klappt! Und dass es nützlich ist :)

Das Watchtower-Label fehlt tatsächlich, das habe ich gerade oben ergänzt. Danke für den Hinweis!

[halmich]

Hey Georg,
Anleitung ist super, scheint alles gut zu funktionieren bisher. Logs sind fehlerfrei.
Der Power Splitter lädt gerade die historischen Daten in die influxDB. Das geht bei mir noch ca. 25 Minuten ;-) Er arbeitet ab 2021 an (was etwas unnötig ist, da sowohl Wärmepumpe als auch Wallbox erst Anfang 2024 in Solectrus integriert sind), aber er arbeitet.
Ich denke ab spätestens 21.30 uhr kannst du in meiner Instanz schauen, ob alles läuft :)
Viele Grüße, Michael

Update: So, ist durchgelaufen.
Sieht echt super aus! Werte scheinen stimmig und es macht echt was her.
Schade, dass ich erst ab Mai, bzw. Juni die Wärmepumpe/ E-Auto in den Daten haben. Bin gespannt, wie das ganze dann im Dezember aussieht :)

[ledermann]

Top, das freut mich! :)

[norbertle]

Was ich spannend finde ist das das auch für den Hausverbrauch erfolgt.
Das ist in dem Fall für mich interessant, weil wir das Warmwasser/Dusche über 11kW Durchlauferhitzer erzeugen. Und da kann ja der Speicher kurzfristig nicht so viel zur Verfügung stellen und es kommt zum Speicher / Netzbezug Mischbetrieb.
In der Demo sehe ich auf jeden Fall auch dort die Aufteilung auf Netz und Photovoltaik.

[ledermann]

In der Live-Demo ist es so, dass es Wärmepumpe und E-Auto gibt. Somit erfolgt eine Aufteilung für insgesamt drei große Verbraucher:

• Wärmepumpe
• E-Auto
• Hausverbrauch (also Rest)

Hat man hingegen keine Wärmepumpe und auch kein E-Auto, macht der Power-Splitter zwar auch eine Aufteilung, diese entspricht dann aber der bereits vorhandenen Autarkie-Ermittlung. Man hat also nichts gewonnen.

Hier ein Beispiel aus der Live-Demo zu einem Tag, wo das Auto nicht geladen wurde und die Wärmepumpe noch gar nicht existierte. Da wird beim Hausverbrauch angezeigt, dass 64% des Stromverbrauchs aus Photovoltaik kam. Diese Zahl steht aber bereits im Autarkie-Badge:

Falls du für deinen Durchlauferhitzer separate Verbrauchswerte abfragen kannst, könntest du diesen in SOLECTRUS per MQTT integrieren - auch wenn der Verbraucher dann als "Wärmepumpe" bezeichnet wird, eine frei definierbare Bezeichnung gibt es noch nicht.

Anschließend würde der Power-Splitter den Netzbezug von Durchlauferhitzer und restlichem Hausverbrauch trennen.

[StevieC121176]

So, auch bei mir jetzt logs ohne Fehler. Historische Daten sind auch geladen. Läuft ohne Probleme.
Schaut sehr gut aus.

[q2doc]

Hat auf Anhieb funktioniert und wie frizzle0815 schrieb merkt man erst was einem fehlte wenn...

wobei was mir noch fehlt ist die Integration der zweiten Wallbox (freue mich sehr auf den Beta-Test!).

Sponsor ich übrigens gerne, wann steht denn Dein Sponsor Konzept oder meinst Du das per Kaffee oder GitHub? Diesmal per GitHub - Danke Dir!

[ledermann]

Cool, bislang also überhaupt keine Probleme, das ist äußerst erfreulich!

Mit einer zweiten Wallbox kann SOLECTRUS leider noch nicht umgehen. Ja, das ist schon etwas länger auf der Wunschliste (siehe #2241). Liegt auch daran, dass ich selber nur eine Wallbox habe.

Sponsoring-Konzept steht kurz vor Fertigstellung. Man wird ein Abo klicken können, und zwar integriert in die Registrierung. Das wird dann Ko-Fi und GitHub Sponsor ablösen. Danke dir, dass du nicht abwarten konntest, Geld einzuwerfen ;-)

[gereons]

Noch ein +1 von mir - Umstellung hat problemlos geklappt, alles läuft ohne Fehler im Log und sieht sehr gut aus.

[ledermann]

Ich habe meinen gestrigen Vorschlag nun umgesetzt. Mir selbst gefällt es ganz gut, insbesondere weil keine neue Farbe eingeführt wird.

[ledermann]

Feedback kommt von vielen Seiten, ich habe daher noch zwei Details am Diagramm geändert:

• Die graue Seite der Balken ist nun schmaler als die grüne/rote, was die Lesbarkeit auf kleinen Displays und vielen Balken (z.B. bei Monat) verbessert.
• Rot ist jetzt unten, grün ist oben. Also vertauscht gegenüber bisher. Damit lässt sich die Entwicklung des Netzbezugs besser verfolgen, Jahreszeiten-Effekte sind also besser erkennbar.

[gereons]

Prima, sieht echt gut aus mit dieser Änderung! Den roten Balken unten zu haben ist wirklich eine sehr gute Idee.

Eine winzige Kleinigkeit hätte ich aber noch: die Oberkante der Balken ist asymmetrisch, linke Ecke rund und rechte Ecke eckig. Beide Seiten gleich (rund) sähe vermutlich besser aus.

[ledermann]

Ja, das mit der Rundung wäre mir auch lieber, aber das gelingt mir leider nicht mit Chart.js - wenn das obere Balkensegment sehr klein ist, verschwindet nämlich auch die Rundung. Das ist das Problem, was wir zu Beginn bereits hatten. Daher ist die obere rechte Ecke immer eckig und es ist einheitlich bei jedem Balken so.

[gereons]

Ah OK, ich hatte irgendwie nach dem Screen mit der ersten Idee gehofft dass das doch irgendwie ginge. Schade, aber natürlich auch kein Beinbruch.

[StevieC121176]

Noch eine Kleinigkeit ist mir bei den neuen Tooltips aufgefallen. Der Balken ist rechts etwas „abgeschnitten“. Sh. Screenshot

[ledermann]

Gut gesehen! Ist jetzt korrigiert.

[frizzle0815]

Eine Frage bzw. Anregung würde ich gerne in den Raum stellen. Als Herkunft des Stroms gibt es ja neben PV und Netz auch noch den Hausakku.

Ich musste gestern auf die Schnelle das Auto laden und habe hierfür zum größten Teil den Hausakku verwendet, da zu dem Zeitpunkt nicht ausreichend PV Erzeugung vorhanden war, der Akku aber noch genug Ladung hatte.

In deiner Darstellung wurde dieser Anteil auch dem Bereich "Photovoltaik" zugeordnet. Das ist denke ich im Grundsatz vollkommen in Ordnung, da es den meisten Leuten darauf ankommen wird, ob man den Strom selbst erzeugt oder zugekauft hat.

Ich habe mich dennoch gefragt, ob es nicht sinnvoll wäre, den Power Splitter auch noch um den Hausakku zu erweitern.

[halmich]

fände ich nicht sinnvoll. Der Speicher wurde aus pv beladen, das passt. Es macht wenig Sinn den Hausspeicher zum Beladen des Autos zu nutzen.

[ledermann]

Wegen der Ladeverluste sehe ich das Beladen des E-Autos aus dem Hausakku auch kritisch. Aber die Funktion gibt es, SENEC ermöglicht das beispielsweise nativ über ihre App.

Der Power-Splitter unterscheidet derzeitig nur, ob der Strom aus dem Netz kommt oder nicht. Ob der Strom aus dem Hausakku kommt, bleibt außer Betracht. Es wird implizit davon ausgegangen, dass Strom aus dem Akku zuvor per PV erzeugt wurde.

Damit gibt es dann tatsächlich Edge-Case-Szenarien, wo es hakt:

• Notbeladung im Winter. Der SENEC-Speicher (und andere vermutlich auch) beladen den Speicher manchmal aus dem Netz, wenn es mehrere Tage lang kaum PV-Strom gab. Der Speicher wird dann im geringen Maße (10% oder 20%) aus dem Netz beladen, der Power-Splitter rechnet das dann fälschlicherweise als PV-Strom ab. Der Fehler ist aber äußerst gering, da Notbeladungen sehr selten sind.
• Wer einen dynamischen Stromtarif nutzt, möchte im Winter vielleicht den Speicher aktiv bei günstigem Strom aus dem Netz beladen, ich habe dazu den SENEC-Charger gebaut. Das kollidiert dann tatsächlich mit dem Power-Splitter, der die spätere Entnahme dann als PV-Strom auffasst. Eine Lösung dafür habe ich derzeitig keine.

Momentan möchte ich die Logik des Power-Splitters so belassen. Ich will aber nicht ausschließen, dies in zukünftigen Versionen zu verfeinern.

[frizzle0815]

Dass das Laden des Autos aus dem Hausakku energetisch nicht sinnvoll ist ist klar. Das ist daher sicher kein Szenario, das regelmäßig auftritt.

Was ich mangels eigener Erfahrung nicht einschätzen kann: Wie ist das z.B. mit der Wärmepumpe? Hat man da im Winter über Nacht einen höheren Anteil Speicherentladung, der interessant wäre?

Ansonsten auch prospektiv, wenn irgendwann noch weitere Verbraucher in Solectrus eingebunden werden sollten. Auch hier könnte das vielleicht eher von Interesse sein.

[halmich]

Der Speicher ist im Winter eh oft leer, schon teilweise ab 17 Uhr oder wird nicht voll, sodass der Anteil des Speichers an der Wärmepumpe gering ist.

[ledermann]

Nicht jedem gefällt es, dass die Kosten der entgangenen Einspeisevergütung immer mit einberechnet werden. Daher ist das nun eine einstellbare Option, mit der beeinflusst werden kann, wie im Kreis "Kosten" sowie den einzelnen Verbraucher-Tooltips gerechnet werden soll.

Der Default ist "AUS", bei einem Wechsel von v0.15 auf power-splitter (und später v0.16) ändert sich also nicht die Berechnungsmethode.

In der Live-Demo ist die Option "AN".

[gereons]

Zwei kleine Sachen sind mir nach dem Update auf die entsprechende Version aufgefallen:

a) Der Power-Splitter startet mit einer Deprecation Warning, was er vorher nicht getan hat:

Power Splitter for SOLECTRUS, Version develop, built at 2024-08-11 06:42:25 +0200
Using Ruby 3.3.4 on platform aarch64-linux-musl
Copyright (c) 2024 Georg Ledermann georg@ledermann.dev
https://github.com/solectrus/power-splitter

Accessing InfluxDB at http://influxdb:8086, bucket my-solectrus-bucket
Sensor initialization started

• Sensor 'grid_import_power' mapped to 'SENEC:grid_power_plus'
• Sensor 'house_power' mapped to 'SENEC:house_power'
• Sensor 'wallbox_power' mapped to 'SENEC:wallbox_charge_power'
• Sensor 'house_power' remains unchanged
  Sensor initialization completed

Starting endless loop for processing current data...

2024-08-11 11:20:17 +0200 - Processing day 2024-08-11
DEPRECATION WARNING: to_time will always preserve the timezone offset of the receiver in Rails 8.0. To opt in to the new behavior, set ActiveSupport.to_time_preserves_timezone = true. (called from block (2 levels) in extract_and_transform_data at /power-splitter/lib/flux/extractor.rb:36)
Pushing 12 records to InfluxDB
Sleeping for 3600 seconds...

b) Die Felder "Bezeichnung der Anlage" und "Name des Betreibers" in den Einstellungen haben komische Platzhalter:

[ledermann]

Ooops, ist beides jetzt korrigiert, danke!

[WolfImBusch]

Hi @ledermann ,

die Umstellung hat dank Deiner Anleitung super geklappt und alles funktioniert ohne Probleme! Super!!!! Ich danke Dir!!!!!

Zwei kleine Anmerkungen

a) die "DEPRECATION WARNING" von @gereons sehe ich bei mir auch im log
b) die Umstellung hat mich ein bisschen Zeit gekostet, weil ich (natürlich reichlich unclever von mir!!!) Einstellungen in der Vergangenheit (z.B. Wechsel des Forecast Providers) immert direkt auf der Synlology über den Container Manager geändert habe und nicht etwa direkt in den von dem Konfigurator erzeugten Dateien "compose.yml" und ".env". Ich habe deshalb über den Konfigurator die Dateien neu erzeugt und die o.b. Anpassungen dort eingefügt/geändert. Ich war mir dabei unsicher, ob der Konfigurator bspw. neue Passwörter etc. für die InfluxDB etc. erzeugt - ich aber dankenswerterweise nicht so ....

Viele Grüße

Alex

[ledermann]

Super, danke für das Feedback! Und großartig, dass es mit dem Konfigurator geklappt hat.

Die Deprecation-Warning ist mittlerweile korrigiert.

[ledermann]

Ich habe hier noch etwas ergänzt: Standardmäßig führt der PowerSplitter einmal pro Stunde eine Berechnung durch. Das führt dazu, dass bei der Darstellung des aktuellen Tages die Berechnung immer etwas hinterherhinkt, also im Schnitt der Stromverbrauch der letzten 30min unberücksichtigt bleibt. Im Verlauf des Tages wird das natürlich korrigiert.

Wenn man das nicht haben möchte, kann man die Häufigkeit der Berechnung erhöhen. Hierzu dient die Variable POWER_SPLITTER_INTERVAL, die per Default auf 3600 steht (Angabe in Sekunden). Man kann sie bis auf ein Minimum von 300 (= 5min) einstellen. Die Anzahl der Messpunkte, die langfristig gespeichert werden, erhöht sich dadurch nicht. Es werden nur öfter die Berechnungen des aktuellen Tages aktualisiert (= überschrieben).

Wer die neue Variable verwenden möchte, muss vorher den PowerSplitter aktualisieren, wie üblich per docker compose pull && docker compose up -d. Man sieht im Log, wie lange sich das Tool zwischendurch schlafen legt.

[AlpenFlizzer]

Bezugnehmend auf #2095 (comment) knüpfe ich direkt an:

Wenn ich mir das bewusst ansehe, stehen im Autarkie Badge (oder in den Tooltipps) aber keine abosluten Zahlen oder? Für mich wäre das durchaus interessant.
Im Autarkie Badge stünde zwar der Verbrauch und der Netzanteil, aber dann wird direkt in die Quote umgerechnet und die kWh PV Anteil müsste man händisch ausrechnen.

[ledermann]

Ja, sowohl der Autarkie-Badge als auch die Power-Splitter-Anzeige bei den einzelnen Verbrauchern zeigen nur den relativen PV-Anteil (in %) an, keine absoluten Zahlen in kWh.

Ich habe da natürlich länger überlegt, was genau ich anzeige und habe dann eine Darstellung gewählt, die sich auf das (in meinen Augen) Wesentliche beschränkt. Die jetzige Darstellung ist sicher nicht in Stein gemeißelt, aber das Weglassen von Unwichtigem ist mir recht wichtig.

Nehmen wir als Beispiel diese Darstellung:

Sicherlich könnte hier jetzt auch angezeigt werden, dass die 47% PV-Strom genau 39,5 kWh ausmachen. Und aus dem Netz kamen 44,4 kWh. Ich persönlich halte das aber eher für verzichtbar - ja, das ist total subjektiv ;-)

Übersehe ich den Grund, warum die kWh-Angabe dennoch interessant sein könnte?

[ledermann]

Ich denke, ich belasse es erst mal so, um das Feature erst mal herausbringen zu können. Für weitere Verbesserungen in der Zukunft bin ich grundsätzlich aufgeschlossen.

[ledermann]

Da der Beta-Test erfolgreich verlaufen ist, habe ich den PR #3160 jetzt nach develop übernommen. Das Docker-Tag pr-3160 wird somit nicht mehr aktualisiert. Wer möchte, kann auf develop wechseln oder warten, bis latest aktualisiert wird. Das wird sehr bald geschehen, da ich die Version 0.16 veröffentlichen möchte.

Wie das mit der "Freischaltung nur für Sponsoren" im Einzelnen ablaufen wird, werde ich in Kürze in einem Blog-Beitrag erklären.

Ich danke euch allen für das zahlreiche und nette Feedback! 👍