ecoflow-connector-Script zur dynamischen Leistungsanpassung

[Accu]

@ponti92 das wars. VIELEN DANK

[Waly_de]

@ponti92 das ist eins der nächsten Dinge auf meiner TODO Liste. Aber vielleicht bist du schneller ;-). Ich hab immer im Kopf, das nicht unbedingt das aus der PS kommt, was man per setAC einstellt. Mein Plan ist zu versuchen die Verteilung am Batteriestand fest zu machen und mit einem einzelnen Set zu setzten. Dann fiele aber die Möglichkeit weg, einen PS ohne Batterie zu regeln, was auch nur begrenzt Sinn macht. Aber es müsste dennoch berücksichtigt werden was diese ( und andere Quellen) aktuell einspeisen.

[Waly_de]

@photon-harvester der Wert heißt glaube ich DynamicWatts und ist bei den heartbeat Daten des PS

[Ponti92]

@waly_de ja genau, eine Abhängigkeit von der Prozentanzeige und evtl der Größe des Akkus. Wobei die Größe des Akkus vielleicht eine untergeordnete Rolle spielt, wenn es eh nach der prozentanzeige geht.

Eigentlich müsste das EcoFlow selber handlen, da das bei den Smart plugs auch funktioniert. Dort wird die Leistung der smartplugs einfach halbiert und an die powerstreams verteilt. Wieso geht das mit dem Grundbedarf nicht?
In der App kann ich den grundbedarf für jede einzelne PS selbst einstellen..
logischer wäre ein Grundbedarf, der über alle PS aufgeteilt wird.

[photon-harvester]

@ponti92 sehe ich auch so, besonders praktisch bei Multi-Powerstreams

[photon-harvester]

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

@photon-harvester der Wert heißt glaube ich DynamicWatts und ist bei den heartbeat Daten des PS

Dake dir, habe es gefunden. Wußte bis jetzt gar nicht, dass man die Daten vom PS mit ioBroker auslesen kann... bin nur USER, leider kein Coder.
Ich meinete, dass das Script den DynamicWatts so manipuliert, damit wir den ungefähren Bezug in der ecoflow-App sehen können. Dann könnte ich mir die VIS, cloud, DNS etc. in ioBroker sparen.

[Milchbeck]

Bekomm seid heute und Update der Delta2Max und angeschlossen Solar Panels die fehler

12.9.2023, 16:39:15.679 [info ]: javascript.0 (214) script.js.Ecoflow_New: Unbekannter Delta2Max Set Befehl: {"params":{},"from":"iOS","lang":"de-de","id":"xxx","moduleSn":"xxx","moduleType":1,"operateType":"getAllTaskCfg","version":"1.0"}
12.9.2023, 16:39:15.680 [info ]: javascript.0 (214) script.js.Ecoflow_New: Adresse: app_1664554913946284034_xxxx_thing_property_set
12.9.2023, 16:39:25.702 [info ]: javascript.0 (214) script.js.Ecoflow_New: Unbekannter Delta2Max Set Befehl: {"params":{},"from":"iOS","lang":"de-de","id":"xxx","moduleSn":"xxx","moduleType":1,"operateType":"getAllTaskCfg","version":"1.0"}
12.9.2023, 16:39:25.703 [info ]: javascript.0 (214) script.js.Ecoflow_New: Adresse: app_1664554913946284034_xxx_thing_property_set

Aber das Script läuft soweit

[aherby]

@milchbeck Der "unbekannter Delta2MaxSet Befehl" den du beschreibst war bei mir auch schon in der vorherrigen Version wo es noch oder nur Delta 2 gab vorhaben. Vielleicht ist es einfach eine Rückmeldung an die App ?

[BlackEagleBE]

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

Workaround: Schreibe History-Daten für die einzelnen Messwerte mit und rechne selbst in Verbrauch um, bzw. stelle es in float (Adapter) dar,

Die Idee hatte ich anfangs schon, aber das ist vermutlich leider viel zu ungenau, da ich ja nicht den Verbrauch Sekundengleich abfrage / logge...

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

leider ist mir noch nicht gelungen die Nachrichten, die diese Daten enthalten zu entschlüsseln. Die kommen, aber sehen übel aus. Das gleiche gilt auch für diese Daten der PS.
Vielleicht möchte jemand sich dem annehmen? In dieser Nachricht sind alle Daten enthalten. Aber mir fehlt die .Proto Definition, oder ich habs noch nicht geschnallt... (auch was für schlechtes Wetter )

