Wechselrichterverbindung weg, sobald MQTT aktiviert ist

[fabiankeil1990]

What happened?

Ich habe eine OpenDTU mit ESP32 und CMT2300A. Firmware 24.8.5, Konfigurationsversion 0.1.28 und SDK Version v4.4.7-dirty.

Die Verbindung zu allen 4 Wechselrichtern funktioniert sofort und ist stabil. ( 2x HMS-1600-4T und 2x HMS1800-4T)

Sobald ich MQTT aktiviere, aktualisieren die Wechselrichter nichtmehr. Deaktiviere ich MQTT, bleibt der Zustand so, nichts wird aktualisiert. Erst nach einem Neustart geht es dann wieder.

Ich habe keine nRF24 Antenne für die WLAN verbingung, nutze das interne vom ESP32 dafür.

Hatte jemand schonmal so ein Problem?

Grüße

To Reproduce Bug

ESP32-D0WD-V3

Expected Behavior

Ich habe gehofft MQTT macht keine schwierigkeiten :-D

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

v24.8.5

Relevant log/trace output

No response

Anything else?

No response

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

[DPO99]

Welchen Intervall hast du bei MQTT eingestellt?

[fabiankeil1990]

Moin, im openDTU 5 sekunden.

Mein Homeassistant liefert ihm auch alle 5 sekunden neue werte wenn sich der verbrauch ändert.

[DPO99]

Welcher Intervall ist für die Abfrage der Wechselrichter eingestellt?

Und sende mal nicht alle 5 sek an die Dtu sondern alle 30. Bei 5 sek kommt die DTU nicht hinterher. Vor allem bei 4 Wechselrichtern.

[fabiankeil1990]

Da habe ich alle 8 sekunden eingestellt

[DPO99]

Und den Intervall zum Senden an die DTU auch auf 30 Sekunden gestellt? M.e. sollte es dann laufen.

[tbnobody]

Ist das Problem mit der aktuellen Version noch vorhanden? Wenn ja, was siehst du auf der Seriellen Konsole? Wenn nein, bitte den Issue schließen

[Neffez]

Habe dasselbe Problem, allerdings immer erst am Folgetag. Also MQTT an, alle 10 Sekunden wird ein neues Limit an OpenDTU gesendet, alles funktioniert einwandfrei, am nächsten Morgen kann allerdings keine Verbindung zum Wechselrichter mehr aufgebaut werden, bis MQTT deaktiviert und OpenDTU neu gestartet wird. Versuche logs nachzureichen.

[DPO99]

Habe dasselbe Problem, allerdings immer erst am Folgetag. Also MQTT an, alle 10 Sekunden wird ein neues Limit an OpenDTU gesendet, alles funktioniert einwandfrei, am nächsten Morgen kann allerdings keine Verbindung zum Wechselrichter mehr aufgebaut werden, bis MQTT deaktiviert und OpenDTU neu gestartet wird. Versuche logs nachzureichen.

Auch Dir würde ich empfehlen, von den 10 sek. weg zu gehen. Das ist unnötig und sorgt für Stress in der DTU. Ich hab das auf 30 sek. eingestellt und es läuft wunderbar mit 2 Wechselrichtern.

[Neffez]

Aber wie kann es sein, dass sich dieser "Stress" auf den nächsten Tag auswirkt?

[fabiankeil1990]

