CAN Bus Core Pro [+Ecoflow Powerhub]

[Tristan]

Wenn ich global diese Variablen schreibe, werden sie angezeigt. Was nicht funktioniert hat ist welche zu ergänzen, diese werden nicht angezeigt. Ist auch irgendwie doof an der Stelle, zwecks update
Auch PV wird nicht abgezeigt, obwohl ich die Variablen geschrieben hatte. Als ich testweise mal einen Victron MPPT dran hatte, wurde es angezeigt. hatte testweise einen USB mal auf Victron gestellt und Mainbattery auch auf Victron.

@lbartsch
Zum Thema Ecoflow, es läuft auch mit dem Schalten. AC und DC ist schonmal getestet, jetzt kommt die Kür. jedoch muss ich dann erstmal nen Update auf 2.0.9 machen um die “Softwareschalter” nutzen zu können. Es ist einfach geil, so wie ich es mir am anfang vorgestellt hatte

An dieser Stelle nochmal ein ganz großes Lob an das Vanpi Projekt und das Team drumherum :), ohne wäre es einfach nicht möglich gewesen, etwas so sehr integrierbar zu machen. Da gibt es einfach nichts annähernd vergleichbares auf dem Markt.

[Vincent]

Kannst du mal in der HTTP-API an die function nodes generate objects und create response object Debugs dranhängen, dann schauen wir mal ob alles richtig kommt für die App?
Ist manchmal ein bisschen tricky, weil die App ganz bestimmte Datenformate erwartet.

Könnte auch sein, dass die Variablen irgendwo anders nochmal überschrieben werden? Nimm dir mal einen Trigger, stell den so ein dass er jede Sekunde ausgeführt wird, dann fragst du einfach die Variable ab und beobachtest das im Debug, vielleicht fällt ja was auf.

Variablen hinzufügen kannst du aktuell an der Stelle nicht, die würden so oder so nicht angezeigt werden in der App. Da musst du erstmal den Weg über die Custom Data Funktion gehen.

Und Danke für die netten Worte Ich wünschte manchmal ich hätte einfach dreimal so viel Zeit am Tag um mit allem hinterherzukommen

[Tristan]

Danke, ich hab mal ein bisschen rumprobiert.

Ich bin grade noch am überlegen wie ich das ganze am besten sinnvoll integriere.
So zum grundsätzlichen Verständniss, es gibt ja verschiene Main Battery Möglichkeiten.

BMS (Daly/JBD)

Pekaway shunt

VE Direkt.

So wie ich die HTTP API verstehe, gibt es hierfür gemeinsame globale Variablen? Und nur die werden in der APP/Display angezeigt, die spezifischen(Victron etc) sind nur fürs Dashboard.(teilweise werden andere Variablen (bspw Victron) in diese überführt.)

Batterie
“VoltB”:global.get(“MainBattVolt”) || 0,
“Ampere”: global.get(“MainBattAmps”) || 0,
“battsoc”: global.get(“MainBattSoc”) || 0,

Photovoltaik

“mppt_pv_amps”: parseFloat(global.get(“mppt_pv_amps”) ?? 0),

“mppt_pv_volts”: parseFloat(global.get(“mpt_pv_volts”) ?? 0),

“mppt_pv_watts”: parseFloat(global.get(“mppt_pv_watts”) ?? 0),

“mppt_pv_total”: parseFloat(global.get(“mppt_pv_total”) ?? 0),

BMS

“BMSamps”:global.get(“BMSamps”),

“BMScap”:global.get(“BMScap”),

“BMSnominalAh” : global.get(“BMSnominalAh”),

“BMScell1”:(global.get(“BMScell1”)/1000).toFixed(2),

“BMScell2”:(global.get(“BMScell2”)/1000).toFixed(2),

“BMScell3”:(global.get(“BMScell3”)/1000).toFixed(2),

“BMScell4”:(global.get(“BMScell4”)/1000).toFixed(2),

“BMSmaxcap”:global.get(“BMSmaxcap”),

“BMSmaxvolt”:global.get(“BMSmaxvolt”),

“BMSminvolt”:global.get(“BMSminvolt”),

“BMSpower”:global.get(“BMSpower”),

“BMSsoc”:global.get(“BMSsoc”),

“BMStemp”:global.get(“BMStemp”),

“BMSvolt”:global.get(“BMSvolt”),

