ecoflow-connector-Script zur dynamischen Leistungsanpassung

[ub35bo]

@waly_de said in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

0_userdata.0.ecoflow.RealPower

Herzlichen Dank für deine schnelle Rückmeldung, die ich versucht habe umzusetzen.
Zunächst das Positive:

• der in "0_userdata.0.ecoflow.RealPower" als ganze Zahl enthaltene Wert stimmt weitgehend bis auf einen kleinen Zeitversatz mit den Werten überein, die ich der Discovergy-App entnehmen kann.
• Der History-Adapter ist in der Version 3.0.1 und es laufen 2 Instanzen ohne Fehlermeldung.

history.0
2024-03-17 17:07:02.443 info starting. Version 3.0.1 in /opt/iobroker/node_modules/iobroker.history, node: v18.19.1, js-controller: 5.0.19

history.0
2024-03-17 17:07:02.507 info enabled logging of 0_userdata.0.ecoflow.RealPower (Count=1), Alias=false
host.Raspberry-Pi5-8GB
2024-03-17 17:07:03.417 info instance system.adapter.history.1 started with pid 77473

history.1
2024-03-17 17:07:04.128 info starting. Version 3.0.1 in /opt/iobroker/node_modules/iobroker.history, node: v18.19.1, js-controller: 5.0.19

Die Warnmeldungen, die einmalig beim Start bzw. Neustart zwischen zwei Browseranmeldungen auftauchen, habe ich folgend hineinkopiert. Dabei handelt es sich um alle Befehle,

javascript.0
2024-03-17 17:00:44.111 info Stop script script.js.common.EcoFlow-Connector

javascript.0
2024-03-17 17:00:44.115 info script.js.common.EcoFlow-Connector: Ecoflow MQTT-Client beendet

javascript.0
2024-03-17 17:00:44.221 info Start javascript script.js.common.EcoFlow-Connector

javascript.0
2024-03-17 17:00:44.242 info script.js.common.EcoFlow-Connector: registered 0 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions

javascript.0
2024-03-17 17:00:44.503 warn getState "0_userdata.0.ecoflow.Regulate" not found (3) states[id]=null

javascript.0
2024-03-17 17:00:44.505 warn at getStateCr (script.js.common.EcoFlow-Connector:2612:16)

javascript.0
2024-03-17 17:00:44.505 warn at script.js.common.EcoFlow-Connector:2073:37

javascript.0
2024-03-17 17:00:44.599 info script.js.common.EcoFlow-Connector: Verbunden mit dem Ecoflow MQTT-Broker

Ich hoffe, dass ich die für dein Verständnis notwendigen Meldungen erwischt habe.
Für mich sieht es so aus, dass das Problem auf der EcoFlow-Seite liegt. Muss ich neben den Seriennummern im Script vielleicht auch noch einen zusätzlichen Adapter installieren?

[Thomas Weller]

@thomas-weller said in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Das Blockly sollte dann für meine nicht vorhandenen Programmierkenntnisse so aussehen:

Wenn SOC der DeltaPro <5%
= Skript zur dynamischen Leistungsregelung stoppen
= Shelly SmartPlug (AC-Ladung der Delta Pro bei mir) auf AN
= Excees Power z.b.: 500Watt
Wenn SOC der DeltaPro wieder >10%
= Skript zur dynamischen Leistungsregelung starten

Jetzt muss ich das nur irgendwie zusammenklicken

Hier übrigens das funktionierende Ergebnis für diesen Anwendungsfall (Keine PV an Delta oder PS da lAdung nur über AC-Schaltsteckdose und Speicher darf nicht leer werden weil z.B. Kühlschrank am AC-Ausgang hängt):

[Dreffi]

@waly_de
Frage 1:
Ich habe noch mal ein Problem mit battPozOn.
Ich habe zwei Powerstreams, die im Modus serial arbeiten.
Wenn der Zweite jetzt bei den eingestellten 96% ankommt, wird wie gewünscht auf volle Leistung gestellt. Leider geht der Einspeisesollwert (SetAC) irgendwann auf 0. Dann wird nur noch Überschuss vom Powerstream eingespeist (Einspeisekontrolle ist deaktiviert).

Woran kann das lieg? Laut den Protokollen "denkt" das Script weiterhin der Powerstream steht weiterhin auf 600 W.
In Folge dessen wird auch zu viel eingespeist und ich gebe ca. die Leistung ins Netz ab, die vom PS2 gerade anstelle der gewünschten 600W eingespeist werden.

