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.
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 von einem Moderator 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
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.
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.
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
|
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?
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.
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.
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" ?
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.
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
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.
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
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).
Sooo. In 8 stunden ist mein akku voll. :o)
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?
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.
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.
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.
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.
> 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.
Und JA !
Läuft auch bei mir mit Vin.
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?
Beitrag #7587633 wurde von einem Moderator 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)
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.
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.
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 !
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?
Beitrag #7590893 wurde von einem Moderator 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.
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.
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
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.
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);
|
1 | Serial1.setPins(-1, -1, -1, VEBUS_DE1);
|
läuft besser.
Tolle Recherche. Danke Hadmut.
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.
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.
Werde versuchen es diese Woche auf GitHub zu stellen
Hab mir das bestellt
https://de.aliexpress.com/item/1005006435592754.html
Hat LCD und RS485. Canbus brauch ich nicht. Ist ein S3.
Ich habe mal eine vorab Version auf GitHub gestellt.
https://github.com/GitNik1/VEBus.git
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 😂😂😂
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?
Hab mir noch eine SoC gebastelt.
Hallo,
aktuell steuere ich meinen 1 Woche alten Multiplus mit einem Raspi mit
dem MK3 Adapter über die MK3 Befehle. Gern würde ich mir den Raspi und
den Adapter sparen und einen ESP/Arduino einsetzen.
Im https://github.com/GitNik1/VEBus.git gibt es ja schon ein schmales
Beispielprogramm welches gut als Basis gehen sollte, Danke Nik.
Meine wichtigste Funktion wäre das Steuern (Lade- Entladeleistung). Dazu
habe ich im Beispiel nichts gefunden. Vermutlich ein Parameter aus der
VEBusDefinition.h
Das Programm von PV-Baxi hat wohl alles drinnen ist aber mega
Umfangreich für einen ersten Testaufbau. Ich glaube da verzettele ich
mich bei der Fehlersuche.
Bisher lief meine Anlage mit einem Soyosource, gesteuert von einer SPS.
Der Multiplus soll den Soyosource ersetzen. Alle Messwerte liegen
bereits in der SPS vor, mir geht es also in erster Linie um die
Sollwertvorgabe.
Vielleicht kann mir jemand einen ersten Anschub zum Loslegen geben.
Grüsse
Fred F. schrieb:
> Hallo,
> aktuell steuere ich meinen 1 Woche alten Multiplus mit einem Raspi mit
> dem MK3 Adapter über die MK3 Befehle. Gern würde ich mir den Raspi und
> den Adapter sparen und einen ESP/Arduino einsetzen.
warum willst da ewig rumexperimentieren wenn Du einfach auf den Raspi
Venus OS machen kannst?
Die Vorteile wie z.B. auch das VRM Portal,...
Macht es evtl. andersrum eher Sinn - die SPS durch den Raspi mit Venus
OS zu ersetzen?
Heinz R. schrieb:
> Macht es evtl. andersrum eher Sinn - die SPS durch den Raspi mit Venus
> OS zu ersetzen?
Nee,nee. Die SPS mach die komplette Haussteuerung von der Klingel bis
zum Rollladen inkl. Visualisierung und Fernzugriff. Die Verteilung der
PV-Energie nach Priorisierung (Warmwasser, Klima, Akku) gehört auch
dazu. Ein Raspberry + MK3_USB nur als Protokollumsetzer ist mir zu viel.
Die Beiträge lesen sich als ob die Steuerung mit dem ESP zuverlässig
läuft, also keine Experimente.
Nik schrieb:
> Löst das nicht dein problem?
> https://github.com/GitNik1/VEBus?tab=readme-ov-file#write-a-value-to-multiplus
Das hatte ich in der Doku gefunden, war mir aber nicht sicher ob das
auch die Vorgabe/Steuerung der aktuellen Inverter- und Ladeleistung
beinhaltet.
Welcher Parameter aus der VEBusDefinition.h ist das :
InverterPower = 14,
InverterPower2 = 15,
OutputPower = 16,
InverterPowerNF = 17,
InverterPower2NF = 18 ?
Sind die Bezeichnungen frei vergeben oder offiziell aus einer Doku
übernommen ?
Fred F. schrieb:
> Nee,nee. Die SPS mach die komplette Haussteuerung von der Klingel bis
> zum Rollladen inkl. Visualisierung und Fernzugriff. Die Verteilung der
> PV-Energie nach Priorisierung (Warmwasser, Klima, Akku) gehört auch
> dazu. Ein Raspberry + MK3_USB nur als Protokollumsetzer ist mir zu viel.
Nur Protokollumsetzer?
Ich bin sehr froh darüber hier mehrere dezentrale verteilte Steuerungen
zu haben
Wer macht Dir dann das Akkumanagment beim MP2?
Hier läuft das meiste über MQTT - der Speicher ist Speicher für sich,
ich sage ihm nur das er z.B. bei Wallboxbenutzung nicht entladen soll
Hier reden Venus OS, FHEM, IOBroker .... sehr gut miteinander
Aber mach gerne wie Du magst
Ramvar 14-18 sind nur zum lesen da. Verwendest du die ESS funktion? Ich
habe auf meinem private repo einen offenen feature branch das zum
schreiben und lesen von assistant daten gedacht ist. Da ich aber die
Funktion nicht brauche, habe ich es nie ausführlich getestet und das ist
auch wieder 1 Jahr her. Ich müsste das testing komplett wiederholen.
Ja, habe den ESS Assistenten in der Config mit eingestellt.
Aktuell steuere ich mit dem Python Script von martiby.
Ich Arbeite mich gerade durch die Programme von dir und pv-baxi um eine
Minimalversion zum Schreiben der Leistung zu bekommen.
Hallo zusammen,
erstmal Vielen Vielen Dank für dieses geniale Projekt.
Ich versuche grade baxi's seit einem Tag.
Leider keine Sonne so kann ich nicht besonders viel Testen.
Will aber von dem fürchterlichen und bei mir sehr absturzfreundlichen
raspi linux cerebo zeugs weg, was nebenbei auch total over engineered
ist um einem Steinzeitwechselrichter ein paar Zahlenwerte zu schicken.
Bisher kann ich nur sagen, dass der multiplus letzte Nacht so AUS wie
noch nie war keine Lampe an, kein Sound wie ein
Atomkraftwerk...ungewohnt
Wenn das halbwegs funktioniert könnte man gigawatts an standbyleistung
reduzieren.
Weis vielleich jemand ob das schon wer in ESPHOME umgesetzt hat?
Ich konnte da leider nichts finden.
ich habe mich geirrt. ich hab das Projekt von PepeTheFroggie
installiert.
Leider kann ich bisher keine sinnvolle Funktion erkennen.
Manchmal läd er den akku etwas, in sleep geht er nur, wenn ich es aktiv
sage und aufwachen tut er auch nicht selbstständig. Schade
Ich werde weiter testen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|