@aherby Bei mir klappte es heute Nachmittag mit dem dualem Laden nach dem Update
NEWS
Best posts made by BlackEagleBE
-
RE: ecoflow-connector-Script zur dynamischen Leistungsanpassung
Latest posts made by BlackEagleBE
-
RE: ecoflow-connector-Script zur dynamischen Leistungsanpassung
@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. -
RE: ecoflow-connector-Script zur dynamischen Leistungsanpassung
@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... -
RE: ecoflow-connector-Script zur dynamischen Leistungsanpassung
@aherby Bei mir klappte es heute Nachmittag mit dem dualem Laden nach dem Update
-
RE: ecoflow-connector-Script zur dynamischen Leistungsanpassung
Hallo und vielen lieben Dank für das tolle Script.
Durch dieses Script wurden bekanntlich viele Ecoflow Smartplugs arbeitslos,... man könnte diesen jedoch eine zweite Chance geben und in iobroker als "gewöhnlichen" Smartplug (wie Tasmota, Shelly,...) weiterbeschäftigen.
Dazu kann man diese in einem zweiten ecoflow-Account verwenden und mit einer zweiten Instanz des Scripts in den iobroker einbinden (also zweiter Account nur mit den Plugs), z.B. nach 0_userdata.0.ecoflow2 ... So melden die Plugs bei mir auch keinen Verbrauch an die PowerStream.Nun mein Problem:
Leider liefert der Heartbeat für die Smart Plugs nur den aktuellen Verbrauch und offenbar keinen Wh Zähler, weder "seit dem Einstecken", noch pro Tag, Woche, Monat, etc. Übersehe ich etwas? So sind sie für mich leider wertlos. In der App sehe ich diese Werte (also nicht nur im Graphen, auch in der UI) und zweifelsohne muss der Plug einen solchen Zähler in irgendeiner Form mitschreiben... Besteht die Möglichkeit diesen Wert irgendwie als Objekte abzufragen? Ist hier nicht alles Subscribed? (Meine MQTT Kenntnisse sind leider zu gering um selbst zu stochern.)LG