Monatsrückblick Januar/Februar 2026 ist online!

[KlausN]

@foxthefox

Sorry, war mein Fehler, Asche auf mein Haupt.

ecoflow_3.txt

[foxthefox]

@klausn sagte in Neuer Adapter ecoflow-mqtt:

@foxthefox

Sorry, war mein Fehler, Asche auf mein Haupt.

ecoflow_3.txt

Danke. Jetzt passt es und ich kann mich um die Unterschiede zur anderen Ocean kümmern.

[foxthefox]

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

[foxthefox]

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

[KlausN]

@foxthefox

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!

[foxthefox]

@klausn sagte in Neuer Adapter ecoflow-mqtt:

@foxthefox

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.

[bentschik]

@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?

[foxthefox]

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

[bentschik]

@foxthefox Was ich noch sehe, ist folgendes:

[PROTOBUF decode] HJ37ZDH5ZGCF0067 [update] msg#0 =>
{
	"paraEnergyStreamDetail": [
		{
			"loadPwr": 814.7593994140625,
			"gridPwr": -350.96319580078125,
			"mpptPwr": 1390.2650146484375,
			"bpPwr": 224.54238891601562,
			"timestamp": 1757936700,
			"bpSoc": 69,
			"devSn": "HJXXXXXX"
		},
		{
			"loadPwr": 823.8870849609375,
			"gridPwr": 4.56684684753418,
			"mpptPwr": 1390.2650146484375,
			"bpPwr": 570.94482421875,
			"timestamp": 1757936700,
			"bpSoc": 66
		},
		[....]
	],
	"paraSysSeq": 41630
}

In dem log Eintrag sind auch noch die Daten für 4 weitere timestamps, die ich weggelassen habe.

Ich vermute, dass Du Einträge, wie z.B. den hier meinst:

[Compare] update .JTS1_EMS_HEARTBEAT.pcsVgridThd 0 -> 0.04

Sowas bekomme ich für so ziemlich alles andere, aber nicht für den ParallelEnergyStreamReport. Erst, wenn ich die App anreisse kommt was (gekürzter log):

[Compare] update .ParallelEnergyStreamReport.powerPv2 202.36 -> 203.8
[Compare] update .ParallelEnergyStreamReport.powerPv1 223.48 -> 225.1
[Compare] update .ParallelEnergyStreamReport.bpPwr -259.36 -> -236.75
[Compare] update .ParallelEnergyStreamReport.mpptPwr 425.84 -> 428.9
[Compare] update .ParallelEnergyStreamReport.sysGridPwr -13.65 -> -5.79
[Compare] update .ParallelEnergyStreamReport.sysLoadPwr 671.54 -> 659.86

[foxthefox]

@bentschik
Super Recherche deinerseits.

Genau, für jede Änderung sollte es ein Vergleich geben und bei einem Unterschied gibt es diese [Compare] Einträge im log. Wenn das bei allen anderen kommt, ist das schonmal gut und zeigt, dass Daten kommen und der Mechanismus seinen Dienst tut.

Nun zu den Energiewerten, es gibt immerhin schon einen Unterschied. Bei get_reply scheint es parallelEnergyStream zu geben und bei den Updates ist es parallelEnergyStreamDetail. Also ein klein wenig anders und wahrscheinlich habe ich dieses Telegramm noch nicht verarbeitet. Das nehme ich mal noch mit auf.
Das ist zumindest die Begründung warum keine Updates zu den Werten kommen.
Eine Erklärung warum alle 5min über get_reply nichts verarbeitet wird, ist es noch nicht.

[foxthefox]

@bentschik

Ich habe mal eine 1.4.6 zum Testen in github hochgeladen.
ExpertMode -> custom -> https://github.com/foxthefox/ioBroker.ecoflow-mqtt/tree/1.4.6
damit sollte es bei [updates] nun auch die [Compare] Eintrage geben (ParallelEnergyStreamReport).

