Problem HoymilesZeroExport mit openDTU - hängt in der Früh #211
Comments
|
So sah die DTU-Anzeige heute Früh aus, keine Verbindung zu den WR jedoch die WR produzieren lt. Shelly schon: Ausschnitt von der Konsole: DTU neu gestartet und nach einigen Minuten lief wieder alles perfekt: Morgen Früh werde ich mal probieren ob es reicht nur das Script zu stoppen statt ZeroExport komplett runterzufahren. |
|
Relevant wäre das Log vom Script. Evtl ist aber dein Timing zu schnell, sodass die DTU keine Zeit mehr für eine Abfrage an den Wechselrichter hat? |
Wie schon mein Vorredner: Das Script sendet ja nur alle paar Sekunden ein Limit, sonst wird ja nichts übertragen. Ich nutze Ahoy, und ab einem gewissen Punkt muss ich auch das neu starten, weil es einfach hängt (passiert ca. nach einer Woche, manchmal nach drei Tagen). Ich denke mal, OpenDTU und Ahoy haben viel damit zu tun, alle paar Sekunden Limits zu setzen, und irgendwann ist der Speicher voll oder sowas. Sind ja alles nur Hobbyentwickler hier. |
|
@reserve85 Wie kann ich dir das Logfile privat zukommen lassen, hat ca. 7 MB? Das wäre Zufall dass meine zwei DTUs das selbe Problem haben sollten. Natürlich sind nicht beide DTU gleichzeitig in Betrieb. Falls das Timing zu schnell sein sollte (auf der DTU sind 5 Sekunden Abfrageintervall eingestellt) sollte ein eventuelles Problem auch Untertags auftreten und nicht nur wenn sich beide WR am Abend abschalten. |
|
kannst du hier als *.txt einfach anhängen |
|
schau mal hier, evtl das gleiche Problem: |
|
Ich hatte auch mal das Problem mit der openDTU. Anfangs half immer neu starten. Irgendwann ging überhaupt keine Verbindung mehr. Hatte mehrfach die Software aktualisiert, von mal zu mal wurde es gefühlt schlimmer. Habe dann Ahoy installiert und seit dem läuft es problemlos. Seit Wochen keinen Neustart mehr und alles funktioniert. Das zero Export Script kann ja nicht Schuld sein, es steuert ja nur die DTU an. Vielleicht mal die Frequenz wechseln? |
|
@reserve85 In dem genannten Link schaltet sich der WR aus, bei mir leider beide nicht. @smaicloud Das alle zwei verschiedene DTUs mit verschiedener Software gemeinsam spinnen wäre purer Zufall. |
Konnte gerade nur durchscrollen, aber sehr auffällig, dass "reachable: true" die ganze nacht bei beiden Invertern auf "true" steht. Auch hier beim vermutlichen "Ausschalten weil keine Sonne mehr da": Da werden die Inverter ganz kurz "inaktiv" und im nächsten Durchgang wieder "aktiv". |
|
Akku habe ich keinen. Vielleicht sind diese Einstellungen in der DTU falsch und gehören alle ausgeschaltet?
SMS hat meines Wissens kein MQTT da ich den sonst schon in HomeAssistant eingebunden hätte. So wird die Regelung des HMS1600 von gestern auf heute in HA dargestellt: |
|
ich habe keine Ahnung wie die Abfrage der Inverter bei SMS funktioniert, vielleicht wird da einfach nur geschaut ob "0W" erzeugt wird. Ist nicht open source, daher kann ich auch nicht nachschauen. Jedenfalls sehe ich im Log erstmal keinen Fehler, für mich ist eindeutig der Rückgabewert der DTU falsch. Die andere Frage ist auch noch, ob das auch wirklich das verursachende Problem des "DTU Absturzes" ist. Morgens sind laut im Log die Inverter übrigens auch wieder kurz "inactive" und werden dann im nächsten Schritt "Active": Die DTU akzeptiert da auch das Limit. Sieht für mich alles OK aus bis auf das "Active" nachts... |
|
Danke für die bisherige Info und Mühe!! Das in der Früh mit Active und Inactive habe ich bei SMS auch wenn die WR gerade an der Schwelle beim Mindestwert für die Einschaltung sind. Da geht es um 1 Watt bei einem von den 4 Modulen das noch "unrund" ist. Ich habe jetzt bei beiden WR in der DTU Befehle Nachts senden und Daten Nachts abrufen deaktiviert, mal schauen ob sich die WR heute abschalten. Wenn ich mich noch richtig erinnere fing das Problem an als ich den zweiten WR dazukaufte, bin mir aber nicht so sicher. |
|
Heute Früh waren die Balken beider WR in der DTU noch immer gelb und keine Verbindung zu den WR und die beiden WR produzieren trotzdem schon Strom. Ich aktivierte also diese beiden Befehle wieder, speicherte diese, änderte zum Spaß die Reihenfolge der Wechselrichter und siehe da, nach einigen Minuten wurden die Balken rot, dann gelb und anschließend blau. Werde heute Nachmittag wieder mal den SMS anhängen und schauen ob sich die DTU am Abend abschaltet. |
|
Ok, zeige mir bitte noch das Log von heute Nacht. Würde gern wissen ob das "Active" jetzt passt wenn du die Haken rausgenommen hast. |
|
Woher kommt das Limit -1 wenn es nirgends gesetzt wurde? War gestern auch so. |
|
ganz normal, sobald der inverter als "not reachable" gemeldet wird, wird intern das limit gelöscht (auf -1). aber schau mal hier: alles so wie es sein soll (reachable: false) und um 3:04 erwachen deine inverter um zu produzieren. das kann niemals stimmen, da ist es doch noch stockdunkel.. und ich habs nochmal gelesen: tbnobody/OpenDTU#2040 beschreibt doch genau dein Problem. Inverter ist an aber DTU connected nicht. Ich würde an deiner Stelle das Problem dort auch nochmal melden, aus Sicht des ZeroExportScripts kann ich keinen Fehler finden. |
|
Das mit der Uhrzeit ist wirklich rätselhaft. Werde mal in dem beschriebenen Link einen Verweis auf hierher verweisen. Gibt es eine Möglichkeit irgendwie eine Logdatei aufzuzeichnen zwischen openDTU mit SMS wenn ich diesen am Nachmittag anstecke? Nochmals vielen Dank für die Hilfestellung und deine geopferte Zeit! |
|
Bei der Verwendung von SMS schalten sich beide WR wie es sein soll ab. Irgendwie verstehe ich das ganze wirklich nicht mehr.
|
|
MMn liegt das daran, dass die Inverter als „available“ über die API zurückgegeben werden obwohl es nacht ist. Dann wird vom Script eben versucht wird zu regeln und ggf. läuft dann eine Queue über in der OpenDTU o.Ä.. Aber das ist ins Blaue geraten. Ansonsten kann dir da auch nicht weiterhelfen, bzw. ich wüsste nicht wie. Du könntest mal testweise AHOY versuchen. |
|
Einen neuen Raspy zulegen und alles neu installieren wird mir ja vermutlich nichts bringen. Vielleicht werde ich demnächst einen Versuch starten nur einen WR mit ZeroExport zu verwenden da es ja am Anfang Jänner 2024 funktioniert hat. Da muss ich ja nur in der Override den Invertercount auf 1 und beim zweiten Inverter auf false setzen. Ein anderer Veresuch wäre die DTU und ZeroExport auf die jeweilige Version von Stand Jännere 2024 downzugraden. Ich könnte die DTU auch auf einen SmartPlug-Stecker verwenden und über HA z.B. um 4 Uhr aus- und einschalten und so einen Neustart auslösen. Werde mich mal auch in AHOY einlesen, fürchte mich jetzt schon davor HA damit neu einzurichten. |
|
DTU hat sich mit SMS in der Früh problemlos eingeschaltet, Balken sind bei beiden WR blau. |
Ich würde die einfach rauslöschen, lasse da doch nur die Werte drin die du geändert hast. Ist sonst total unübersichtlich. Jedenfalls kann ich dir da echt nicht helfen, ich setzte nur Limits wenn die Inverter von der DTU als "erreichbar" gemeldet werden. Wenn die DTU nachts "erreichbar" meldet und dann daraufhin abstürzt bzw. die Kommunikation einstellt läuft an dieser Stelle was falsch. So wie ich das sehe stürzt ja die Regelung und die Inverterkommunikation auch nicht ab. Lediglich deine Webansicht der OpenDTU aktualisiert sich nicht... Limits werden ja weiterhin eingestellt. |
|
Mit Ahoy 0.8.84 funktioniert ZeroExport einwandfrei! Nochmals vielen Dank an @reserve85 für die großartige Unterstützung! |
|
Top, |
|
@reserve85 die OpenDTU / Ahoy haben eine priority / fast-lane für das ActivePowerLimit Command implementiert. Diese Command Queue ist m.W. nur ein Command lang / tief. Wenn HoymilesZeroExport jetzt ein Active Power Limit command per MQTT / REST API in diese Queue schreibt, dann ist die OpenDTU / Ahoy befleißigt alles andere stehen und liegen zu lassen und dieses APL command an den Inverter zu schicken. Deshalb kann es beim Verabschieden eines WR in seine wohl verdiente Nachruhe dazu kommen dass evtl. ein ActivePowerLimit Command in der Queue hängen bleibt und der ESP der OpenDTU / Ahoy DTU "Hohle dreht". |
|
Sorry @stefan123t ich hab ganz vergessen zu antworten. Nach meinem Verständnis müsste bei OpenDTU die Queue irgendwie "geleert" werden, wenn ein Command (ggf. zum wiederholten male) nicht erfolgreich übertragen werden kann und dann müsste auch der Inverter nach außen (über die REST API) zur Sicherheit als "not available" gekennzeichnet werden. |
|
@lumapu als Ahoy und @tbnobody als OpenDTU main developer sind prädestiniert das zu wissen, die Details und Unterschiede kenne ich leider nicht. Vielleicht können die beiden ja hier Ihre Implementierung und das Zusammenspiel der REST API und das Senden des ActivePowerLimit einmal kurz skizzieren ? |
openDTU v.24.6.10
HoymilesZeroExport V1.95 auf Raspi pi zero w neu installiert - MQTT ist NICHT aktiviert
Problem bestand auch mit alten ZeroExport Versionen
Seit längerem hat die openDTU in der Früh keine Verbindung zu den zwei WR mehr, der Balken ist gelb. Auch wenn es am Abend finster wird wird der Balken nicht rot sondern bleibt bis in der Früh gelb.
Egal wie oft jetzt die WR oder DTU neu gestartet oder stromlos gemacht und danach bis 15 Minuten gewartet wird, der Balken bleibt immer gelb und es passiert nichts.
Meistens half es nur das Netzwerk komplett zu starten, dann lief alles einwandfrei bis zum nächsten Morgen.
Durch Zufall bin ich aber draufgekommen dass es am einfachsten ist in der Früh ZeroExport runterzufahren, dann bei der DTU einen Neustart machen und nach einigen Minuten wechselt der Balken von gelb auf rot und nach weiteren Minuten auf blau und es läuft. Danach ZeroExport wieder starten und es läuft den ganzen Tag ohne Probleme bis nächsten Morgen.
Das Problem kann meiner Meinung nach nur an einem Bug in der Software liegen weil ich letzte Woche einige Tage statt ZeroExport den SMS verwendet habe und da lief mit der gleichen DTU alles astrein:
am Abend kam der rote Balken, in der Früh wurde der Balken gelb und dann blau ohne einmal ein Gerät neu starten zu müssen.
LG
The text was updated successfully, but these errors were encountered: