Ja dadurch bin ich drauf gekommen die Bits zu zählen 
Hatte zwar 250 und 500 ausprobiert, aber nicht 1000
Ich bin da noch guter Dinge, ich hab ja in dem anderen Thread von dir mal nen Git angehängen, wo jemand im Endeffekt das gleiche gemacht hat, aber eben am Batteriecan an der Ecoflow. Oder wars doch der gleiche ?
Jedenfalls so schlimm kann es glaube ich nicht sein die ecoflow überlad dich zwar mit Infos, aber viele wird sich ja nicht verändern.
Also, im Anhang mal ein logfie (Ahh mist, geht nicht), faaaaaaaals einer lust hat. Aber ich glaube so schwer wirds nicht.
zwar ist das wohl tatsächlich der RV/C Bus in der Doku, aber ich denke nicht, dass hier was völlig anderes abgeht, denn im RV/C wird nur gesenet, was im EcoCan eh da ist.
Schaun wa mal:
Auf dem Bus haben wir folgende Can ID’S
| ID Ecoflow | Länge |
|---|---|
| 0x10002001 | 8 Byte |
| 0x10036001 | 8 Byte |
| 0x10050001 | 8 Byte |
| 0x10102001 | 8 Byte |
| 0x10136001 | 8 Byte |
| 0x10150001 | 8 Byte |
| 0x10202001 | 1,2,4,8 |
| 0x10236001 | 4,6,7 |
| 0x10250001 | 1,4,5,7,8 |
| 0x10602001 | 8 Byte |
| 0x10650001 | 8 Byte |
In der Dokumentation des (vermutlich RV/C) haben wir folgende für mich Relevante ID (Andere werden von einem Anderem Teilnehmer verschickt, vermutlich das Link oder das Display.
| PGN Name | PGN Number | Can ID | Default Source Address | Data Länge | |
|---|---|---|---|---|---|
| 1 | BATTERY_TOTAL_STATUS | 0x00E100 | 0x18E1E546 | 0x46 | 8 Byte (4X2) |
| 2 | BATTERY STATUS_1 | 0x00E200 | 0x18E2E546 | 0x46 | 7 |
| 3 | BATTERY_STATUS_2 | 0x00E300 | 0x18E3E546 | 0x46 | 8 |
| 4 | BATTERY_STATUS-3 | 0x00E400 | 0x18E4E546 | 0x46 | 6 |
| 5 | INTPUT_TOTAL_STATUS | 0x00E500 | 0x18E5E546 | 0x46 | 2 |
| 6 | INPUT_STATUS_1 | 0x00E600 | 0x18E6E546 | 0x46 | 7 |
| 7 | OUTPUT_TOTAL_STATUS | 0x00E700 | 0x18E7E546 | 0x46 | 2 |
| 8 | OUTPUT_STATUS_1 | 0x00E800 | 0x18E8E546 | 0x46 | 7 |
| 9 | KITS_TOTAL_STATUS | 0x00EA00 | 0x18EAE546 | 0x46 | 4 |
| 10 | LOAD_STATUS_1 | 0x00EB00 | 0x18EBE546 | 0x46 | 8 |
| 11 | LOAD_STATUS_2 | 0x00EC00 | 0x18ECE546 | 0x46 | 4 |
| 12 | BATTERY_CHARGE_STATUS | 0x00ED00 | 0x18EDE546 | 0x46 | 5 |
Das sind zumindest schonmal eine ähnliche anzahl an Can ID’s
Und auch die Art der Can Frames scheint (für einen Can Analyse Leihen) gleich zu sein.
Ich habe schon ein wenig geguckt, welche sich garnicht ändern im Log (Ganz oder Teilweise) Hierrüber lässt sich schon eine plausibelität ableiten. aber vermutlich werde ich über einen Anlyser nicht rumkommen, um live die Daten in Savvy anzusehen. Auch muss ich mich noch in das Prgramm einarbeiten, um Muster zu erkennen. Ich kann mir vorstellen, das die ds nicht komplett u mgebogen haben, zumindest muss ja alles was über den RV/C bus läuft, auch direkt auf dem Eco Can sein.
Nächtle
Edit: Morgen mal schaun ob ich das ans laufen bekomme.
zumindest könnte ich das auf das PiCan interface von meinem Desktop zugreifen.
@Vincent wie macht ihr das ?
@lbartsch
Kannst du, wenn du das nächste mal an deinem Bus bist, am Can Sniffen ?
Ich brauch auf jedenfall später noch die Signale die vom Display geschickt werden, um bspw. AC einzuschalten, oder Entladegrenzwerte setzbar zu machen (Wobei man hier auch immer noch die Eco App nehmen kann).
Tatsächlich währen AC/DC An so die wichtigsten sachen, oder Falls dir was einfällt was du gerne hättest. 
Am besten ohne Powerlink, ich will nicht wissen, was der noch alles auf den Bus haut
Ich glaube das wird deeeeutlich einfacher werden als umgekehrt.
Ansonsten habe ich mich etwas durch das Dokument gewühlt, ich denke mit Powerlink ist das ne schnelles Ding die Eco zu integrieren, da ist echt alles Dokumentiert für den RV/C Bus 
Hat noch wer eine Idee, warum ich über Sockencan(d) den Can vom PI nicht übers Netzwerk bekomme, schonmal wer ausprobiert ? Über Powershell sind die Ports erreichbar, aber Savvycan findet den Socketcand Adapter nicht.
Leider ist mein bestellter USB Dongle immer noch nicht da und es reizt weiter zu machen
So ich bin weiter, Can Dongle ist da und Analyse kann beginnen.
Was ich bisher weiß, es gibt 11 unterschiedliche Can-Frames auf dem Bus.
Absender ist immer 0x01 (Der Powerhub)
Damit hängen die Batterien vermutlich an einem eigenen Canbus.
Emfänger sind
0x00 (4mal)
0x20 (4mal)
0x60 (3mal)
Jetzt würde es ungemein helfen zu wissen wer das ist. Vermutlich ist das eine der “Powerlink” und das zweite das Display “Powerinsight” und das dritte das “Smart distribution Panel” (Sicherungsblock)
Da ich keines der Geräte besitze, ist es etwas schwierig, hier könnte man 2/3 der Arbeit aussortieren. @lbartsch wie schauts ? Welche geräte hast du ? Kannst du einen Candump machen mit einzelnen Geräten nur ?
Wie gesagt, ich komme die nächsten Wochen an mein Powerkit nicht dran.Ich höre mich aber mal im.
Kein Problem, ich hab jetzt mal ein Display bestellt und schau mal was dabei rumkommt
Also es geht weiter 
Und es ist vieeel schwieriger als gedacht.
was ich schonmal mehr weiß:
Das Display selber sendet folgende ID`s
0x10A34331 → beim einschaltern der Spannungsversogung genau 22x , danach nie wieder. Vermutlich eine Art “wakeup”.
0x10034001 → keine Ahnung, Inhalt variiert
0x10134001 → keine Ahnung, Inhalt variiert
0x10234001 → hier drin wird AC und DC eingeschaltet (Vom Display, zum HUB).
0x10634001 → keien Ahnung, immer konstant.
Dann habe ich mal die Kommunikation gesnifft und über Savvycan zurück auf das Display geloopt (ohne HUB und ohne die ID`S die das Display sendet)
Erfolg! das Display zeicht wat an (Und bleibt beim zweiten Versuch auch an, der erste hatte nur 10sec. geloopt, hier fehlte wohl eine Art “keep alive”, worauf hin das Display neu startete und eine Art Kommunikationsneustart erzwingen wollte. (22x 0x10A… s.O.)).
Was ich weis, wenn ich im Loop (vom HUB) die ID`s teilweise unterdrücke passiert folgendes:
0x10136001 oder 0x10236001 → die Anzeige mit Restlaufzeit und Batterie Staus verschwindet.
0x10102001 oder 0x10202001 → die Anzeige für Solar 1+2 und Wechselstrom Laden Verschwindet.
0x10050001 oder 0x10150001 → die Anzeige für Lichtmaschine verschindet.
0x10250001 → die Anzeige für Ausgangsleistung verschwindet.
Es sind unglaubliche viele Abhängigkeiten in der Übertragung die ich nicht verstehe.
Die Werte selber habe ich auch noch nicht gefunden.
Etliche Werte zählen zyklisch hoch etc.
Am weitesten bin ich bisher beim Display Frame 0x10234001
Da ist ein Frame immer 2 sec. lang, wobei die Abstände innerhalb des Frames am Anfang größer werden und am Ende kleiner.
Die Frames beginnen mit der Doppelt (Uptime?) läuft hoch mit Systemstart in sec. von 03 bis FF
also
03 03 ?? ?? ?? ?? 00 00 bis FF FF ?? ?? ?? ?? 00 00
Und endet jeweils mit doppel Byte, jeweils +1 hochgezählt.
Dann recht interessant:
Toogle ich am Display AC in, gibt es immer ein zwischen Frame (im Laufenden Frame). Die Gesammtlaufzeit des Frames wird nicht beeinflusst, sondern dazwischen gehauen.
Hierbei ist:
FF FF FF FF ?? ?? 00 00 → AC an UND aus ?!?
50 22 FF 01 ?? ?? 00 00 → DC AN
50 22 FF 00 ?? ?? 00 00 → DC AUS
Die Abhängigkeit der ?? verstehe ich nicht.
Irgendwie ne Checksumme aus Festwert/laufender Zähler?/BEfehlt selber?
(AC An/Aus muss ja auch noch unterschieden werden)
Mor ist eben eine für mich geniale Kleinigkeit beim Basten aufgefallen.
Das bisherige Problem war ja, der Core Pro am DC port hängt und sobald ich diesen Abschalte, der Core tod ist. Damit entfällt auch eine Sinnhaftigkeit DC abschalten zu wollen.
Aber, wie ist denn das Originale Display mit Strom versorgt ? richtig über die RJ45 CAN Dose.
Diese ist always on, denn das Display kann über Can den Hub immer einschalten. Die Specs des Display sind:
Dann wird der Stromverbrauch des Core nicht mehr unter DC gemessen, das würde er aber über einen DC/DC auf 48V auch nicht. (Der Eigenverbrauch des Hub generell auch nicht :/)
Ich weiß nicht wie genau die shunts in den Batterien sind, aber damit kann ich guuut leben.
Zwar finde ich nix zu der Max Stromaufnahme des Core Pro, aber selbst wenn wir von den Max Werte des Pi ausgehen mit 8.8W, die wir nie erreichen werden, ist da dick Luft 
Damit sollte sich auch das “Aufhängen” des Core Netzteils erledigt haben. (Das sich komischerweise auch nicht mit einer diode bezwingen ließ)
also bei mir (CorePro mit Rpi5 mit 16gb und 1TB SSD) braucht er im Idee 8W + ca 0,5W pro angezogenem Relais
summiert sich schon ganz gut um ehrlich zu sein
Bei meinem LiFePo4 Batterien JK BMS habe ich auch Tests gemacht bezüglich Stunt und hab mitbekommen das unter 1A also ca 24W nicht einmal ein verbrauch angezeigt wird und somit auch nicht gemessen
im idle modus hat das bms keinen SOC Verlust obwohl die batterie irgendwann mal leer ist da ich aber sowieso einen victron Stunt verbaut habe is mir der wert eh lieber
8W?? Das ist ja wahnsinnig viel.
Hast du die nvme oder USB?
Die jk BMS sind leider dafür bekannt . Die haben keinen richtigen shunt, sondern nur einen relativ kleinen Wiederstand (aber faktor 10-100 höher als ein richtiger shunt, da die Strommessung des BMS ursprünglich nur für die Überstromabschaltung da ist.
Die Ecoflow nmbatterien zeigen zumindest minimal 0.1 A an. Das sind bei 50V immerhin noch 5 W Genauigkeit.
Leider aber bei 3 Batterien parallel schon fast 15W in der Theorie.
Fällt mir ein, könnte man nicht über die Tankwiderstand Eingänge einen mini shunt anschließen ? Also im <50W Bereich?
NVME
Ja da Is 1A mehr oder weniger egal ^^
Sind die Batterien in Serie? Wenn parallel wäre es ja egal dann hättest no immer 5W
was würde es dir bringen? müsstet ja dann den SOC der Batterie selber berechnen dann mit einem Offset
ob es ned besser wäre einen richtigen Stunt in die Batterieleitung hängen aber da die ja nur glaub gestapelt werden gibts wohl keine anschlusskanbel
Ne, die sind parallel geschaltet. Aber wenn jede Batterie quasi knapp 5 Watt undedektiert lässt (ich weiß ja nicht ab wann der Wert auf 0.1 lA spring, sind es ja maximal 15W die insgesamt nicht gemessen werden bei drei Stück parallel.
Dem Preis der Batterien nach zu urteilen, müssen die shunts aber aus Gold und hochprezise sein
Alternative shunts hatte ich ursprünglich mal überlegt, aber die sind auch zuaufwendig.
Dazu kann nur der Victron überhaupt 48V Systeme verkraftet. Dann bräuchtest du 3 Stück (nebst serial Wandler, bzw Bluetooth) um gegenseitige Entladung überhaupt zu bemerken. Das alles macht das System ja eigentlich schon ab Werk und gibt es über den Canbus aus.
Ansonsten ja, mann müsste den soc selber neu berechnen.
Es gibt von Ecoflow noch das distribution panel (Sicherungsblock) , von der Idee geil, mir aber zu teuer. Dort hast du quasi auf jeden AC/ DC kanal gleich noch nen Shunt nebst Relais mit drauf.
Boar ist das frustrierend.
Ich habe noch nie etwas so inkonsistentes/verschlüsseltes erlebt wie den Ecoflow Can.
Es ist super einfach gewesen, herauszufinden welche Daten sich unter welchen ID’s verstecken, aber weder war herauszufinden, wie sich diese Daten dort verchlüsseln, noch wie sich in den CanFrames Checksummen Bilden um die Daten nachzubilden
In jedem einzelnen Log ist es anders, absolut keine Konsistenz.
Keine Standard Can CRC matched, es steck sichtbar ein rolling Counter dahinter, aber selber die Checksummen? dahinter sind inkonsistent.
Wenn ich das Display anstecke (4 x getestet) dann habe ich 4 mal den gleichen log, jedoch einen völlig anderen als beim letzten Versuch vor Wochen.
Das einzige was bisher klappt, komplette logs (Display an, Aktion ausgeführt, Log ende) zurück auf den Can zu Spiegeln. Das ist jedoch im Endeffekt maximal Grütze, da dadurch jeder Befehl um die Bootzeit des Displays (bzw dem gleichzeitigen kommunikationsaufbau) und dem Ausführen des Buttondruckes verzögert ist, noch ist ein sichere Replizierbarkeit gewährleistet, da das Display auch unterschiedliche Dinge sendet, jenachdem wann ich es logge.
@Vincent hat der Core pro eigentlich ein oder zwei can Interfaces ? Die multicom sind ja auch leicht unterschiedlich belegt.
Ist pin 3 Can GND, bzw ist can GND = System GND
Beim Eco ist das tatsächlich getrennt. Ich würde mir so ja quasi die System masse mit dem Can ground im eco shorten?
Der Core Pro hat nur ein Interface. Und GND ist System GND
Gruß Wulle
Sooo, einmal tief durchatmen, ich habs kapiert (hoffentlich:D)
Ich habe gestern nochmal Stewart von Wazzup angeschrieben und ne Antwort bekommen. Im Endefekt, ist es weit weniger kompliziert, wenn man das Muster Versteht. Der Trick ist eigentlich: Ecoflow hat sich quasi sowas wie einen eignen Can-FD gebaut und auf den Extended Can aufgesetzt.
Wie haben sie das gemacht? Sie nutzen nicht nur unterschiedlich CAN IDS für unterschiedliche Nachrichteninhalte, sondern sie zersplitten ihre Nachrichten in mehrere ID, um quasi endlos lange Nachrichten Frames zu ermöglichen.
-Eine Can ID startet die Message (03x Gruppe)
-Eine Can ID beinhaltet die eigentliche Nachricht (13x Gruppe), diese wird so lange in 8 Byte Länge senden, bis die Nachricht übermittelt ist.
-Eine Can ID beendet die Nachricht, inkl. Checksum Berechnung.
Ein Beispiel: DC Einschalten
| 0x10034001 | AA | 03 | 02 | 00 | F4 | 0D | 27 | F6 → Start der Nachricht | |
|---|---|---|---|---|---|---|---|---|---|
| 0x10134001 | 3B | 69 | 09 | 00 | 52 | 50 | 01 | 00 → Nachricht | |
| 0x10234001 | 50 | 22 | FF | 01 | 41 | 5E | 00 | 00 → Ende inkl Checksumme |
Anderes Beispiel:
| 10034001 | AA | 03 | 20 | 00 | 70 | 2D | 06 | 00 → Start |
|---|---|---|---|---|---|---|---|---|
| 10134001 | 00 | 00 | 0D | 3C | 34 | 35 | 01 | 00 |
| 10134001 | 35 | 10 | 07 | 4B | 37 | 36 | 30 | 5C |
| 10134001 | 37 | 44 | 33 | 5C | 41 | 37 | 4C | 36 |
| 10134001 | 36 | 37 | 32 | 07 | 0B | 3A | 07 | 06 |
| 10234001 | 34 | 30 | 07 | 07 | 04 | 07 | CC | D1 |
| 10134001 | 04 | 0A | 07 | 06 | 04 | 03 | 06 | 06 |
| 10234001 | 06 | 06 | E4 | 61 | 00 | 00 | 00 | 00 → Ende |
Jetzt erkennt man auch eine Logik in dem Ganzen Can-wirrwar.
Ich hab mich immer nur auf die 0x10234001 versteift, da hier beim blinden betrachten der Bytes, beim toggeln der Switches am Panel, die größten Änderungen sichtbar waren.
Das ganze erklärt jetzt auch völlig logisch dieses Verhalten:
0x10136001 oder 0x10236001 → die Anzeige mit Restlaufzeit und Batterie Staus verschwindet.
0x10102001 oder 0x10202001 → die Anzeige für Solar 1+2 und Wechselstrom Laden Verschwindet.
0x10050001 oder 0x10150001 → die Anzeige für Lichtmaschine verschindet.
0x10250001 → die Anzeige für Ausgangsleistung verschwindet.
Es wird zwar noch ziehmlich komplex (wissensstand jetzt :D) den Aufbau der ganzen Kommunikation zu Realisieren, jedoch sollte sich so das ganze Panel Nachbilden lassen.
Hier überlege ich noch wie weit ich da gehen will, denn die ganzen Einstellungen lassen sich ja auch über die Ecoflow APP machen. Wenn ich die Hauptparameter aber über das Vanpi steuern kann, könnte ich Wlan im Ecoflow abschalten um Energie zu sparen. Dann verliere ich zwar die Fernwartbarkeit über die APP, für die notwendigen Einstellungen kann ich dann aber die Pekaway APP nutzen. Und sollte das System nicht laufen, hätte ich ja eh kein Internet für das EcoFlow
Der Rest läuft dann lokal über Bluetooth.
Es läuft!!!
Ich bekomme die Batterie Daten aus dem Ecoflow Canbus!!
Ich glaube das war eine der verzwicktesten Dinge die ich bisher gemacht habe Da ist jeder PKW Canbus nen offenes Wörterbuch gegen.
Es ist natürlich noch viel zu tun, ich will ja noch umgekehrt das Display ersetzen, also den Hub ein und ausschalten können, solar triggern, AC/DC etc.
Aber das Protokoll ist durchdrungen.
Sobald ich das was Handfestes habe, lade ich das hier hoch.
Ich nutze aktuell die Victron Variablen, da sie für mich am meisten sinnvoll nutzbare Datenfelder haben (Inverter/Solar/etc ) (ich schreibe dazu meine Werte in die Global Variablen)
Was mich wundert, wenn ich in der Pekaway App auf Batterie klicke, bekomme ich nur leere BMS Daten (JBD?)
Im Dashboard habe ich “Main battery” auf Victron gestellt, in der App finde ich nichts weiter. Wie bekomme ich da die Victron Variablen in der App dargestellt? SOC/Strom/Spannung in der Übersicht sind da. Freudige Grüße
Hey Tristan,
in der HTTP-API hast du den Endpunkt /app_home, da siehst du die Variablen die für die Batterie, BMS und MPPT gelesen und zur App geschickt werden.
msg.payload.batt = {
“VoltB”:global.get(“MainBattVolt”) || 0,
“Ampere”: global.get(“MainBattAmps”) || 0,
“battsoc”: global.get(“MainBattSoc”) || 0,
“BMSamps”: global.get(“BMSamps”) || 0,
“BMScap”: global.get(“BMScap”) || 0,
“BMSnominalAh”: global.get(“BMSnominalAh”) || 0,
“BMScell1”: (global.get(“BMScell1”) / 1000).toFixed(3) || 0,
“BMScell2”: (global.get(“BMScell2”) / 1000).toFixed(3) || 0,
“BMScell3”: (global.get(“BMScell3”) / 1000).toFixed(3) || 0,
“BMScell4”: (global.get(“BMScell4”) / 1000).toFixed(3) || 0,
“BMSmaxcap”: global.get(“BMSmaxcap”) || 0,
“BMSmaxvolt”: global.get(“BMSmaxvolt”) || 0,
“BMSminvolt”: global.get(“BMSminvolt”) || 0,
“BMSpower”: global.get(“BMSpower”) || 0,
“BMSsoc”: global.get(“BMSsoc”) || 0,
“BMStemp”: global.get(“BMStemp”) || 0,
“BMSvolt”: global.get(“BMSvolt”) || 0,
“mpptAmps”: parseFloat(global.get(“mppt_pv_amps”) ?? 0),
“mpptVolt”: parseFloat(global.get(“mppt_pv_volts”) ?? 0),
“mpptWatts”: parseFloat(global.get(“mppt_pv_watts”) ?? 0),
}
In die Variablen schreibst du deine Werte rein, dann funktioniert es
