[Bug] Regelung über API

RealNBB commented 4 weeks ago

Platform

ESP32

Assembly

I did the assebly by myself

nRF24L01+ Module

nRF24L01+ plus

Antenna

circuit board

Power Stabilization

nothing

Connection picture

[ ] I will attach/upload an Image of my wiring

Version

0.8.130

Github Hash

24ceb3e

Build & Flash Method

was already installed

Setup

Nicht geändert. Meine Standardeinstellung wie in den Versionen zuvor.

Debug Serial Log output

No response

Error description

Hallo,

ich nutze das Skript "HoymilesZeroExport", um eine Nulleinspeisung zu realisieren. Das Skript regelt ja bekanntlich die Leistung der einzelnen Inverter; bei mir in Summe drei Stück. Ab Version 0.8.130 steigt bei mir nach einiger Zeit das WebIf aus bzw. gleich der ganze Inverter, heißt, er verharrt auf einer x-beliebigen eingestellten Leistung und ist dann nicht mehr erreichbar/regelbar.

Version 0.8.129 lief bis dato ohne Probleme mit den identischen Settings wochenlang absolut stabil durch.

lumapu commented 4 weeks ago

kannst du bitte mal diese Firmware testen: https://github.com/lumapu/ahoy/issues/1685#issuecomment-2282879153

Diese hat einen anderen Webserver, den ich gerne in Zukunft einsetzen würde.

Ollipop030 commented 3 weeks ago

Ab Version 0.8.130 steigt bei mir nach einiger Zeit das WebIf aus bzw. gleich der ganze Inverter, heißt, er verharrt auf einer x-beliebigen eingestellten Leistung und ist dann nicht mehr erreichbar/regelbar.

Exact das Gleiche passiert bei mir auch. ESP32 mit 2 Invertern und HoymilesZeroExport. Alles >130 steigt nach ein paar Stunden aus, die Versionen darunter laufen tagelang durch. Neue Version teste ich auch mal.

Könnte das damit zusammenhängen?:

merge PR: Power limit command accelerated

seit Version 130?

SnakeGER commented 3 weeks ago

Habe ein ähnliches Problem. Bei mir werden 3 Hoymiles über MQTT geregelt (Akkustand Speicher ~ MQTT Raspberry ~ AHOY). 9 von 10 Limit-Befehle werden nicht auf allen 3 WR umgesetzt. Die Befehle kommen zwar laut Konsole auf dem AHOY an, aber bei mindestens einem WR steht dann sowas wie "CMT tx fail". Bis zur version 0.8.129 lief das aber wunderbar und es gab auch keine technischen Veränderungen. Habe das gerade nochmal mit der 0.8.141 getestet. Problem bleibt. Ich bleibe jetzt erstmal bei der 0.8.129 bis das Problem behoben ist. LG

lumapu commented 3 weeks ago

@SnakeGER naja, wenn ich ins changelog schaue wurde schon was geändert, wahrscheinlich meintest du techn. Änderungen auf deiner Seite.

Auszug aus dem Changelog, was sich mit deiner Beobachtung decken könnte:

0.8.130 - 2024-08-04

merge PR: Power limit command accelerated #1704

Changelog

SnakeGER commented 3 weeks ago

@lumapu natürlich meine ich auf meiner seite. Aber das mit dem "Power limit command accelerated" könnte natürlich zu dem Fehler führen, aber davon hab ich zu wenig Ahnung 😆 Jedenfalls muss etwas geändert worden sein, denn bis zur 129 gabs den Fehler nicht

reserve85 commented 3 weeks ago

Ich hatte das bis gestern nicht feststellen können. Habe gestern dann aber ein mal den Fall gehabt, dass ein Limit set auf 100% als accepted gemeldet wurde aber der inverter weiter bei dem letzten wert verblieb. Keine Ahnung ob das damit zusammenhängt? Ansonsten gabs bei mir keine Abstürze o.Ä.. aktuell bin ich auf der 140.

edit: bei mir nur 1 inverter

RealNBB commented 3 weeks ago

kannst du bitte mal diese Firmware testen: #1685 (comment)

Diese hat einen anderen Webserver, den ich gerne in Zukunft einsetzen würde.

Hi....also sowohl die von dir verlinkte Version als auch die neue 141 funktioniert nun ohne Aussetzer! Von meiner Seite also alles wieder top! :)

Dank Dir und einen schönen Sonntag!

/edith/ Kommando zurück! 1.41 hängt sich weiterhin sporadisch auf.