Starte ich das Script neu, greift wieder battPozOn, aber nur für begrenzte Zeit.

Frage 2:
Ich habe zwei Powerstreams mit angeschlossener Powerstation und an jeder Powerstation sind ebenfalls Paneele angeschlossen.
Ist es für die Regelung erforderlich diese zu berücksichtigen? Sämtliche Steuerung erfolgt in ioBroker. Die Auswertung und Visualisierung erledige ich komplett extern in Home Assistant.

[maik1007]

@waly_de
Super und vielen Dank. Ich habe es jetzt auf -2 Prio Speicher gestellt. Das war genau das was ich gesucht habe so langsam komme ich dahinter was die ganzen Optionen bedeuten.
Des Weiteren habe ich mir jetzt per Blockly ein simples Script erstellt das auf einen Schalter in Home Assistant reagiert. So kann ich per Home Assistant die dynamische Steuerung ein und aus stellen in Home Assistant kann ich nun auch ganz simpel alles per Zeitschaltuhr steuern. Für mich ist das die beste Lösung da ich im Home Assistant zu Hause bin. Ich habe auch schon überlegt wie ich das ganze ohne mein Zutun automatisieren könnte aber da bin ich selber noch auf keine Lösung gekommen. Das ganze müsstest abhängig vom Akkustand des Speichers geschehen. Hab ich mehr Strom kann ich mehr teure Tibber Stunden ausgleichen. Ist der Akkustand niedriger muss ich mich auf die teuersten konzentrieren. Momentan mache ich das per Zeitschaltuhr ihn Home Assistant. Automatisieren wird da schwer da zu viele Faktoren eine Rolle spielen.
Das Script funktioniert jetzt aber genauso wie ich es mir vorgestellt habe. Dafür und für deine Hilfe vielen Dank.

[Dreffi]

@maik1007
Ich glaube das was du suchst habe ich in Home Assistant bereits umgesetzt.
schau mal hier rein: https://www.photovoltaikforum.com/thread/208943-ecoflow-powerstream-bastelecke-plug-nachbau-zur-messwerte-übergabe-eines-energie/?postID=3653326#post3653326

Ich speise automatisiert in den möglichst teuersten Stunden ein. Wie viele das sind ermittle ich am Akkustand und der PV Prognose.

An ioBroker wird nur ein Schalter übergeben, der Regulation true oder false setzt.

[Marco 1]

Hallo
was muss ich bei der Delta Pro eintragen in dem Script unter :

Bezeichnungen für Typen: PowerStream:"PS"; DeltaMax:"DM"; Delta2: "D2" ; Delta2 Max: "D2M"; SmartPlug: "SM"; Andere: "NA"

//#######################################################################
{
seriennummer: "XXXXXXXXXXXXX",
name: "DELTA Max",
typ: "DM",
subscribe: false, // "true": Alle Daten für dieses Gerät werden angefragt. "false": Es werden keine Statusdaten abgefragt
},

Delta Pro sehe da nicht.

Habe schon gesucht, aber nichts gefunden oder übersehen.

[Ponti92]

@Waly_de
Eine Frage zu den Werten MaxPower und Zusatzpower_Offset bzw. generell zur Zusatzpower.
Mein Powerstream wurde nun durch irgendein Update auf 800W erhöht und wenn ich nun den Wert MaxPower auf 800W setze, dann stimmt die Berechnung zur Zusatzpower weiter unten im Skript nicht mehr.

Außerdem würde ich den Wert MaxPower aufspalten in die wirkliche maximale Power des Powerstreams (600W/800W) und die Leistung, die man einspeisen will. Z.b. wenn man mehrere PS hat, dann beide auf 300W/400W einstellt, um nicht generell zu hoch einzuspeisen.

Wenn ich jetzt aber die MaxPower bei mir auf 400W stelle, dann regelt das SKript die Zusatzpower schon ab diesem Wert und resultiert dann in einem komischen Verhalten.

Darüber hinaus wird die Zusatzpower ja nur benötigt, wenn die Einspeiseleistung < 200W beträgt, da die Batterie maximal mit 600W geladen werden kann.

Ich würde den Wert für die Zusatzpower nicht abhöngig von der MaxPower machen, sondern fix auf 600W Ladeleistung bzw. 200W Einspeiseleistung setzen, damit das sauber funktioniert.

[ub35bo]

