Du bist gut ausgestattet und deine Recherche ist spannend. Vielen Dank!
Ich hätte noch eine Challenge für dich: https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/issues/7
Merci, merci.
A fool with a tool is still a fool
Ich habe nämlich die TX Leitung vom Wifi-Modul gar nicht am Logic Analyzer angeschlossen ![]()
Ok, kaum macht mans richtig schon gehts. Es kommt nämlich vor der Status-Message immer ein gleichbleibender Request
55 01 2C 2B 5A 63 00 00 00 04 00 E6
Sieht so etwas LIN-mäßig aus mit dem Sync-Byte am Anfang. Ist aber kein LIN.
So, jetzt was wir eigentlich wissen wollten: wenn man eine neue Konfig schickt, kommt:
55 0B 2C 2B 5A 63 00 00 00 04 12 CA
Also wieder genau das selbe, nur mit 0B am Anfang und am Ende die 12 statt 00. Und eben diese 12 ist der neue Modus
- 01 = PV Mode
- 11 = PV Limit
- 02 = BatConst
- 12 = BatLimit
Die anderen Sachen dürften wieder klar sein: Startspannung, Mindestspannung, Leistung, Frequenz (kann man nicht einstellen, aber ist halt da) und zuletzt die Wartezeit.
Ich würde allerdings über die Config-Message keine Leistungsvorgabe machen weil ich vermute, dass jede solche Message in einem Flash-Schreibvorgang resultiert. Da wäre dann nach 10000s oder so Schluss ![]()
Also ich denk mal mit diesen Infos müsste man seinen Soyosource auch ohne die abenteuerliche App auf Batteriebetrieb umstellen können.
worum gehts da? 
Ich hätte noch eine Challenge für dich: https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/issues/7
Achja, hier mal noch ein Bild von der "Anlage"
Ja, ich habe zwei alte 40er LFP Akkus mit dem 12S NMC Akku in Reihe geschaltet
Nur dadurch bleibe ich im Spannungsbereich vom Wechselrichter
Wie man die Checksumme über die angeforderte Leistung berechnet ist bekannt, jedoch ist unbekannt wie man das Status-Frame des Inverters auf Korrektheit prüft. Man kann aus dem Mitschnitt (vieler Nachrichten -> Im Issue verlinkt) erkennen, dass manche Nachrichten die nur ein Bit auseinander liegen die gleiche Checksumme haben. Mir ist es deshalb ein Rätsel, über welchen Teil der Nachricht und wie konkret sich die Checksumme berechnet.Ich hätte noch eine Challenge für dich: https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/issues/7worum gehts da?
Ok, verstehe. Das wäre natürlich auch für die config-Message von Bedeutung. Ich schaue es mir mal an
Es könnte irgendeine Art Summe sein, also kein XOR, CRC oder so:
35 1 1 0 0 0 31 0 0 0 239 100 2 6 132
35 1 1 0 0 0 33 0 0 0 237 100 2 5 132
Gleiche Prüfsumme, 31+239=33+237
Ich probiere mal weiter
Richtig. Es sieht wie eine Summe aus. Insb. wenn ein Wert klettert und einer sinkt, dass man dann wieder bei der gleichen Checksumme rauskommt. Unlogisch wird es an diesen Stellen:
0x23 0x01 0x01 0x00 0x00 0x00 0x26 0x00 0x00 0x00 0xEF 0x64 0x02 0x06 0x84
0x23 0x01 0x01 0x00 0x00 0x00 0x27 0x00 0x00 0x00 0xEF 0x64 0x02 0x06 0x84
Hier unterscheidet sich nur ein Wert und trotzdem bleibt die Checksumme gleich. Nun könnte man behaupten: Nagut diese Position wird einfach nicht mit summiert. Leider kann man dieses Spiel mit vielen Stellen des Payloads treiben. ![]()
So, habe jetzt mal den Quellcode aufgehübscht. Es gibt jetzt je ein Python-Skript für das Manson-Netzteil, den Soyosource und für Zero-Export. Die kommunizieren untereinander per MQTT.
https://github.com/jsphuebner/esp-egycounter
Das Projekt ist damit in seiner Basis-Funktionalität abgeschlossen, vielen Dank auch für eure Hilfe!
Hier ein deutsches Video, da fehlt allerdings der Teil mit dem Inverter. Das gibts dann im englischen Video, das in der Beschreibung verlinkt ist.
https://youtu.be/CiuBiqD8IjA
Super Arbeit! Da kann man ne Menge lernen.
Der STM32 hat zwei UARTs. An einem haengt das Display/WLAN-Dongle und am anderen der RS485-Wandler.
Wenn man den Wandler tauscht, würden dann die stummen soyos den Status ausspucken?
Anders gefragt: hast du den Port mal belauscht?
Mein Soyo kann hören und sprechen. Vielleicht hat Johannes ja Lust diesem Thema nachzugehen. Man kann auch das Soyo eigene Converter-Modul gegen ein beliebiges anderes tauschen. Es sitzt auf einem Pinheader.
Insofern der 2. soyo spricht, werde ich die Module mal tauschen und sehen ob es hilft!
(noch warte ich darauf)
Insofern der 2. soyo spricht, werde ich die Module mal tauschen und sehen ob es hilft!Gut Idee! Du bist der gleiche Tom, der im Photovoltaikforum die Messung zur Traegheit des Inverters gemacht hat, richtig? Hast du Erfahrungswerte, was ein zu kleines und was ein zu hohes Update-Intervall für die "power demand"-Nachricht ist? Ich habe Schwierigkeiten aus dem Graphen abzulesen.
Sehr gut, bin gespannt was ihr das herausfindet. Eventuell verbinde ich auch den Wifi-UART direkt mit dem Beaglebone.
Zu der Reaktionszeit kann ich nicht viel sagen, da mein Regeltakt von 1s durch den eBZ Stromzähler vorgegeben ist.
Erfahrungswerte, was ein zu kleines und was ein zu hohes Update-Intervall für die "power demand"-Nachricht ist?Die Auflösung und Genauigkeit der Messung ist natürlich sehr unscharf, aber die Grafik gibt das ungefähr her.
So nach ca 5s ohne Anforderung hört der soyo auf mit der Einspeisung:
- die 5s Lücke erreicht die 900 W Marke nicht
- in der 9s Lücke hört die Einspeisung nach ungefähr der Hälfte der Zeit auf
Wirklich Erfahrung habe ich aber auch nur für das Gesamtsystem EBZ (1s Intervall) mit dem Soyo.
Das Gesamtintervall ist bei mir 1,5s, darunter schwingt es zu stark.
Es sollte so kurz wie möglich sein, um den Bedarf möglichst gut abzudecken.
Hast du eine Grundidee, was für einen Regelkreis du über die Software realisiert hast? Einfacher P Regler?
Ich kann erläutern, was genau die ESPHome-Implementierung tut, wenn dir das eine Hilfe ist. Ich bin jedoch nicht von Fach, dass ich der Regelung einen Namen geben könnte.
Hast du eine Grundidee, was für einen Regelkreis du über die Software realisiert hast? Einfacher P Regler?Nein, benennen kann ich das nicht.
Aber beschreiben:
die Leistung aller Phasen wird gelesen und ergeben die an den WR geschickte Einspeiseleistung:
angeforderte_Leistung = L1 + L2 + L3 + die vorletzte_angeforderte_Leistung
Das wird an den WR geschickt, 1,5s gewartet und wieder von vorne.
Getaktet ist das ganze durch die EBZ Intervalle.
Welchen Regler habe ich da gebaut? ;-)
Die ESPHome Implementierung macht es genauso. Wichtig ist, dass der Stromzähler auch negativen Bezug melden kann, so dass ein zurück regeln auch sauber gewährleistet ist. Die Update-Intervalle (Stromzähler vs. Bedarfsanforderung) können unabhängig voneinander gesteuert werden. Ich sende jede Sekunde einen Bedarf an den Inverter. Aktualisiere die Berechnung des Bedarfs aber seltener um Schwingungen zu vermeiden / Trägheit auszugleichen.
Ich will vorwegschicken, nichts was ich schreibe soll ärgern...
Das ist eine korrekte mathematische Berechnung für den gewünschten Sollwert.
Aber beschreiben:
die Leistung aller Phasen wird gelesen und ergeben die an den WR geschickte Einspeiseleistung:
angeforderte_Leistung = L1 + L2 + L3 + die vorletzte_angeforderte_Leistung
Mysteriös ist die "vorletzte" Leistung, ich nehme an einer der Versuche, die Schwingneigung zu verringern.
Das wird an den WR geschickt, 1,5s gewartet und wieder von vorne.Soweit, so gut.... :angel:
Getaktet ist das ganze durch die EBZ Intervalle.
Welchen Regler habe ich da gebaut? ;-)Der kommt in der Regeltechnik so eigentlich nicht vor... :D
Also, ich rede nachfolgend nicht von richtig oder falsch, sondern stelle eine (mögliche) Vorgehensweise aus der Sicht der Regelungstechnik vor.
Mir ist auch klar, dass es nicht einfach ist, den Wandler zu steuern, weil er entweder einen ziemlichen Tiefpass als Regelkennlinie hat, oder noch schlimmer, eine Totzeit.
Des weiteren erwähne ich, das das Ziel eines Regelkreises ist, das er Veränderung schnell und genau folgen soll... So gut es geht. Wenn aber der Wandler träge ist, dann gibt es keinen Trick, auch nicht mit korrekter Regelungstechnik, ihm das abzugewöhnen.
Zu deinem Regelkreis. Du bekämpft die Schwingneigung, die durch Tiefpass oder Totzeit verursacht wird, mit.... Totzeit, deine 1,5 Sekunden, in denen du den Wandler in Ruhe lässt. Im Ergebnis regelst du garnicht mehr, du steuerst, und zwar langsamer als der Wandler selber ist.
( Das ist überspitzt, um die Situation verständlich zu machen.)
Der Nachteil ist, das du damit langsamer bist, als es vielleicht möglich wäre, vielleicht nicht viel, aber immerhin.
Zum Vorschlag, Versuche dochmal folgendes, Stelle die Formel so um:
Summe der Phasen Mal Korrekturfaktor + letzter Wandlerwert ist neuer Wandlerwert
Korrekturfaktor ist der Proportionalitätsfaktor der P-Regelung, ich hab's umbenannt damit es nicht mit der Phase verwechselt wird.
Und diese Schleife lässt du so schnell laufen, wie es noch vernünftig geht. Alle 100 ms zum Beispiel.
Nimmst du p gleich 1, ist es genau deine alte Gleichung, also mache ihn kleiner, z.b. 0,5. Jedenfalls so klein, dass es nicht schwingt.
Da in die Zahl auch die Wiederholungsrate der Übertragung eingeht, könnte die funktionierende Zahl auch kleiner als 0,1 sein. Must du probieren.
Das wäre dann ein P Regler, P für proportional.
Das müsste sich etwas besser verhalten als deine Variante.
