Leistungslimitierung

[hubsi5]

Welche Abstände zwischen den Befehlen für eine Leistungslimitierung wird empfohlen? Kann man das sagen? Versuche momentan eine Nulleinspeisung zu realisieren, da wird alle 60 Sekunden ein Wert für die Limitierung per mqtt (devcontrol/0/11) gesendet. Aber irgendwie kommt da ahoy nicht ganz mit. Gibt es da schon Erfahrungswerte?

Geht da auf Dauer der EEPROM des Wechselrichters drauf?

[aschiffler]

Gute Frage. Man kann theoretisch die kürzest mögliche Zykluszeit dadurch rausholen wenn man die Berechnung für einen neuen power limit sollwert (den man auf devcontrol/0/11 published) als callback für das topic <CHOOSEN_TOPIC_FROM_SETUP>/<INVERTER_NAME_FROM_SETUP>/ch0/PowerLimit implementiert auf einem RPI oder ähnlich. So ist man nahe an der theoretischen Grenze. Allerdings würde dann die Abfrage der normalen Daten nicht mehr erfolgen da ständig das aktive limit abgefragt wird.

Siehe auch hier: https://github.com/grindylow/ahoy/blob/main/tools/esp8266/User_Manual.md#zero-export-control

[stefan123t]

Also ein einzelnes Kommando mit nur einem Antwortpaket dauert in der DTU-Pro zwischen 300-500ms dann erfolgt der übliche RX Timeout. Für mehrere Pakete wird immer wieder der Timeout erhöht.

1. Wie @aschiffler beschrieben hat wird das PowerLimit gesetzt und die Antwort abgewartet.
2. Dann wird das gesetzte PowerLimit per SystemConfigPara geprüft.
3. Und dann erst kommt irgendwann wieder die übliche Abfrage der aktuellen Werte. Die Abfrage der Werte braucht je nach Modell mehrere Antwortpakete (und evtl Retransmits).

Momentan wird mW jedes MQTT Kommando per Priority Lane in die Queue geschoben.

Vielleicht braucht es hier ein etwas anderes Vorgehen:

1. per Default geht ein MQTT Kommando ans Ende der Default Schlange. Priority Lane muss per Flag erzwungen werden.

2. zusammengesetzte Kommandos, zB PowerLimit setzen + SystemConfigPara abfragen oder mehrere ChannelStatus Kommandos für MI-600 2-on-1 und 4-on-1 MI-1200 Geräte

Und nicht vergessen die AhoyDTU braucht ja auch noch Zeit für Ihre anderen Aufgaben (WebInterface, MQTT, etc).

Dh die Priority Lane darf nicht zu lange sein oder überfüllt werden.

Ggf muss dann schlicht ein Kommando abgelehnt werden wenn die Prio Lane (noch) voll oder aktiv ist ?

[stefan123t]

@hubsi5 alle 60 Sekunden scheint ein Wert zu sein den einige im Discord Chat #ess-speichersysteme m.W. auch verwenden. Wie viele WR sind denn von Deinem AhoyDTU zu betreuen und zu befragen, das hat ja evtl. auch Auswirkungen auf die mögliche PowerLimit Frequenz. Durch die Umstellung auf AsyncWebServer und evtl. eine Event Driven UI Oberfläche können wir evtl. die Antwortzeit auch noch verbessern. Beim setzen des PowerLimit kannst Du das temporär machen, dann sollte es auch nur im Memory des HM Wechselrichters gesetzt werden. Ist dann nach einem Neustart weg. Ansonsten kann man auch ein Limit permanent setzen das ist dann vermutlich im EEPROM des Wechselrichters persistiert und gilt dann auch am nächsten Tag. Das setzen Einige für Ihre BMS ein.

[hubsi5]

Es ist nur ein Wechselrichter der angesteuert wird. Aber ich denke den Zeitraum werden ich etwas verlängern. Ich werde das einmal beobachten. Es gibt aber sicher einige andere die sich besser auskennen und da werde ich mir hoffentlich einmal etwas abschauen können

[aschiffler]

@stefan123t

Momentan wird mW jedes MQTT Kommando per Priority Lane in die Queue geschoben.

Zur Info und Klarstellung wie es momentan implementiert ist. Es gibt zwei grundsätzliche Kommandos: Info-Kommmando und Control-Kommando. Die Info-Kommandos werden via einer Queue abgearbeitet. Immer wenn die Antwort auf das Info-Kommando (tx-id: 0x95) erfolgreich geparst wurde oder der Timeout zuschlägt wird das Kommando aus der Queue gelöscht (_queue.pop()).