[bentschik]

@foxthefox Dein letztes Update hat einiges in Bewegung gebracht ;-)
Ich bekomme jetzt tatsächlich 5-minütliche Updates, und die Daten landen auch in den IOB-Objekten:

Ich habe mir hier mal einen Wert geschnappt, damit ich das besser beobachten kann. Interessant sind diese Blöcke zu 6 Updates direkt hintereinander weg. Bei anderen Datenpunkten können es auch andere "Blockgrössen" sein. So wirklich verstehe ich das nicht. Sind das historische Daten aus den vorherigen 5 Minuten, oder wie ist das zu interpretieren?
Ich hatte in einem Anfall von Wahnsinn noch versucht, das irgendwie mit paraEnergyStreamDetail zu korrelieren, weil dort timestamps kommen, aber hab's nicht hinbekommen.

Mit dem Update habe ich nun auch plötzlich Daten für die system1 Datenpunkte mpptPwr/powerPv1/PowerPv2 obwohl ich an anderer Stelle noch behauptet habe, dass Null absolut in Ordnung wäre, weil die Systemkomponente gar keinen Wechselrichter hat...da muss ich nun selbst mal schauen, was das wohl für Werte sein könnten

[foxthefox]

@bentschik
Danke für die Rückmeldung. Schonmal gut, wenn es jetzt mit den updates etwas ausliest.
Da die Daten einen Zeitstempel haben, werden Teile davon auch quasi historisch sein.
Das wird in einem Rutsch übernommen, also ggf. in dem Moment ändert sich der Datenpunkt mehrmals.

Ich glaube da ist dann noch etwas nicht fertig meinerseits.
Du hattest oben erwähnt, daß es hier weitere 4 Sets (Objekte mit {} gibt), d.h. das kommt nicht sortiert rein, wie beim get_reply.
Da muß ich also korrelieren, was drin ist, um es richtig auf ocean und system1 zu sichern.

Ich mach das mal gleich und melde mich wieder.

[bentschik]

@foxthefox Hier hast Du doch nochmal ein volles Beispiel. Vielleicht ist es hilfreich:

[PROTOBUF decode] HJXXXXXX [update] msg#0 => ParallelEnergyStreamDetail
{
	"paraEnergyStreamDetail": [
		{
			"sysLoadPwr": 503.03240966796875,
			"sysGridPwr": 301.1585693359375,
			"bpPwr": -201.8738555908203,
			"timestamp": 1757961000,
			"bpSoc": 90,
			"devSn": "HJXXXXXX"
		},
		{
			"sysLoadPwr": 506.3233947753906,
			"sysGridPwr": -3.4679183959960938,
			"bpPwr": -509.79132080078125,
			"timestamp": 1757961000,
			"bpSoc": 89
		},
		{
			"sysLoadPwr": 502.0224304199219,
			"sysGridPwr": 304.16064453125,
			"bpPwr": -197.86178588867188,
			"timestamp": 1757960940,
			"bpSoc": 91,
			"devSn": "HJXXXXXX"
		},
		{
			"sysLoadPwr": 510.2342529296875,
			"sysGridPwr": -0.3312835693359375,
			"bpPwr": -510.5655517578125,
			"timestamp": 1757960940,
			"bpSoc": 90
		},
		{
			"sysLoadPwr": 547.7385864257812,
			"sysGridPwr": 352.0101623535156,
			"bpPwr": -195.72840881347656,
			"timestamp": 1757960880,
			"bpSoc": 91,
			"devSn": "HJXXXXXX"
		},
		{
			"sysLoadPwr": 507.2791748046875,
			"sysGridPwr": 18.305538177490234,
			"bpPwr": -488.9736328125,
			"timestamp": 1757960880,
			"bpSoc": 90
		},
		{
			"sysLoadPwr": 510.12713623046875,
			"sysGridPwr": 310.16888427734375,
			"bpPwr": -199.95823669433594,
			"timestamp": 1757960820,
			"bpSoc": 91,
			"devSn": "HJXXXXXX"
		},
		{
			"sysLoadPwr": 511.625732421875,
			"sysGridPwr": -1.3682823181152344,
			"bpPwr": -512.9940185546875,
			"timestamp": 1757960820,
			"bpSoc": 90
		},
		{
			"sysLoadPwr": 510.26312255859375,
			"sysGridPwr": 309.22314453125,
			"bpPwr": -201.0399932861328,
			"timestamp": 1757960760,
			"bpSoc": 91,
			"devSn": "HJXXXXXX"
		},
		{
			"sysLoadPwr": 518.1139526367188,
			"sysGridPwr": 4.331111907958984,
			"bpPwr": -513.7828369140625,
			"timestamp": 1757960760,
			"bpSoc": 90
		}
	],
	"paraSysSeq": 42461
}