@waly_de
Ich habe den Fehler versucht einzukreisen. Irgendwie kam ich zu der Erkenntnis, das Regulate nicht definiert ist und habe es durch "" ersetzt, wie ich es in älteren Scripten gefunden habe.
// RegulationState: "Regulate", // Wenn angegeben, kann mit diesem State die Regulation ein- und ausgeschaltet werden (Wird automatisch unter 0_userdata.0.ecoflow angelegt)
RegulationState: "", // Wenn angegeben, kann mit diesem State die Regulation ein- und ausgeschaltet werden (Wird automatisch unter 0_userdata.0.ecoflow angelegt)
Jetzt läuft mein System wie gewünscht.

Jetzt stellt sich mir die Frage, ob bzw. wie ich die dynamische Leistungsanpassung zeitgesteuert laufen lassen kann.
Hintergrund: Ich bin Tibberkunde und es macht für mich vor allem in den Morgen- und Abendstunden, die besonders teuer sind, einzuspeisen. Leider bin ich noch nicht in Scripten firm und würde mich über Hilfe freuen.

[Waly_de]

@dreffi sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Woran kann das lieg? Laut den Protokollen "denkt" das Script weiterhin der Powerstream steht weiterhin auf 600 W.

Wie meinst du das mit "denkt"? Was genau steht denn in dem Objekt "0_userdata.0.ecoflow.app_1XXXXX_thing_property_set.writeables.SetAC" ?
Wird da null eingesetzt? Oder siehst du das nur in der App?
Du sagst, das geht nur eine gewisse Zeit sind das Sekunden Minuten Stunden?

@dreffi sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Frage 2:
Ich habe zwei Powerstreams mit angeschlossener Powerstation und an jeder Powerstation sind ebenfalls Paneele angeschlossen.
Ist es für die Regelung erforderlich diese zu berücksichtigen? Sämtliche Steuerung erfolgt in ioBroker. Die Auswertung und Visualisierung erledige ich komplett extern in Home Assistant.

Nein. Es ist nicht nötig diese Paneele zu berücksichtigen. Die Angabe ist nur dann sinnvoll, wenn die Gesamtsolarleistung im iobroker erfasst werden soll. (0_userdata.0.ecoflow.totalPV)

[Waly_de]

@ponti92 sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Mein Powerstream wurde nun durch irgendein Update auf 800W erhöht

Das ist mir neu. Wann gab es dieses Update? Der Powerstream ist ja von Haus aus in der Lage, 800 W zu liefern, ist aber im Moment aufgrund der Regelungen in Deutschland noch auf 600 W begrenzt. Solange das so ist, würde ich MaxPower auf 600 W stehen stehen lassen.

Zum begrenzen der Einspeiseleistung würde ich mit diesen Parametern arbeiten:

  lowBatLimitPozOn: 100, lowBatLimitPozOff: 101, // Bei Unterschreiten der Batterieladung von "lowBatLimitPozOn" % ist die maximale Einspeiseleistung auf 
  lowBatLimit: 400,                           // "lowBatLimit" limitiert, bis der Ladezustand wieder bei "lowBatLimitPozOff" ist

Mit dieser Einstellung sollst das Limit immer greifen, und der entsprechende powerStream maximal 400 W einspeisen.

[Waly_de]

@ub35bo sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Jetzt stellt sich mir die Frage, ob bzw. wie ich die dynamische Leistungsanpassung zeitgesteuert laufen lassen kann.
Hintergrund: Ich bin Tibberkunde und es macht für mich vor allem in den Morgen- und Abendstunden, die besonders teuer sind, einzuspeisen. Leider bin ich noch nicht in Scripten firm und würde mich über Hilfe freuen.

Das geht grundsätzlich auch einfach mit einem Blocky oder 2 "Rules"
Schau mal dieses Video an. Das erklärt die Grundlagen von Blockys ganz gut.
https://youtu.be/Of2C8F_n11U?si=vjXG24y1lTdlaScF

Du musst also zwei Zeitpläne erstellen, die Regulate jeweils ein und ausschalten.
Alternativ kannst du auch mit dem Tibber Adapter arbeiten, und auf den aktuellen Preis direkt reagieren. Sprich bei Änderung auf "TEUER" das Script aktivieren.

[karo2204]

@waly_de Da könnte man doch auch Dein Tibber Script nehmen oder? Also das folgende auskommentieren und dann sollte es doch gehen.... ?

 //BatMax: 99,                                  //Bei diesem Ladestand stoppt die AC-Ladung und das Script wird wieder eingeschaltet 
    //BatMin: 50,                                  //Der Ladestand der Batterie muss kleiner sein als BatMin , damit der Akku per AC-Ladung geladen wird 
   // SwitchID: "shelly.0.shellyplusplugs#b0b21c19ff40#1.Relay0.Switch", //ID des Schalters, der die AC-Ladung einschaltet. "true" und "false" werden gesetzt

