ecoflow-connector-Script zur dynamischen Leistungsanpassung

[GerdSo]

@waly_de Danke, habe es jetzt auf 3000 hochgesetzt und es steigt zwar aus, durch den reconnect verbindet sich es aber wieder und es erscheint nicht mehr die error Zeile.

[BlackEagleBE]

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

[aherby]

@waly_de So heute wurde für die Delta 2 Max ein bzw zwei neue Updates ausgerollt. Einmal WLAN und Firmware.
Einige meinten nun würde das duale Laden also über Powerstream und Solar-Module an der Delta 2 Max funktionieren.
Habe auch die Updates eingespielt und bin gespannt was ab morgen passiert oder in den Logs zu finden ist.

[BlackEagleBE]

@aherby Bei mir klappte es heute Nachmittag mit dem dualem Laden nach dem Update

[Waly_de]

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

Da ich jetzt ein paar Tage unterwegs bin nur ganz Kurz...

@waly_de
Nach langen Debuggen und versuchen zu verstehen wie das Skript so funktioniert konnte ich den Übeltäter im Skript nun weiter eingrenzen.
An dieser Codestelle wird überprüft ob gewisse Zeitstempel größer/kleiner sind und dann ob Realtime sich in einem gewissen Zeitrahmen geändert hat.
Ich könnte mir vorstellen, dass das bei 2 PS nicht ganz funktioniert, da diese nicht synchron geregelt werden, sodass die Hauslast nur mit einer PS geregelt wird und die 2. auf einem beliebigen Wert stehen bleibt.
Sobald das Skript dann in Zeile 12 hinein kommt, returned es, bevor es den RealPower Value weiter unten schreiben kann.

Sehr gut analysiert Aber Du siehst, ich hab mir da einige Gedanken zu gemacht und verschiedenes Versucht. Das soll schon genau so sein.
Sinn: Wenn ich einen neuen Wert für die Einspeisung setzte, dann muss beim nächsten Messintervall der Wert für die Tatsächliche Eispeisung der PS (Das ist ja die Grundlage für die Berechnung des Bedarfs) Jünger sein als der Zeitpunkt des letzten SetAC. Wenn das nicht so ist, ist dieser Wert eigentlich Wertlos. Darum skipe ich und warte auf das nächste Intervall. Als Backup wird nach der halben Rückschauzeit mit dem alten Wert weiter gearbeitet. Das Funktioniert auch bei mehreren PS ganz gut. Natürlich nur so lage, wie der PS auch per MQTT Daten in die Cloud sendet. Tut er das nicht, kann das Script auch nichts mehr berechnen. Mein PS Legt sich definitiv komplett schlafen, wenn keine Solarenergie kommt und der Accu leer ist.

                for (const item of ConfigData.seriennummern) {
                    if (item.typ == "PS") {
                        const asn = item.seriennummer;
                        const LastACset = getState(ConfigData.statesPrefix + '.app_' + mqttDaten.UserID + '_' + asn + '_thing_property_set.setAC').ts;
                        const invOutputWattsState = GetValAkt(ConfigData.statesPrefix + ".app_device_property_" + asn + ".data.InverterHeartbeat.invOutputWatts", 50, true);
                        const invOutputWatts = Number(invOutputWattsState.val) / DIVISION_FACTOR;
                        const lastOutset = invOutputWattsState.ts;

                        if ((Number(lastOutset) < Number(LastACset)) && invOutputWatts !== 0) {
                            const lastRealset = getState(ConfigData.statesPrefix + ".RealPower").ts;
                            if (Number(lastRealset) > Date.now() - ((ConfigData.MinValueMin * 1000 * 60) / TOLERANCE_PERIOD_FACTOR)) {
                                log("RealPower Set Warte auf aktuelle Daten von: " + asn + " lezter: " + new Date(lastOutset).toLocaleTimeString('de-DE') + " / ACset: " + new Date(LastACset).toLocaleTimeString('de-DE'));
                                WorkInProz = false;
                                return;
                            } else {
                                //log("Überspringe ab jetzt warten auf Daten von: " + asn + " und setzte Wert für Einspeisung auf 0 ")
                                //setState(ConfigData.statesPrefix + ".app_device_property_" + asn + ".data.InverterHeartbeat.invOutputWatts", "0")
                                Einspeisung += invOutputWatts;
                            }
                        } else {

                            Einspeisung += invOutputWatts;
                        }
                    }
                }
                const RealPower = Number((Hausstrom + Einspeisung).toFixed(0))
                if (RealPower + 100 < LastRealPower) {
                    //log("PeakSkip Delta: " + (LastRealPower - RealPower) )
                } else {
                    setState(ConfigData.statesPrefix + ".RealPower", RealPower);
                }
                LastRealPower = RealPower
                WorkInProz = false;