Hab leider auch noch keine Lösung gefunden :(

[tbnobody]

Aber wie kann es sein, dass sich dieser "Stress" auf den nächsten Tag auswirkt?

wenn du alle 10 sek ein update schickst wird dieses in eine queue eingereit die nach und nach abgearbeitet wird. unterm tag, im normalfall geht das recht schnell und der wechselrichter beantwortet diese anfrage. in der nacht muss jedoch auf einen vordefinierten timeout gewartet werden. wenn du vor diesem timeout jedoch gleich das nächste paket sendest gibt es keine chance mehr die queue leer zu machen.
des weiteren wird aktuell nur eine statistik anfrage an den wechselrichter gesendet wenn die queue leer ist.
als workaround könntest du also entweder die zeit für deine updates höher stellen oder nur updates senden wenn der WR erreichbar ist (es gibt dafür eine topic).
Ich arbeite auch schon an einer verbesserung dieses handlings.

[DPO99]

@tbnobody m.E. ist die "Lösung" bzgl. des höheren Intervalls völlig ausreichend. Wie du sagst, kann man auch Nachts das abfragen abstellen. Ich habe bisher auch noch keine gute/logische Begründung gehört, warum das Ding alle 10 oder 8 Sekunden reagieren soll...so schnell ist die Hardware im Worst-Case gar nicht....selbst bei 30 sek. frag ich mich persönlich manchmal schon, ob das wirklich notwendig ist.

[Neffez]

@DPO99 Also mein Wechselrichter reagiert innerhalb von 5 Sekunden auf eine Limitänderung. Bei starken Schwankungen im Bedarf kann einiges an Energie verloren gehen, wenn der Wechselrichter jedes Mal 30 Sekunden braucht um das Limit wieder zu erhöhen.

@tbnobody Danke für die Erklärung, jetzt macht das Verhalten auch Sinn. Ich würde dann darauf achten, dass ich nichts mehr schicke wenn der WR nicht mehr erreichbar ist.

[DPO99]

@DPO99 Also mein Wechselrichter reagiert innerhalb von 5 Sekunden auf eine Limitänderung. Bei starken Schwankungen im Bedarf kann einiges an Energie verloren gehen, wenn der Wechselrichter jedes Mal 30 Sekunden braucht um das Limit wieder zu erhöhen.

@tbnobody Danke für die Erklärung, jetzt macht das Verhalten auch Sinn. Ich würde dann darauf achten, dass ich nichts mehr schicke wenn der WR nicht mehr erreichbar ist.

Das kann ich mir ehrlich gesagt nicht vorstellen.....Wenn du um 12:00h sagst bitte mach 1000W...selbst wenn er in 5 oder 10 Sekunden reagiert, ist er nicht sofort dort. Und sobald er den Wert erreicht, sendest du wieder den nächsten hinterher. Im Ergebnis wirst du IMMER eine Differenz haben....und "einiges" an Energie? Du betreibst dann wohl 30? Wechselrichter und hast nen Verbrauch von nem Kraftwerk, damit du noch "einiges" sparen möchtest? Dazu hast du solche Lasten, dass sich alle 5 Sekunden der Verbrauch von 500-30000w ändert?

Versteh mich nicht falsch...man kommt niemals auf 0 außer man geht immer etwas höher mit der Last um Schwankungen abzufedern. Und lass uns bitte auch nicht darüber sprechen, ob Deine Anlage bei solchen "Werten" dann auch legal betrieben wird. Losgelöst davon, dass es dann auch völliger Quatsch ist das ganze über ein "BALKONKRAFTWERK" abzuwickeln.

[fabiankeil1990]

Also ich mache mit 4 Wechselrichtern auch so eine Art Nulleinspeisung. Dafür muss aber alles relativ schnell reagieren, sonst wird zu viel eingespeist.
Die fertigen Anlagen machen ja auch nichts anderes. Haben halt ihren eigenen Smartmeter.

Man kann damit schon sehr gut höheren bedarf steuern. Bei mir z.B. die Klimaanlagen im Sommer.
Das hilft schon, wenn es alles automatisch angepasst wird an den aktuellen verbrauch.

[Neffez]

@DPO99 ich habe meinen Use-Case und mein Problem beschrieben und eine Erklärung und Lösung bekommen. Es geht hier um OpenDTU, was hier wie in welchem Rahmen betrieben wird spielt keine Rolle und ist Off-Topic.

[DPO99]

@DPO99 ich habe meinen Use-Case und mein Problem beschrieben und eine Erklärung und Lösung bekommen. Es geht hier um OpenDTU, was hier wie in welchem Rahmen betrieben wird spielt keine Rolle und ist Off-Topic.

Nö ist es nicht. Hier geht es um die OpenDTU Basis-Applikation zur Überwachung und ggf. Steuerung der Wechselrichter. Das was du möchtest, ist hier nicht notwendig. Wende dich am besten an OpenDTU onBattery oder einen anderen Ableger. Es ist für die Basisapplikation nicht hilfreich und notwendig, wenn ständig so ein Quatsch rein kommt.

[stefan123t]

Aber wie kann es sein, dass sich dieser "Stress" auf den nächsten Tag auswirkt?

wenn du alle 10 sek ein update schickst wird dieses in eine queue eingereit die nach und nach abgearbeitet wird. unterm tag, im normalfall geht das recht schnell und der wechselrichter beantwortet diese anfrage. in der nacht muss jedoch auf einen vordefinierten timeout gewartet werden. wenn du vor diesem timeout jedoch gleich das nächste paket sendest gibt es keine chance mehr die queue leer zu machen. des weiteren wird aktuell nur eine statistik anfrage an den wechselrichter gesendet wenn die queue leer ist. als workaround könntest du also entweder die zeit für deine updates höher stellen oder nur updates senden wenn der WR erreichbar ist (es gibt dafür eine topic). Ich arbeite auch schon an einer verbesserung dieses handlings.

Die Queue an sich ist sinnvoll für die unterschiedlichen ActivePowerLimits unterschiedlicher Inverter. Es sollte aber pro Inverter nur einen aktuellen Zielwert geben. Dh wenn ein zweiter oder n-ter Zielwert per MQTT / REST API reinkommt braucht der Inverter die alten Zielwerte nicht mehr ansteuern, sondern immer nur den aktuellsten.
D.h. die Senderoutine prüft ob es eine Differenz zum aktuellen Limit gibt und schickt ggf das aktuelle Limit bzw den Zielwert an den Inverter. Die Queue arbeitet intial die Befehle ab und merkt sich nur den Zielwert in einer Variablen pro WR, das Senden des Limits erfolgt dann wie beschrieben asynchron im Anschluss.
Folglich wird wenn der Inverter am nächsten Tag wieder erreichbar ist auch nur einmal das aktuellste Limit gesendet und nicht mehr die Queue der vergangenen Nacht abgearbeitet. Das ist ja bereits immer wieder in-memory passiert.

[schlimmchen]

Hoffentlich ist es nicht zu hochnäsig oder arrogant das zu erwähnen, aber... siehe #1093, was auch das hier beschriebene Problem verhindert hätte 😉 Ich bin gespannt, was Thomas kredenzt, denn er schrieb ja, dass er schon an einer Verbesserung in diesem Kontext arbeitet 👍