Open prorun26 opened 1 month ago
@prorun26 also die Probleme bei Einsatz von zwei DTUs mit zwei HMS Wechselrichtern sind erklärbar, hier verwenden beide DTUs den selben Kanal im 868MHz Band und somit stören die sich gegenseitig bei der Arbeit.
Bei nur einer DTU mit zwei HMS Wechselrichtern sollte eigentlich alles schick sein. Dass hier die Verbindung zu einem (hier dem grünen WR) einbricht kann ich mir selber auch nicht erklären. Aber ich habe auch keinen HMS und somit keinen CMT2300A Radio Chip im Einsatz. Hier wurde in der letzten Zeit immer wieder davon berichtet, dass die WR sich irgendwie nicht mehr sauber auf einen Kanal des 868 MHz Bandes festnageln lassen. Vielleicht ist ja einer der beiden WR davon betroffen ? Ist es immer der selbe (grüne) WR der das Problem hat oder ist es eher zufälig auch ab und zu der Andere (rote) ?
Okay konzentrieren wir uns auf die Variante mit einer DTU:
Beim Einsatz einer einzigen DTU ist es immer der gleiche WR, der die Verbindung verliert: HMS-800-2T (grün)
Bei 5s Abfrage-Intervall fragt die DTU ja jeden WR alle 10s, aber eben mit 5s Versatz (wahrscheinlich damit keine Kollision mit den Datenpaketen des jeweils anderen WR auftreten).
Ich teste seit zwei Tagen mit einem 6s Abfrage-Intervall (also jeder WR alle 12s mit 6s Versatz zum anderen WR) und so wie es aktuell aussieht funktioniert es nun problemfrei.
Da es nur bei höheren Leistungen auftritt: ist ggf. bei der Abfrage des ersten WR das Datenpaket bei 4 Modulen mit jeweils 3-stelliger Watt-Leistung etwas zu lang sodass der Timeout zum Schluss etwas zu kurz ist und somit evlt. der Request an den nächsten WR gestört wird!?
@prorun26 nette Erklärung, aber so ist es mit Nichten ;)
Die Anzahl der Datenpakete hängt indirekt vom Inverter und der Anzahl der angeboten Eingänge ab (i.d.R. die 4-in-1, 2-in-1 und 1-in-1 Modelle eben).
Bei längerem Betrieb können ggf. noch Fehlermeldungen dazu kommen, die OpenDTU mit AlarmData abholt und darstellt. Hier könnte ich mir evtl. Overvoltage oder andere Meldungen bei starker Sonneneinstrahlung und niedrigen Temperaturen als Ursache vorstellen.
Was für Events zeigen denn Deine beiden WR an und welches Grid Profile hast Du eingestellt, passt dieses zu Deinem Wohnort bzw. dem Ort der beiden PV Wechselrichter ?
ich habe immer lediglich nur ein einziges Event:
Bin nicht genau sicher was du mit Grid Profil meinst. Was hiervon? Ort der WRs ist Leipzig.
Da versteckt sich das Grid-Profil.
@prorun26 okay, wenn Du keine entsprechenden Events hast (Overvoltage, etc.), dann sollte das auch nicht das Problem aufgrund Deines Grid Profiles sein.
Ich kann Dir daher aber auch gerade nicht weiterhelfen.
Follow the link to the documentation to setup for USB / serial logging: https://www.opendtu.solar/firmware/howto/serial_console/
Da ich keine Events habe und der WR auch in den Momenten wo keine Verbindung besteht munter weiter Strom produziert kann man die Grid Profiles eigentlich ausschließen. Aber ich habe jetzt gesehen, dass meine beiden WR offensichtlich unterschiedliche Grid-Profile nutzen. In den Spezifikationen unterscheiden sich beide auf den ersten Blick sehr stark. Das DE-Profil scheint deutlich mehr Toleranzen zu bieten. Da wäre es doch eigentlich angebrachter beide WR mit dem gleichen Grid-Profil laufen zu lassen, oder? Am besten das DE - DE_VDE4105_2018 ? Standort der WR ist Leipzig.
Aktuell:
HMS-800-2T XX - EN 50549-1:2019 (v2.0.1)
HMS-1600-4T DE - DE_VDE4105_2018 (v2.0.1)
Gibt es mittlerweile ein Möglichkeit das Grid-Profil ohne echte DTU zu ändern?
Darauf zielte meine Vermutung dass der eine WR durch das EU Grid Profile früher abregelt. Das VDE Profil hat etwas mehr Spielraum in gewissen Grenzen, das EU Profil ist vermutlich der Kleinste Gemeinsame Nenner aller EU Staaten.
Ja nur noch keine Implementierung ;) Siehe #900
Also meine Tests ergeben, dass bei einem 5s Abfrage-Intervall eine Datenkollision entsteht, sodass einer der beiden WR nicht mehr lesbar ist. Auf die Stromerzeugung wirkt sich das jedoch nicht aus - nur auf die Übertragung zur DTU. Komischerweise ist der Effekt besonders stark wenn die Leistung der beiden WR ansteigt.
Wenn ich mit einem 6s Abfrage-Intervall arbeite funktioniert alles einwandfrei.
@prorun26 verwendest Du ein Active Power Limit, oder ähnliches zum Limit setzen, das braucht nämlich meist ca. 12-15 Sekunden um vom WR akzeptiert zu werden.
Wenn man den WR beim Sinnieren über das neue Limit unterbricht, dann kann er durchaus auch mal für einige Zeit die Zusammenarbeit verweigern.
@stefan123t - Beide ohne Limit
@prorun26 ja ohne Serial Log passend zu den Graphen aus dem MQTT werden wir da wohl nicht weiter kommen. Wie gesagt bei zwei DTUs ist das bekannt und prinzipiell nicht supported, bei einer DTU kann das bei Empfangsproblemen / Störungen auch passieren aber ohne Logs 🪵 ist das nur Mutmaßung.
What happened?
Hallo in die Runde, ich habe Kommunikationsprobleme sobald ich 2 Wechselrichter abfrage (HMS-800 & HMS-1600). Sowohl wenn ich mit einer openDTU zwei WR abfrage als auch wenn ich je WR eine eigene openDTU verwende. Ich habe zwei andere DTUs und zwei andere Wechselrichter probiert (anderer HMS-800 & HMS-2000) leider ohne Veränderung.
To Reproduce Bug
Wenn ich zwei DTUs verwende stören sich beide gegenseitig. In der Console erkannt man, dass die Abfrage der einen DTU dafür sorgt, dass die Datenpakete der anderen DTU kaputt gehen. Mal kommen die Werte von WR1 bei DTU1 an und mal von WR2 bei DTU2 aber nur ganz selten beide parallel.
Wenn ich nur eine DTU verwende, scheint es so als bricht die Kommunikation zu einem der beiden WRs ab, sobald die Gesamtleistung steigt.
Wenn ich nur eine DTU verwende, und die Leistung beider WRs ist sehr niedrig funktioniert komischerweise alles einwandfrei.
Mein Abfrageintervall steht auf 5s und in den Diagrammen sind die Linien unterbrochen wenn keine Kommunikation seit mehr als 30s stattgefunden hat.
Expected Behavior
Schön wäre es, wenn ich mit einer openDTU fehlerfrei beide WR abfragen kann.
Install Method
Pre-Compiled binary from GitHub releases
What git-hash/version of OpenDTU?
v24.10.6
What firmware variant (PIO Environment) are you using?
opendtu-generic.bin
Relevant log/trace output
No response
Anything else?
No response
Please confirm the following