ecoflow-connector-Script zur dynamischen Leistungsanpassung
-
@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.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:27Zwischendrin 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.
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..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.) -
ich würde gerne den Watt Ladewert der EF DP per Skript hochregeln.
Weiß jemand wieso der Wert nicht überschreibbar ist? Ich versuche z.B. 300W zu setzen, sehe auch kurz dass der wert in dem Datenpunkt hinterlegt wird, aber irgendwie wird das sofort auf 200W zurück gesetzt.
auch mit dem Befehl "steuere" gehts nicht.
0_userdata.0.ecoflow.app_device_property_DCEBZ8ZE7041280.data.params.inv.cfgSlowChgWatts -
@accu Das musst du über die writeables steuern, z.b. bei der D2M
0_userdata.0.powerstream.app_XXXXXXXXXXX_XXXXXXXXXX_thing_property_set.writeables.slowChgWattsDa ich keine config im Skript für die DP sehe, weiß ich nicht, ob das schon unterstützt wird. Kannst du einen writeables Ordner im *thing_property_set." Ordner deiner DP sehen?
-
@ponti92 danke für den Hinweis. Habe im Skript den Powerstream komplett gedisabled und nutze nur die Werte für die Delta Pro, die im iobroker angzeigt werden, die das Skript bereit stellt.
Habe jetzt mal auf den writeable gestellt: 0_userdata.0.ecoflow.app_155651236123138923482_DCEBZ8ZE7041280_thing_property_set.writeables.slowChgPowerund mal kurz getestet.
im iobroker wird das writeable tatsächlich jetzt mit den richtigen wert aus dem Skript befüllt (300, 400 ...) allerdings wenn ich die iOS app aufmache, steht darin leider immer noch die 200W beim Laden
-
@accu Hast du als Typ "DM" eingetragen für deine Delta Pro?
Manchmal dauert es auch ein bisschen, bis der Wert in die App übernommen wird, da die App sehr träge ist..Leider habe ich keine DP, sodass ich das Testen kann, aber zumindest in GitHub habe ich die selbe Konfiguration der DP für das slowChg gefunden:
Chargepower from grid { "from": "Android", "id": "312541279", "moduleType": 0, "operateType": "TCP", "params": { "slowChgPower": 300, "id": 69 }, "version": "1.0" },https://github.com/tolwi/hassio-ecoflow-cloud/issues/1
Das sieht eigentlich genauso aus, wie es in diesem Skript verwendet wird..
closed Delta Pro #1
-
@ponti92 nein DP für Delta Pro
Schaut so bei mir aus:
{ seriennummer: "DCE123358Z45672341280", name: "DELTA Pro", typ: "DP", subscribe: true, // "true": Alle Daten für dieses Gerät werden angefragt. "false": Es werden keine Statusdaten abgefragt },``` -
@accu dieser Type wird aber im Skript nicht explizit unterstützt. Da gibt es nur PS, D2, D2M, SM und NA (andere).
Deshalb würde ich mal „DM“ probieren, da die config für slowChgPower wie für die DP identisch sein müsste. -
@accu DM funktioniert für die Delta Pro sehr gut, inkl. setzen des AC-Ausgangs
-
@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.
-
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
-
@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. -
@aherby Bei mir klappte es heute Nachmittag mit dem dualem Laden nach dem Update
-
@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:27Zwischendrin 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? -
@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 - Realpower
-
@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 )0a5f0a3308c101120608a89ebba70612060880a3bba706120608d8a7bba706120608b0acbba70612060888b1bba706120608e0b5bba7061035182020012801400248850150335801800103880103ca0110485735325a44483453463635343333330a500a2408ffff03120608b8a0fea70612060890a5fea706120608e8a9fea706120608c0aefea7061035182020012801400248870150245801800103880103ca0110485735325a44483453463635343333330a780a4c08ffff0312220880b1f9a70610051a180000000000000000000000000000000000000000000a000012220880b1f9a70610061a180000000000000000000000000000000000000000000f1f00103518202001280140fe014820504c5801800103880103ca0110485735325a4448345346363534333333https://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,
-
Moin Moin,
ließe sich mit dem Script auch der dynamische Netzbezug/-einspeisung in der ecoflow-App darstellen?
LG
photon -
@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:
-
@ponti92 das wars. VIELEN DANK
-
@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.
-
@photon-harvester der Wert heißt glaube ich DynamicWatts und ist bei den heartbeat Daten des PS