Ich habe Zeile 12 wieder einkommentiert und nach einiger Zeit habe ich diese Logs auch bekommen:

2023-09-10 23:23:14.868 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:00 / ACset: 23:23:14
2023-09-10 23:23:20.192 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:00 / ACset: 23:23:14
2023-09-10 23:23:25.498 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:00 / ACset: 23:23:14
2023-09-10 23:23:30.836 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:23:36.173 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:23:41.494 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:23:46.836 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:23:52.227 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:23:57.586 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:24:03.187 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:24:08.442 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:24:13.942 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:23:01 / ACset: 23:23:27
2023-09-10 23:24:19.273 - info: javascript.0 (1259) script.js.Ecoflow3: Hausstrom: 27.19
2023-09-10 23:24:19.273 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower: 316
2023-09-10 23:24:19.274 - info: javascript.0 (1259) script.js.Ecoflow3: LastRealPower: 326
2023-09-10 23:24:19.274 - info: javascript.0 (1259) script.js.Ecoflow3: Einspeisung: 289.3
2023-09-10 23:24:24.676 - info: javascript.0 (1259) script.js.Ecoflow3: Hausstrom: 27.19
2023-09-10 23:24:24.678 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower: 318
2023-09-10 23:24:24.679 - info: javascript.0 (1259) script.js.Ecoflow3: LastRealPower: 316
2023-09-10 23:24:24.679 - info: javascript.0 (1259) script.js.Ecoflow3: Einspeisung: 290.4
2023-09-10 23:24:30.158 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:24:20 / ACset: 23:24:27
2023-09-10 23:24:35.525 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:24:20 / ACset: 23:24:27
2023-09-10 23:24:40.984 - info: javascript.0 (1259) script.js.Ecoflow3: RealPower Set Warte auf aktuelle Daten von: XXXXXXXXXXXXXXX lezter: 23:24:20 / ACset: 23:24:27

Zwischendrin kommen dann wieder Werte (Hausstrom, RealPower etc), aber das Skript hängt dann anschließend weiter in dieser Schleife und der Realpower Wert wird nur all 1 min 30s aktualisiert, was dann die Regelung komplett ruiniert.

aber du siehst an den Logs ja super, was das Problem ist. Es kommen einfach keine Daten mehr.
du kannst noch mit TOLERANCE_PERIOD_FACTOR spielen und den wert vergrößern , damit er schneller mit den alten Werten weiter macht.

EDIT:
Es sieht so aus, als ob die Daten vom ersten PS nicht richtig ankommen und er deshalb da hängenbleibt. Auch wenn ich das ganze auskommentiere und immer die Einspeisung schreibe, dann fehlt dort der Wert vom ersten PS. Irgendwie kann er die nicht mehr abrufen..

Das ist das Problem

Ich vermute es liegt doch irgendwie an der MQTT Verbindung und dem reconnect Zyklus in der Nacht. Da wird ja nur alle 15min reconnected, wenn beim PS nichts mehr ankommt. Tagsüber jede Minute. Muss es noch länger beobachten.
Jedenfalls konnte ich feststellen, dass bei einem Ausfall die Regelung wieder gestartet hat, nachdem ich die App geöffnet habe. Als ich dann die App komplett geschlossen habe, ist die Regelung wieder stehen geblieben. (Ein restart des Skripts hilft auch dabei, sich wieder mit dem Mqtt zu verbinden.)