Nur diese können dargstellt werden ?
Also wenn ich auf Batterie tippe, werden nur die BMS Daten dargestellt, ob genutzt oder nicht.
Verstehe ich das soweit richtig das die BMS Variablen Namen in der App hardgecodet sind?
Vllt könnnte man die Namen der Felder selber über die Api mitschicken, das man auch über den Tipp auf die Batterie, dort eigene Daten darstellen kann in irgendeiner zulünftigen Version.
Auf jedenfall bekomme ich über die APP jetzt Testdaten zum MMPT

[Vincent]

@Tristan

So wie ich die HTTP API verstehe, gibt es hierfür gemeinsame globale Variablen? Und nur die werden in der APP/Display angezeigt, die spezifischen(Victron etc) sind nur fürs Dashboard.(teilweise werden andere Variablen (bspw Victron) in diese überführt.)

Richtig, damit haben wir dann eine Hauptbatterie, die für die Anzeigen im Display und der App benutzt werden.

@Tristan

“BMSamps”:global.get(“BMSamps”),

“BMScap”:global.get(“BMScap”),

“BMSnominalAh” : global.get(“BMSnominalAh”),

“BMScell1”:(global.get(“BMScell1”)/1000).toFixed(2),

“BMScell2”:(global.get(“BMScell2”)/1000).toFixed(2),

“BMScell3”:(global.get(“BMScell3”)/1000).toFixed(2),

“BMScell4”:(global.get(“BMScell4”)/1000).toFixed(2),

“BMSmaxcap”:global.get(“BMSmaxcap”),

“BMSmaxvolt”:global.get(“BMSmaxvolt”),

“BMSminvolt”:global.get(“BMSminvolt”),

“BMSpower”:global.get(“BMSpower”),

“BMSsoc”:global.get(“BMSsoc”),

“BMStemp”:global.get(“BMStemp”),

“BMSvolt”:global.get(“BMSvolt”),

Genau, die App schaut nach den Keys “BMSamps”, “BMScap”, usw. was da drin steht ist an sich egal, solange es numerische Werte sind.

Theoretisch kann man das natürlich auch freier programmieren in der App, so dass einfach alles angezeigt wird was ankommt. Dann aber nur als Liste und nicht mehr formatiert mit verschiedenen Kategorien. So wie bei den Custom Daten aktuell.
Das Ding ist aber, dass wir etwas auf den Traffic achten müssen für die LTE Bridge. Aber ich hab da auch schon Ideen die ich gerne umsetzen würde in Zukunft, da wollte ich demnächst ein paar genauere Tests machen.

Generell würde ich die App gerne noch dynamischer gestalten und weniger hardcoden, der Fokus liegt aber immer erstmal darauf die Dinge vernünftig am Laufen zu haben die vorhanden sind, für Leute die nicht selber programmieren. Alles Weitere kommt Schritt für Schritt.

[Tristan]

Das klingt doch super!

Bin sehr zufrieden, habe jetzt alle relevanten Werte aus der Ecoflow in der App.

Checke das jetzt nochmal am Display und dann Guck ich mal bezüglich des Updates, dass ich auch die restlichen werte als Userdata Dargestellt bekomme. Ob man die jetzt braucht, sei mal dahingestellt, aber ich habs sie ja jetzt

PV geht auch, die Sonne scheint nur nicht

[Vincent]

@Tristan

Ob man die jetzt braucht, sei mal dahingestellt, aber ich habs sie ja jetzt

Alles was da ist will man ja auch sehen, je mehr Zahlen, desto besser

[Frehd]

Ich kann hier (leider) nichts produktiv zum Thema beitragen, wollte aber meinen Dank und Respekt zum Ausdruck bringen für die Arbeit und die Mühe die ihr in das Thema steckt.

Ich plane gerade meinen Ausbau und sowohl der Power Hub als auch der Core Pro liegen schon zuhause. Die Arbeit von Tristan liegt weit über meinen Fähigkeiten und ohne solche Cracks, die dazu auch noch bereit sind ihre Ergebnisse mit anderen zu teilen, kämen Leute wie ich nie in den Genuss einer solch coolen Lösung.

Von daher einfach mal ein fettes “Dankeschön”!

[Tristan]

Hey, Danke für die Rückmeldung. es ist immer schön wenn man so viel Arbeit reinsteckt und teilt, es dann auch für andere zu gebrauchen ist

Ich bin schon sehr weit gekommen.

