ecoflow-connector-Script zur dynamischen Leistungsanpassung

[kaiausBrieselang]

Hallo,
Ich habe noch eine Frage zu den InWatts-/InputtWatts-Werten und die Übertragung in die Objekte des IOBroker.
Ich habe im Moment nur ein Solarmodul angeschlossen.
In der D2M habe ich für den PV1 Eingang
0_userdata.0.ecoflow.app_device_property_R351Zxxxxxxx.data.params.mppt.inWatts
und für den PV2 Eingang
0_userdata.0.ecoflow.app_device_property_R351Zxxxxxxxx.data.params.mppt.pv2InWatts
genommen, um die Eingangsleistung anzuzeigen (im VIS).
Ich war hier etwas irritiert, dass das Objekt für den PV1 Eingang nicht "...pv1InWatts" betitelt wurde.
Ist das Absicht und so gewollt?
Oder habe ich das falsche Objekt ausgewählt?

Beim PS wiederum habe ich für PV1
0_userdata.0.ecoflow.app_device_property_HW51Zxxxxxx.data.InverterHeartbeat.pv1InputWatts
und für PV2
0_userdata.0.ecoflow.app_device_property_HW51Zxxxxxx.data.InverterHeartbeat.pv2InputWatts
genommen.
Beim PS habe ich jedoch das Phänomen, dass dort ein dreistelliger Wert übertragen wird, obwohl in der APP nur zweistellig ist. Es scheint, als ob hier noch eine Nachkommastelle im IOBroker dargestellt wird. Ist das korrekt? Ist das so gewollt?
Oder bin ich einfach am falschen Objekt dran?
Danke für eure Hilfe
Gruß Kai

[foxthefox]

@kaiausbrieselang
Wenn ich nicht irre, so werden die Daten bei der Verwendung des scripts einfach übernommen. Für normierte Werte mit Einheit empfehle ich den ecoflow-mqtt Adapter, der kann auch parallel zum Script laufen (nur nicht mit identischen Android-Gerätekennung).

[kaiausBrieselang]

@foxthefox
Danke für deine Antwort. Der Ecoflow-mqtt Adapter läuft bei mir nicht. Die 4 Felder werden nicht automatisch befülllt.

[foxthefox]

@kaiausbrieselang
Dann hängt es wohl an der admin Version die notwendig ist, damit die Felder gefüllt werden.

[lui1307]

@waly_de Hallo Waly_de, ich habe nun Dein Script in einer PI 4 Umgebung laufen und die lokale Einbindung meines Tibber Puls mit Deinem Zusatz-Script „Tibber Pulse: Verbrauchsdaten lokal auslesen“ vorgenommen.
Die Tibber Puls Daten kommen. Dein Script liest die Daten per SmartmeterID: "0_userdata.0.TibberPulse.SML.Power" auch ein.
Angeschlossen und konfiguriert habe ich aktuell eine DeltaPro plus Zusatz Akku, sowie einen Powerstream mit AC Einspeisung.
Solarmodule sind noch nicht anschlossen. Die würde ich dann später ich gerne wegen der höheren Einspeiseleistung direkt an die DeltaPro anschließen wollen.
Wie schon zuvor mal gesagt bin ich noch relativ unerfahren mit der Handhabung des ioBroker.
Mir würde es daher helfen, wenn Du mir kurz beschreiben könntest wie ich nun das System weiter testen kann. Was und wie sollte ich vorgehen?
Wie kann ich es denn nun erreichen, dass z.B. das Script eine AC-Einspeisung über den Powerstream einleitet. Am besten so viel, wie der Puls an Leistung misst.
Vielen Dank im Voraus!
P.S. Eine Spende ist auch auf dem Weg, LG

[foxthefox]

@kaiausbrieselang
Für die 4 Felder braucht es den Admin Adapter mit mind 6.12.4, mittlerweile its 6.13.16 im stable.
Wenn also die 6.13.16 des Admin Adapters installiert ist, sollte es mit den 4 Feldern klappen.