Das ist immer so: App schließen beendet sofort alle Kommunikation per MQTT. Erst nach einem Reconnect gehts weiter.
Du kannst ja das Intervall für nächtliche Reconnects runter setzen. Aber ich denke der PS schläft einfach irgendwann. Dann kann man auch nichts mehr damit regeln. Vielleicht nutzt es etwas, wenn ich schlafende PS einfach skipe? Macht der PS denn noch was? Hat er noch Bat-Power, oder nur der, der noch zu erreichen ist?

[Waly_de]

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

@waly_de ich weiß die Smartplugs magst du nicht so aber vielleicht für die Anzeige von Energieflüssen würde ich sie vielleicht weiter verwenden. Wäre es für dich einfach "zentral" die Wattwerte der Smartplugs durch 10 zu teilen und als nur lesendes Objekt auszugeben? Scripte liegen mir gerade nicht so oder irgendwie fehlt mir die Stelle wo ich durch 10 teile oder so.

Ne leider nicht. Aber mach doch selbst. Neues Script und dann sowas:

var regex = /^0_userdata\.0\.ecoflow\.app_device_property_.*\.data\.plug_heartbeat_pack\.watts$/;
on({ id: regex, change: "ne" }, function (obj) {
    var sum = 0;
    var states = $("0_userdata.0.ecoflow.app_device_property_*plug_heartbeat_pack.watts").each(function (id, i) {
        if (regex.test(id)) {
            var value = getState(id).val;
            sum += value;
        }
    })
    // Teile die Summe durch 10
    var newValue = sum / 10;
    
    // Schreiben Sie den neuen Wert in den Ziel-Datenpunkt
    // Selbst anlegen:
    //setState("0_userdata.0.meinePlugWatt", newValue);

    log("Summe der Plugs:" + newValue)
});

das summiert alle Plugs in einen Wert. Kannst natürlich auch jeden Plug einzeln umrechnen und schreiben

Ich brauche zudem noch mal eine Erklräung was folgende Objekte genau sind oder wie ich was damit machen:

• Realpower
  das was verbraucht wir, hier ist die Einspeisung der PS abgezogen... damit die Grundlage für die Berechnung des Bedarfs

• totalPV
  Summe aller PV-Eingänge aller PS

• RegulationState: ""
  // Wenn angegeben, kann mit diesem State die Regulation ein- und ausgeschaltet werden (Wird automatisch unter 0_userdata.0.ecoflow angelegt)

• BasePowerOffset: 30 (kann der Wert auch negativ sein)
  theoretisch ja... macht das sinn?

und was würde passieren wenn man die Smartplugs bei BasePowerOffset irgendwie berücksichten könnte / würde?

vielleicht ist es auch gerade noch zu warm oder das Brett vorm Kopf löst sich nicht. Danke

Ich überlege immer noch... Irgendwo muss ich einfach die Einspeiseleistung der Plugs aufaddieren, dann stören sie nicht mehr .... aber mir ist auch warm

[Waly_de]

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

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.)

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.

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

[photon-harvester]

Moin Moin,
ließe sich mit dem Script auch der dynamische Netzbezug/-einspeisung in der ecoflow-App darstellen?
LG
photon

[Ponti92]

@waly_de danke für die Erklärungen!
Ja ich habe zurzeit den reconnect nachts von 15 min auf 1 min gestellt, da bei diesem Wetter meine powerstreams die ganze Nacht durchlaufen und ich morgens immer noch ca 30% Akku habe.
Dadurch läuft es jetzt erst mal wieder.

Als nächstes wollte ich verstehen, wie du die einzelnen PS ansprichst und evtl einen neuen Modus hinzufügen, der die Leistung der PS nach einer gewissen Logik aufteilt.
Weil manchmal wird nur eine PS bedient und dann die andere, was ein bisschen Zufall ist, je nachdem welche PS gerade eingestellt wird.

Sie sieht es dann meistens aus, das ist der akkustand von beiden Akkus über die Nacht:

[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.