Was bisher funktioniert:

-Auslesen-

Gesammt SOC/ Restlaufzeit (Exact die Werte aus dem System, nicht selber errechnet)

Batterie Daten 1/2/3 (ich hab kein Powerdock, daher kann ich es nicht testen für Batterie 4-9)

Solar 1/2 Leistung/Strom/Spannung

AC Leistung (Laden/Entladen)

Im Display funktioniert bisher PV Leistung gesammt, sowie Strom/Spannung von einem Eingang, da es nur eine Variable gibt die übergeben werden kann.

In der App funktioniert Batterie Soc/Strom/Spannung (Warum eigentlich nicht Leistung ? :D)

PV Leistung/Strom/Spannung

-Steuern-

AC, Ein/Aus

DC, Ein/Aus

Was nicht funktioniert hat,

Solar 1/2 , AC/DC Laden –>Ein/Aus Schalten.

Hier scheint entweder doch der rolling Counter genutzt zu werden, oder es werden mehr Befehle gesendet als angenommen.

Was ich noch erledigen will, bevor ich was brauchbares Hochlade:

-Aktuell ist der Flow noch voller Debug Nodes und super unstrukturiert.

-Die Can Kommunikation ist noch eigenständig, ich muss das noch auf die VANPI Can Kommunikation umstellen.

-Einen neuen Tab im Dashboard bauen, der sämtliche sinnvolle Variablen darstellt.

-Die Werte nullen, wenn die Can Kommunikation abreißt.

Insgesamt soll es so “Serientauglich” wie möglich sein.

An dieser Stelle nochmal ein dickes Danke an Stewart vom Wattzup, ich habe sein Programm zwar nie ans Laufen bekommen oder Verstanden, jedoch einige Teile des Decoders mit einbeziehen können, was es für mich sehr viel einfacher gemacht hat die Werte zu interpretieren.

Bin soweit echt zufrieden mit dem Ergebniss bisher

[Tristan]

Von mir einmal den ersten “Prototyp”

Warum Prototyp? Erstmal funktioniert ziemlich viel, aber der Flow ist noch unnötig “kompliziert”, um das finden von Can-Frames zu erleichtern. Dazu an vielen Stellen noch kompaktisierbarer.

Was muss gemacht werden?

OS <2.0.9
→Userflow importieren/deployen

→Can schnittstelle aktvieren durch Eintrag in der .yaml (siehe Vincent ganz am Anfang)

→Internetverbindung muss bestehen

→einmal auf den inject drücken der die structs.json vom git läd

Der Rest passiert automatisch

OS 2.0.9

→Den Vanpi Canflow deaktivieren (ich integriere das später)

→Userflow importieren/deployen

→Internetverbindung muss bestehen

→einmal auf den inject drücken der die structs.json vom git läd

Was funktioniert ?

→ Neue Tab im Dashboard taucht auf, mit vielen Steuerungselementen und Daten.

→ AC DC lassen sich ein und Auschalten.

→ Alle Batterie und PV Daten in der Vanpi APP !

→ Software Switches in der APP zum toggeln (bisher geht nur AC/DC) (und im Dashboard natürlich).

→beim abschalten von DC werden alle Relais/Dimmer abgeschaltet (um den Stromverbrauch der Relaisspulen zu verhindern. Sollte damit was anderes geschaltet werden, muss man das anpassen)

Was kommt noch ?
→ MQTT Topics zum automatisieren (bspw wechselrichter einschalten, wenn man Boilercontrol/Kühlschrank etc. nutzt, wobei viel auch über globale Variablen läuft)

→ Integration des Can Flows vom Vanpi

→ hoffentlich die anderen Schalter (PV lichtmaschine AC Laden, leider sehr kompliziert)

→ korrekte Abfrage des Status, wenn über den HUB oder die Ecoflow APP AC/DC geschaltet wird. (aktuell wird das nicht korrekt auf die switches übertragen)

→ Integration von dritthersteller Batterien (Shunt übersetzer)

→ Abschalten des ganzen Ecoflow Systems, dies setzt aber einen Puffer an der 12V oder eine andere 12V versrgung vorraus.

Es empfielt sich den Core nicht an die DC-Seite des Powerkit zu hängen, sondern an die 12V Versorgung der RJ45/CAN Schnitstelle des HUB.

Haftugsausschluss/eigenes Risiko. Laut Datenblatt ist diese mit 12W belastbar (Stromaufnhame des Display) vermutlich mehr, da er auch das Powerlink versorgt.

Can am Powerkit ist:
Pin1_H, Pin2_L, Pin4_+11,4V, Pin5_GND, (Selber Überprüfen!)

Mullticom:
Pin7_H, Pin8_L, Pin3 CanGND

Aktuell plane ich eine kleine Powerbank mit Ecoflow Can RJ45 auf der einen und Multicom Schnittstelle auf der anderen Seite. Dann erspart man sich das Adapterkabel und der Core läuft auch bei abgeschaltetem Powerkit (12V auf der RJ45 sind nicht andauernd aktiv)

Viel Freude!

Powerkit 231225.json (120.4 KB)

[Tristan]

Im Anhang eine neue Version.

Changelog:
Einige falsche Variablen gefixt, die zu falschen (bzw fehlenden) Werten geführt haben.

Neue Werte hinzugefügt.

Code optimiert

Ich hab es endlich geschafft den Eigenvebrauch des Systems auf 5W zu bekommen (Vorher 20-25W!) ohne das das System aus ist. Jetzt ist das endlich brauchbar, bisher hatte es mir 6kwh Akku in wenigen Tagen leergesaugt

Ohne das Can Plugin wäre ich dem nicht so schnell auf die Schliche gekommen, da Ecoflow den Eigenverbauch schön unterdrückt.
Die Lösung, richte kein Internet im Powerkit ein (zurücksetzen aus dem Konto löschen und bei der Einrichtung überspringen) ein, dann geht zwar auch kein Bluetooth mehr aber das ist ja jetzt fast unnötig

@Vincent Wie ist die Vanpi Can Implementierung gedacht, wie komme ich an die Can Frames ?

im Dashboard unter Debug sehe ich es wie es soll, aber wie sollen die Frames übergeben werden?
Im Flow sieht es für mich so aus, als wäre dafür der dritte Anschluss am Router. kommt da noch ein LinkOut/Mqtt (ist das schnell genug ? :D) oder noch keine Lösung? Über mqtt wird ja nur der Status übergeben.

Edit: Hab noch nen Bug gefunden, der UI-Switch in der App wurde immer wieder Off gesetzt, obwohl die Quelle an war. Ist gefixt, kommt in einer späteren Version

Was mir ncoh aufgefallen ist, gestern war der Stromverbrauch bei 12-15 Watt (5-6 Watt der Ecoflow/ 2- 3 Watt das Huawai LTE Modem/5-8 Watt der CorePro)
Heute morgen sind es wieder 20-30 Watt obwohl sich sonst nix verändert hat. Meine Vermutung, sobald PV Spannung ansteht, versucht die Quelle zu laden obwohl ich die Spannung in der Ecoapp schon auf deutlich mehr gestellt habe. ich vermute das die 10-15Watt die verluste des Relais (sind 2 vom gehöhr) und des DC/DC MPPT Wandlers sind. Irgendwie doof, da es so diesig ist, das nicht geladen wird sobald ich PV auch toggeln kann, überlege ich mir ob man das irgendwie sinnvoll steuern kann (Wetterdaten etc.)

Edit 2: Vermutungen mit dem Standby-Verbrauch erhärten sich. Aktuell noch 20V PV Spannung, aber null Sonne, habe den PV Eingang mal deaktiviert. Bei aktivem Eingang und keiner Sonne scheint der Mppt knapp 10-15W zu fressen. Irre.

Nachtrag –> es ist definitiv so, sobald einer von beiden PV Eingängen aktiviert ist, verbraucht das System 20W mehr, unabhängig von von der Spannung oder dem Ertrag.

Hier zeigt sich mal wieder wie furchtbar closed Source ist Evtl. lege ich die PV Eingänge auf Bistabile Relais, mal gucken ob ich da was i2C fähiges finde (btw. Habe nal eine defekte Powerbank zerlegt, tatsächlich sind die chips I2C fähig, leider auf 5V, Mal sehen ob ich da was rausbekomme Wäre ein genialer puffer. Man könnte das das System abschalten über nacht außerhalb des Camping Betriebes und wieder aktivieren, sollte die Powerbank leer sein. )

Powerkit 271225.json (123.7 KB)

[Vincent]

Du hast in der CAN router function eine Zeile

const mqtt = (global.get(“canBus_mqttOutput”) || false) == true ? msg : null // this variable can be set to true in a userflow if needed