Ansonsten hat der Adapter noch einen eignen Thread:
https://forum.iobroker.net/topic/69819/neuer-adapter-ecoflow-mqtt

[Accu]

@Waly_de ich habe Dein Skript jetzt seit einiger Zeit erfolgreich am laufen. Vielen Dank dafür und Deine Arbeit!!!

Dennoch eine Frage an Dich und auch an die Gruppenmitglieder hier:
Ich nutze an dem AC Ladeeingang meiner Delta Pro einen Shelly, welchen ich in der entsprechenden Sektion des Skripts konfiguriert habe. Das klappt auch super gut. Bei PV Überschuß, schaltet der Shelly automatisch ein und läd zzl über AC meine DP mit ZA auf. Dabei wird entsprechend reguliert, wieviel Überschuss da ist.

Ich hatte selber mal ein ähnliches Skript gebastelt, welches dynamisch über AC in Abhängigkeit des verfügbaren PV Überschusses nachregelt. Bin aber dann davon wieder abgekommen, weil hier im Forum mir jemand den Hinweis gegeben hat, dass die DP (und wahrscheinlich auch andere EF Geräte) den Ladewert beim AC Eingang im EEPROM speichern und nicht im Flash Memory. Ich hatte den EF Support dazu einmal angeschrieben und die haben mir dieses bestätigt: "The change to the AC Load setting will be written to EEPROM memory not flash memory."

Jetzt ist es so, dass das EEPROM wohl eine sehr begrenzte Beschreibbarkeitsanzahl (ca. 100.000mal) gegenüber dem Flash Memory hat, bevor der Chip "stirbt".
D.h. ändert sich der AC Lade-Watt-Wert häufig geht die Lebensdauer immer weiter zurück.
Wie siehst du das?

[Ralf77]

@accu das wäre ja der absolute Hammer und wäre so, als würde eine regelmäßige Änderung des Gaspedals die Lebensdauer des Autos reduzieren.

Wenn dem so wäre, dann wäre ja auch die dynamische Änderung der Einspeisung ein Problem, oder? Macht ja keinen Sinn das unterschiedlich zu implementieren.

Wenn dem so ist, dann gehe ich davon aus, dass meiner die Garantiezeit nicht überleben wird

[Accu]

@ralf77 ich kann nur wiedergeben, was ich hier im Forum aufgeschnappt hatte und was mir der EF Support bestätigt hat.
"*This is Elena from EcoFlow.

The change to the AC Load setting will be written to EEPROM memory not flash memory.

Hope my answer can help you.*"

Ich denke bei der Einspeisung über den PowerStream ist das sicherlich anders zumal man ja davon ausgehen muss, dass sich die Einspeiseleistung eben ständig verändert, wenn man den PS in Kombination mit den Smart Plugs betreibt.

Beim AC Ladeeingang tust du aber in der Regel die Ladeleistung nicht ständig ändern (außer du nutzt eben ein Skript, was von EF so nicht vorgesehen war). Denke damit ändert sich diese nicht 10.000 mal.

@Homoran = FYI

[giovanne]

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

...
Ich denke bei der Einspeisung über den PowerStream ist das sicherlich anders zumal man ja davon ausgehen muss, dass sich die Einspeiseleistung eben ständig verändert, wenn man den PS in Kombination mit den Smart Plugs betreibt.
...