und das hier muss dann auch noch angepasst werden:

function checkTibber() {
    if (tibberID && batSocID) {
        const RegulateID = ConfigData.statesPrefix + "." + ConfigData.RegulationState
        let priceLevel = getState(tibberID).val;
        let batsoc = Number(getState(batSocID).val)
        let OldRegulate = toBoolean(getState(RegulateID).val)
        //log("Tibber Preislevel: " + priceLevel + " OldRegulate: " + OldRegulate + " batsoc: " + (batsoc))
        if ((tibberConfig.LevelToSwitch.includes(priceLevel))) {
            if (OldRegulate) {
               // if (batsoc <= tibberConfig.BatMin) {
                    setState(RegulateID, false);  // Regulierung aus
                   // setState(tibberConfig.SwitchID, true) //Schalter einschalten
                    log("Script abgeschaltet AC-Ladung Ein, weil priceLevel:" + priceLevel + " batsoc:" + batsoc + "%")
                }
            } else {
               // if (batsoc >= tibberConfig.BatMax) {
                    setState(RegulateID, true);  // Regulierung an
                    //setState(tibberConfig.SwitchID, false) //Schalter ausschalten
                    log(" Batterie bei BatMax. Script eingeschaltet AC-Ladung Aus. priceLevel:" + priceLevel + " batsoc:" + batsoc + "%")
                }
            }
        };

Dann wird bei CHEAP und VERY_CHEAP "Regulate" ausgeschaltet, und wenn das nicht ist, ist "Regulate" an. Verstehe ich das so richtig?

[Accu]

@waly_de ich wollte nochmal das Thema: "AC Laden", wenn an der DP vorne ein Verbraucher eingesteckt ist, ansprechen.
Wie beschrieben: ist es für mich ungünstig, wenn die DP z.B. gerade mit 500W über den AC Eingang lädt und vorne an den Steckdosen ein Verbraucher mit 500W angesteckt wird. In diesem Falle würden dann in Summe 1.000W aus dem Netz gezogen. Daher würde ich gerne eine Option haben, die beim Einschalten der DP Steckdosen das AC Laden abstellt.
Mir wurde hier gerade, dass via einem separaten Skript zu machen. Was ich auch tun könnte ABER dann würde der Shelly der den AC Ladeeingang schaltet ping-pong spielen. D.h. das Skript schaltet den AC Ladeeingang der DP ab. Das Leistungsanpassungsskript wieder an.

Kann man das nicht als Option mit hier im Skript einbauen?

[Waly_de]

@karo2204 klasse Idee!

es müsste auch reichen die Config so anzupassen:

var tibberConfig = {
    BatMax: 101,                                  //Bei diesem Ladestand stoppt die AC-Ladung und das Script wird wieder eingeschaltet 
    BatMin: 100,                                  //Der Ladestand der Batterie muss kleiner sein als BatMin , damit der Akku per AC-Ladung geladen wird 
    //SwitchID: "", //ID des Schalters, der die AC-Ladung einschaltet. "true" und "false" werden gesetzt
    LevelToSwitch: [                             //Hier die Werte definieren, bei denen die AC-Ladung eingeschaltet werden soll
        "NORMAL",
        "CHEAP",                                 //Einkommentieren falls gewüscht 
        "VERY_CHEAP"
    ],
}

In diesem Fall wird das Skript nur aktiviert, wenn der Preis Level expensive ist.

[Waly_de]

@accu was ist mit meinen Vorschlägen weiter oben?:
https://forum.iobroker.net/topic/66743/ecoflow-connector-script-zur-dynamischen-leistungsanpassung/1079

[karo2204]

@waly_de Hab's probiert und er hat nen Fehler geworfen.

Jetzt lasse ich zwei Skripte laufen, einmal wenn Tibber CHEAP oder VERY_CHEAP ist, und keine Solarpower anliegt, dann wird über AC geladen:

tibber-ecoflow-charge-nosolar-v1.txt

Und wenn Solarpower reinkommt, dann wird nur das Script ausgeschaltet:

tibber-ecoflow-charge-solar-v1.txt

Ich hoffe ich habe hier richtig gedacht

[Accu]

@waly_de warum kann man nicht den einfachsten Weg gehen und sowas in der Art machen:

WENN AC Eingang der DP eingeschaltet DANN setze das Skript für diesen Zeitraum außer Betrieb = z.B. "RegulationState: "Regulate", // Wenn angegeben, kann mit diesem State die Regulation ein- und ausgeschaltet werden (Wird automatisch unter 0_userdata.0.ecoflow angelegt)" = OFF

ich meine der AC Schalter an der DP ist folgender Datenpunkt:

[Waly_de]

@accu du meinst den AC Ausgang? Eingang würde ja keinen Sinn machen.

Aber so ganz verstehe ich auch noch immer nicht, was du möchtest.
Das Skript regelt ja die Überschussladung mit den Einstellungen unter ExcessCharge und schaltet entsprechend den AC Eingang deiner DP ein, wenn Überschuss an PV Leistung da ist.

Dein Problem, wenn ich es richtig verstanden habe ist doch dass das Skript glaubt, dass die Leistung, die in dein an den AC Ausgang angeschlossen das Gerät geht in die Batterie fließt. Eigentlich ist es aber regulärer Verbrauch.
Versuch bitte, was ich beschrieben habe und sieh, ob das ein Problem löst.

Bei mir ist die Leistung am AC-Ausgang hier:
0_userdata.0.ecoflow.app_device_property_DAXXXXXXXXXXX.data.params.inv.outputWatts

Die Konfiguration wäre also:

AdditionalPower: [
        {
            name: "AC Leistung am Delta Ausgang",
            id: "0_userdata.0.ecoflow.app_device_property_DAXXXXXXXXXXX.data.params.inv.outputWatts",
            factor: -1,
            offset:0,
            NoFeedIn: false,                            // True setzen, wenn die enthaltene Leistung nicht ins Hausnetz fließt. (Nur in PVTotal aufnehmen)
            NoPV: true,                                // true setzen, wenn die enthaltene Leistung nicht in TotalPV einfließen soll. (Nur in Realpower aufnehmen)
        },

[Waly_de]

Ich kann auch empfehlen mal mit ChatGPT zu spielen. Der kann auch komplexere Probleme in ein brauchbares Skript umsetzten. Probiert doch zum Beispiel mal den folgenden Promt aus:

Ich verwende ioBroker und benötige ein JavaScript für den JavaScript-Adapter, das folgende Funktionen umsetzt:

Wenn der aktuelle Tibber-Strompreis das Niveau "NORMAL" oder höher erreicht, soll das Objekt "Regulate" auf true gesetzt werden, andernfalls auf false.

Falls die Batterieladung unter 20% fällt und der Tibber-Preis günstig oder sehr günstig ist, soll der Schalter für das Laden der Batterie auf true gesetzt werden.
Dies bleibt so, bis der Preis nicht mehr günstig ist oder die Batterie einen Ladestand von 80% erreicht hat.

Die Position des Tibber-Strompreises ist hier: tibberlink.0.Homes.XXXXXXXX.CurrentPrice.level

"Regulate" befindet sich hier: 0_userdata.0.ecoflow.Regulate

Die Batterieladung finden Sie hier: 0_userdata.0.ecoflow.app_device_property_DAXXXXXXXXXX.data.params.bmsMaster.soc

Der Schalter ist unter folgendem Pfad zu finden: sonoff.0.NOUS-DVES_F0A844.POWER

[Dreffi]

@waly_de said in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

@dreffi sagte in ecoflow-connector-Script zur dynamischen Leistungsanpassung:

Woran kann das lieg? Laut den Protokollen "denkt" das Script weiterhin der Powerstream steht weiterhin auf 600 W.

Wie meinst du das mit "denkt"? Was genau steht denn in dem Objekt "0_userdata.0.ecoflow.app_1XXXXX_thing_property_set.writeables.SetAC" ?
Wird da null eingesetzt? Oder siehst du das nur in der App?
Du sagst, das geht nur eine gewisse Zeit sind das Sekunden Minuten Stunden?

SetAC stand dann auf 0 (glaube ich, jedenfalls nicht 600!). Das passiert nach wenigen Minuten.
Das Script verhält sich so, als würde der betroffene Powerstream auf 600 W stehen. Es werden keine neuen SetAC Befehle für diesen Powerstream ausgegeben und nur der andere Powerstream ändert seine Einspeiseleistung.

Ich weiß nicht was diesen falschen SetAC Wert verursacht. Meiner Meinung nach wäre ein periodischer Abgleich des Werts SetAC gut.

Irgendeine Idee wo ich da gezielt nachschauen kann? Ich könnte batPozOn zum Test niedrig ansetzen um das Verhalten zu provozieren.