Neues Script: Hausspeicher Energiemanager Sonnen

[babl]

Dies ist eine komplett neue Script version für das alte Thema hier:

https://forum.iobroker.net/topic/69604/hausspeicher-laden-dynamisch-tibberlink-scripte/186

Zu diesem Script werden nur noch 3 Adapter benötigt.

Sonnenadapter
Tibberlink Adapter
PV Prognose
Optional EVCC Adapter

Bitte lasst uns hier diskutieren, was man besser machen könnte, und bitte in diesem Thread auch nur daß was mit dem Script zusammenhängt, keine anderen Fragen zu anderen Adaptern oder zu anderen Scripten sonst wird es einfach zu unübersichtlich.

Anleitung Vis und Scripte.zip

In dieser Zip findet ihr den Energiemanager als Zip zum importieren in Javascript, eine Vis zum Importieren, und eine Anleitung als Word Datei.

Ich hoffe daß bei Änderungen oder anderen Batteriespeichern dieser Thread weitergeführt wird und so für einige der Batteriespeicher eine Lösung getroffen werden kann. Funktionieren tut das ganze natürlich nur mit Tibber als Stromanbieter für andere müßte einiges umgeschrieben werden, ebenso für die anderen Batteriespeicher außer Sonnen.

[Scotty42]

Hallo @babl,

danke für deine Skripte, ich habe die Logik zum Laden und Sperren des Speichers auf Sungrow adaptiert. Die beiden json Dateien (Javascript Editor, nicht Blockly) verlinke ich als GitHub Gist.
8_Speicher_sperren.json
7_Speicher_laden.json

Ich zeichne den Verlauf der Datenpunkte derzeit auf um das Verhalten nachvollziehen zu können. Bislang sieht es so aus, als würde alles wie beabsichtigt funktionieren und der EMS Modus schalten.
Der Sungrow WR hat einen Force Charge Moduls (App, Web, Modbus Register), der allerdings mehr für Zweitarifzähler gedacht ist, wo grundsätzlich jede Nacht ein günstiges Fenster besteht. Dieser wird mit Ziel SoC und Uhrzeit gesetzt. Diese Änderungen versuche ich zu vermeiden.

Daher setze ich auf den EMS Übersteuerungsmodus, der das Sungrow EMS für die Batterie deaktiviert, erzwungen Laden, Entladen oder das Sperren erlaubt. Dieser ist meinem Eindruck nach für Elektriker gedacht, die in der entsprechenden Berechtigungsebene der App für Wartungs- / Erweiterungsarbeiten des Speichers diesen Modus nutzen können.

