OpenDTU stoppt die Kommunikation mit den Invertern HM-300
peterd57 opened this issue · 15 comments
What happened?
Habe 2 HM-300 angeschlossen. Wobei die Kommunikation auch mit einem HM-300 schon abgebrochen wurde. Inverter Stoppen/starten/neustarten mittels der DTU-SW gelingt nicht, weil "letzter Übertragungsstatus" aussteht.
MQTT zeigt reachable=1,producing=1, nur der limit_relative bleibt auf 0.00 stehen.
To Reproduce Bug
Leider nicht bekannt. Da Fehler irgendwann auftritt.
Expected Behavior
Should not disconnect from inverters.
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
v24.5.6
Relevant log/trace output
No response
Anything else?
Please confirm the following
- I believe this issue is a bug that affects all users of OpenDTU, not something specific to my installation.
- I have already searched for relevant existing issues and discussions before opening this report.
- I have updated the title field above with a concise description.
- I have double checked that my inverter does not contain a W in the model name (like HMS-xxxW) as they are not supported
@lehmartin the HM imverters do not have the option of setting a fixed RF comm frequency to the inverter. The HM uses NRF which constantly cycles through all five NRF channels. Whereas the HMS/HMT models use CMT chip which allows to set a base frequency.
Möglicherweise ist dies das gleiche Problem:
Ich habe zwei Wechselrichter HM-400 in Betrieb. Beide werden von jeweils von einem Akku gespeist. Wenn ein Akku abschaltet, beendet openDTU die Kommunikation mit beiden Wechselrichtern, obwohl der andere Wechselrichter normal weiterarbeitet. Symptom: In der Web-Oberfläche zählt die Zeit immer weiter hoch und es ist nicht mehr möglich beim produzirenden Wechselrichter das Limit zu setzen Wenn der Wechselrichter wieder mit Strom versorgt wird, dann funktioniert openDTU nach einigen Minuten wieder wie erwartet.
@bw-pv ich weiß nocht wie sich OpenDTU bei mehreren WR und MQTT verhält. Vor allem wenn es einen der beiden WR nicht mehr erreichen kann.
Genaueres sollte man ggf aus dem Serial Log erfahren.
Follow the link to the documentation to setup for USB / serial logging:
https://www.opendtu.solar/firmware/howto/serial_console/
Hier ist ein entsprechendes logfile. Ich kann es leider selbst nicht interpretieren. Zuerst arbeiten beide Wechselrichter, dann schalte ich den PV-Akku bei einem Wechselrichter ab, d.h. der WR bekommt keine Energie mehr am Eingang, hängt aber weiterhin am Netz. Der zweite WR arbeitet normal weiter, aber openDTU bekommt auch vom arbeitenden WR keine Daten mehr.
Ich verwende kein MQTT, sondern steuere die beiden WR mittels Web API.
openDTU.log
@bw-pv danke erstmal für das Logfile. Das ist relativ aufschlussreich. Wie wir schon an anderer Stelle vermutet haben kommt es beim Steuern der WR über die REST API oder auch über MQTT zu einer “Übersteuerung”, das ActivePowerLimit Command wird von der OpenDTU mit Vorrang behandelt um es möglichst zeitnah an den WR zu senden.
Wenn der WR aber nicht erreichbar ist, dann erfährt die DTU auch auf die Rückfrage nach dem aktuellen PowerLimit keine Antwort. Und dann versucht sie weiter das APL an den WR zu senden. Ad infinitum.
@tbnobody hier müssen wir entweder das APL irgendwann aus der Fast Lane / Queue schmeißen (Timeout) oder das Prinzip der Prio Queue ganz aufgeben ? Oder zumindest anderweitig sicherstellen dass die anderen WR auch noch abgefrag, weiter angezeigt und ansprechbar bleiben.
Ich denke, dass jeder WR seine eigene Queue haben sollte. Unabhängig davon, ob irgendwo ein Problem ist, sollte dann zyklisch jeweils ein Kommando für jeden WR abgearbeitet werden. Im nächsten Durchlauf kann dann beim nicht erreichbaren WR das Kommando wiederholt werden. Dann sollten diese "Hänger" nicht mehr auftreten.
Derzeit bekommt man bei der Abfrage mit Rest API nicht mit, dass der WR nicht erreichbar ist.
Ich denke, dass jeder WR seine eigene Queue haben sollte.
Ok. aber dann braucht es aber auch für jeden WR ein Funkmodul. Aber gleichzeitig Funken geht auch nicht weil damit die Funksignale verfälscht werden. Es braucht also unterschiedliche Luftrräume. Und mehr Speicher....
Unabhängig davon, ob irgendwo ein Problem ist, sollte dann zyklisch jeweils ein Kommando für jeden WR abgearbeitet werden.
Du hast den Code aber nicht angeschaut oder? Weil genau das passiert. Nur muss nach jedem Befehl entweder auf ein vollständiges Paket oder auf einen Timeout gewartet werden. Das ist mit ein Grund warum alles länger dauert wenn ein WR nicht erreichbar ist.
Derzeit bekommt man bei der Abfrage mit Rest API nicht mit, dass der WR nicht erreichbar ist.
Klar... die WebApp zeigt es ja auch an.
Du hast den Code aber nicht angeschaut oder? Weil genau das passiert. Nur muss nach jedem Befehl entweder auf ein vollständiges Paket oder auf einen Timeout gewartet werden. Das ist mit ein Grund warum alles länger dauert wenn ein WR nicht erreichbar ist.
Den Code habe ich nicht angeschaut, weil ich ihn vermutlich nicht verstehe.
Derzeit bekommt man bei der Abfrage mit Rest API nicht mit, dass der WR nicht erreichbar ist.Klar... die WebApp zeigt es ja auch an.
? In der Web App sehe ich, dass die Zeit bei "Letzte Aktalisierung" bei beiden WRn ständig (ad finitum) hochgezählt wird. Das Feld ist blau hinterlegt, so als wenn alles normal wäre. Genauso wird es auch per Web API ausgegeben, d.h. ich habe keine Chance, mitzubekommen, dass einer der beiden WR nichts mehr liefert und auch das Power Limit kann nicht mehr gesetzt werden. Es bräuchte hier ein vernünftiges Timeout, damit man beim produzierenden Wechselrichter irgendwann das PowerLimit wieder setzen kann.
Wenn ich dem WR die Netzspannung wegnehme, dann funktioniert alles normal. Das ist auch klar, weil das Funkmodul noch kommunizieren kann. Wenn aber der Speicher abschaltet, dann fehlt ganz plötzlich die Energieversorgung für das Funkmodul und der WR ist nicht mehr erreichbar. Das sollte dann halt in irgend einer Weise vernünftig abgehandelt werden.
@tbnobody also ich hatte in dem Logfile (auf dem Handy, daher nur im Augenwinkel) gesehen, dass sehr häufig das ActivePowerLimit gesetzt wird.
Das ist dann zu aller Erst ein Problem der Zero Export Steuerung die das Kommando (wiederholt?) absetzt auch wenn der WR aus verschiedenen Gründen (Nacht, Bewölkung, Akku leer, etc) einfach vorrübergehend nicht erreichbar ist.
Vielleicht könnten wir den WR dann auch nach einer Weile (ca 1-10 Min) den WR in der Prio runterstufen und/oder das APL Kommando verwerfen. Wenn die Zero-Export Steuerung es dann immer noch versucht obwohl das Flag unavailable gesetzt ist, bekommt sie einfach einen REST API (oder MQTT?) Error Code zurück, da sollte sich die DTU mE nicht beirren lassen und auch mal APL Commands ablehnen.
Erst einmal vielen Dank für eure Mühen!
Am 08.09.2024 um 14:51 schrieb stefan123t:
@tbnobody also ich hatte in dem Logfile (auf dem Handy, daher nur im Augenwinkel) gesehen, dass sehr häufig das ActivePowerLimit gesetzt wird.
Das ist dann zu aller Erst ein Problem der Zero Export Steuerung die das Kommando (wiederholt?) absetzt auch wenn der WR aus verschiedenen Gründen (Nacht, Bewölkung, Akku leer, etc) einfach vorrübergehend nicht erreichbar ist.
Das ist ja gerade das Problem. Wenn ich mittels Rest API mitbekommen würde, dass der WR nicht mehr arbeitet, dann könnte ich das APL Kommando unterdrücken. So ist es auch vorgesehen, aber die Abfrage mit Rest API liefert mir: "erreichbar"/"produzierend", obwohl das nicht stimmt. Ich habe auch schon daran gedacht, das APL Kommando zu unterdrücken, wenn das Alter des letzten gültigen Wertes einen bestimmten Wert überschreitet. Das Hauptproblem ist aber, dass openDTU auch für den produzierenden WR das gleiche Verhalten zeigt.
Ich weiß leider nicht, wie die Kommunikation mit dem WR genau funktioniert. Ich hätte angenommen, dass ein Abfragekommando abgesetzt wird und wenn der WR nicht innerhalb einer bestimmten Zeit antwortet, dieser als nicht erreichbar gilt und dies auch bei einer openDTU-Abfrage mittels RestAPI so kommuniziert wird, von mir aus auch mit einer gewissen Verzögerung. Entscheidend ist aber, dass der noch produzierenden WR nicht von dem Problem betroffen sein sollte.
Vielleicht könnten wir den WR dann auch nach einer Weile (ca 1-10 Min) den WR in der Prio runterstufen und/oder das APL Kommando verwerfen. Wenn die Zero-Export Steuerung es dann immer noch versucht obwohl das Flag unavailable gesetzt ist, bekommt sie einfach einen REST API (oder MQTT?) Error Code zurück, da sollte sich die DTU mE nicht beirren lassen und auch mal APL Commands ablehnen.
Ich bekomme leider kein unavailable (siehe oben).
Die REST API der OpenDTU ist mW asynchron da beim ActivePowerLimit sonst sehr lange gewartet werden müsste. Sockets können wir auf dem ESP32 mE nicht so lange offen halten, das führt sonst evtl sogar zu Abstürzen.
Das APL Command wird an den WR geschickt und dann wird nach ca 15 Sekunden der aktuelle Prozent Wert aus der Antwort des WR auf das SystemConfigPara Command gelesen und verglichen. Erst danach ist für OpenDTU das Setzen erfolgreich und das nächste APL kann gesetzt werden. Ein APL sollte mE auch min 30W oder ca 5% Unterschied zum letzten Wert haben damit es einen derart aufwendigen Prozess rechtfertigt.
Der Hinweis, dass sich APL-Kommandos in der Queue anhäufen, war wertvoll. Da ich bei einer openDTU-Abfrage mittels RestAPI leider immer fälschlich als Ergebnis "erreichbar"/"produzierend" bekomme, werte ich nun auch das Alter des abgefragten Limits aus und sende ein nues APL-Kommando nur dann, wenn das Alter kleiner als 50 Sekunden ist. Diese Heuristik verhindert das Füllen der Queue und nach einer gewissen Zeit wird auch der Status der beiden WR wieder korrekt zurückgeliefert. Somit hat sich das Probem für mich gelöst. Ich fände es allerdings sinnvoll, wenn openDTU in diesem Sinne "eigensicher" sein könnte, indem z.B. nicht ausführbare APL-Kommandos einfach verworfen werden.
Ist es geplant OpenDTU hinsichtlich der Problematik mit den APL-Kommandos anzupassen ?
Oder ist dies derzeit eher nicht absehbar
siehe zB
reserve85/HoymilesZeroExport#242
@tbnobody können wir für das APL Kommando je WR einen eigenen Soll Wert hinterlegen ?
Wenn der Nutzer einen neuen (temporären?) Wert vorgibt überschreiben wir einfach den Soll Wert und beim nächsten Versuch werden einfach Ist/Soll verglichen und bei Abweichung >30W / 2-5% wird wieder einmal versucht das APL Kommando zu senden?
Beim permanenten Limit sollten wir wie bisher das Senden des Limit sicherstellen und so lange blockieren, das erfolgt ja in der Regel auch manuell.