SnakeGER commented 3 weeks ago

Bei mir leider immernoch das Problem mit den nicht umschaltenden WR. Aber die 0.8.129 läuft gut und ich warte erstmal ob sich in den kommenden Updates etwas ändert. Sonst mache ich mal einen eigenen Thread auf. Hab mich ja hier nur eingemischt ;)

Trotzdem nochmal großes Lob an die Entwickler, dass ihr sowas tolles auf die Beine gestellt habt. Hut ab

Ollipop030 commented 3 weeks ago

Bei mir läuft die 141 leider auch nicht. Gestern gegen 16:00 neu geflasht, heute morgen war die DTU noch online, kurz nach Acht kommt in HoymilesZeroExport nur Aug 19 08:07:05 Pi-Hole python3[24517]: 2024-08-19 08:07:05 WARNING Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ReadTimeoutError("HTTPConnectionPool(host='192.168.0.19', port=80): Read timed out. (read timeout=10)")': /api/inverter/id/1 WebInterface ist dann auch weg.

ArnoldSchrader commented 3 weeks ago

Ich habe ein ähnliches Problem; ab Version 0.8.130 läuft die Ansteuerung per API nicht mehr zuverlässig. Ich vermute, das Problem tritt nur bei mehr als einem konfigurierten Inverter auf, da ich es nur dann beobachtet habe, wenn mehr als ein Inverter per API geändert werden sollen: Es wird zwar ein ok jeder der Änderungen zurückgegeben - aber diese passiert beim 2. dann scheinbar nicht. Ignoriert die #1704 ggf. bei zwei gleichzeitig vorhandenen Änderungen die 2.?

BlackcatSandy commented 3 weeks ago

Ich habe ein ähnliches Problem; ab Version 0.8.130 läuft die Ansteuerung per API nicht mehr zuverlässig. Ich vermute, das Problem tritt nur bei mehr als einem konfigurierten Inverter auf, da ich es nur dann beobachtet habe, wenn mehr als ein Inverter per API geändert werden sollen: Es wird zwar ein ok jeder der Änderungen zurückgegeben - aber diese passiert beim 2. dann scheinbar nicht. Ignoriert die #1704 ggf. bei zwei gleichzeitig vorhandenen Änderungen die 2.?

Leider nicht, bei mir ist es auch mit nur einem HM600. Habe deshalb auch meinen Chip gewechselt von esp8266 auf esp32s3 weil ich dachte es wird dem Chip Zuviel

ArnoldSchrader commented 3 weeks ago

@BlackcatSandy Okay, war auch mehr geraten als gewusst ;-) Dann wundert mich aber, dass hier nicht deutlich mehr betroffen sind?!

Ollipop030 commented 3 weeks ago

Dann wundert mich aber, dass hier nicht deutlich mehr betroffen sind?!

Ich schätze mal, nicht jeder hat immer die aktuelle Dev Version installiert, und von denen hat ein noch kleinerer Teil eine Nulleinspeisung laufen. Und es ist ja noch Urlaubszeit, viele chillen vielleicht noch in der Sonne. ;-)

BlackcatSandy commented 3 weeks ago

@BlackcatSandy Okay, war auch mehr geraten als gewusst ;-) Dann wundert mich aber, dass hier nicht deutlich mehr betroffen sind?!

Ich denke viele nutzen OpenDTUonBattery und haben das tolle Script von Tobias noch nicht gefunden oder nutzen OpenDTU ohne weiteren Server

dtuuser commented 3 weeks ago

Ich fahre die Nulleinspeisung über ein eigenes Programm mit CURL Aufruf. Aktuell noch mit Version .113, da alle neueren DEVs ab und zu mal ein Limitsetzen vergessen bzw. vom WR nicht angenommen werden. Arbeite gerade an dem Auslesen des aktuellen Limits und wenn das eine Differnz zum vorher geschickten hat, dann wird das Limit nochmals geschickt. Alle Tools laufen unter Windows

BlackcatSandy commented 3 weeks ago

Also kostest du auch unabhängig von uns diese Probleme in neuen Versionen feststellen 🧐 Ja sollte recht einfach gehen mit einer globalen Variable und dann den letzten Wert speichern und notfalls falls du den aktuell gesetzten Wert nicht bekommst, einfach den aktuellen P_AC wert nehmen

dtuuser commented 3 weeks ago