Wenn du diese Variable auf true setzt, werden die CAN-Frames per MQTT gesendet (erster Ausgang). Immer zusammengefasst nach einem Ablauf von 0,5 Sekunden nach der ersten Nachricht. Das Zusammenfassen müsste man nochmal anpassen wenn mehr Geräte dazukommen, aber die Idee ist immer alle Frames eines Gerätes auf einmal zu bekommen. Oder je nachdem wie Ecoflow die Daten sendet kannst du wahrscheinlich auch ohne die Join-Node arbeiten für einzelne Frames.

Dann kannst du diese Frames an anderer Stelle wieder aufgreifen und weiterverarbeiten.

Der dritte Ausgang des Routers ist eine Vorbereitung für weitere Geräte und wird aktuell nicht benutzt.

[Tristan]

Danke, das hatte ich nicht gesehen und falsch interpretiert, ich dachte nur es wird per mqqt übertragen, ob der Can aktiv ist oder nicht.

Kann man die Bündelzeit denn dann einstellbar machen übers Dashboard ?

Ich habe aktuell ein sauber funktionierende Can Verarbeitung, welche aber vorraussetz, dass der VANPI Can Flow deaktiviert wird.

Zum teilen wäre es aber sinnvoll so wenig wie möglich node Red Eingriffe machen zu müssen (so unpraktisch wie der Parität bei Webasto)

Bei 5000 Frames die Sekunde, wären 0,5s Sammeltzeit ein wench lang

Evtl könnte man das ja an die Übertragungsrate koppeln, bei 1Mbit nur noch 50ms Sammeltzeit oder so.

[Vincent]

Bei 5000 Frames pro Sekunde wäre es wohl sinnvoller ein Link-Out zu setzen nach dem CAN.Router. Mach ich mal im nächsten Update
Da hast du den Bus aber schon ganz schön ausgelastet

[Tristan]

Da kann ich ja nix für

Wenn du am Candump nen Debug machst und 5 Sekunden aktivierst, dann passiert erst nüschts, anschließen explodiert dein debug tab für wenige Minuten

Glaube das ist eine sinvolle Idee als Alternative zu Mqtt (wobei das, so wie ich mir angelesen habe, auch kein Problem darstellen sollte von der Kapazität)

Was ich mir noch angucken muss, wenn ich direkt an den Candump in deinem Flow einen Link out mache und an meinem Flow direkt hinter den Candump gehe, den ich aus deinem alten Testscript gebastelt habe, dann kommt da abunzu wilder Kram an, da die Frames irgendwie durcheinander gehauen werden. (Den alten natürlich deaktiviert) Beim schnellen gucken habe ich aber keinen Unterschied gesehen. Wobei ich gegen 21MW PV nichts einzuwenden hätte:D

[Vincent]

Ich denke mal NR Debug kommt da einfach nicht hinterher mit dem Rendern. Kann es sein, dass du zwei candump Prozesse laufen hast?
5000 Frames kommt mir auch eher unüblich vor, damit würde die Ecoflow ja den Bus schon vollständig besetzen… Beim Victron BMS Protokoll sind es z.B. nur 16Frames/s

Sendest du Frames zurück auf den Bus?
Teste mal in der Konsole:

ip -details -statistics link show can0

Was steht bei RX dropped und RX errors?

candump -L can0 | pv -l -i 1 > /dev/null

damit kannst du die Framerate messen direkt auf dem Bus, vorher sudo apt install pv

[Tristan]

Hoopalla, da ist mir eine 10er Potenz verrutscht

Hatte die Frame Rate noch aus Savvycan, hab ich mich vertan. Laut PV sind es ca 550-580 Frames/s mit display müssten es dann umgerechnet ca 750-800 gewesen sein (habe ich nichtmehr).
Bin mir auch nicht ganz sicher ob der Akku Canbus getrennt oder ob es sich um den gleichen Bus hat.

pi@pekaway:~ $ ip -details -statistics link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size

65536 gso_max_segs 65535 tso_max_size 65536
tso_max_segs 65535 gro_max_size 65536 parentbus spi parentdev spi0.0
RX: bytes packets errors dropped missed mcast
720925087 94846666 3291 0 0 0
TX: bytes packets errors dropped carrier collsns
72 9 0 0 0 0

[Vincent]

Sieht soweit gut aus, dann könnten deine Werte auch einfach ein parsing Fehler sein?