[foxthefox]

@bentschik
Danke.
Das hilft. Interessanterweise ist "BK...." gar nicht enthalten. Also nur Gesamtsystem und Ocean.

Ich habe mal eine nächste Variante in git hochgeladen.
Bitte einmal ausprobieren.

[foxthefox]

@KlausN

Ich habe nochmal über mppPwr "<20" nachgedacht. Mit Berücksichtigung der Erkenntnis, daß bei ParallelEnergyStreamReport die updates nicht darüber, sondern über ParallelEnergyStreamDetail kommen, müsste dies für JTS1_ENERGY_STREAM_RPORT auch so sein.
Habe also mal das EnergyStreamDetail implementiert.

Ich habe mal die nächste 1.4.6 zum Testen in github hochgeladen.
ExpertMode -> custom -> https://github.com/foxthefox/ioBroker.ecoflow-mqtt/tree/1.4.6

Bitte mal testen, ob jetzt die Power Werte besser kommen und speziell auch "<20" behoben ist.

[bentschik]

@foxthefox Folgendes bezieht sich auf Deine neueste Version. Es gibt auch Einträge zum BK...

[PROTOBUF decode] HJXXXXXX [get_reply] msg#10 => ParallelEnergyStreamReport {"paraEnergyStream":
{
	"paraEnergyStream": [
		{
			"sysLoadPwr": 464.5927734375,
			"sysGridPwr": -17.036794662475586,
			"mpptPwr": 293.6735534667969,
			"bpPwr": -187.95602416992188,
			"bpSoc": 30,
			"powerPv1": 148.34454345703125,
			"powerPv2": 145.32901000976562
		},
		{
			"sysLoadPwr": 464.1156005859375,
			"sysGridPwr": 89.7088851928711,
			"mpptPwr": 293.6735534667969,
			"bpPwr": -80.73316955566406,
			"bpSoc": 29,
			"devSn": "HJXXXXXX",
			"powerPv1": 148.34454345703125,
			"powerPv2": 145.32901000976562
		},
		{
			"sysLoadPwr": 0.7440109252929688,
			"sysGridPwr": -106.47884368896484,
			"bpPwr": -107.22285461425781,
			"bpSoc": 30,
			"devSn": "BKXXXXXX"
		}
	]
}

system1 scheint mir mit Vorsicht zu geniessen zu sein. Die mpptPwr/powerPv1/powerPv2 Datenpunkte kann ich weiterhin nicht zuordnen. Mit der letzten Adapter-Version verhalten sich diese Punkte aber einheitlich zu den anderen powerPv-Werten in der Form, dass mppt die Summe von Pv1 und Pv2 ist. Das war vorher nicht so. Die Werte liegen oft sehr nahe bei den ocean_ Werten, aber wie gesagt, keine Ahnung, was das genau ist.
sysGrid-/LoadPwr scheint aber relativ genau mit der Anzeige in der App zu der Systemkomponente zusammen zu passen (was man so erkennen kann...)

