Zusätzlich werden kleine Leistungsanforderungen nicht mehr sauber verarbeitet, also wenn ich 20W haben will bringt er 300W raus oder sowas.
Ich kenne diesen Effekt durch fehlerhaften Code beim erzeuge des Frames. Möglicherweise liegt es daran? siehe hier
Bei den Hardware Problemen bin ich leider raus, zum Glück laufen meine Soyos bisher problemlos.
Solltest du es übersehen haben, mein script zur Regelung.
Danke für deine Arbeit und das du auch über Misserfolge berichtest!
Hmm, mein Code sieht auch so aus wie der von CarlosGS
req[4] = int(finalPower / 256) req[5] = finalPower & 255 req[7] = (264 - req[4] - req[5]) & 255
Allerdings hat der bisher funktioniert, erst seit der Wechselrichter halb kaputt ist, gehts nichts mehr.
Allerdings hat der bisher funktioniert, erst seit der Wechselrichter halb kaputt ist, gehts nichts mehr.
Der Fehler produziert extreme Spikes im Leistungsverlauf bei sehr niedriger Anforderung.
Vielleicht war das Monitoring nur zu grob?
Die Suche nach der Ursache dieser Spikes hat mich eine ganze Weile debugging gekostet. 😉
Oh, war 2 Wochen im Ausland. Ok, dann ändere ich den Code mal und schaue ob es dann aufhört.
UPDATE: ja läuft perfekt, danke!
Gerade werden 5W angefordert (was real eher 40W entspricht) und die Sprünge sind weg /p>
Hallo,
ich betreibe ein Soyosource 1000W und 24V LiFepo4 Akku mit BavarianSuperGuy Projekt, um die Grundlast über Nacht abzudecken, das funktioniert soweit gut bis auf die Aussetzer RS485 im Display von Soyo. Die Anzeige RS485 verschwindet im Display und der Soyo geht mit der Regelung auf Null, das wiederholt sich alle paar Sekunden. Deswegen möchte ich andere Variante versuchen.
Jetzt meine Frage an E-t0m könnte ich statt dem Lesekopf für den Stromzähler ein Shelly 3em verwenden?
Ein Raspi ist vorhanden sowie Esp8266 und RS485 TTL Adapter
Vielen Dank.
Jetzt meine Frage an E-t0m könnte ich statt dem Lesekopf für den Stromzähler ein Shelly 3em verwenden?
@lupenrainer hat sowas mal gezeigt: klick hier
geht aber sinnvoll nur mit eSmart3
Jetzt juckt es mich doch sehr in den Fingern, noch einen zweiten Soyosource zu kaufen und am Prozessormodul zu scopen. Das ist ja sogar beschriftet. Hat schonmal jemand gemessen und kann sagen, ob die eigentliche AC Stromregelung direkt mit dem Prozessor gemacht wird? Oder gehen von dort nur Befehle an einen IC der die PWMs an die H-Brücke generiert?
Also anders ausgedrückt macht der Prozessor nur Betriebsführung oder auch Regelung?
sogar mit eigener Platine. Respekt. Ich war da etwas konservativer. Hab da jetzt nur ein esp8266 dran hängen und steuer das Poti mit MQTT über NodeRed. Die Einspeiseleistung messe ich über eine Messsteckdose wobei ich diesen Leistungswert garnicht zur Regelung brauche. Ich sag dem Poti nur „mach mehr“ oder „mach weniger“ um eine Nulleinspeisung zu erreichen.
Moin zusammen.
Ich grätsche hier mal eben schräg von der Seite rein. Ich nutze seit einem halben Jahr diesen Python Code um den Limiter des Soyosource anzusteuern (s.u., einrücken funktioniert hier wohl nicht. ggf. selber nachholen).
Den Powerwert meines aktuellen Bezuges ziehe ich mir über die API von Discovergy, meinem Messstellenbetreiber. Nachteil: Latenzzeit einige Sekunden.
Beim Soyosource ist ja nun schon mal ein Gerät dabei, dass eine Phase misst und quasi mit dem selben Protokoll den Soyosource versorgen könnte.
Meine Idee: 3 davon, also an jeder Phase einen, und die seriellen Ports mit einem Raspberry Pi zu belauschen. Die Power-Werte zähle ich einfach zusammen und lege sie ein eine Text-Datei die im Verzeichnis des Webservers liegt. Somit wäre mein Gesamtverbrauch direkt mit HTML auszulesen und mit einem anderen (oder meinetwegen auch demselben) Pi auszulesen und ich steuere mit meinem Script wieder den Soyosource an. Sollte weniger Latenzzeit benötigen und ich wäre weder von einem funktionierenden Internet noch von meinem Netzbetreiber abhängig.
Soo, nun endlich meine Frage: Hat schon jemand ausgetüftelt wie man, so simpel wie im Code unten, mit Python die drei Seriellen Ports ausließt und die Powerwerte extrahiert?
Vermutlich könnte man die Antwort aus diesem Thread herausdestilieren, ist mir bisher aber so noch nicht gelungen...
Vielen Dank vorab.
def computeCRC(power): pu = power >> 8 pl = power & 0xFF return (264 - pu - pl) & 0xFF def read_consumed_power(ser): time.sleep(0.1) # Wait and clear input buffer to ensure proper packet synchronization ser.reset_input_buffer() try: raw = ser.read(8) # Read 8 bytes except: return -1 (a,b,divider,c,consumed_power,d,crc) = struct.unpack('>BBBBHBB', raw) if computeCRC(consumed_power) != crc: return -2 # Checksum mismatch return consumed_power def set_generated_power(ser, power): a = 0x24 b = 0x56 divider = 0x00 c = 0x21 d = 0x80 crc = computeCRC(power) out = struct.pack('>BBBBHBB', a,b,divider,c,power,d,crc) ser.write(out) ser.flush() # Wait for data to be written out
Den Powerwert meines aktuellen Bezuges ziehe ich mir über die API von Discovergy, meinem Messstellenbetreiber. Nachteil: Latenzzeit einige Sekunden.
Dein Code enthält den Bug, der ein paar Beiträge weiter oben thematisiert ist.
Kannst du den Stromzähler nicht selbst auslesen? Dann brauchst du keine weiteren Messklemmen etc.
Siehe meine Signatur:
@solarjuergen Wow !.....300 € für`n WR ??? .....bei mir läuft seit 4 Jahren ohne Probleme ein Billig - China . Teil....69 Euro inkl. Versand
bei mir läuft seit 4 Jahren ohne Probleme ein Billig - China . Teil....69 Euro inkl. VersandMeinen Glückwunsch, wenn der völlig ohne Probleme und ohne Störungen läuft. Dann hast Du einen guten Fang gemacht oder einfach Glück gehabt. 😀
In der Preisklasse ist es aber nicht selten, daß die gar keinen Sinus erzeugen, sondern irgendeine Wellenform, die eher einem Barockschloß ähnelt ("Treppchen"). Je nach Steilheit der Treppchenflanken kann das Störungen bis mindestens in den VHF- oder gar UHF-Bereich erzeugen. Im VHF-Bereich, um das mal als Beispiel aufzugreifen, befindet sich der Flugfunk (Amplitudenmodulation), aber auch UKW-Rundfunk, Amateurfunk, Bündelfunk, Taxifunk usw.. Wenn Du Pech hast, gerade Dein Exemplar stört und ein Betroffener ruft den Prüf- und Meßdienst der BNetzA, dann kann dieser Deinen WR stillegen und im Wiederholungsfall sogar ein Bußgeld verhängen.
Du brauchst jetzt nicht gleich in Panik zu geraten, aber Du solltest Dir dessen bewußt sein, daß der Hersteller solcher WR-Billigheimer immer irgendwo sparen muß und bei der Funkentstörung wird nun mal sehr gerne gespart. (Die kann man natürlich nachrüsten, das geht schon, aber das ist dann wieder mit Kosten verbunden, so daß man eigentlich auch gleich von Anfang an den "besseren" WR hätte nehmen können.) Wie heißt es doch so schön? Wer billig kauft, kauft zweimal.
Daniel
Den Powerwert meines aktuellen Bezuges ziehe ich mir über die API von Discovergy, meinem Messstellenbetreiber. Nachteil: Latenzzeit einige Sekunden.
Dein Code enthält den Bug, der ein paar Beiträge weiter oben thematisiert ist.
Kannst du den Stromzähler nicht selbst auslesen? Dann brauchst du keine weiteren Messklemmen etc.
Siehe meine Signatur:
Hi,
nee, der Zähler ist im Keller und ich im 3.Stock. Außerdem klebt ja der Discovergy-Sensor auf der optischen Schnittstelle, das soll schon auch so bleiben. Das ganze wäre eher noch als Backuplösung gedacht, falls mal Netzausfall ist o.ä. Außerdem bin ich mir nicht sicher, wie genau eigentlich diese Schlaufen messen. Vielleicht wäre dann doch der Shelly die bessere Wahl.
Mit Bug meinst Du "Der Fehler produziert extreme Spikes im Leistungsverlauf bei sehr niedriger Anforderung."? Könnte sein, aber da der WR im sehr niedrigen Bereich eh nicht so effizient ist, habe ich dem Code eh gesagt, dass er unter 50W nichts mehr einspeisen soll. Aber 60W laufen bei mir eh immer. Somit habe ich von diesem Bug nie etwas bemerkt. 😉