Problem der auslesenden Rückmeldung.....dauert bis zu 2 Minuten. Aktuell lese ich alle 10 Sekunden mit Tasmota den Stromzähler aus und regel dann alle 60 Selunden den WR. So habe ich eine Einspeisung von knapp 5% vom Ertrag hinbekommen.

BlackcatSandy commented 3 weeks ago

Ich habe ja wie gesagt das Skript von Tobias im Einsatz, Shelly meldet alle 3 Sekunden und demnach wird auch geschaltet, bis dann Ahoy nicht mehr mitkam (heute nach die plötzliche Einspeisung). Durch das neue Updated von gestern läuft es wieder gut und ich habe noch eine Peak detection eingebaut, die ich morgen früh nochmals poste wegen sondercase fixes die seit 19 alle hoffentlich gefixed sind

Ollipop030 commented 3 weeks ago

Was mich aber wundert: Bei euch scheint die 141 ja zu laufen, bei mir stürzt die Version alle paar Stunden ab. Übrigens auch die Versionen davor. Das Problem fängt bei mir ab der 130 an, alles davor läuft wunderbar über Wochen.

BlackcatSandy commented 3 weeks ago

Was meinst du mit abstürzen? Ahoy komplett nicht erreichbar oder bei Zero Export

Ich hatte immer wieder Aussetzer (3:30), deshalb habe ich sogar einen neuen Chip gekauft weil ich dachte ahoy kommt nicht hinterher

Hast du das neue Update von Tobias schon installiert? hier auch ein Absturz von mir vor dem Update (siehe Bild oben)

ps: Ich habe auch eine neue Funktion zur Kühlschrankerkennung eingebaut, die noch nicht in der neuen Version enthalten ist. Wenn du willst kannst du diese auch testen (den post hat Tobias oben schon verlinkt) Du musst nur das letzte zip installieren und in der config den neuen Parameter hinzufügen

ArnoldSchrader commented 3 weeks ago

Also ich setze auch meine eigene Lösung mit esp8266 ein, die per http auf die API zugreift aber heute gab es leider noch nicht genug Sonne, damit der Zeroexport-Modus genutzt wird (dann wird viel geregelt und die Probleme mit 0.8.130+ fielen erst da auf; nun habe ich auch eine Kontrolle über Wunsch und Wirklichkeit eingebaut und siehe da, auch bei den kleinen Anpassungen im einstelligen Wattbereich werden nur etwa die hälfte wirklich umgesetzt - die andere Hälfte muss nochmal upgedated werden :-/ ; das ist mir optisch bisher nur nicht aufgefallen...).

Insofern kann ich dahingehend noch nix zur 0.8.141 sagen außer, dass die ESPAsyncWebServer für mich keine Verbesserung darstellt - eher schlechter: es gibt deutlich häufiger Timeouts und leere/unvollständige Daten. Meist nach einem Update kann man "darauf warten", dass anschließend innerhalb 5s mindestens eine Abfrage scheitert (Status wird alle 2s pro Inverter abgefragt; Ich habe auch schon mit den Timeouts "gespielt" aber keine Verbesserung erzielt). Auch hier leider aktuell ein Rückschritt ggü 0.8.129. Vorher gab es so einen Timeout/Unvollständigen Request nur ca einmal die Minute.

lumapu commented 2 weeks ago

⚠ Achtung, Version 0.8.142 funktioniert nicht, siehe

1743

ArnoldSchrader commented 1 week ago

So, ich muss noch berichten - aber leider nichts positives: Habe die 0.8.143 ausprobiert und muss leider sagen, dass ich keinen Unterschied bei API-Stabilität zur >=0.8.130 feststellen kann. Lediglich bei den HTTP-Requests ist es nun "empfindlicher" (setSync muss false und setNoDelay true sein, sonst werden POSTs völlig ignoriert). Aber auch mit der 0.8.143 muss etwa 40-50% der API-Posts min 1x wiederholt werden (also tlws. bis zu 10x/Min). Auf 0.8.129 war das vllt 1x in der Stunde erforderlich.

Hinweis: ich habe in den Einstellungen bei Wechselrichter 1s als Intervall. Ich werde wohl erstmal bei 0.8.129 bleiben müssen..

RealNBB commented 3 days ago

@lumapu

Also ich kann über die 0.8.143 nichts negatives (mehr) berichten. Läuft abgesehen davon...

https://github.com/reserve85/HoymilesZeroExport/issues/228#issuecomment-2339939791

...einwandfrei nun mehr bei mir.

lumapu / ahoy