Wirklich merkwürdig finde ich noch sowas hier (ich meine, dass hätte ich aus dem Augenwinkel auch schon bei der vorherigen Testversion gesehen):

2025-09-16 09:11:03.735	debug	[Compare] update .ParallelEnergyStreamReport.system1_devSn BKXXXXXX -> HJXXXXXX
2025-09-16 09:10:10.237	debug	[Compare] update .ParallelEnergyStreamReport.system1_devSn HJXXXXXX -> BKXXXXXX
2025-09-16 09:06:03.642	debug	[Compare] update .ParallelEnergyStreamReport.system1_devSn BKXXXXXX -> HJXXXXXX
2025-09-16 09:05:10.500	debug	[Compare] update .ParallelEnergyStreamReport.system1_devSn HJXXXXXX -> BKXXXXXX

[foxthefox]

@bentschik
Super Auswertung. Danke.

Also das Ersetzen von devSn darf nicht sein, das ist ein Fehler und ich habe auch schon das Problem erkannt, ist schon auf git ausgebessert.
Hatte mir zwar zum Vergleich den derzeitigen Wert von devSn geholt aber nicht .val benutzt. Blöder Fehler.

Am besten du löscht den Objektbaum ParallelEnergy... mal raus und startest den Adapter neu. Dann legt er die Daten wieder an und befüllt sie.
Das system1_powerPV müsste demnach immer leer bleiben (wegen Stream AC ohne MPPT). Und devSn sollte auch stabil den gleichen Wert haben.

Meine Inetrpretation:

• die Werte ohne prefix sind die Gesamtwerte
• prefix ocean ist der Anteil von powerocean
• prefix system1 ist der Anteil von Stream AC
• ocean und system1 müssten zusammengerechnet den Wert für ohne Prefix geben ( sysGrid -106 + 89 = -17; bpPower -107 -80 = -187)
  kommt ungefähr hin.
  Allerdings hab ich keine Ahnung was es bezüglich der Gesamtbilanzierung aussagt.
  In etwa die Last ist 464W und wird gedeckt durch 293W Solar + 187W Batterie und leider werden 17W zurückgespeist.

[bentschik]

@foxthefox Ich hab's mal gelöscht und werde beobachten.

Es gibt im Ecoflow Webportal eine Analyse-Funktion, wo man sich diverse Werte mal kurzeitig visualisieren kann. Dort ist es so dargestellt, dass ein "System 1" in einer Baum-Hierachie über dem Wechselrichter steht.

Aber ich schliesse mich Deiner Interpretation an, weil das eigentlich nur so (auch nach den Werten) halbwegs Sinn ergibt.

[foxthefox]

@bentschik sagte in Neuer Adapter ecoflow-mqtt:

@foxthefox Ich hab's mal gelöscht und werde beobachten.

Es gibt im Ecoflow Webportal eine Analyse-Funktion, wo man sich diverse Werte mal kurzeitig visualisieren kann. Dort ist es so dargestellt, dass ein "System 1" in einer Baum-Hierachie über dem Wechselrichter steht.

Aber ich schliesse mich Deiner Interpretation an, weil das eigentlich nur so (auch nach den Werten) halbwegs Sinn ergibt.

System1 ist von mir so benannt, es ist ja nicht Teil der Daten. Das sollte relativ neutral sein, weil es unterschiedliche Komponenten sein könnten.
Und da ich im Adapter auch keine Mechanismen zur dynamischen Anlage von Datenpunkte habe, muss ich generische Namen vergeben. Andererseits könnte man devSn in die Datenstruktur aufnehmen, was aber beim Start noch unbekannt ist.

Dann beobachte bitte mal die Situation.
DevSn sollte auf jeden Fall stabil sein und die Werte sollte in dem jeweiligen ‚System‘ eine gewisse Kontinuität haben und nicht hin und her springen.