0a5f0a3308c101120608a89ebba70612060880a3bba706120608d8a7bba706120608b0acbba70612060888b1bba706120608e0b5bba7061035182020012801400248850150335801800103880103ca0110485735325a44483453463635343333330a500a2408ffff03120608b8a0fea70612060890a5fea706120608e8a9fea706120608c0aefea7061035182020012801400248870150245801800103880103ca0110485735325a44483453463635343333330a780a4c08ffff0312220880b1f9a70610051a180000000000000000000000000000000000000000000a000012220880b1f9a70610061a180000000000000000000000000000000000000000000f1f00103518202001280140fe014820504c5801800103880103ca0110485735325a4448345346363534333333

https://protobuf-decoder.netlify.app

damit kann man in die Nachricht sehen. Aber ich glaube der Decoder versagt da. Mit der richtigen .proto Definition wird es besser klappen.

Danke für deine Antwort... Ich habe mich nun mal mit dem Thema Protobufs beschäftigt und ein wenig Reverse Engineering betrieben Ich denke die wichtigsten Felder scheine ich aufgelöst zu haben. Bei mir stimmen die Werte überein... wenn die Daten so in der ioBroker Objekt-Struktur landen würden, könnte man die etwas aufbereiten. Versuche es mal mit folgender .proto Datei von mir... Auf https://www.protobufpal.com konnte ich sowohl dein Beispiel als auch meine Daten damit decodieren... die konstanten Werte sind wohl alle aus dem Header.

message base {
  optional header plugData = 1;
}
message header { // --> header
  optional plug_datalists pData = 1;
  optional int32 src = 2; // immer 53  ... src
  optional int32 dest = 3; // immer 32 ... dest
  optional int32 dSrc = 4; // immer 1 ... dSrc
  optional int32 dDest = 5; // immer 1 ... dDest
  optional int32 cmdFunc = 8; // immer 254 ... cmdFunc
  optional int32 cmdId = 9; // immer 32 ... cmdId
  optional int32 dataLen = 10; // immer 76 ... dataLen
  optional int32 needAck = 11; // immer 1 ... needAck
  optional int32 version = 16; // immer 3 ... version
  optional int32 payloadVer = 17; // immer 3 ... payloadVer
  optional string deviceSn = 25; // ... deviceSn
}
enum plug_datalist_type {
  WattHours = 5;
  MinutesPoweredOn = 6;
}

message plug_datalists {
  optional int32 X_Unknown_Field1 = 1; // immer 65535
  repeated plug_datalist data = 2;
}
message plug_datalist {
  optional int32 date = 1; // unix timestamp today 00:00 GMT+0
  optional plug_datalist_type valueType = 2;
  optional bytes valuesPerHourGMT = 3;  // one value per GMT hour ... first = 00:00-0:59, second = 01:00 - 01:59, etc
}

Ich hoffe das hilft schonmal.

Nachtrag... Ach ja, evtl. eine kurze Erklärung: Er speichert den Verbrauch scheinbar je Stunde ab. Also der erste Eintrag in valuesPerHourGMT ist der Verbrauch zwischen 0:00 und 0:59:59 GMT des heutigen Tages, der zweite zwischen 1:00 und 1:59:59, etc... Leider ein bisschen blöd, da die meisten hier nicht in GMT leben Aber man bekommt alle Werte und kann sie historisieren.

Nachtrag 2: Ich habe das Script nun so angepasst, dass die Werte automatisch in den iobroker übernommen werden, indem ich die writeables erweitert habe. Dabei ist mir aufgefallen, dass im Code noch mehrfach "SP" bzw. 'SP' verwendet wird, statt dem in der letzten Version geänderten "SM" für SmartPlugs. Ebenso habe ich gesehen, dass die gleiche CmdId auch für den PS verwendet wird, dort habe ich aber noch nicht geschaut, ob identisch ist oder es ggf. weitere Enums gibt...

[Waly_de]

@blackeaglebe sehr schön... befasse ich mich nächste Woche mit, wenn ich wieder zuhause bin.

[Waly_de]

@blackeaglebe wichtig noch für deine weitere Arbeit:

mein Beispiel enthält 3 unterschiedliche Nachrichten inclusive Header
Du musst nur :

 optional header plugData = 1;

gegen

repeated header plugData = 1;

tauschen, damit das auch in deiner Definition verarbeitet werden kann.
Den header hab ch ja schon vollständig definiert im Script. vielleicht sogar Definitionen für andere Nachrichten, die ich nur noch nicht richtig zugeteilt habe. Klau dir am besten die schon bestehenden Definitionen aus dem Script. bin gespannt was du noch raus findest.

[BlackEagleBE]

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

Den header hab ch ja schon vollständig definiert im Script. vielleicht sogar Definitionen für andere Nachrichten, die ich nur noch nicht richtig zugeteilt habe. Klau dir am besten die schon bestehenden Definitionen aus dem Script.

