NEWS
Neuer Adapter ecoflow-mqtt
-
@klausn
Danke.
Die Objektstrukturen sind für 2+3 bestimmt angelegt, aber werden noch nicht befüllt, richtig?
Das hängt a den Telegrammen, Powerocean schickt die Batterien als Einzeltelgramme und nicht als Array, anstatt repeated sind es nur einzelne Batterien. Da ich bisher nicht mit solchen Telegrammen gerechnet habe, wird nur das letzte von den vielen mit gleicher Kennung übernommen. Je nachdem welche Batterie die letzte in dem Telegramm ist, gibt es neue Werte. Für 2,3 die tendenziell immer in der Mitte liegen können, ist somit die Chance recht schlecht.
Ich muss intern etwas umbauen um alle Telegrammteile zu verarbeiten.
Die Übergänge nach 0 könnten damit zusammenhängen. -
@bentschik sagte in Neuer Adapter ecoflow-mqtt:
@foxthefox Alles klar, das klingt ja halbwegs zuversichtlich
Melde Dich gerne falls ich Dir mit Testdaten etc. aushelfen kann.
Fall es nützlich ist: Derzeit hängen 4x Stream AC Pro, die als ein System zusammengefasst sind, als Systemkomponente am PowerOcean.In der Ecoflow-Facebook-Gruppe wurde mir bereits bestätigt, dass meine Konstellation sehr ungewöhnlich ist.
Ich habe auch ehrlich gesagt nicht damit gerechnet, dass ich die dann doch relativ preiswerten AC-Speicher in den PowerOcean integriert bekomme. Von den Wandlungsverlusten mal abgesehen. Funktionieren tut das Ganze tadellos.@bentschik
ich habe eine nächste Version angefangen (1.4.4)
die könntest du über expertmode und custom und der url: https://github.com/foxthefox/ioBroker.ecoflow-mqtt/tree/1.4.4
installieren
Es sollte laufen, testen konnte ich aus Mangel an Testdaten nicht.Der neue ParallelEnergyStreamReport sollte nun 3 Anteile haben.
ohne prefix evtl. das gleiche wie vorher, dann mit ocean als master system und system1 als slave für die STREAM.
Einfach mal die Werte anschauen und berichten was du ablesen kannst.
unknown9/10 ist nicht klar was das ist, höchstwahrscheinlich auch eine Leistung. -
@foxthefox Ich habe es direkt mal ausprobiert. Das Resultat passt noch nicht so ganz, aber dafür ist das Testen ja da:
-
@bentschik
Ok, dann schau doch mal was im debug mode so geloggt wird. Dazu in der Gerätezeile und auf der ersten Seite msgSetGet msg Update ein Häckchen setzen. Es müsste die neue Objektstruktur Parallel… dabei sein.
Gern auch das log posten bzw. als persönliche Nachricht -
@foxthefox
Tausend Dank. Es geht nun.
Sollte was auffallen, melde ich mich. -
@mouk
Danke für die Rückmeldung. -
@foxthefox Bin endlich mal dazu gekommen, die logs einzusammeln...
Den "grossen" log kann ich Dir vermutlich ersparen, weil ich darin schon folgendes sehe:
2025-09-08 09:54:14.553 - [34mdebug[39m: ecoflow-mqtt.0 (19640) [PROTOBUF decode] <snip> [get_reply] msg#10 => ParallelEnergyStreamReport { "paraEnergyStream": [ { "sysLoadPwr": 433.5506591796875, "sysGridPwr": -50.13569641113281, "mpptPwr": 2.5528552532196045, "bpPwr": -481.1335144042969, "bpSoc": 42, "unknown9": 2.5528552532196045 }, { "sysLoadPwr": 406.5067443847656, "sysGridPwr": 156.0901641845703, "mpptPwr": 2.5528552532196045, "bpPwr": -247.8637237548828, "bpSoc": 42, "devSn": "<snip>", "unknown9": 2.5528552532196045 }, { "sysLoadPwr": -18.66717529296875, "sysGridPwr": -251.9369659423828, "bpPwr": -233.26979064941406, "bpSoc": 41, "devSn": "<snip>" } ] }
D.h. es sieht für mich so aus, als wenn die Daten (zumindest teilweise) korrekt kommen, aber noch nicht in den entsprechenden iobroker Objekten landen.
Ich bin mal durch das log gegangen und stelle fest, dass in dem StreamReport bislang keine der ocean_* oder system1_* Datenpunkte dabei waren.
Falls Du doch noch den grossen log benötigst, muss ich die Sache mit der PN noch lernen, da ich die Funktion einfach noch nicht gefunden habe
-
@bentschik
Danke für die Info. Ich glaube mit nem kurzen Blick das Problem schon zu sehen. Es braucht noch eine Schleife um durch die einzelnen Datenpunkte zu gehen.
Nächste Versuch kommt wahrscheinlich heute Abend. -
-
@klausn sagte in Neuer Adapter ecoflow-mqtt:
Anbei das LOG.
Super. Danke.
Kannst du mal prüfen, ob die Häckchen drin sind?
Ich glaube, die fehlen.
Falls ja, bitte nochmal ein log posten. -
msgUpdate und msgSetGet waren angekreuzt, so wie Du gesagt hattest.
Ich hab jetzt mal noch msgUpdateValue und msgCmd angekreuzt.Voila:
-
@klausn sagte in Neuer Adapter ecoflow-mqtt:
msgUpdate und msgSetGet waren angekreuzt, so wie Du gesagt hattest.
Ich hab jetzt mal noch msgUpdateValue und msgCmd angekreuzt.Danke, irgendwas passt noch nicht.
Es müsste mindestens nach dem Start eine Zeile:ecoflow-mqtt.0 (4820) [PROTOBUF decode] R37xxxxxx [get_reply] raw (hex): 0a83030.....
auftauchen.
Laut log ist das Telegramm auch angekommen und funktioniert bis zur msg7. Dann gibt es noch Probleme die noch Ursachenforschung brauchen. Aber dazu brauch ich die vermissten Anteile im Log.
Kannst du hier nochmal überprüfen (debug, Häckchen gesetzt)?!
Danke.
-
-
@klausn sagte in Neuer Adapter ecoflow-mqtt:
Sorry, war mein Fehler, Asche auf mein Haupt.
Danke. Jetzt passt es und ich kann mich um die Unterschiede zur anderen Ocean kümmern.
-
Eine neue Version ist auf npm und git verfügbar.
Hauptsächlich Dinge für Powerocean, speziel der Heizstab ist nun dabei.
Und auch ein paar Kleinigkeiten im Zusammenspiel mit Homeassistant.@bentschik
Parallelenergie ist nun mit powerPv drin, die alten unknown9/10 Datenpunkte können gelsöcht werden.@KlausN
Die Daten sollten nun richtig verarbeitet werden. Das Problem der <20 habe ich noch nicht angegangen, da braucht es eine Umstrukturierung.
Aber die Batterien und Heizstab sollte nun richtig angezeigt werden.1.4.4 (npm)
- (foxthefox) new datapoints for PowerOcean (HeatingRod, ParallelEnergy)
- (foxthefox) improvements tp powerocean plus
- (foxthefox) corrections for powerocean
- (foxthefox) testing JSON->buffer
-
die Version 1.4.5 ist neu auf git und npm verfügbar
@KlausN
Das Problem mit den <20 hoffe ich gelöst zu haben, da jetzt alle ankommenden Telegramme (auch die mehrfachen zu einem Objektbaum) nun verarbeitet werden.1.4.5 (npm)
- (foxthefox) change from object to array for messages (for telegrams with multiple messages of same type i.e. powerocean)
- (foxthefox) change of cmdId/CmdFunc structure
-
Kurze Rückmeldung zu 1.4.5:
HeatingRodEnergyStreamShow.rod1_temp zeigt keine Temperatur an,
statusReportBattery2 und 3 fehlen noch,
Werte mit 0 W, z.B. JTS1_ENERGY_STREAM_REPORT.mpptPwr (und andere) werden nicht angezeigt, es verbleibt im MQTT-Objekt der vorherige Wert > 0.Danke für Deine Mühe!
-
@klausn sagte in Neuer Adapter ecoflow-mqtt:
Kurze Rückmeldung zu 1.4.5:
HeatingRodEnergyStreamShow.rod1_temp zeigt keine Temperatur an,
statusReportBattery2 und 3 fehlen noch,
Werte mit 0 W, z.B. JTS1_ENERGY_STREAM_REPORT.mpptPwr (und andere) werden nicht angezeigt, es verbleibt im MQTT-Objekt der vorherige Wert > 0.Danke für Deine Mühe!
Danke für die Rückmeldung.
Hmm. Das die Batterien nicht mit Daten befüllt werden, wundert mich. Hattest du in der Zwischenzeit mal die EF-App offen? Die fordert an sich das gleiche Telegramm an, wie beim starten des Adapters. Dieses vom Start und auch Updates habe ich erfolgreich bei mir durchgetestet. Sehr merkwürdig, dass 2 Batterien keine Daten haben.
Evtl mal das log anschauen. Ob da was an Fehlern kommt und wie oft dort eine Telegramm reinkommt. Evtl. Kommen bestimmte Telegramme nur wen die App offen ist.
Im log sind auch die nach json gewandelten Daten zu sehen, dort mal drauf achten ob hier rod1_temp mit drin ist. Bzw mpptPwr. -
@foxthefox Auch an dieser Stelle nochmals vielen Dank für Deine Arbeit
Für mein eigenes Verständnis zum Update der Werte habe ich noch eine Frage. Soweit ich das verstanden habe, soll das 5-minütige getLatestQuotas sicherstellen, dass die Daten mindestens in diesem Intervall aktualisiert werden. Ich habe mir das Ganze mal mit dem ParallelEnergyStreamReport angeschaut. Alle Werte dort aktualisieren sich nicht mehr, solange die App nicht aktiv ist. Ich sehe im debug log, dass das getLatestQuotas läuft. Im log sehe ich auch folgendes, wobei ich mir nicht ganz sicher bin, ob das eine Antwort auf getLatestQuotas ist:
[PROTOBUF decode] HJXXXXX [get_reply] msg#10 => ParallelEnergyStreamReport { "paraEnergyStream": [ { "sysLoadPwr": 397.404296875, "sysGridPwr": -12.054679870605469, "bpPwr": -409.458984375, "bpSoc": 44 }, { "sysLoadPwr": 400.8734436035156, "sysGridPwr": 245.0974884033203, "bpPwr": -155.7759552001953, "bpSoc": 43, "devSn": "HJXXXXX" }, { "sysLoadPwr": -1.880767822265625, "sysGridPwr": -255.56381225585938, "bpPwr": -253.68304443359375, "bpSoc": 44, "devSn": "BKXXXX" } ] }
D.h. diese Werte kommen wohl an, aber die entsprechenden IOB-Objekte werden nicht aktualisiert. Das zweite Datenset entspricht vermutlich den Daten für ocean und das dritte für system1:
Die Daten hier wurden letztmalig gestern um 21:27 aktualisiert.
Weiterhin sieht es dann wohl so aus, als wenn getLatestQuotas nicht alle Datenpunkte des ParallelEnergyStreamReports bekommt. Ist zumindest dieser Punkt erwartetes Verhalten?
-
@bentschik
Danke für diese detaillierte Rückmeldung.
Zur Ursache habe ich noch keine Idee, aber die Erkenntnis des Problems ist schonmal wichtig.Also, es sollte eigentlich anders laufen.
GetLatestQuotas taucht als [get] im log auf, wird auch von der App in gleicher Weise benutzt.
Das [get_reply] ist die Antwort darauf und in dem Telegramm sind mehrere Messages msg.
Msg#10 ist in dem Fall das Update zu den Leistungen.
Das kommt als Array und das erste Objekt sollte das gesamt System sein und die anderen haben dann de prefix von mir. So wie du es beschreibst.
Grundsätzlich wird das Telegramm und damit die enthaltenen Messages und dann die Datenpunkte durchlaufen und bei Abweichungen zum derzeitigen IOB-Wert wird das Neue übernommen.Gemäß deiner Schilderung werden die Daten geholt und auch dekodiert, aber es wird nichts abgespeichert.
Du könntest mal noch bei msgUpdateValue noch ein Häckchen setzen. Evtl kommt da etwas zum Vorschein.Ich schau heute Abend mal im Code, vielleicht sehe ich da auch was.