z.B. angenommen du bist mit einem byte verrutscht, wenn du 00 54 50 … hast und eigentlich 0x0054 haben wolltest (= 84 W), hast aber stattdessen 0x5450 genommen ( = 21584 W)
Oder Little und Big Endian vertauscht, also du hast 0x5400 und als Big Endian (erst high byte, dann low byte) ergibt das 21504, aber als Little Endian (erst low byte, dann high byte) wären das wieder die 84.

Die 850kV könnten dann auch damit zusammenhängen, dass das Parsing einfach falsch ist. Und dann ist das Byte für Ampere nicht mehr richtig und deshalb NaN oder sowas und damit gleich 0…

Schwer zu debuggen wenn man das nur theoretisch macht

nach deinem candump splittest du aber die Zeilen korrekt bei \n? Also so wie im Beispiel, dass man einzelne Zeilen bekommt und keine chunks?
Wenn du die ID weißt für den Frame der die Spannung liefert und die Power kannst du mal loggen mit

candump -L can0,ID:XXX | head -n 1000 > idXXX.log

und schauen ob was auffälliges passiert. Aber wie gesagt, dadurch dass Power, Spannung und Strom gleichzeitig so komisch sind, muss es ja eigentlich ein Parsing Fehler sein, also der CAN sollte vernünftig funktionieren.

[Tristan]

Muss Grade überlegen, hab Grade kein Zugriff auf node Red,

Die Daten Frames bestehen aus 3-10 Can Frames unterschiedlicher id’s im Extender Can. Dann kann ein Datenfeld schnell mal 80 Byte lang sein, das macht es sehr mühselig die Daten zu finden.

Bspw. Start id für Batterien ist 0x10036001

Dann beliebig Can Frames viele mit 0x10136001

Und dann ein Abschlussframe mit 0x10236001 insgesamt gibt es 5 solcher Blöcke und noch ein paar einzelne.

Die ganzen Daten muss ich erstmal zu einem Datenframe zusammenbauen, anschließen nach Id’s weitersortieren.

Hierbei werden die Can Frames nur akzeptiert, wenn der Timestamp größer als der des letzten Canframes war. Das ganze ist relativ aufwendig, aber eigentlich sehr robust gebaut. Funktionierte auch Fehlerfrei in meinem Flow.

Ich check das die Tage nochmal im Node red, vllt war versehentlich doch irgendwie doch nen zweiter Candump an weil ich ne Deploy vergessen habe oder so, war immerhin 3 Uhr nachts Aktuell klingt das am logichsten. Bin aktuell mit dem Bus unterwegs und will nix anfassen

Wenn das dann über Mqtt hinhaut, baue ich das mal so ein, sonst ggf über den Link out, wenn im Image einer ist. Vermutlich nutzt es aktuell eh noch niemand außer mir

[Tristan]

Ich habe eben eine ganz interessante Entdeckung gemacht.
Mittlerweile habe ich das System soweit, dass es sich bei 12-13W Standby Verbrauch eingependelt hat. (CORE + Ecoflow + LTE)
Leider ist das langfristig immer noch zu viel, weshalb ich es jetzt abgeschaltet habe, worauf es auch nicht erreichbar war. Zu meiner Überraschung war es heute morgen jedoch online, aber in einem ungewöhnlichen Zustand.
Ich bekomme keine Batteriedaten über den Can, da diese abgeschaltet zu sein scheinen. Jedoch bekomme ich PV Spannung angezeigt (kein Ladestrom)
Ich vermute das über die PV Anlage das System mit Strom versorgt wird und sich selber gestartet hat.
(Man kann ja 12W erwarten bei diesigem Wetter und 700Wp :D)
Interessant hierbei ist auch das der PV Eingang Ansich aber gar nicht aktiviert ist (der er 15-20W Standby-Verbrauch hat, zumindest ließ sich das immer aus dem Can Batteriedaten so ermitteln, wenn aktiv und keine Sonne)

Wenn das System so aktiv ist. Könnte man es über den Can aus der Ferne wieder einschalten. Bzw auch DC wieder aktivieren. Ich werde das mal weiter beobachten.

[ahtdf]

Guten Morgen @Tristan

Kannst du den Flow mal reinstellen in dem du die ganzen Werte zur app sendest. Dann brauche ich mir nur nen halben Kopf zu machen, wenn ich ein Beispiel habe

Gruß Arno