Das Control-Kommando (0x51) wird nicht in der Queue behandelt, sondern separat. Das Kommando wird im jeweiligen Intervall der Info-Queue vorgezogen wenn das flag devcontrolRequest = true ist. Die Antwort muss nicht geparst werden, da es nur ein ACK oder NACK gibt (byte 12 ist vorhanden und hat den Wert des Sub-Kontorl-Kommandos ja/nein ). Nur für den Fall Leistungslimitierung wird nach ACK die Info-Queue gelöscht und ein Sub-Info-Kommando (0x05 = get limit) ge-queued. Dann ist die Queue leer und in diesem Fall wird immer das "default" Sub-Info-Kommando rein geschrieben. (Das könnte man theoretisch weglassen und rein auf das ACK vertrauen dass das Limit gesetzt wurde). Das ACK als Antwort auf das Control-Kommando geht quasi innerhalb weniger Millisekunden und könnte theoretisch auf MQTT Topic geschrieben werden für das Timing externer Zero-Export-Regelungen.

Man kann somit im Moment, wenn man schnell/häufig das Limit ändert die Abfrage so "steuern" das nur noch das Limit mit dem Info-Kommando abgefragt wird und keine anderen Daten mehr.

Deswegen war mein Vorschlag die Logik der Zero-Export-Regelung so zu implementieren (auf Gerät außerhalb von DTU) dass man die subscribe callback (MQTT) nutzt um das Timing zu haben. Sprich die DTU gib den Takt vor durch das publish auf den Topics "P_AC" oder "PowerLimit".

[hubsi5]

habe das jetzt minütlich realisiert. Klappt bis jetzt einwandfrei! Läuft nun seit 6 Stunden durch, mit minütlicher Leistungsanpassung

[Ziyatoe]

der wr braucht es etwa 20-25 sek (heir ein MI-1500) um auf die leistung zu kommen, ein minutenweise update kann ev. schiefgehen, da der wr ev. noch nicht dort ist, dann wird ein neues limit gesetzt, so kann es sein, dass der wr "laenger" schwingt.

[hubsi5]

Funktioniert einwandfrei. Aber normal wird nicht jede minute etwas zum wechselrichter gesendet. sendet nur wenn Differenz mehr als 50Watt beträgt (alter Wert-neuer Wert).

[Telekatz]

Ich regle meine WR (HM-600) alle 5 Sekunden nach. Der WR braucht etwa 3 Sekunden, bis er die Leistung anpasst. Funktioniert auch einwandfrei.

[stefan123t]

Der original Hoymiles DTU Pro source code regelt in AntiReflux.c auch nur bei mehr als 30W Abweichung nach. Das ist also schon fast eine Best Practice.

[Ziyatoe]

Der original Hoymiles DTU Pro source code regelt in AntiReflux.c auch nur bei mehr als 30W Abweichung nach. Das ist also schon fast eine Best Practice.

und dem sagen sie zeroexport ;-) übrigens, das orginal regelt alle 10min, hier eine DTU-Pro. darum muss ich die DTU über modbus selber regeln

[hubsi5]

So wie ich das nun haben passt mir das. Jede Minute wird mein Stromverbrauch angeschaut. Dann wird der Wechselrichter geregelt. Ich habe es so eingestellt, dass er immer 150W einspeisen soll. Damit fange ich eventuelle Verbrauchssprünge etwas ab. Ändert sich nach dieser einen Minute die Soll Limitierung weniger als 50W passiert gar nichts. Ich will auch vermeiden, dass der Wechselrichter zu oft die Limitierung ändern muss. So habe ich unter Tags oft über einer halben Stunde keinen einzigen Befehl zum Wechselrichter senden müssen. Danke noch einmal für das tolle Projekt!

[hubsi5]

Irgendwie ist da ein Wurm drinnen. Seit ich den Wechselrichter mit ahoy limitiere, hängt sich ahoy öfter auf. Also man kann ahoy normal über den Webbrowser erreichen, MQTT ist auch connected. Heute habe ich gesehen, dass der Wechselrichter plötzlich nichts mehr produzierte. Also ich ahoy neu startete hat der Wechselrichter wieder produziert. Gestern hat ahoy per mqtt nichts mehr gesendet, obwohl connected stand. Leider habe ich keine logs, da ich das Ganze immer von der Arbeit aus gesehen habe.

[Ximerox]

Ich ändere das Limit ca alle 5 Sekunden. Funktioniert bis jetzt problemlos. Allerdings ist dann die Ahoy Oberfläche nicht mehr wirklich funktional, auch gibts keine aktuellen Werte per mqtt mehr. Aber über die Leistungsmessung am AC-Ausgang über einen Shelly PM sehe ich, dass es funktioniert.

[DanielR92]

Denke dieses Issue kann vorerst auch geclosed werden, oder wäre noch was offen? :)