Danke für die Info! Brauchte ich aber gar nicht - das macht dein Script scheinbar bereits automatisch
Ich hatte die .proto-Datei zuerst ohne Einbinden in deinen Code erarbeitet.
Mir ist daher auch erst später aufgefallen, dass der Header und das Handling bei dir bereits genau so drin ist und das alles von deinem Script korrekt interpretiert wird. Ich musste daher lediglich proto-Defintion (für enum, datalists, datalist) neu hinterlegen und die datalists in die writeables eintragen (und das ignor beim PS rausnehmen). Daher hatte ich kein Problem mit dem optional/repeat und dem Header... Die Daten werden bei mir übrigens bereits erstmal korrekt eingelesen und der Verbrauch (über ein eigenes Script) nach Tag/Monat/Jahr (in der korrekten zeitzone) zusammengezogen... Genau das was ich wollte. Merci.

bin gespannt was du noch raus findest.

Was fehlt denn noch außer dem einen Unknown Feld? In dieser Nachricht hatte ich sonst alles, oder?
Wenn ich dir noch irgendwie helfen kann, meld dich einfach.

[Accu]

@Waly_de weißt Du was dieser Fehler bedeutet und was ich dagegen machen kann?

[Waly_de]

@blackeaglebe mega… das sind immer die Besten sagen, die einfach funktionieren
Wenn du mir Deine geänderte Version von meinem Script mit Kommentaren an Stellen die du ergänzt bzw. geändert hast schickst, wäre das super.

Ich kann im Moment leider nichts machen erst nächste Woche wieder …

[Waly_de]

@accu Netzwerk Probleme vermutlich… Neustart und warten könnte helfen

[umele]

Hallo zusammen,

ich lese hier fleissig mit und bin dank der vielen Inputs (und trotz meiner Inkompetenz) schon recht weit gekommen:
Inzwischen bekomme ich die Daten vom Sensor in iobroker, und habe die Sensor-ID im Script eingetragen.
Aaaber - ich finde nirgends das Objekt 0_userdata.0.ecoflow.RealPower (und kann auch nicht erkennen, dass sich die Einspeisung anpasst).
Was mache ich falsch?

Edit: noch ein Screenshot meiner Ecoflow-Objektstruktur

vielen Dank
umele

[photon-harvester]

Moin Moin,
habt ihr einen Tip für mich, wie ich verschiene IDs zu einem Wert addieren kann, um es anschließend zu visualisieren?
Bsp. ID:AkkuSoC1 +ID:AkkuSoC2 = ID:AkkuSoCgesammt --> dann ablegen in history für z.B. VIS
Danke
PS: kann leider nicht programmieren, nur copy-paste oder Widgets

[umele]

Habe das Script jetzt mal mit voller Protokollausgabe laufen lassen. Es findet anscheinend den Sensor überhaupt nicht.

Es kommt noch nicht mal dazu die Funktion SetBasePower auszuführen (in der wird das Objekt RealPower erstellt). Laut Script müsste diese Funktion geloggt werden.

Auch im Debug Modus ist nichts zu finden. Bin gerade ratlos...

Schade, dass der Debug Modus es nicht erlaubt, das Script step-by-step auszuführen - dann könnte ich das Problem vielleicht finden...

Wäre echt toll, wenn jemand eine Idee hat - Danke!!

[Waly_de]

@umele wie du sagst, das Script prüft die Existenz des Sensors. Es muss also an der id liegen was genau hast du denn als smartmeterid angegeben?

[Dreffi]

@waly_de
Direkte Frage an Markus:
Ich habe jetzt mehrfach beobachtet, dass sich einer meiner Powerstreams im falschen Prio Modus befand.

Einer ist konfiguriert bei vollem Akku auf Prio Akku zu schalten, der andere soll voll einspeisen. Das klappt soweit einwandfrei.
Gestern und heute fiel mir abends auf, dass der Powerstream der voll einspeisen soll auf Prio Akku stand.

Ich kann nicht sagen wieso hier überhaupt die Priorisierung geändert wurde und ob das Script dafür verantwortlich ist. Da der Bedarf irgendwann höher als die abgegebene Leistung war, hätte hier aber irgendwann umgeschaltet werden müssen.

Der andere Powerstream wechselte unabhängig davon wunschgemäß wegen Bedarfs von Prio Akku auf Einspeisung. Der Bedarf war schnell wieder gering. Die eingestellte AC Last betrug dann wieder 0 W, aber der Powerstream wurde trotz vollem Akku nicht wieder auf Prio Akku zurückgestellt.

Die Trigger für das Umstellen der Priorisierung scheinen nicht so richtig zuverlässig zu funktionieren.