Ich besitze einen multiplus2 48/3000. Dieser kommuniziert mit MK3 dongle mit PC. Mich interessiert das ve.bus protokoll, nicht das mk3-usb was bekannt ist. Habe den Salae and den mk3 internen rs485 wandler angeschlossen und gescannt. Ist 250kbaud seriell. Bild 1 oberer kanal das kommt alle 20ms, keine daten drin. unterer kanal sind offenbar RX und TX gemischt. Wie unterscheide ich was RX und was TX ist? Bild 2 Das sind daten zwischen dan 20ms sync. Dann habe ich einen seriell-usb wandler angeschlossen und aufgezeichnet. Die msg habe ich nach 0xFF formatiert. Mit der grünen led an (active): 8383FE4FE48050C3D004A6490FD75F86351A015FFF 8383FD50557208A694FF 8383FE51E43A50C320C8A6490FEB5F86341A017CFF 8383FD5255F1CBA650FF 8383FE53E48050C3708BA7490FFA7F5F86341A0192FF 8383FD5455F08EA78BFF 8383FE55E43C50C3C04EA8490FFA7F5F86341A01C0FF 8383FD56557252A842FF 8383FE57E48050C31012A9490FFA7F5F86341A0165FF 8383FD5855F215A9FA02FF 8383FE59E43E50C360D5A9490FFA7F5F86341A0192FF 8383FD5A55F0D8A939FF Mit der grünen led aus (sleep mode): 8383FE22E48050C3704FED400FF82F86C20901F6FF 8383FD2355D852EDCAFF 8383FE24E47C50C3C012EE400FF82F86C20901E4FF 8383FD25555816EE83FF 8383FE26E48050C310D6EE400FF82F86C30901C9FF 8383FD2755D6D9EE40FF 8383FE28E47E50C36099EF400FF82F86C20901B6FF 8383FD2955D69CEF7AFF 8383FE2AE48050C3B05CF0400FF82F86C309019DFF 8383FD2B555860F031FF Ich brauche hilfe bei der interpretation.
:
Bearbeitet durch User
Da die Frage in deinem Post fehlt, Stelle jetzt ich eine ;) Suchst du sowas wie siehe Anhang? victron schrieb: > Beachten Sie, dass es keinen > Unterschied im Protokoll zwischen > den MK2- und MK3-Schnittstellen gibt. In den PDFs ist auch ein Link, wo der Kram her ist. mfg mf
Hadmut F. schrieb: > oberer kanal das kommt alle 20ms, keine daten drin. > unterer kanal sind offenbar RX und TX gemischt. Was ist "oberer Kanal"? RS485 nutzt zwei Signalleitungen zur differentiellen Datenübertragung, d.h. beide führen das gleiche Signal, nur auf einer ist es invertiert. Dein "oberer Kanal" hat damit irgendwie nichts zu tun. Wo hast Du Deinen LA angeschlossen? > Wie unterscheide ich was RX und was TX ist? Wenn Du direkt am RS485-Treiberbaustein messen kannst, kannst Du dort das Signal zur Sender-/Empfänger-Umschaltug abgreifen. Kannst Du das nicht, lässt sich das nur anhand der Protokollinhalte unterscheiden, aber dazu müsste man das Protokoll kennen.
@Achim Das ist das protokoll mk2/mk3 - PC, das ist bekannt und das suche ich nicht. Ich suche multiplus - mk2/mk3. @Harald Ich messe am rs485 wandler, rs232 seite. TX -> oberer kanal, RX -> unterer kanal. Ich denke TX läuft nicht über diesen wandler und ich bekomme bei RX alles gemischt. Weitere analyse: Kurzes msg 8383 FD50 55 7208A694FF : 8383 ist sync FD ist richtung, TX oder RX. 50 ist fortlaufende nummer 55 ist ein syncwort. rest unbekannt. FF ist "end of message". ganzer block kurze msg: greenon 8383 FD50 55 7208A694FF 8383 FD52 55 F1CBA650FF 8383 FD54 55 F08EA78BFF 8383 FD56 55 7252A842FF 8383 FD58 55 F215A9FA02FF greenoff 8383 FD23 55 D852EDCAFF 8383 FD25 55 5816EE83FF 8383 FD27 55 D6D9EE40FF 8383 FD29 55 D69CEF7AFF 8383 FD2B 55 5860F031FF Lange msg: greenon 8383 FE4F E48050C3D004A6490FD75F86351A015FFF 8383 FE51 E43A50C320C8A6490FEB5F86341A017CFF 8383 FE53 E48050C3708BA7490FFA7F5F86341A0192FF greenoff 8383 FE24 E47C50C3C012EE400FF82F86C20901E4FF 8383 FE26 E48050C310D6EE400FF82F86C30901C9FF 8383 FE28 E47E50C36099EF400FF82F86C20901B6FF 8383 FE2A E48050C3B05CF0400FF82F86C309019DFF
Beitrag #7543552 wurde vom Autor gelöscht.
Nach rumprobieren mit https://reveng.sourceforge.io/ ... viel simpler: Die Checksumme ist "Zweierkomplement(Summe der Bytes) + 0x01" Regeln: * die 8383er sync zählen nicht zur Summe * die 55er sync zählen nicht zur Summe * die Checksumme selbst und das Ende-FF natürlich auch nicht... Hier https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/ ist ein netter Rechner, der das ausprobieren lässt. Einige Ergebnisse: 8383 FD50 55 7208A694FF Hex input: FD507208A6 CheckSum8 2s Complement: 93 93 + 01 = 94 8383 FD58 55 F215A9FA02FF Hex input: FD58F215A9FA CheckSum8 2s Complement: 01 01 + 01 = 02 8383 FE4F E48050C3D004A6490FD75F86351A015FFF Hex input: FE4FE48050C3D004A6490FD75F86351A01 CheckSum8 2s Complement: 5E 5E + 01 = 5F 8383 FE53 E48050C3708BA7490FFA7F5F86341A0192FF Hex input: FE53E48050C3708BA7490FFA7F5F86341A01 CheckSum8 2s Complement: 91 91 + 01 = 92 mfg mf
:
Bearbeitet durch User
TY Achim. Werde noch die msg "wake up" & "sleep" mithören und dann noch die "generate X watts" und "charge with X watts". Dann versuchen das zu verstehen. Damit wird ein esp32 + rs485 wandler zur nulleispeisung und nulladung ohne das teure Cerbo teil möglich sein. Und potentialtrennung ist dann per WiFi.
:
Bearbeitet durch User
Wenn es dir nur um den Ersatz des Cerbo geht, dann kannst du auch einen normalen Raspberry Pi 4 nehmen. Victron hat das neben anderen Dingen zum Download zur Verfügung gestellt. Die Seite enthält auch weitere interessante Informationen von Victron. https://www.victronenergy.com/live/open_source:start So teuer sind die Cerbos allerdings auch nicht (Cerbo GX knapp €200,- und Cerbo GX S ca. €160,-. Ist das die Mühe wert?
Die ve.bus Protokolle wirst du von Victron nicht bekommen. Das ist auch nicht ganz ungefährlich weil darüber auch die Syncronisation von 1-n Multiplus Geräten im 3 Phasen-Netz gemacht wird. d.H. hier kann man eventuell mithören aber selbst senden dürfte schwierig sein. Timing im unteren ms Bereich wird da wichtig werden. Das ist aber auch nicht nötig. Dafür gibt es ja das mk2 Interface. Das macht auf der einen Seite RS485 Victron ve.bus Protokoll und auf der anderen Seite implementiert das das mk2 Protokoll. Es ist definitiv mehr als nur ein einfacher Wandler. Das mk2 Protokoll ist von Victron ausreichend dokumentiert und auch wie man darüber den Multiplus steuert. Ein Programm dafür hatte ich vor 2 Jahren mal für meinen Geschäftspartner geschrieben. Das stellt einfach die releventen Daten ins mqtt und reagiert auf Leistungsvorgaben (Einspeisen bzw. Laden) die über mqtt-Tokens kommen. Damit braucht man kein Ceberos o.ä. mehr. Eigentlich reicht die momentane Leistung vom Zähler um eine Nulleinspeisung zu machen. Alles andere liefert der Multiplus. Wenn man das RS232 MK2 Interface von Victron nimmt, kann man den Code auch auf einen µC bringen ohne Betriebssystem. Einen USB-Host für den MK2-USB Wandler auf barer Hardware habe ich mal probiert und bin daran gescheitert. Mann kann aber die RX/TX Leitungen im USB Interface abgreifen wenn man will. Auf alle Fälle würde ich nicht versuchen ve.bus zu spielen sondern mich auf das mk2 Protokoll beschränken. Die knapp 50 € für das Interface tun nicht so sehr weh und zum Konfigurieren braucht man es sowieso.
Jürgen L. schrieb: > Alles andere liefert der Multiplus. Wenn man > das RS232 MK2 Interface von Victron nimmt, kann man den Code auch auf > einen µC bringen ohne Betriebssystem. Das ist der plan falls die ve.bus analyse zu schwierig ist. Jürgen L. schrieb: > Einen USB-Host für den MK2-USB > Wandler auf barer Hardware habe ich mal probiert und bin daran > gescheitert. Der MK2 und MK3 haben verschiedene protokolle. Als nächstes muss ich rausfinden wer was sendet, ob MK3 oder multiplus. Da senden nicht über den rs485 chip frag ich mich wie.
Hab ich. Läuft auch. Braucht aber einen PC oder raspi und das MK3.
1 | "The Multiplus 2 is connected to a MK3 Inteface and controlled with ESS Mode 3." |
Ich möchte dasselbe ohne MK3. Ja ich weiss um die potentialtrennung.
Hadmut F. schrieb: > Hab ich. Läuft auch. Braucht aber einen PC oder raspi und das MK3. > "The Multiplus 2 is connected to a MK3 Inteface and controlled with ESS > Mode 3." > > Ich möchte dasselbe ohne MK3. > Ja ich weiss um die potentialtrennung. Nein du kannst auch das RS232 Interface nehmen, die bits und bytes sind die gleichen. > Der MK2 und MK3 haben verschiedene protokolle. Aber MK2 reicht um den Victron zu steuern und fuer VEconfig. Beim mk3 kann man sich auf eine höhere Baudrate einigen. Das ist jedenfalls mein Kenntnisstand. Ich habe beide Interfaces und sie gehen identisch. Wie willst du den den Multiplus konfigurieren ohne das Interface? Und ohne Konfiguration geht das nicht weil zumindestens das ESS als Agent konfiguriert werden muss. Das ist in den default Einstellungen nicht enthalten. Auch das o.g. Projekt https://github.com/martiby/multiplus2 geht mit dem Interface: https://www.yachtzubehoer-nordsee.de/products/victron-interface-mk2-2b-ve-bus-zu-rs232 da es auch nur als serielle Schnittstelle angesprochen wird.
Jürgen L. schrieb: > Nein du kannst auch das RS232 Interface nehmen, die bits und bytes sind > die gleichen. Ich hab das so verstanden dass die protokolle multiplus-mk2 und multiplus-mk3 verschieden sind. Ob mk2-pc und mk3-pc gleich ist weiss ich nicht. Hab nur das MK3. Jürgen L. schrieb: > Wie willst du den den Multiplus konfigurieren Mit dem MK3 :o) Für den dauerbetrieb braucht es dann nur wakeup/sleep und setpower messages.
Wenn du den mk3 usb mit einem µC steuern willt (da er sowieso schon da ist) dann mach ihn auf und geh an die RX und TX Leitungen vor dem Serial Usb Wandler. Bei meinen mk3 ist das jedenfalls ein separater ftdi Chip. Hadmut F. schrieb: > Für den dauerbetrieb braucht es dann nur wakeup/sleep und setpower > messages. Und die die ist-Werte des WR.
:
Bearbeitet durch User
Jürgen L. schrieb: > Und die die ist-Werte des WR. Brauchts eigentlich nicht. Man nimmt an istwert = letzter sollwert.
Der Ist-Wert ist schon nicht so verkehrt. Der Multiplus 2 ändert seine Leistung nur mit 400 Watt pro Sekunde (oder 600??). Wenn du das nicht berücksichtigst, dann führt es leicht zum Überschwingen in der Regelung. Ebenso wenn der Akku leer ist. Dann liefert der Wechselrichter nichts mehr und die Regelung denkt sie müsste die Leistung immer mehr erhöhen.
Einzelne lastsprünge mittels schneller regelung ausgleichen macht eigentlich wenig sinn. Was $$$ kostet ist die dauerleistung. Um lastspikes soll sich der netzversorger kümmern. Das ve.bus macht offenbar ein stuffing. Ein byte wird durch eine 2 byte sequenz ersetzt. Dadurch wird das message länger. Vielleicht FF oder 55? Versteht das jemand?
1 | FD7D55 F24AB5 96FF |
2 | FD7F55 F20DB6 D0FF |
3 | FD7755 F200B3 E8FF |
4 | FD0555 F257B8 FA04FF |
Edit: Die zahlen FA bis FF werden durch FA XX ersetzt. 0xFA wird zu 0xFA 0x00 0xFB wird zu 0xFA 0x01 ... 0xFE wird zu 0xFA 0x04 0xFF wird zu 0xFA 0x05 Stimmt das? Aber was ist denn das?
1 | FE72E4 4850 C38076B1 490F 02608634 1A01 1CFF |
2 | FE74E4 8050 C3D039B2 490F 02608634 1A01 CEFF |
3 | FE76E4 4A50 C320 FA7DB2 490F 02608635 1A01 73FF |
4 | FE78E4 8050 C370C0B3 490F 02608634 1A01 A2FF |
:
Bearbeitet durch User
Hallo Hadmut, ich vermute ich habe bereits etwas in die Richtung gemacht. Schau es dir gerne an: https://github.com/pv-baxi/esp32ess Unter /docs ist auch eine Beschreibung meiner bisherigen Erkenntnisse zum VE.Bus Protokoll: https://github.com/pv-baxi/esp32ess/tree/main/docs#readme Hier noch zwei Youtube Videos meines Systems in Aktion: https://www.youtube.com/watch?v=5YttD_S421Q https://www.youtube.com/watch?v=WXgG3uDJ3_o Viele Grüße, Baxi
Sagenhaft. 👍 Ich danke! 👍👍 Kennst du messages für "wakeup" und "sleep"? Die 4 transistor boards sind level-shifter?
:
Bearbeitet durch User
Von meinem salae scan her denke ich das 0x55 ist der eigentliche sync. Wo ist genau das zeitfenster für "setpower" message? Ich habe leider keinen scan von mk3 -> multiplus.
Sind die vermutungen im bild richtig? Ich kann den esp32 TX auf millisec genau nach den 0x55 sync legen. Welchen delay würdest du empfehlen? Bis jetzt hatte ich nicht den mut das an den realen multiplus anzuschliessen. Hab angst dass die potentialtrennung schiefgeht.
Hallo Hadmut, ja, die 4-Transistor-Boards sind bidirektionale level-shifter von 5V auf 3,3V. Ich stimme dir zu, dass die 0x55 sicherlich der eigentliche Sync-Impuls sind. Denn, wie in deinem oberen Bild im ersten Post zu sehen, sind sie mit etwas zeitlichem Abstand zu den restlichen Bytes im Frame und bei der Checksumme wird die 0x55 ebenfalls nicht mitgerechnet. Trotzdem ist die 0x55 immer Bestandteil des Sync-Frames. Ich kann dir nicht sagen, wie die originale "setpower"-message von Victron aussieht. Ich habe, wie in meiner Dokumentation beschrieben, das Kommando 0x37 (CommandWriteViaID) benutzt. Bei meinem Multiplus 48/5000 mit Firmware v502 liegt dann die Power-Variable des ESS-Assistenten auf ID 0x83 im assistent memory. Für die Codierung des Wertes, schau gerne in meine Doku unter: https://github.com/pv-baxi/esp32ess/blob/main/docs/README.md#vebus-send-frames Zu einer "wakeup" oder "sleep" message kann ich dir leider nichts sagen. Ich sende ausschließlich die aktuell benötigte Leistung an den Multiplus. Erhält dieser für >72 Sekunden keinen erneuten Leistungswert, schaltet er Ladegerät und Entladegerät automatisch ab. Falls du die zu "wakeup" und "sleep" passenden Frames herausfindest, würde ich sie in meine Dokumentation mit aufnehmen :-) Zu deinem letzten Post: Genau in dem von dir markierten Zeitraum sende auch ich mein 0x37-Kommando. Und in 98,5% der Fälle nimmt der Multiplus es auch an und sendet die entsprechende Acknowledge-Nachricht (siehe meine Doku) zurück. Ich kann allerdings bei mir nicht exakt sagen, wie viele ms nach dem Sync ich mein Kommando tatsächlich sende, da ich wie beschrieben meine Empfangs/Sendefunktion leider nicht in eine ISR packen konnte. Und ich weiß nicht wie lange einzelne ESP32-Funktionen, wie z.B. der Webserver, brauchen bis ich meine Nachricht im Empfangspuffer auslese bzw. dann mein Kommando sende. Bezüglich der Potenzialtrennung ist natürlich immer Vorsicht geboten. Ich messe allerdings bei mir im Realbetrieb von den VE.Bus-Leitungen gegen Schutzerde keine höheren Spannungen als +/-5V. Weder AC noch DC. Deshalb sah ich bei mir keine Probleme damit, meinen ESP32 und RS485-Tranceiver direkt dort anschließen. Meine Schaltung ist aufgrund des isolierten USB-Netzteils nicht nochmal mit Schutzerde verbunden, sondern somit nur indirekt über den Multiplus. Ein kleiner Tipp noch zu den Regelzeiten des Multiplus: Ich habe diese für verschiedene Lastsprünge in meinem System gemessen, daraus eine "Formel" gebildet und schätze diese in meinem Code in der Funktion applyNewEssPower(short power) ab.
Baxi schrieb: > Falls du die zu > "wakeup" und "sleep" passenden Frames herausfindest, würde ich sie in > meine Dokumentation mit aufnehmen :-) Hab noch etwas gescannt: Ich habe "sleep" und "wakeup" dumps angehängt. Suche "98F7" für mk3->multiplus. Ich dussel hab die "timestamp" beim loggen nicht abgespeichert. Jetzt darf ich den testaufbau nochmals machen :o((( Uebrigens mit meinem neuen $2 potentialgetrennten usb-serial von ali. Baxi schrieb: > Ich kann allerdings bei mir nicht exakt sagen, wie > viele ms nach dem Sync ich mein Kommando tatsächlich sende, da ich wie > beschrieben meine Empfangs/Sendefunktion leider nicht in eine ISR packen > konnte. Das musst du auch nicht. Geht einfacher. Du kannst bei "0x55" die zeit abspeichern und dann erst "x ms nach 55" senden.
1 | bool syncrxed; |
2 | unsigned long synctime; |
3 | |
4 | void multiplusCommandHandling() |
5 | ..... |
6 | char c = rxbuf[n]; //read one byte |
7 | frbuf[frp++] = c; //store into framebuffer |
8 | if (c==0x55) synctime = millis(); |
9 | if (c==0xFF) //in case current byte was EndOfFrame |
10 | ..... |
11 | if (n == nr-1) //if new ESSpower should be written |
12 | { |
13 | Serial.println("Send OK"); |
14 | syncrxed = true; |
15 | } |
und im loop:
1 | multiplusCommandHandling(); / |
2 | if (syncrxed) |
3 | { |
4 | if (millis() > synctime + 5) |
5 | { |
6 | syncrxed = false; |
7 | sendmsg(); |
8 | } |
9 | } |
Dann sendet er 5-6 ms nach sync. Direkt nach dem FF zu senden halt ich für falsch, der multiplus braucht ja noch zeit um die richtung der rs485 zu drehen bevor er empfangen kann.
:
Bearbeitet durch User
Danke für die Logfiles. Ich schau sie mir mal an, wenn ich mal etwas mehr Zeit habe. Mit welchem Victron-Programm hast du sie erzeugt bzw. den Multiplus angesteuert? Da der potentialgetrennte Converter auf USB ist, vermute mich mal, dass du es im Moment noch nicht mit dem ESP32 sondern erst mal mit dem PC probierst? Meine ersten Ansteuerungs-Versuche hatte ich mittels Laptop, einem normalen USB-seriell-RS485-Konverter und einem Python-Script gemacht. Bezüglich des Vorschlags mit der Synctime habe ich etwas Bedenken. Einen ähnlichen Code hatte ich auch erst in meinem Programm. Ich hatte allerdings nicht millis() sondern einen weiteren 100µs-Counter aus meiner ISR verwendet. Und ich hatte ebenfalls 5ms genommen. Hatte leider bezüglich der 1..2% Fehlerrate keine Verbesserung gebracht, deshalb hatte ich den Code wieder entfernt. Das Problem sehe ich darin, dass von dem Moment wo die 0x55 über die VE.Bus Leitung gehen, bis zu dem Moment wo ich in meinem Programm endlich dazu komme, sie aus meinem RX-Puffer auszulesen, vermutlich schon etwas Zeit vergangen ist. Vermutlich sogar mehrere Millisekunden, da allein meine Display-Updatefunktion schon ca. 5ms braucht. Eventuell muss dann auch das WiFi-Modul bzw. der Webserver noch auf irgendwas vorher reagieren. Das geht also nach meinem Verständnis nur dann, wenn das am seriellen Port ankommende Multiplus-Byte einen Interrupt auslösen würde welcher mein Programm sofort und kurz unterbricht und mich erstmal darauf reagieren lässt. Deshalb mein Ansatz mit der ISR.
Baxi schrieb: > Mit welchem Victron-Programm hast du sie erzeugt bzw. > den Multiplus angesteuert? mit dem python von Martin Steppuhn auf PC laufend https://github.com/martiby/multiplus2 Die log files sind von einem externen usb-seriell der an den rs485-wandler chip im MK3 drin angelötet ist. Frickelarbeit. Damit hab ich auch die pulseview salae-clone scans gemacht. Einen rs485 wandler hab ich da, aber nicht angeschlossen. Zuerst muss mir der rest klar sein. > Vermutlich sogar mehrere Millisekunden, > da allein meine Display-Updatefunktion schon ca. 5ms braucht. Dann mach das display nur wenn sonst nichts läuft, gleich nach sync-FF wenn nichts gesendet werden muss. Display hat unterste priorität. Webserver dasselbe.
:
Bearbeitet durch User
Hier noch eine "98F7" (befehl an multiplus) sequenz mit dem salae. Gemacht um timing in relation zu sync "55" zu sehen. Wow. Bis jetzt nichts abgeraucht :) "55" ist 371ms "98F7" ist 385ms "8383" ist 386ms Ziemlich enges timing? Das würde heissen senden 14ms nach sync? Hab gleich die pulseview sitzung angeheftet. multiplus2.sr, damit kannst du selber schauen. Was ist wohl die "F8F8" anfrage? Ist das "get led" ?
:
Bearbeitet durch User
Hier bei 820ms ein "98F7" 9ms nach sync. Beantwortet 15ms nach sync. Das empfangswindow scheint recht gross. Bei 966ms ein "F8F8" Bei 1126 gleich 3 datensäze vom multiplus. Was das wohl ist? Bei 1870ms ein "F8F8" Falls du das nicht schon hast, pulseview ist gratis und geil :o) Eigentlich sollte ich die daten multiplus-mk3 zusammen mit mk3-PC loggen. Dann sieht man zusammenhänge ve.bus mit dem bekannten mk3-pc protokoll.
:
Bearbeitet durch User
Anregungen: warum verwendest du für display nicht den zweiten core? https://www.youtube.com/watch?v=jpVcCmh8sig warum verwendest du nicht die 12V am vin von ve-bus mit einem 50ct wandler für die stromversorgung? Hasu du mal callback anstatt interrupt für das serielle lesen versucht? https://github.com/espressif/arduino-esp32/blob/master/libraries/ESP32/examples/Serial/OnReceive_Demo/OnReceive_Demo.ino
:
Bearbeitet durch User
OK, RX scheint zu laufen :o) string -> hex print geht einfacher:
1 | char temp[10]; |
2 | for (int i=0;i<10;i++) |
3 | { |
4 | sprintf(temp,"%02x ",rxbuf[i]); |
5 | webpage += temp; |
6 | } |
7 | webpage += "<br>"; |
Scheint zu funktionieren. Irgendwie den RX level shifter vergessen .... egal, läuft noch. Der multiplus <-> MK3 braucht ein crossover kabel. Die gezeigten pin belegungen sind mit crossover kabel. Bei straight kabeln muss man die pinnummer ändern (pin2 -> pin6, nicht getestet). Siehe bild.
:
Bearbeitet durch User
Das mit den 12V vom vin läuft nicht sauber. Der multiplus pulst das und geht nachher in fehler. KA warum. Externe versorgung muss sein. Der rs485 mit 3.3V läuft. Das mit dem auf null regeln mit dem shelly 3EM klappt. Nicht null aber +-25W um null. Messe alle 5 sek. Die interpretation der antwort auf "38 = read snapshot" würde mich interessieren. Log: 0x99, [ <Lo(V0)> <Hi(V0)> [<Lo(V1)> <Hi(V1)> [Lo(V2)> <Hi(V2)> [Lo(V3)> <Hi(V3)> [Lo(V4)> <Hi(V4)> [Lo(V5)> <Hi(V5)>]]]]]] idle 98F7 FE 6E 00E9 3874FF 99 response 8383FE7100E9 99 response 0000 V0 0000 V1 3A14 V2 - 5178 0000 V3 C800 V4 - 200 FAFF 80W invert 98F7 FE 19 00E8 38CAFF 8383FE1D00E8 99 0000 0F00 - 15 0E15 - 5390 F8FA - 64248 7FC8 - 51327 00FAFF 130w charge 98F7FE2400E838BFFF 8383FE2800E8 99 0000 0E00 - 14 0E15 - 5390 -> 53.9 V F8FA - 64248 / 1288 7FC8 - 51327 / 3781 00F0FF
:
Bearbeitet durch User
Hallo Hadmut, vielen Dank für deine Anregungen :) Es ist mir ein Rätsel, warum ich die 12V am VE.Bus damals nicht gemessen hatte. Total super, dass dir das aufgefallen ist. Habe es bei mir genauso mit einem Step-down Wandler umgesetzt wie du auf deinem Foto. Funktioniert super! Jetzt brauche ich endlich das Netzteil nicht mehr. Allein das ist aus meiner Sicht ein echter Pluspunkt unserer ESP32-Implementierung im Vergleich zu Cerbo GX oder Venus OS. Die Callback-Funktion für die Serielle Schnittstelle finde ich eine gute Idee, danke für den Link. Ich weiß allerdings nicht wann ich Zeit finden werde mich damit zu beschäftigen. Wenn ich Zeit habe, werde ich als nächstes mal SML für meinen digitalen Stromzähler implementieren, sodass ich endlich mal die Leistung mit Vorzeichen bekomme und somit problemloser und schneller kompensieren kann. Noch eine Frage zu deinem letzten Post: In deinem Versuchsaufbau verwendest du ein Crossover-Kabel, richtig? Ich verwende bei mir ein Patchkabel und habe somit RS485/VEBus an Pins 4 & 5 und die 12V an Pins 2 & 3. Woher hast du die Info, dass man ein Crossover-Kabel für den VE.Bus bräuchte? Dies habe ich nirgendwo gelesen. Und auch am MK3-Interface funktioniert mein Patchkabel super. Die 12V von Vin laufen bei mir seit heute morgen einwandfrei. Keinerlei Probleme und das sogar mit meinem Display mit Hintergrundbeleuchtung, dem zusätzlichen CAN-Transceiver und der IR-Empfangsschaltung. Alles insgesamt benötigt bei mir 90mA an 5V. Wenn ich nun Vin im Betrieb messe, liegen jetzt unter Last immer noch 10,3V an. Das ist ok. Ich habe bei mir quer unter dem ESP32 allerdings noch einen 10µF Kondensator um die Stromspitzen vom WiFi abzufangen. Und den Level-Translator am RS485-Transceiver würde ich dir doch noch empfehlen einzufügen, weil die Pins des ESP32 eigentlich nicht 5V tolerant sind. Könnte sein, dass so schon recht viel Strom durch die Schutzdioden fließt.
> Habe es bei mir > genauso mit einem Step-down Wandler umgesetzt wie du auf deinem Foto. > Funktioniert super! Warum ging das anfangs bei mir auch und jetzt nicht mehr? Irgend etwas hab ich vermurkst. KA was. > Wenn ich Zeit habe, werde ich als > nächstes mal SML für meinen digitalen Stromzähler implementieren, sodass > ich endlich mal die Leistung mit Vorzeichen bekomme und somit > problemloser und schneller kompensieren kann. Den code für den 110 eur shelly 3EM kann ich dir reinstellen, der hat +-. Die leistung der 3 phasen kann man damit mit einem http aufruf beziehen. > Woher hast du die Info, dass man ein Crossover-Kabel für den > VE.Bus bräuchte? Mein MK3 hat am normalkabel nicht funktioniert. Nur mit dem gelben kabel ging das, und gelb = crossover? Könnte auch genau anders sein. > Ich habe > bei mir quer unter dem ESP32 allerdings noch einen 10µF Kondensator um > die Stromspitzen vom WiFi abzufangen. Werde das mal versuchen. Hast du den über 5V oder 3.3V oder 12V? > Und den Level-Translator am > RS485-Transceiver würde ich dir doch noch empfehlen einzufügen, Ich lass den rs485 inzwischen mit 3.3V vom esp32 board laufen. Braucht keine level shifter. Angefügt das .zip vom shelly code. Mit "http://192.168.178.57/up" kann man OTA machen (neue firmware über wifi flashen).
:
Bearbeitet durch User
Timing: bild1: tx und sende-empfangs umschaltung. Scheint sauber. Das arduino flush() um auf ende-tx zu warten funktioniert. bild2: tx sollte 10ms nach sync sein, ist aber runde 12ms. Warum?
:
Bearbeitet durch User
Ich konnte die zeit und zuverlässigkeit massiv verbessern indem zwischen sync und message senden einfach gar nichts anderes gemacht wird als zu warten. Auch kein webserver. Eingestellt 8ms, erreicht 8,8ms. Perfekt. Jetzt muss noch ein timeout rein sonst blockiert das ganze wenn nichts über rs485 reinkommt.
:
Bearbeitet durch User
Hab deine abschäzung ob power positiv oder negativ ist gesehen. Auf die idee muss man erst mal kommen. 👍 Du brauchst den can bus zum BMS nur für max/min abschaltung? Kann das der multiplus nicht selber? Das ist ein "nice to have" aber nicht relevant? Kann man die akkuspannung nicht auch über vebus vom multiplus lesen? Hast du eine idee wie angehen? Macht das ganze powerlevel langsam rauf/runterfahren sinn wenn ich nur 5sek oder 10sek messintervalle mit stromrichtung vom shelly habe? Habe den code auf 2 kerne verteilt aber noch nicht ausgemessen. Alles vebus zeugs auf einem kern und das ganze webserver-http gedöns auf dem anderen. Hoffe auf gute vebus responstime und zackige reaktion des webservers. Schade hast du keinen shelly.
Auslesen der batteriespannung: TX command read ram -> 30 0x98 0xf7 0xfe desiredFrameNr 0x00 0xe6 0x30 0x04 response 83 83 fe 77 00 e6 85 86 14 87 ff 85 -> ok, 90 -> fail, 14 86 = 5254 = 52.54 Volt. Damit kann man RAM variable alle auslesen: 0 UMainsRMS 1 IMainsRMS 2 UInverterRMS 3 IInverterRMS 4 UBat 5 IBat 6 UBatRMS (= RMS value of ripple voltage) 7 Inverter Period Time (time-base 0.1s) 8 Mains Period Time (time-base 0.1s) 9 Signed AC Load Current 10 Virtual switch position 11 Ignore AC input state 12 Multi functional relay state 13 Charge state (battery monitor function) 14 Inverter Power (filtered) 15 Inverter Power (filtered) 16 Output power (filtered) 17-19 correspond with 14-16 but these are the ‘unfiltered’ values. Aus https://www.victronenergy.com/upload/documents/Technical-Information-Interfacing-with-VE-Bus-products-MK2-Protocol-3-14.pdf seite 23.
:
Bearbeitet durch User
Mankann die sachen auch aneinanderhängen. outbuf[j++] = 0x00; //our own ID outbuf[j++] = 0xe6; //our own ID outbuf[j++] = 0x30; //Command read ram outbuf[j++] = 0x00; //umain outbuf[j++] = 0x04; //4-bat volt ergibt dann 83 83 fe 44 00 e6 85 15 5e 80 14 4d ff 1480 -> 52.48 V bat 5E15 -> 240.85 V mains Was ich nicht verstehe ist der strom.
Fehler gefunden :) Ich kann jetzt sowohl AC wie auch DC spannung und strom vom multiplus lesen. Das macht eingentlich für eine verbindung zum BMS überflüssig. Richtig ?
Hi Hadmut, die Stromversorgung meiner Schaltung über Vin läuft immer noch absolut zuverlässig. Hier ein paar Antworten zu deinen Beiträgen: > Den code für den 110 eur shelly 3EM kann ich dir reinstellen, der hat > +-. Die leistung der 3 phasen kann man damit mit einem http aufruf beziehen. Den Shelly 3EM offiziell zu unterstützen finde ich sehr sinnvoll. Ich persönlich lese die Leistung trotzdem weiterhin lieber von meinem offizellen Zähler aus. Denn dieser ist sowieso vorhanden und mit dem bin ich logischerweise auch am genauesten. > Mein MK3 hat am normalkabel nicht funktioniert. Nur mit dem gelben kabel > ging das, und gelb = crossover? Könnte auch genau anders sein. Von früher kenne ich, dass Cross-Kabel mal rot waren. Heutzutage gibt es natürlich auch Patchkabel in allen Farben. Dass Cross gelb ist, halte ich hingegen für selten. > Werde das mal versuchen. Hast du den über 5V oder 3.3V oder 12V? Ich habe nur einen 10µF Kondensator quer unter dem ESP32 DevBoard zwischen 5V und GND. Danke für das Beispiel mit OTA. Hätte ich mir viel komplizierter vorgestellt. Bezüglich des RS485 Transceivers an 3,3V: Das kann funktionieren, aber eventuell auch nicht immer zuverlässig. Super finde ich auch deine Implementierung mit dem Serial1.flush() Befehl. Werde ich bei mir auch noch so ändern. Ist so viel einfacher und universeller. Toll, dass jetzt das Auslesen von Spannung und Strom bei dir klappt. Ich hatte das auch mal ganz am Anfang gemacht, um rauszufinden in welcher Multiplus-RAM-Variable die ESS-Leistung steht. Da habe ich alle möglichen ausgelesen und geschrieben und geschaut was passiert. > Du brauchst den can bus zum BMS nur für max/min abschaltung? Eigentlich ja. Allerdings ist der SOC-Wert für mich tagtäglich neben der momentanen PV-Leistung der interessanteste Wert auf den ich schaue. Will ihn also nicht missen. Die Besonderheit bei LiFePO4-Akkus ist nun mal, dass man anhand der Spannung leider nicht wirklich auf den Ladezustand schließen kann. Die Lade-Entladekurve ist so flach, dass zwischen 10% und 90% Ladezustand die Spannung eigentlich gleich ist. Wenn man also wirklich nur grob bei ganz voll oder ganz leer den Multiplus abschalten will, reicht vermutlich auch die Spannung. Wenn man allerdings den Akku lieber in einem gesunderen Ladezustand halten möchte (30..50%), dann geht es nur über den SOC-Wert vom BMS. Genau das möchte ich bei mir jetzt ändern. Ich habe nämlich momentan das Problem, dass bei dem trüben Wetter der Akku von der PV immer nur ganz wenig geladen werden kann, und dann abends immer wieder restlos leer wird. Ich habe meinen Multiplus ja per ACin und ACout angeschlossen, das heißt der Multiplus kompensiert die Leistung an ACout momentan selber und nutzt somit die im ESS-Assistenten konfigurierten Spannungsschwellen um festzustellen ob der Akku voll oder leer ist. Diese habe ich durch mehrfaches Probieren auch gut auf 4%/97% SOC eingestellt. Allerdings durch dieses ständige nur-wenig-aufladen ist das BMS scheinbar nicht mehr in der Lage ordentlich zu arbeiten und mittlerweile zeigt mir mein Master-Pylontech sogar schon bei 8% SOC einen Pre-Alarm rot an. Dies hat mich überzeugt, das ich die Steuerung derart verbessern sollte, dass der Akku immer eher mittelvoll gehalten wird, mit Schwellen abhängig vom momentanten PV-Ertrag.
Baxi schrieb: > Genau das möchte ich bei mir jetzt ändern. Ich habe nämlich momentan das > Problem, dass bei dem trüben Wetter der Akku von der PV immer nur ganz > wenig geladen werden kann, und dann abends immer wieder restlos leer > wird. Löse dir bei openweathermap eine ID (gratis). Damit kannst du schauen wie morgen die bewölkung ist und eine sonnenscheinvoerhersage erstellen. Hatte ich vor einem jahr mal gemacht um den max entladelevel zu bestimmen. http://api.openweathermap.org/data/2.5/weather?q=Berlinb,de&units=metric&appid=deine_api_id Falls du beim json decoden mühe hast, ich hab das noch irgendwo. Baxi schrieb: > Ich habe nur einen 10µF Kondensator quer unter dem ESP32 DevBoard > zwischen 5V und GND. hab das reingemacht und jetzt startet der esp32 nur mit reset knopf zuverlässig. Muss den tauschen. Beim strom war das problem dass kleine negative werte in den FA-FF stuffing bereich kamen. Es braucht beim input generell ein de-stuffing. Die regelung wird besser wenn ich die leistung vom multiplus einlese anstatt sie zu schäzen. Ich stell den code nochmals rein. Mit graphik & de-stuffing & 2-kernen & bat/power auslesen.
:
Bearbeitet durch User
Das ist die grafik heute morgen. "Charge Only" mode. Skala oben 1000W verbrauch, mitte 0W, unten 1000W einspeisung. rot daten vom shelly3EM, blau esspower zum MP2, grün MP2 AC power meldung. Zeitachse ist ein punkt alle 5 sek. 480 punkte -> 40 minuten. Die regelung versucht die negativen shelly werte auf -10W zu regeln. Motto: für 8ct speis ich nix ein ! Blob mitte -> kafee. Andere -> oelheizung.
:
Bearbeitet durch User
> Das ist die grafik heute morgen.
Megacool, Hadmut!
Die Idee die aktuelle Leistung aus dem Multiplus auszulesen anstatt den
Abschluss der Regelung zu schätzen finde ich auch gut. Ich habe ja die
Vermutung, dass der Multiplus sicherlich auch selber weiß, wenn er sich
eingeregelt hat. Dies muss er ja auch einem Cerbo GX mitteilen. Könnte
dies vielleicht im sync-frame in dem noch unbekannten Byte (0x51)
codiert sein, welches nach dem 0x55 folgt?
Heute herausgefunden warum der MP2 manchmal in fault gegangen ist. Weil der esp32 nicht zuverlässig startet und die rs485 leitung zum MP2 dann auf senden hält. Das hatte mit Vin gar nichts zu tun :) Das problem ist beim doit V1 bekannt. C der reset schaltung zu klein.
Die rot eingezeichneten leitungen können den MP2 in standby versetzen. Wie genau weiss ich nicht. Damit kann der verbrauch nachts wenn akku leer ist auf fast null gesenkt werden. Die gehen original über einen transistor nach gnd. Danke das würde mit einem esp32 pin im OpenCollector mode auch funktionieren, vielleicht noch eine diode um von 4V auf 3.3V zu kommen. 40ma kann der GPIO ab. Ob sich in stby Vin abschaltet?
:
Bearbeitet durch User
Beitrag #7587633 wurde vom Autor gelöscht.
Es ist dir bewusst dass du mit überlagerung von AC spannung und AC strom ziemlich einfach die stromrichtung rausfinden kannst? Dann musst du nicht mehr raten :o)
So stell ich mir das vor. Eine 50hz SWR brücke. Bei verbrauch sind U und I synchron, addieren, bei erzeugung sind U und I 180grad versetzt, subtrahieren. Oder anders rum :o)
:
Bearbeitet durch User
Hallo Hadmut, danke für deine Überlegung. Ich habe nicht vor meinen eigenen (3-phasigen) Stromzähler zu bauen ;-) Denn ich habe ja schon einen digitalen Zweirichtungszähler. Und dadurch dass ich auch meinen 4-stelligen Zählercode habe, gibt mir dieser über die digitale optische Schnittstelle per SML jede Sekunde auch die exakte Leistung inklusive Vorzeichen aus. Ich muss nur einfach mal Zeit finden, die SML-Auswertung in ESP32ESS mit zu implementieren. Das ist kein Hexenwerk und wird in YouTube (IchBauPV) gut erklärt. Ich habe es bisher nur noch nicht gemacht, weil ich mit der Impuls-Schnittstelle erstmal eine Möglichkeit schaffen wollte, die man an jedem digitalen Zähler nutzen kann, selbst wenn man keinen Zählercode oder keinen Zweirichtungszähler hat. Außerdem hat die Kompensation so bisher ausreichend gut funktioniert und SML hatte deshalb noch keine hohe Priorität. Kommt aber demnächst, keine Sorge ;-)
Hadmut F. schrieb: > Die rot eingezeichneten leitungen können den MP2 in standby versetzen. > Wie genau weiss ich nicht. Damit kann der verbrauch nachts wenn akku > leer ist auf fast null gesenkt werden. Ich arbeite auch daran den Standbyverbrauch zu reduzieren. Meiner zieht sonst im ESS Modues 0,6A @50V bei 0W AC Leistung. Das ist nicht schön:( In der Schnittstellenberschreibung des MK2 steht unter "3.5 Jumpers in the MK2" ... To be able to switch it on one needs to pull the “Stand by” line to GND. This will enable the internal power supply and make it possible to receive and send commands. The “switch on” command can be send then and the unit will switch on ... Man kann mit der Stanbyleitung das Gerät also nicht in abschalten, sondern dafür sorgen, dass ein ausgeschaltetes Gerät trotzdem per Schnittstelle ansprechbar ist um dieses per Befehl ein oder aus zuschalten. Dann wäre noch die Frage wieviel das Gerät zieht mit Hardwareschalter Off und Standbyleitung Low.
:
Bearbeitet durch User
Matthias X. schrieb: > Man kann mit der Stanbyleitung das Gerät also nicht in abschalten, > sondern dafür sorgen, dass ein ausgeschaltetes Gerät trotzdem per > Schnittstelle ansprechbar ist um dieses per Befehl ein oder aus > zuschalten. Interessant. Hast du eine ahnung was dieser einschalt oder ausschalt befehl ist? Ich hab das mit dem MK3 mal geloggt aber nie rausgefunden. Die beiden tasten im bild. Hab die dumps mal angehängt. wakeup-sleep.txt ist zusammenfassung. Ich seh da nichts. > Dann wäre noch die Frage wieviel das Gerät zieht mit Hardwareschalter > Off und Standbyleitung Low. Null bei stby high nehm ich an? Hab das nie gemessen.
:
Bearbeitet durch User
ist das wakeup? 98F7FE603F070000005DFF und das sleep? 98F7FE6F3F0400000051FF Die wakeup prozedur wäre dann stby auf low und 98F7FE603F070000005DFF senden? Fuck! Jetzt hat er ausgeschaltet un will nicht wieder an !
:
Bearbeitet durch User
Ich habe es noch nicht probiert. Ich nutze aber das MK3 und würde diesen Befehl versuchen: Command: ‘S’ <Switch state> <Pot value> <Panel scale> 0x01 <Flags> Reply: ‘S’ <Switch state> Meaning 1 Charger only 2 Inverter only 3 On 4 Off
Ja ich hab in mit dem MK3 wieder einschalten können. Lol. Probier den ausschaltbefehl nicht bevor die einschaltlogik steht. Der geht nämlich dann auch mit dem schalter nicht mehr an. 1 Charger only 2 Inverter only 3 On 4 Off Interpretation: 04 = off, 07 ist 03 + 04 = on? Wenn die sonne untergeht probier ich das mal. Das stby signal kann ich auf dauer low lassen?
:
Bearbeitet durch User
Beitrag #7590893 wurde vom Autor gelöscht.
Das wäre gut wenn du es ausprobieren könntest. Kannst du den DC-Strom und AC-Leistung messen? Meine Vermutung (Hoffnung): Schalter auf Ein: AC~0W, DC~ 0,6A Schalter auf Aus + Standby-Signal floating: AC~0W; DC~ 0,000A; keine Kommunikation möglich Schalter auf Aus + Standby-Signal GND: AC~0W; DC< 0,1A; Kommunikation möglich. Dann würde das Abschalten des MP definitiv was bringen.
Ich werde kaum mein multimeter opfern um DC strom zu messen. Der 300ah akku putzt die 10A sicherung problemlos weg. Das zangenamp meter dürfte zu unempfindlich sein. Damit kann man zwar erdmagnetfeld messen, aber keine kleinen ströme. Und die DC A anzeige vom daly-bms taugt auch nix.
Hast du einen DC-Trennschalter? Wenn es riskant für das Multimeter wird, dann messe ich den Strom so: Zangenmultimeter anschließen. Wenn angezeigter Strom nur noch gering, dann gehe ich mit den Messspitzen des Multimeters über den DC-Trennschalter. Wenn Zangenstrom weiterhin gering, Trennschalter öffnen, Strom am Multimeter ablesen und Trennschalter wieder an. Geht einfach, ist sicher und sehr genau.
Hallo Zusammen. Tolle Arbeit von euch. Bin auch gerade am ve.bus Protokoll um es mit dem ESP32 anzusteuern und auszulesen. könnte das eine Error Meldung sein vom Multiplus-II? 83 83 FE 15 E4 80 50 C3 70 64 08 00 0E 00 00 00 31 05 01 56 FF https://www.victronenergy.com/live/ve.bus:ve.bus_error_codes
Matthias X. schrieb: > Hast du einen DC-Trennschalter? Ich bastle erstmal ein funktionierendes ein-aus system mit einem schalter an der "stdby" leitung. Dann mess ich mal methode "Trennschalter". Nik schrieb: > könnte das eine Error Meldung sein vom Multiplus-II? Der mit dem besten durchblick ist der pv-Baxi. Der kann inzwischen temp und amps aus dem "normalmessage" rausholen. Ist auf seinem git. Mein "read ram variable" system ist da viel komplizierter. Ich brauch "bat volt" um meine brandneuen eve305ah nicht abzuschiessen. BMS kommunikation hab ich keine. Uebrigens das ganze ist 12 stunden durchgelaufen und kein problem. Nur der lüfter des multiplus stört.
:
Bearbeitet durch User
Hadmut F. schrieb: > Mein "read ram variable" system ist da viel komplizierter. Ich brauch > "bat volt" um meine brandneuen eve305ah nicht abzuschiessen. BMS > kommunikation hab ich keine. Das verstehe ich nicht. 1. Das BMS sollte doch dafür sorgen, dass die Spannungsgrenzen des Akkus eingehalten werden. Und das für jede Zelle. 2. Der MP2 hat doch auch Grenzen für maximum charge voltage und undervoltage. Außerhalb davon kann ich dem ESS Werte geben wie ich will, es wird nicht weiter geladen/entladen.
Der MP2 hat das gedöns mit bulk & absorption & float das eigentlich für bleiakkus ist und das ich nicht verstehe. Heute hat er bei 20A laden mit akku auf 80% einfach abgestellt und 56V "absorption" angezeigt. Strom null. BMS hatte nur 53.2V. KA was der macht. Einstellungen default für lifepo4. Ausserdem berechnet der MP2 den stromabhängigen spannungsabfall auf den kabeln nicht ein. Das BMS ist nur letzte sicherung falls anderes versagt.
Hadmut F. schrieb: > Heute hat er bei 20A laden mit akku auf 80% einfach abgestellt und 56V > "absorption" angezeigt. Strom null. BMS hatte nur 53.2V. KA was der > macht. Kann es sein, dass dein BMS getrennt hat weil eine Zelle bereits voll war?
Hadmut F. schrieb: > Der MP2 hat das gedöns mit bulk & absorption & float das eigentlich für > bleiakkus ist und das ich nicht verstehe. Das sind Begriffe aus der Bleiakkuzeit. Da hat man eine Autobatterie auf 14,4V geladen aber nach ein paar Stunden musste man auf 13,8V runter gehen weil die dauerhaften 14,4V zu Gasung und damit zu einer kurzen Lebensdauer führt. Bei LiFePo Akkus ist das nicht notwendig. Du kannst einfach für absorbtion und float 16x3,5V eintragen. > Ausserdem berechnet der MP2 den stromabhängigen spannungsabfall auf den > kabeln nicht ein. Doch, dass kannst du zumindest für das Entladen einstellen. Beim ESS Tool hast du die Möglichkeit die Abschaltspannung bei 0,005C; 0,25C; 0,7C und 2C einzustellen. Da kannst du deine Kabelverluste einberechnen.
Die zellen sind alle im 0.002V bereich. Denke das war das BMS mit max ladestrom. Hab 40A eingestellt, nichtwissend dass die stromanzeige vom daly wild schwankt. Der hat wohl bei 22A mal über 40A gemessen und kurz abgestellt. Das abstellen hat der MP2 dann als "voll" interpretiert.
Uebrigens, das sleep - wakeup zeugs läuft ohne hardwaremodifikation. Man muss STB gar nicht runterziehen. So:
1 | int cmdOnOff(char *outbuf, byte desiredFrameNr, bool doon) |
2 | { |
3 | // 98F7 FE 60 3F07 0000005DFF wakeup |
4 | // 98F7 FE 6F 3F04 00000051FF sleep |
5 | byte j=0; |
6 | outbuf[j++] = 0x98; //MK3 interface to Multiplus |
7 | outbuf[j++] = 0xf7; //MK3 interface to Multiplus |
8 | outbuf[j++] = 0xfe; //data frame |
9 | outbuf[j++] = desiredFrameNr; |
10 | outbuf[j++] = 0x3F; //cmd |
11 | if (doon) outbuf[j++] = 0x07; //wakeup |
12 | else outbuf[j++] = 0x04; //sleep |
13 | outbuf[j++] = 0x00; |
14 | outbuf[j++] = 0x00; |
15 | outbuf[j++] = 0x00; |
16 | return j; |
17 | } |
Gemäss dem $20 Aneng ST209 china-ampometer: on = 0.6A off = 0.05A Dabei bleibt Vin auf 12V und die kommunikation mit dem MP2 läuft weiter.
:
Bearbeitet durch User
Sehr interessant. Laut Dokumentation sollten die 12V abschalten. Danke für die Messungen. Da lag ich ja mit meinen Schätzungen ganz gut. Das macht immerhin 30W Unterschied. Ist aber schon komisch, dass deine Daly-Anzeige bei 20A Ladestrom peaks bis 40A misst.
Muss ich vielleich die "panel" leitung runterziehen? Oder hab ich falsch angeschlossen? Egal, die 3W darf er brauchen. Das schwanken ist beim daly bms so. Abhilfe mit einem firmware update der vielfach schiefgeht. Also lass ich das. Hab jetzt den daly auf 100A gestellt und die absorption/float V so wie du sagst.
@Hadmut Danke für deine ganzen Tipps die du mir hier gegeben hast :) Und danke auch für deinen Github-Link. Meine veBusHandling-Routine läuft jetzt ebenfalls auf Core0, nun endlich mit einer Fehlerrate von Null. Beachte bitte, dass wir einen Fehler in der Checksummen- und destuff-Routine hatten. Bei einer Checksumme von 0xFA wird kein 0x00 eingefügt. Und dein Sleep/Wakeup-Kommando kam genau im richtigen Moment. Ich nutze es, um beim minimal gewünschten Akkustand in den ChargeOnly-Modus (=5) umzuschalten. Wie dir schönerweise aufgefallen ist, habe ich nun so viele wie möglich von den "Normalmessages" entschlüsselt. Ich weiß noch nicht wann ich dazu kommen werde, die Erkenntnisse in meiner Github-Doku zu ergänzen. Bis dahin durchstöbere gern meine decodeVEbusFrame() Funktion. @Nik Das E4-frame ist leider die einzige Normalmessage, der ich noch keine nützlichen Infos entlocken konnte. Es kommt ja genauso wie das Sync-frame mit 50Hz. Es enthält vermutlich Zeitstempel sowie AC-Phasenlagen-Infos. Ein Fehler-Kommando ist es meiner Meinung nach nicht. Diese sehen vermutlich so aus: 83 83 FC 00 0F 7F 00 77 FF
:
Bearbeitet durch User
Baxi schrieb: > Beachte bitte, dass wir einen Fehler in der Checksummen- und > destuff-Routine hatten. Danke, korrigiert. > Und dein Sleep/Wakeup-Kommando kam genau im richtigen Moment. Ich nutze > es, um beim minimal gewünschten Akkustand in den ChargeOnly-Modus (=5) > umzuschalten. Ich denke das für power-save zu verwenden wenn akku low und keine sonne. Da muss der MP2 keine 25W verbraten, dann kann der standby gehen und nur 3W verheizen. Das Vin power bleibt ja erhalten. > Wie dir schönerweise aufgefallen ist, habe ich nun so viele wie möglich > von den "Normalmessages" entschlüsselt. Deine geschwindikeit und gründlichlkeit ist bewundernswert. Ich komm da gar nicht mit. Ohne dein projekt hätte ich nie etwas funktionsfähiges hingebracht. Meinen 💛 dank dafür. Z.z. spiele ich mit der regelung. Blau = geschäzter gesamtverbrauch, Rot = shelly verbrauchsmessung, Grün = MP2 einspeisung. Target = 50W. Gefilterte regelung wenn vorzeichen verbrauch und einspeisung gleich, andernfalls schnelle regelung. Deine spike reduzierung werde ich noch anschauen. Habs gesehen aber noch nicht begriffen.
:
Bearbeitet durch User
Man kann das RS485 read/write signal auch per hardware erzeugen lassen indem man das espressif API verwendet. Dann muss man am ende des tx nicht warten bis alles raus ist und den wandler auf empfang stellen. Für serial1 testproggi:
1 | #include "driver/uart.h" |
2 | |
3 | const int VEBUS_RXD1=16, VEBUS_TXD1=17, VEBUS_DE1=4; |
4 | const int UART_USED = UART_NUM_2; |
5 | |
6 | void setup() |
7 | { |
8 | Serial.begin(115200); |
9 | Serial.println("Start"); |
10 | |
11 | uart_config_t uart_config = |
12 | { |
13 | .baud_rate = 256000, |
14 | .data_bits = UART_DATA_8_BITS, |
15 | .parity = UART_PARITY_EVEN, |
16 | .stop_bits = UART_STOP_BITS_1, |
17 | .flow_ctrl = UART_HW_FLOWCTRL_DISABLE, |
18 | .rx_flow_ctrl_thresh = 32, |
19 | }; |
20 | uart_driver_install(UART_USED, 256, 256, 0, NULL, 0); |
21 | uart_param_config(UART_USED, &uart_config); |
22 | uart_set_pin(UART_USED, VEBUS_TXD1, VEBUS_RXD1, VEBUS_DE1, -1); |
23 | uart_set_mode(UART_USED, UART_MODE_RS485_HALF_DUPLEX); |
24 | |
25 | Serial.println("Done"); |
26 | } |
27 | |
28 | char buf[3] = { 0xaa, 0x00, 0x55 }; |
29 | |
30 | void loop() |
31 | { |
32 | uart_write_bytes(UART_USED, buf, 3); |
33 | delay(100); |
34 | } |
Mit dem MP2 hab ich das noch nicht probiert.
Wenn man nicht den port #3 nimmt wird es einfacher. lol. Die doppeldefinition von serial.open und uart_set_pin kann ich nicht vermeiden.
1 | const int VEBUS_RXD1=16, VEBUS_TXD1=17, VEBUS_DE1=4; |
2 | const int UART_USED = UART_NUM_1; // serial port 0,1,2 |
3 | |
4 | void setup() |
5 | { |
6 | Serial1.begin(256000, SERIAL_8N1, VEBUS_RXD1, VEBUS_TXD1); |
7 | uart_set_pin(UART_USED, VEBUS_TXD1, VEBUS_RXD1, VEBUS_DE1, -1); |
8 | uart_set_mode(UART_USED, UART_MODE_RS485_HALF_DUPLEX); |
9 | } |
10 | |
11 | char buf[3] = { 0xaa, 0x00, 0x55 }; |
12 | |
13 | void loop() |
14 | { |
15 | Serial1.write(buf, 3); |
16 | buf[1]++; |
17 | delay(100); |
18 | } |
oder noch einfacher
1 | Serial1.begin(256000, SERIAL_8N1, VEBUS_RXD1, VEBUS_TXD1); |
2 | Serial1.setPins(-1, -1, VEBUS_DE1, -1); |
3 | Serial1.setMode(UART_MODE_RS485_HALF_DUPLEX); |
:
Bearbeitet durch User
Die ID im Protokoll, bei baxi ist es die [0x00,0xE6], kann so wie ich das sehe zwischen [0x00,0x80] und [0x00,0xFF] beziehungsweise [0x00,0x0xFA,0x7F] sein.
Hab meine hardware von provisorisch auf permanent updated. Mit "double sided stiky tape" aufgeklebt.
:
Bearbeitet durch User
Guten Morgen. Ich habe Probleme die "Inverter Power (filtered)" RamVar zu interpretieren. Habt ihr da schon erfolg?
Hadmut F. schrieb: > Hab meine hardware von provisorisch auf permanent updated. Da ich mich auf die Software konzentriert habe, verwende ich den LILYGO T-CAN485. Dies ist eine Plug and Play Lösung und funktioniert für die ersten Gehversuche perfekt. Zudem kann ich dann auch gleich den VE.CAN testen.
Bis jetzt funktioniert bei mir die folgenden Funktionen: _vEBus.WriteViaID(Settings::IMainsLimit, value); _vEBus.ReadInfo(RamVariables::IBat); _vEBus.Read(RamVariables::IBat); _vEBus.ReadInfo(Settings::IBatBulk); _vEBus.Read(Settings::IBatBulk); Ich habe noch nicht alle RamVar und Settings getestet aber es sieht nicht schlecht aus. Ausser eben die "Inverter Power (filtered)".
Machst du das denn über 0x30 read ram mit der 0x85 antwort? Das dürfte inverter AC leistung gefiltert sein. Hab ich nie angeschaut, hat mich nicht interessiert, brauch ich nicht.
Hadmut F. schrieb: > Machst du das denn über 0x30 read ram mit der 0x85 antwort? Genau über den 0x30 und interpretieren über den 0x36
rein aus Interesse - wo seht ihr den Vorteil gegenüber einfach einem Raspi mit Venus-OS zu nutzen? Bessere Steuerung? Höhere Effizienz?
Ich benötige das Victron System in meinem Wohnmobil und A. Möchte kein betriebssystem an board weil das System immer wieder Ausgeschaltet wird. B. Ich möchte es in mein System integrieren, sprich mein eigenes Display mit Integration von Lichtsteuerung und Standheizungen ect.
Nik schrieb: > Ich habe Probleme die "Inverter Power (filtered)" RamVar zu > interpretieren. Habe den fehler gefunden. hatte die falsche Adresse hinterlegt.
Hab mir das bestellt https://de.aliexpress.com/item/1005006435592754.html Hat LCD und RS485. Canbus brauch ich nicht. Ist ein S3.
Was bis jetzt funktioniert: *Senden und Empfangen von Nachrichten auf Core 0. *Erneutes senden wenn nicht geklappt. *Wenn vor dem Timeout das gleiche Setting oder RamVar gelesen wird, wird es im Sende Fifo überschreiben. *Wert Validierung. *Werte können Volt/Ampere (float) eingegeben werden.
PS: Validierung mit Multiplus-II 12/3000 getestet und hinterlegt. Ich vermute mal der 5000er hat andere defaults und min max Werte. Bei Interesse kann ich weitere #defines für Geräte einpflegen. Mehr darüber, einfach melden.
Nik schrieb: > Ich habe mal eine vorab Version auf GitHub gestellt. > https://github.com/GitNik1/VEBus.git Super. Habe es auf meinem git verlinkt. Muss das erst mal durchschauen. Scheint etwas weniger hemdsärmeilig als mein zeugs 😂😂😂
:
Bearbeitet durch User
Habe noch ein Example hochgeladen wie man alle RamVar- und SettingInfos printed. Wenn ihr möchtet könnt ihr das testen und mir den output zusenden. So kann ich, wenn ihr ein anderes Gerät habt als den Multiplus-II 12/3000, ein neues Gerät hinzufügen.
Dachte immer mit meinem schlecht orientierten 3kwp BKW bekomm ich die 15kwh nie voll. Aber der erste sonnige februar tag bringt den akku auf 54V :) Grummel. Die störche auf nachbars baum sind auch schon wieder dabei. Geklapper ohne ende. Ist das nicht etwas früh?
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.