Soweit ich das überblicke, ändern die Plugs aber nicht "permanentWatts" was die Einspeisekontrolle nutzt (vermutlich EEPROM) sondern die nutzen "dynamicWatts" (vermutlich nicht EEPROM), siehe Ecoflow API Beschreibung (https://developer-eu.ecoflow.com/us/document/powerStreamMicroInverter)...

[foxthefox]

es wär halt schon schön, wenn man das dynamicWatt beeinflussen könnte. Nachdem in einem der letzten PlugUpdates geschrieben war, daß Bluetooth abgeschalten wird um WLAN Stabilität zu verbessern (und auch danach kein Stecker über BLE mehr gescannt werden konnte), sollte es einfacher werden die Kommunikation mitzuschneiden.
Habe bisher nur UDP Telegramme gesehen, die aber mehr Ping Charakter hatten. Ich glaube eher, daß es über ein noch unbekanntes topic über mqtt läuft.

[giovanne]

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

es wär halt schon schön, wenn man das dynamicWatt beeinflussen könnte. ....
Habe bisher nur UDP Telegramme gesehen, die aber mehr Ping Charakter hatten. Ich glaube eher, daß es über ein noch unbekanntes topic über mqtt läuft.

Ja wäre cool wenn du da etwas bzgl Kommunikation der Geräte heraus findest. (Idealerweise in lokalen Netz Aktuell hilft nur Smartplug selbst für Beeinflussung von dynamicWatts zu nutzen.

[Waly_de]

@accu das höre ich jetzt auch zum ersten Mal. Das wäre natürlich nicht förderlich. Allerdings müsste mein Power Stream dann längst gestorben sein, denn grob überschlagen habe ich mindestens 200000-400000 mal den Wert gesetzt seit Juli 2023.
Nichts, desto trotz sollte man mit den Jungs und Mädels von ECO-FLOW sprechen. Durch eine Firmware Änderung könnte man vermeiden, dass jedes einzelne Mal in das EEPROM geschrieben wird. wenn du da sowieso in Kontakt bist, regt das doch mal an.
Was ich tun könnte, wäre das Intervall mit dem geschrieben wird zu verlängern. Außerdem könnte ich ein Modulo einführen. Also den Wert nur in bestimmten Stufen, zum Beispiel 50 W ändern, und auch nur dann schreiben, wenn sich der aktuelle Messwert von dem zuvor geschriebenen unterscheidet. Damit könnte man die Frequenz mit der in das EEPROM geschrieben wird deutlich reduzieren.
Das alles geht natürlich auf Kosten der Reaktionsfähigkeit und Genauigkeit des Skripts. Das wäre wirklich schade.

[Accu]

@waly_de das wäre gut. Zur Klarstellung ich spreche hier nicht vom PowerStream, sondern vom AC Ladeeingang an der Delta Pro.

Wie oben beschrieben nutze ich die Sektion in deinem Skript wo man zzl. noch einen Shelly angeben kann, der den Ladeeingang der Delta Pro AN bzw. AUS schaltet. Ist der AC Ladeeingang einmal AN, regelt ja Dein Skript die Ladeleistung von z.B. 200W oder wie in meinem Fall bis zu 700W.

Dieser Wert (in der App am Schieberegeler) wird wohl im EEPROM gehalten.

[Waly_de]

@accu okay, das beruhigt mich.
Anbei eine neue Skriptversion mit den besprochenen Änderungen. Ich hatte noch keine Gelegenheit das Intensiv zu testen, daher poste ich das zunächst nur in diesem Beitrag, quasi als Beta-Fassung.

(1.2.3) 21.02.2024

• Neue Parameter für den Bereich AdditionalPower: NoFeedIn und NoPV.
  • Offset: Wert wird zum Messwert addiert um Messabweichungen ausgleichen zu können
  • NoFeedIn: true setzen, wenn die enthaltene Leistung nicht ins Hausnetz fließt. (Nur in PVTotal aufnehmen)
  • NoPV: true setzen, wenn die enthaltene Leistung nicht in TotalPV einfließen soll. (Nur in Realpower aufnehmen)
• Neue Parameter für Überschussladung: ExcessChargeMinRegulatePause und ExcessChargeRegulateSteps
  • ExcessChargeMinRegulatePause: Mindestpause in Minuten zwischen einzelnen Regelbefehlen (EEPROM-Schutz)
  • ExcessChargeRegulateSteps: Stufen in Watt, in denen die Werte geändert werden sollen
• Neuer Parameter "RegulationIntervalSec": Intervall in Sekunden, in denen gemessen und reguliert wird

ecoflow-connector_v123.txt (21.02.2024)

[Accu]

@waly_de scheint erstmal zu laufen. Werde es weiter testen. Einzige Fehlermeldung bisher:

[guhfy9966]

@waly_de

Ich habe das jetzt mal ausprobiert mit den "externConfig" Parameter.
Das Objekt wird auch korrekt durch mein Blocky script gesetzt, das Ecoflow Script reagiert jedoch gar nicht darauf.

Sind meine Variablen hier korrekt? Soll für 3 Powerstream gesetzt werden.

 {
        VarName: "seriennummern[0].MaxPower",                                    //Variabelname aus "ConfigData" bei Aufzählungen [0...X] in der Reihenfolge der Angaben 
        id: "0_userdata.0.MaxPower_manuell"                     //Das Objekt (State) das den Wert für diese Variable enthalten soll. Muss manuell angelegt werden. 
    },
    {
        VarName: "seriennummern[1].MaxPower",                                    //Variabelname aus "ConfigData" bei Aufzählungen [0...X] in der Reihenfolge der Angaben 
        id: "0_userdata.0.MaxPower_manuell"                     //Das Objekt (State) das den Wert für diese Variable enthalten soll. Muss manuell angelegt werden. 
    },
    {
        VarName: "seriennummern[2].MaxPower",                                    //Variabelname aus "ConfigData" bei Aufzählungen [0...X] in der Reihenfolge der Angaben 
        id: "0_userdata.0.MaxPower_manuell"                     //Das Objekt (State) das den Wert für diese Variable enthalten soll. Muss manuell angelegt werden. 
    },
   

[Waly_de]

@guhfy9966 das sieht korrekt aus. Allerdings ist MaxPower so ziemlich die einzige variable, die im Moment während der Laufzeit nicht zu verändern ist. das ist auch mit Vorsicht zu genießen, denn MaxPower reguliert auch die Batterieladung.

Was genau möchtest du denn erreichen, indem du diese Variable änderst?

[Ralf77]

Hallo, ich habe seit 2 Tagen das Problem, dass mein Script nicht mehr funktioniert. Ich hatte bisher immer vermieden Updates meiner Adapter zu machen (never touch a running system). Da das Script seit 2 Tagen aber meinen Hausstrombedarf immer auf "0" setzt (davor ist das Script seit Wochen ohne Probleme gelaufen) habe ich heute mal die ganzen Updates der Adapter und vom Host durchgeführt. Leider hat das nichts geändert. Die Regelung geht immer noch nicht (Hausstrombedarf wir dimmer auf 0 gesetzt) und ich bekomme folgende Fehlermeldungen im Protokoll:

2024-02-29 17:22:40.684 - error: javascript.0 (130429) npm
2024-02-29 17:22:40.686 - error: javascript.0 (130429)
2024-02-29 17:22:40.688 - error: javascript.0 (130429) WARN deprecated har-validator@5.1.5: this library is no longer supported
2024-02-29 17:22:41.030 - error: javascript.0 (130429) npm
2024-02-29 17:22:41.032 - error: javascript.0 (130429) WARN deprecated node-inspect@2.0.0: This module is part of Node.js core and does not need to be installed separately. It is now unmaintained.
2024-02-29 17:22:41.246 - error: javascript.0 (130429) npm
2024-02-29 17:22:41.247 - error: javascript.0 (130429) WARN deprecated uuid@3.4.0: Please upgrade to version 7 or higher. Older versions may use Math.random() in certain circumstances, which is known to be problematic. See https://v8.dev/blog/math-random for details.
2024-02-29 17:22:41.487 - error: javascript.0 (130429) npm
2024-02-29 17:22:41.488 - error: javascript.0 (130429) WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142

Ich wäre über Hilfe und Tipps sehr dankbar, da das System für mich erst mit dem Script wirklich sinnvoll funktioniert.

Aktuell verwende ich folgende Version:
Version: 1.2.1
Release date: 05.01.2024

Und folgende Instanzen:

mikeal created this issue in request/request

open Request’s Past, Present and Future #3142

[guhfy9966]

@waly_de

ich wollte wenn mein eAuto geladen wird die Einspeisung deutlich beschränken, damit nicht jedesmal die Batterien komplett leer sind...
Oder geht das auf einen eleganteren Weg?