Für Anwender: An anderen Stellen in den Skripten finden sich Sonnen-Aliase, hier bitte selbst anpassen. In den meisten Fällen wird der SoC referenziert. Ich kommuniziere mit dem Sungrow WR (BYD Batterie) über Modbus. Bei mir ist das der Adapter 3. Bitte proaktiv selbst Eindenken und verstehen.

  Batteriespeicher_Netto_in_Wh = getState('0_userdata.0.Energiemanager.Batteriespeicher_Kapazität').val;
  Zeit_Batteriespeicher = (Batteriespeicher_Netto_in_Wh * getState('modbus.3.inputRegisters.13022_Battery_level').val) / 100;
  if ((() => { const d = new Date().getDay(); return d === 0 ? 7 : d; })() == 6) {

Allerdings auch die PV DC Leistung, wie im Skript zur Berechnung des PV Durchschnitts.

Wolkentimer_Zeit = (Wolkentimer_Zeit_in_Min * 60) / 5;
Liste = listsRepeat(getState('modbus.3.inputRegisters.5016_Total_DC_Power').val, Wolkentimer_Zeit);
on({ id: [].concat(['modbus.3.inputRegisters.5016_Total_DC_Power']), change: 'any' }, async (obj) => {
  let value = obj.state.val;
  let oldValue = obj.oldState.val;

Oder die Last:

liste = [];
on({ id: [].concat(['modbus.3.inputRegisters.13007_Load_power']), change: 'ne' }, async (obj) => {
  let value = obj.state.val;

[babl]

Es gibt 2 Änderungen, da es mit dem evcc und der Grundlastberechnung so nicht klappte, jetzt sollte um Mitternacht die Differenz berechnet werden und somit auch die reelle Grundlast richtig berechnet werden.

Grundlast_Berechnung.txt

Auch im Script Pv Ertrag habe ich noch was geändert, da daß mit dem PV Module voll Schnee mir so nicht gefallen hat, hier die Änderung

PV-Ertrag_Durchschnitt.txt

Bitte die beiden alten Scripte durch diese beiden neuen ersetzen.

[Doppellhelix]

Hat sich erledigt. Sorry

[babl]

Es gibt 2 Änderungen und einen neuen Datenpunkt, damit die Berechnung von EVCC auch funktioniert wird jetzt der Stand um 00:00:02 ausgelesen und in den Datenpunkt geschrieben und dann abends damit gerechnet.

Deshalb 2 Änderungen.

1 mal im Script Datenpunkte erzeugen, dies nach der Änderung dann bitte 1 mal ausführen, so wird der Datenpunkt angelegt.

Datenpunkte_erzeugen.txt

und dann in der Grundlast Berechnung, es wird dann mit dem neuen Datenpunkt gerechnet.

Grundlast_Berechnung.txt

[raspmad]

Hallo Babl,
bin gerade beim Stöbern im Forum auf dein Projekt gestoßen.
Was für eine Arbeit, Respekt!

Leider bin ich Fronius Nutzer (Symo Gen 24 Plus & BYD HVS) und kann das nicht 1:1 nutzen

Bevor ich mich in die Tiefe der WR Anpassungen begebe, hier meine Frage in die Runde:

Hat sich da schon jemand herangewagt und mag die Infos teilen?

Würde mich riesig freuen, Vielen Dank

[babl]

@raspmad hi, lade dir mal die daten runter und schau einfach ob du das auf dein system umschreiben kannst, wenn es läuft dann könntest du es ja hier auch veröffentlichen für deine konfiguration, so haben alle was davon

Hier sind nochmals alle Dateien aus dem Java Script exportiert.

Energiemanager.zip

[raspmad]

@babl Moin babl,

Vielen Dank für die zur Verfügung Stellung deiner Daten.
Ich schaue mir das an und starte einen Versuch das auf Fronius & BYD anzupassen.
Wenn das funktionieren sollte, gebe ich das natürlich gerne an die Gemeinschaft weiter.

Grüße

[raspmad]

@babl Hi, kannst du mir bitte noch einen Hinweis geben, in welchen scripten ich den WR und die BYD Batterien anpassen muss. Vielen Dank

[babl]

@raspmad Hausspeicher-laden und Hausspeicher Sperre

[mg99]

@babl mal ein Danke für seine Ideen uns Scripte.

@raspmad, ich habe allerdings mit einem Fronius Symo & BYD HMS begonnen die Scripte anzupassen.
Außerdem läuft bei mir aWATTar.
Teilweise läuft die Anpassung - eine 1:1 Umsetzung mache ich allerdings nicht - wie gesagt, selbst erst am probieren.

Grob gesagt die Ansteuerung via aWATTar auf Fronius und BYD funktioniert, inwieweit ich die Grundlastberechnung etc. umsetzte weiß ich noch nicht.
Die Ansteuerungsmöglichkeit zu meiner Bösch Wärmepumpe via Modbus habe ich vor kurzem bekommen.

[lehmann-maker]

Hi @babl ,

Ich habe deine Skripte auf meinen Anwendungsfall (SMA STP 6.0 SE + SMA Home Storage + SMA EV Charger 22). Auch Adapter nutze ich andere:

PV-Vorhersage: Solarprognose Adapter
Wallbox: SMA-EV-Charger Adapter
Wechselrichter: Modbus Adapter

Integration war soweit erst einmal kein Problem, nur ein Hinweis: Nach Import der Zip müssen den Skripten einzeln die Java-Skript Instanz manuell (unter Stift -"bearbeiten") zugeordnet werden. Ich hab viel gesucht bis ich das fand Vor erschien bei mir neben den run/stop button nur "Die Instanz ist deaktiviert".

Nun zur eigentlichen Frage: Berücksichtigt das Skript das Nachladen in der Nacht um die Nacht/den morgen bis zu errechnetem Grundlast-SOC mit möglichst günstigen Strom zu überbrücken obwohl der Ertrag am nächsten Tag größer als die die berechnete Tagesgrundlast und/oder Speicherkapazität?

Grund meiner Frage: Skript 2 enthält die SOC Berechnung mit folgenden ähnlichen Blöcken:

Dies sieht für mich so aus, als würde der errechnete SOC nachfolgend immer <0 bzw im Weiteren 0 % , da (Batteriekapazität-Grundlast-PV-Ertrag(nächster Tag)) << 0. Ist das korrekt oder wurde nachladen in der Nacht berücksichtig?

Ich habe das Problem, dass das Skript momentan zumindest noch nicht das Laden zulässt, obwohl der Preis niedrig genug wäre.

Außerdem möchte ich gern fragen, ob "PV_Ertrag" der Ertrag der Überschuss (PV Leistung - Grundlast) abzüglich Speicherbeladeleistung ist oder soll die Beladeleistung aus der Grundlast herausgezogen werden? Momentan erechnet sich meine Grundlast (bei dir sonnen.0.status.consumption) ohne die Beladeleistung.

Dank dir für die Hilfe und deine Skripte

Grüße

Sebastian

[babl]

@lehmann-maker hallo,

der errechnete soc sollte eigentlich nicht kleiner als 0 sein, du hast es ja oben recht schön gerechnet, Batteriekapazität - Grundlast - Pv Ertrag nur du musst bedenken einmal rechnet sie von mitternacht weg und einmal mitternacht zu darum hast du das 5x grundlastspezifisch, nachladen wurde in der nacht berücksichtigt nur aktuell sind halt in der nacht die preise teilweise höher als unterm tag, hierzu habe ich ncoh nicht wirklich eine lösung gefunden, zumindestens nicht mit diesem script.
Der PV Ertrag Durchschnitt wird zur Berechnung von Schnee auf dem Dach zwischen sonnenaufgang und untergang berechnet. Ansonsten wüsste ich jetzt nicht welchen datenpunkt du meinst?

Gruß

[lehmann-maker]

@babl In dem gewählten blockly Beispiel substrahiert er den gesamten PV-Ertrag des Folgetages. Um das in Zahlen auszudrücken: Mein Batteriespeicher hat 13120 netto Wh, morgen zeigt mein PV-Forecast 33613 Wh, die Grundlast hab ich mit 800 Wh angegeben. Daraus folgt 13120 - 5x800 - 33613 = -24,493 Wh. Oder versteh ich etwas falsch? Dank dir

[babl]

@lehmann-maker ja bei soviel erzeugung ist es natürlich nicht gedacht die batterie mit netzstrom zu laden, dies ist nur gedacht wenn es tage gibt wo nur 3 - 4 kwh vorhergesagt sind und dann funktioniert auch die rechnung, so würde er natürlich immer unter 0 sein und daher auch nie laden. aber achtung es gibt 3 verschiedene möglichkeiten bei dem errechneten soc.

1 mal mit der vorhersage für heute
1 mal mit der vorhersage rest des tages heute
und dann mit der geschätzten energie für morgen.

dies ist nur interessant wie bereits oben geschrieben.

10kwh Batteriekapazität - 5* 800 Grundlast - 4 kwh Vorhersage = 2kwh Rest => errechneter Soc von 20% wurde dies um diese Uhrzeit unterschritten sucht er nach einem günstigen Preisfenster vorher und läd dann die Batterie. Dieses Script habe ich für mich geschrieben, da ich eigentlich eine Grundlast von ca. 200-300 habe und wir in einem Nebelloch sind und daher auch die Vorhersagen teiwlweise bis unter 2kwh für den ganzen Tag sind. Wenn du es für dich ummünzen willst dann brauchst du nur den Block mit dem errechneten Soc (wie dein Beispiel) auf dich umändern. Ich weiß das Script ist nicht das beste, aber es hat das letzte Jahr erfolgreich seinen Dienst erledigt. Für mich war es so optimal und du musst natürlich auch bedenken, daß hier alles nur von errechneten werten oder geschätzten vorhersagen abhängt.

[lehmann-maker]

@babl OK verstanden. Bliebe noch das Problem mit dem ausbleibenden Laden über Nacht, da die Preise hier höher sind als am Tag. Wäre es möglich das Script zu in einem Nacht- und einen Tagmodus zu splitten? Es müsste dann über eine Vergleichsfunktion den niedrigsten Preis zwischen bspw. 9:00 und 16:00 finden und zwischen 16:00 und 9:00. Ich befürchte jedoch, dass ich das nicht hinbekomme

[lehmann-maker]

Warum war es nötig den EVCC Durchnitt /6 /60 /24 umzurechnen? Wir dieser durch den EVCC Adapter nicht bereits in Wh angezeigt, oder steckt hier mehr hinter? Danke.

[babl]

@lehmann-maker da steckt mehr dahinter, weil wenn evcc aktiv ist, dann soll ja evcc nicht in die grundlast miteinfließen, so war damals mein plan. dies wird dann auf die 24 stunden wieder rausgerechnet, so daß die grundlast dann wirklich nur deine grundlast vom haus beträgt.

[FloHa 0]

Hat schon jemand das Tibber script auf die neue 15 Minütige berechnung angepasst?

[lehmann-maker]

@floha-0 dafür müsste zunächst der Adapter tibberlink angepasst werden. Die einstündige Berechnung funktioniert aber nach wie vor.