Hallo,

Mir ist letztlich aufgefallen, dass bei meinem PowerOcean DC der Datendatz für JTS1_ENERGY_STREAM_REPORT gar nicht mehr aktualisiert wird. Was ich ausprobiert habe:

• Update auf Adapter-Version 1.4.2
• Ecoflow-App laufen lassen
• Löschen aller Datenpunkte und Adapter-Neustart

Nach dem letzten Punkt wird der entsprechende Ordner mit den Datenpunkten zwar angelegt, bleiben aber dauerhaft auf null

Ich habe dann mal überall den debug angerissen, und im log sehe ich auch keinerlei Hinweis, das dieser Datensatz überhaupt irgendwie aufschlägt. Alle anderen JTS1* und der statusReportBattery1 sind scheinbar kein Problem.

Die letzten Daten sind am 17.07. angekommen. Am Adapter habe ich, soweit ich mich erinnern kann, zu dem Zeitpunkt nichts geändert. Allerdings habe ich irgendwann ein paar STREAM AC Pro Akkus als Systemkomponente integriert. Ich kann mir aber nicht so recht vorstellen, dass sowas zu solchen Problemen führen könnte.

Fall ich noch weitere Informationen zum debugging zur Verfügung stellen kann, sagt gerne bescheid. Wäre schon super, wenn diese Daten wieder fliessen würden

@foxthefox Die Integration der Stream Akkus über die App ist im Prinzip das Einzige, was ich in der letzten Zeit angestellt habe und zeitlich könnte das durchaus hinkommen.
Ich könnte als Gegentest mal die Stream Akkus wieder aus den Systemkomponenten-Verbund rauswerfen und dann mal checken, ob der Datensatz wieder kommt.

Ich habe es just mal ausprobiert: die Daten fliessen, wenn die Stream-Akkus wieder "autonom" sind...na toll...aber irgendwas ist ja immer

@foxthefox Ich habe es direkt mal ausprobiert. Das Resultat passt noch nicht so ganz, aber dafür ist das Testen ja da:

@foxthefox Bin endlich mal dazu gekommen, die logs einzusammeln...

adapter-debug.json

Den "grossen" log kann ich Dir vermutlich ersparen, weil ich darin schon folgendes sehe:

2025-09-08 09:54:14.553  - debug: 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

@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 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 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 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 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 Vielen Dank

Die devSN ist gestern absolut stabil geblieben. Mit dem jetzigen Zustand kann ich nun auch anfangen, die Daten "seriös" zu verarbeiten. Melde mich, falls ich noch Merkwürdigkeiten entdecken sollte.

@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 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 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 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 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 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 Bin endlich mal dazu gekommen, die logs einzusammeln...

adapter-debug.json

Den "grossen" log kann ich Dir vermutlich ersparen, weil ich darin schon folgendes sehe:

2025-09-08 09:54:14.553  - debug: 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

@foxthefox Ich habe es direkt mal ausprobiert. Das Resultat passt noch nicht so ganz, aber dafür ist das Testen ja da:

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