MQTT-Limit-Einstellungen werden nicht an WR übertragen

[SnakeGER]

Platform

ESP32

Assembly

I did the assembly by myself

nRF24L01+ Module

No response

Antenna

external antenna

Power Stabilization

Elko (~100uF)

Connection picture

• [ ] I will attach/upload an image of my wiring

Version

0.8.146

Github Hash

CC BY-NC-SA 4.0

Build & Flash Method

AhoyDTU Webinstaller

Setup

.

Debug Serial Log output

No response

Error description

Hallo, ich habe 2x Hoymiles HMS 1600 4T und 1x Hoymiles HMS 800 2T an meiner DTU. Mein Stromspeicher meldet den Stand in % via MQTT und der Broker sendet daraufhin das gewünschte Limit an die DTU, welche dann alle 3 WR einstellt. Dies funktionierte bis zur Version 0.8.129 auch wunderbar. Sobald ich allerdings eine neuere Version auf der DTU installiere, wird nur noch sporadisch das gewünschte Limit an alle WR übertragen. Von 10 Limit-Einstellungen funktioniert es nur einmal, dass alle 3 WR die Limit-Anforderung empfangen. Meistens bleibt ein WR oder manchmal sogar 2 WR auf dem alten Limit "hängen". Wie gesagt: Bis zur v129 (welche ich auch weiterhin nutze, bis das Problem behoben ist) funktionierte dies einwandfrei. Die zuverlässige Limit-Einstellungen für alle 3 WR sind für meine Nulleinspeisung unerlässlich.

[lumapu]

Hallo, das ist gut verständlich. Hast du für mich ein Log aus der Web-console? Das wäre sehr hilfreich zu sehen was die Komminikation zu diesem Zeitpunkt sagt. In der Zwischenzeit versuche ich es nachzustellen.

[lumapu]

Ich denke ich habe das Problem verstanden. Die interne Queue wird befüllt während sie bereits abgearbeitet wird. Eine fehlende Synchronisation kann dazu führen, dass Kommandos unbeabsichtigt verloren gehen.

[SnakeGER]

Hey. Ok, brauchst du noch irgendwas? Im Moment läuft wieder die 129. Sonst muss ich nochmal updaten auf die neueste Version. LG

[lumapu]

nein, Fehler ist gefunden und in Bearbeitung, danke für den Hinweis. Erfordert leider größere Umbauten, bin mir sicher dass die nächste Version bezüglich Übermittlung der Limits die beste Version seit langem wird.

[SnakeGER]

Ich kanns nur immer wieder sagen: Hut ab vor eurer Leistung. Das ist echt ein mega Projekt und ein toller Service von euch. LG

[SnakeGER]

Habe nun die 147 aufgespielt. Es läuft besser mit den Limit-Einstellungen, aber leider auch nicht Fehlerfrei. Es kommt trotzdem immer noch zu nicht übertragenen Limit-Anforderungen. Hier mal ein Auszug aus der Console:

12:15:58.100 ----- 12:15:58.167 I: MQTT got topic: AHOY/ctrl/limit/0 12:15:58.170 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":0} 12:15:58.183 I: (#0) sendControlPacket cmd: 0b 12:15:58.270 I: (#0) RX 70ms | 17 -50dBm | d1 81 12:15:58.271 I: (#0) has accepted power limit set point 80.00 with PowerLimitControl 1 12:15:58.274 ----- 12:15:58.278 I: com loop duration: 1273ms 12:15:58.278 ----- 12:15:59.194 I: MQTT got topic: AHOY/ctrl/limit/1 12:15:59.195 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":1} 12:15:59.199 I: (#1) sendControlPacket cmd: 0b 12:15:59.276 I: (#1) RX 71ms | 17 -53dBm | d1 81 12:15:59.277 I: (#1) has accepted power limit set point 80.00 with PowerLimitControl 1 12:15:59.280 ----- 12:15:59.281 I: com loop duration: 84ms 12:15:59.282 ----- 12:16:00.094 I: (#0) RX 81ms | 27 -52dBm | 95 81 12:16:00.097 ----- 12:16:00.218 I: MQTT got topic: AHOY/ctrl/limit/2 12:16:00.220 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":2} 12:16:00.223 I: (#2) sendControlPacket cmd: 0b 12:16:00.633 I: (#2) RX 70ms | 27 -59dBm | 95 01 12:16:00.770 I: (#2) RX 68ms | 27 -59dBm | 95 02 12:16:00.842 I: (#2) RX 67ms | 23 -59dBm | 95 83 12:16:00.845 ----- 12:16:00.934 I: (#1) RX 84ms | 27 -53dBm | 95 81 12:16:00.937 ----- 12:16:01.225 I: (#1) RX 110ms | 27 -53dBm | 95 01 12:16:01.228 I: (#1) RX 187ms | 27 -53dBm | 95 03 12:16:01.229 I: (#1) RX 232ms | 27 -53dBm | 95

Die ersten beiden WR melden: ...has accepted Powerlimit... Der dritte leider nicht.

Ich behalte trotzdem die v147 und beobachte weiter. Ich kann den Fehler auch nicht so oft reproduzieren, wie mit der v146. Also es ist auf jeden Fall besser geworden.

Wenn nochwas gebraucht wird, gerne Bescheid sagen. LG

[SnakeGER]

Hier wurde jetzt der erste WR nicht umgestellt. Ich habe sogar über Node-Red den MQTT-Broker so eingestellt, dass jede Limit-Anforderung 2mal im Abstand von 5 sekunden an die DTU gesendet wird. Aber auch dies brachte keine Besserung.

12:45:31.295 ----- 12:45:31.361 I: MQTT got topic: AHOY/ctrl/limit/0 12:45:31.362 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":0} 12:45:31.366 I: (#0) sendControlPacket cmd: 0b 12:45:31.711 I: (#0) RX 68ms | 27 -52dBm | 95 01 12:45:31.848 I: (#0) RX 71ms | 27 -52dBm | 95 02 12:45:31.985 I: (#0) RX 69ms | 27 -52dBm | 95 03 12:45:31.986 I: (#0) timeout, no attempts left 12:45:31.987 ----- 12:45:31.988 I: com loop duration: 987ms 12:45:31.988 ----- 12:45:32.234 I: MQTT got topic: AHOY/ctrl/limit/1 12:45:32.237 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":1} 12:45:32.252 I: (#1) sendControlPacket cmd: 0b 12:45:32.328 I: (#1) RX 70ms | 17 -53dBm | d1 81 12:45:32.329 I: (#1) has accepted power limit set point 80.00 with PowerLimitControl 1 12:45:32.332 ----- 12:45:32.333 I: com loop duration: 87ms 12:45:32.334 ----- 12:45:33.222 I: MQTT got topic: AHOY/ctrl/limit/2 12:45:33.224 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":2} 12:45:33.228 I: (#2) sendControlPacket cmd: 0b 12:45:33.302 I: (#2) RX 69ms | 17 -60dBm | d1 81 12:45:33.303 I: (#2) has accepted power limit set point 80.00 with PowerLimitControl 1 12:45:33.306 ----- 12:45:33.307 I: com loop duration: 81ms 12:45:33.308 -----

[knickohr]

Bei dem letzten Auszug kam ein RX Timeout. Kann gut sein das das Ack hier nicht von der DTU empfangen worden ist, obwohl es der WR geschickt haben könnte.

Ach nochwas, Du solltest nicht gleiche Limits noch einmal schicken, das kann den WR blockieren und er ist unter Umständen sogar bis zu 15 Minuten beleidigt. Neue Limits nur senden wenn sich auch der Wert geändert hat und wenn vorher ein Ack empfangen worden ist.

[lumapu]

beim nächsten Tageslicht können wir einen neuen Versuch starten, ich hoffe diesmal alles erwischt zu haben.

[SnakeGER]

Werde die neue Version morgen testen. Vielen Dank und gute Nacht

[SnakeGER]

Hallo zusammen. Ich würde gerne etwas anderes berichten, aber mit der 0.8.148 startet sich meine DTU bei jeder Limit Anforderung neu. Die 129 ist momentan die stabilste Version bei mir. @knickohr Ich habe das doppelte Senden der Limits abgeschaltet. Das sollte nun nichtmehr das Problem triggern.

LG

[lumapu]

meine Tests sind ohne Absturz. Wie viele WR regelst du? Ich habe 4 WR gleichzeitig auf 99% geregelt, 10s später wieder auf 100%

import requests,json
import time

def setLimit(id, limit):
    url = 'http://10.20.1.200/api/ctrl'
    payload = '{"id":' + str(id) + ',"token":"*","cmd":"limit_nonpersistent_relative","val":"' + str(limit) + '"}'
    headers = {
        'Content-Type': 'application/json;charset=utf-8'
    }
    r = requests.post(url, data=payload, headers=headers)

    print(r.text)
    #print(r.json)

setLimit(0, 99)
setLimit(1, 99)
setLimit(2, 99)
setLimit(3, 99)

time.sleep(10)

setLimit(0, 100)
setLimit(1, 100)
setLimit(2, 100)
setLimit(3, 100)

[SnakeGER]

Es sind 3 WR. 2x HMS 1600 4T 1x HMS 800 2T

Habs auch gerade nach deinem Post nochmal mit der 148 versucht, aber dasselbe Resultat.

[blueline13]

@lumapu Ich kann das verhalten 0.8.148 auf einem ESP32 bestätigen, wobei die DTU bei mir zwischen 1-10 Minuten durchhält bevor sie rebootet. Scheint nur davon abhägig zu sein wie oft Limits geschrieben werden.

Ich hänge mal gerade den letzten coredump an. 2024-10-01_13-40-17_v0.8.148_esp32-wroom32_coredump.zip

[SnakeGER]

Ok, ich hab natürlich zum Testen die Limits ca. alle 10-20 Sekunden geschickt. 90%, 80%, 50%, usw...

[lumapu]

@blueline13 Der Fehler war vorprogrammiert. Sorry das wird eine 0.8.149 beheben müssen 😇. Der Coredump war super hilfreich und hat mich direkt zum Fehler geführt - ein nullptr

Für die Insider:

==================== THREAD 2 (TCB: 0x3ffbd8e8, name: 'loopTask') =====================
#0  0x400dcf83 in Communication::closeRequest (this=0x3ffc8360 <myApp+17904>, q=0x3ffc8a04 <myApp+19604>, crcPass=false) at hm/Communication.h:653
#1  0x400f1af4 in Communication::innerLoop (this=0x3ffc8360 <myApp+17904>, q=0x3ffc8a04 <myApp+19604>) at hm/Communication.h:280
#2  0x400f206d in Communication::loop (this=0x3ffc8360 <myApp+17904>) at hm/Communication.h:79
#3  app::loop (this=0x3ffc3d70 <myApp>) at app.cpp:141
#4  0x400f25a5 in loop () at main.cpp:42
#5  0x4010a740 in loopTask (pvParameters=<optimized out>) at /home/runner/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:50

Die Kommunikation ist fertig. leider war der CRC falsch, weshalb das Kommando wieder in die Queue eingereiht wird. Beim Einreihen in die Queue wird das akutelle Objekt nicht kopiert sondern 'gemoved'. Dadurch bekomme ich ein leeres Objekt zurück, bei dem alles NULL ist. Ein Zugriff auf einen Member führt unweigerlich zum crash.

[SnakeGER]

Hehe. Auch wenn ich in dem Fall nur "Bahnhof" verstehe, werde ich die neue Version natürlich ausprobieren, sobald sie online ist.

Gute Nacht

[blueline13]

Dann warten auf 0.8.149 und morgen wird es sicher auch wieder hell für einen neuen Versuch 😁 Super Job wie immer!!!

[blueline13]

@lumapu Kurze Bestätigung das es nun wieder rund läuft. 👍

[SnakeGER]

Hallo zusammen. Leider ist das Limit-Problem mit der 149 immernoch nicht behoben. Ich habe zwar keine Neustarts der DTU mehr, aber die Limits werden weiterhin nicht zuverlässig eingestellt. Hier nochmal ein Auszug aus der Console:

14:41:16.875 I: MQTT got topic: AHOY/ctrl/limit/0 14:41:16.876 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":0} 14:41:16.881 I: (#0) sendControlPacket cmd: 0b 14:41:16.954 I: (#0) RX 67ms | 17 -46dBm | d1 81 14:41:16.955 I: (#0) has accepted power limit set point 80.00 with PowerLimitControl 1 14:41:16.958 ----- 14:41:16.959 I: com loop duration: 80ms 14:41:16.960 ----- 14:41:17.896 I: MQTT got topic: AHOY/ctrl/limit/1 14:41:17.898 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":1} 14:41:17.902 I: (#1) sendControlPacket cmd: 0b 14:41:17.978 I: (#1) RX 71ms | 17 -52dBm | d1 81 14:41:17.979 I: (#1) has accepted power limit set point 80.00 with PowerLimitControl 1 14:41:17.982 ----- 14:41:17.983 I: com loop duration: 83ms 14:41:17.984 ----- 14:41:18.092 I: (#0) RX 82ms | 27 -46dBm | 95 81 14:41:18.096 ----- 14:41:18.377 I: (#0) RX 85ms | 27 -46dBm | 95 01 14:41:18.378 I: (#0) RX 135ms | 27 -46dBm | 95 02 14:41:18.379 I: (#0) RX 184ms | 27 -46dBm | 95 03 14:41:18.380 I: (#0) RX 234ms | 27 -46dBm | 95 04 14:41:18.381 I: (#0) RX 275ms | 15 -46dBm | 95 85 14:41:18.394 ----- 14:41:18.481 I: (#1) RX 82ms | 27 -53dBm | 95 81 14:41:18.484 ----- 14:41:18.761 I: (#1) RX 82ms | 27 -53dBm | 95 01 14:41:18.762 I: (#1) RX 132ms | 27 -53dBm | 95 02 14:41:18.763 I: (#1) RX 182ms | 27 -53dBm | 95 03 14:41:18.764 I: (#1) RX 232ms | 27 -53dBm | 95 04 14:41:18.765 I: (#1) RX 272ms | 15 -53dBm | 95 85 14:41:18.778 ----- 14:41:18.934 I: MQTT got topic: AHOY/ctrl/limit/2 14:41:18.938 I: json: {"val":80,"path":"ctrl","cmd":"limit_nonpersistent_relative","id":2} 14:41:18.942 I: (#2) sendControlPacket cmd: 0b 14:41:19.096 I: (#2) RX 83ms | 27 -59dBm | 95 01 14:41:19.099 I: (#2) RX 133ms | 27 -59dBm | 95 02 14:41:19.190 I: (#2) RX 73ms | 23 -59dBm | 95 83 14:41:19.201 ----- 14:41:19.204 I: com loop duration: 1199ms 14:41:19.205 ----- 14:41:21.277 I: (#0) RX 82ms | 27 -46dBm | 95 01 14:41:21.279 I: (#0) RX 130ms | 27 -46dBm | 95 02 14:41:21.280 I: (#0) RX 181ms | 27 -46dBm | 95 03 14:41:21.281 I: (#0) RX 230ms | 27 -46dBm | 95 04 14:41:21.282 I: (#0) RX 271ms | 15 -46dBm | 95 85 14:41:21.295 ----- 14:41:21.572 I: (#1) RX 81ms | 27 -53dBm | 95 01 14:41:21.573 I: (#1) RX 130ms | 27 -53dBm | 95 02 14:41:21.575 I: (#1) RX 180ms | 27 -53dBm | 95 03 14:41:21.575 I: (#1) RX 230ms | 27 -52dBm | 95 04 14:41:21.576 I: (#1) RX 271ms | 15 -53dBm | 95 85 14:41:21.580 ----- 14:41:21.763 I: (#2) RX 82ms | 27 -58dBm | 95 01 14:41:21.764 I: (#2) RX 132ms | 27 -59dBm | 95 02 14:41:21.765 I: (#2) RX 178ms | 23 -59dBm | 95 83 14:41:21.767 ----- 14:41:21.768 I: com loop duration: 768ms 14:41:21.769 ----- 14:41:24.277 I: (#0) RX 82ms | 27 -46dBm | 95 01 14:41:24.279 I: (#0) RX 131ms | 27 -46dBm | 95 02 14:41:24.279 I: (#0) RX 181ms | 27 -46dBm | 95 03 14:41:24.280 I: (#0) RX 231ms | 27 -46dBm | 95 04 14:41:24.281 I: (#0) RX 271ms | 15 -46dBm | 95 85

Beim dritten WR wieder mal kein: "...has accepted power limit..."

Naja, nochmal zurück zur 129. LG

[SnakeGER]

So sieht das in der 129 aus:

14:53:01.635 I: MQTT got topic: AHOY/ctrl/limit/0 14:53:02.006 I: sendControlPacket cmd: 0b 14:53:02.081 I: (#0) RX 69ms | 17 -46dBm | d1 81 14:53:02.082 I: (#0) has accepted power limit set point 80.00 with PowerLimitControl 1 14:53:02.085 ----- 14:53:02.087 I: com loop duration: 82ms 14:53:02.088 ----- 14:53:02.679 I: MQTT got topic: AHOY/ctrl/limit/1 14:53:03.008 I: sendControlPacket cmd: 0b 14:53:03.080 I: (#1) RX 67ms | 17 -52dBm | d1 81 14:53:03.081 I: (#1) has accepted power limit set point 80.00 with PowerLimitControl 1 14:53:03.085 ----- 14:53:03.174 I: (#0) RX 82ms | 27 -46dBm | 95 81 14:53:03.178 ----- 14:53:03.454 I: (#0) RX 82ms | 27 -46dBm | 95 01 14:53:03.455 I: (#0) RX 131ms | 27 -46dBm | 95 02 14:53:03.457 I: (#0) RX 181ms | 27 -46dBm | 95 03 14:53:03.458 I: (#0) RX 231ms | 27 -46dBm | 95 04 14:53:03.459 I: (#0) RX 271ms | 15 -46dBm | 95 85 14:53:03.462 ----- 14:53:03.648 I: (#2) RX 84ms | 27 -58dBm | 95 01 14:53:03.649 I: (#2) RX 134ms | 27 -58dBm | 95 02 14:53:03.651 I: (#2) RX 181ms | 23 -58dBm | 95 83 14:53:03.654 ----- 14:53:03.654 I: com loop duration: 648ms 14:53:03.655 ----- 14:53:03.705 I: MQTT got topic: AHOY/ctrl/limit/2 14:53:04.049 I: sendControlPacket cmd: 0b 14:53:04.131 I: (#2) RX 71ms | 17 -59dBm | d1 81 14:53:04.133 I: (#2) has accepted power limit set point 80.00 with PowerLimitControl 1 14:53:04.138 ----- 14:53:04.145 I: com loop duration: 99ms

Und das klappt jedes Mal, wenn eine andere Limit-Anforderug kommt. 99,99999% zuverlässig.

Natürlich gucke ich immer zuerst bei mir (Verkabelung, Antenne, usw.) bevor ich dem Programmierer, welcher trotzdem einen absolut tollen Job macht, auf die Nerven gehe. Da die 129 allerdings bei mir TOP läuft, schließe ich einen Fehler meinerseits aus.

[Ollipop030]

Da die 129 allerdings bei mir TOP läuft, schließe ich einen Fehler meinerseits aus.

Bei mir exakt genauso. Habe seit heute morgen die .149 drauf, aber alle paar Minuten kommt es bei meiner Nulleinspeisung vor, dass einer von zwei WR das Limit nicht annimmt. Ich kehre auch regelmäßig zur .129 zurück, wenn eine nachfolgende Version Probleme macht. Die bisherigen .140er haben bei mir leider gar nicht funktioniert.

[blueline13]

Merkwürdig aber vielleicht auch nicht ich schreibe die Limits per API. Sicher es geht mal das eine oder andere Paket verloren beim senden. Weil der Inverter gerade nicht will oder ein Knoten in der Funkverbindung ist. Ich betreibe auch eine aktive Regelung und das mit 5 Invertern.

Doch ich prüfe erst welches Limit überhaupt als letztes geschrieben wurde und ein neues Limit wird nur bei Abweichungen geschrieben. Dann ist unbedingt das ack_pwr_limit des entsprechenden Inverter auszuwerten ob das geschriebene Limit auch vom Inverter bestätigt wurde. Damit geht mir eben kein Wert verloren. Ich konnte eins feststellen das es manchmal ein paar Sekunden brauch bis die Inverter das Ganze bestätigen. Ich betreibe das schreiben von neuen Limits auch sehr aggressiv wenn es kein ACK vom Inverter kam. Dann bekommt er nach 4 Sekunden ein neues Limit übergeholfen, also aus 80% werden dann 80,1%. Das funktioniert sehr zuverlässig. Aber auch meine 4 HMS Inverter sind oft Morgens und Abends übel gelaunt und fahren sich dann einfach mal aus heiterem Himmel runter und machen nur noch 0 Watt. Für so einen Spaß ist sicher die DTU und die Regelung nicht verantwortlich aber der Inverter das unbekannte Wesen. Also heißt es auch solche Zustände automatisch abfangen und einen Restart an den Inverter senden und bav warten bis er wieder lebt.

Sollte ihr die Nulleinspeisung nicht selber programmiert haben sonder vorgefertigte Scripte verwenden, geht bitte auf die Programmierer zu und bitte das so mit einzubauen. Damit ihr eine stabile Regelung sicherstellen könnt.

Was aber auch genauso wichtig ist, ist der Abstand wann neue Limits geschrieben werden. @knickohr wird mich sicher schon schief angucken wegen der 4 Sekunden! Aber ich gehe dabei davon aus(zig mal geprüft auch 15 Sekunden lang) das das Limit eben nicht vom Inverter verarbeitet wurde und er bekommt ein neues Limit was dann zu weit über 99% sofort bestätigt wird. Ansonsten halte ich mich auch Strickt daran nicht unter 10 Sekunden neue Limits zu schreiben. Ich prüfe zwar alle 6 Sekunden die Werte aber ich schreibe im Abstand von 12 Sekunden. Die Inverter brauchen auch Zeit um die Werte aus zu regeln!!!! Beispiel: ein HMS2000 der von 5% voll aufdrehen soll, ist an das Gesetzt gebunden und DARF nicht mehr als 400W pro Sekunde hoch "rampen" was schon mal 5 Sekunden sind! Dazu noch alles was mit Bestätigungen und Reaktionen zu tun hat und für eine stabile Ausregelung sollten da unbedingt die 10 Sekunden eingehalten werden! Wenn ich bei mir auf 10 Sekunden runter gehe wird meine Regelung auch zappiliger beim Ausregeln von schwankenden Lasten.

Es ist einfach unverantwortlich alle zwei Sekunden ein Limit zu schreiben und dazu noch das Gleiche wie vorher!

Sorry das es etwas länger geworden ist, aber soll allen helfen das etwas besser zu verstehen. Ansonsten bestätigen meine Erfahrungen auch zu 100% @knickohr seinen Aussagen was die Limits angeht.

@lumapu Ich habe auch immer wieder mal die .129 am laufen. Ich kann nur sagen das die 129 und die 149 sich nicht wirklich anders verhalten was die Limits und API angeht. Ich logge das mit, wie oft ein Limit neu geschrieben wurde. Das passt und ist in etwa grob gleich. Auf jeden Fall kann ich das Problem von @Ollipop030 bestätigen. Das diese Reboots uns ja schon länger plagen.

Ich habe dir mal ein Bild rein gepackt wo man den Heap Speicher und System sehen kann kurz vor einem Reboot. Jedes mal wenn der wieder hoch schnellt ist das ein Reboot. Ich hatte auch mal heute versucht mit "wildem rumklicken" auf der Weboberfläche das auszulösen des der Heapspeicher runter geht ... kein Erfolg. Da muss irgendwo etwas nicht wieder freigegeben werden. Was aber im Zusammenhang mit diesen Reboots steht ist das wie oft Limits an die DTU geschickt werden. Viele Limits kürze Abstände zwischen den Reboots.

Ach und ein paar Coredumps von heute. Vielleicht hilft das ja mit dieser Version dir etwas dem auf die Schliche zu kommen. Kurz vor dem Reboot

Nach dem Reboot

2024-10-02_12-00-41_v0.8.149_esp32-wroom32_coredump.zip

[knickohr]

Sehr gut !

Die neue „bedarfsoptimierte Leistungsregelung“ die in Ahoy implementiert wurde und in Kürze hoffentlich öffentlich wird, macht es nicht anders. Es wird ein Limit gesendet und es wird überprüft ob das Limit angekommen ist (Ack), wenn nicht wird spätestens nach der Abfrage der Inverterdaten das Limit noch einmal gesendet. Außer es ist bereits das was im Inverter drin ist. Außerdem wird überprüft of das neue Limit nicht unter die 2%-Marke ist und ob der Inverter „soft off“ geschaltet ist.

Wir haben aus der Vergangenheit und mit sehr vielen Versuchen gelernt wie die Imverter ticken. Das mal Imverter beleidigt ist und 15 Minuten nicht mehr angesprochen werden will kommt eigentlich nicht mehr vor.

[SnakeGER]

Hi. Das mit dem Ack überprüfen und ggf. erneut Senden, wäre die Lösung. Das mit dem "beleidigt sein" (15min) hatte ich nur, als ich vor nem halben Jahr die Frequenzen geändert hatte. Damals hatte ich zeitweise eine ganz schlechte Verbindung von DTU zum WR. Nachdem ich die Frequenzen geändert hatte, kam 15min garnichts und seitdem alles TOP. Aber das ist ein anderes Thema, sorry.

Gute Nacht

[lumapu]

es gibt eine 0.8.150, die wieder einen nullptr-bug behebt.

[Ollipop030]

ich schreibe die Limits per API.

So mache ich das auch, alle 13 Sekunden wir ein neues Limit gesetzt.

Doch ich prüfe erst welches Limit überhaupt als letztes geschrieben wurde und ein neues Limit wird nur bei Abweichungen geschrieben.

Ich benutze das Script von @reserve85, das läuft super. Hier wird das Limit auch nur einmal gesendet, nur bei einer Änderung wird auch ein neues gesendet.

Sollte ihr die Nulleinspeisung nicht selber programmiert haben sonder vorgefertigte Scripte verwenden, geht bitte auf die Programmierer zu und bitte das so mit einzubauen. Damit ihr eine stabile Regelung sicherstellen könnt.

Im besagten Script wird auch das ACK abgewartet, bei mir 7 Sekunden lang. Wenn in der Zeit kein ACK kommt, wird ein Timeout gemeldet, und das Script macht dann weiter mit der nächsten Schleife.

Ich bekomme mit der .149 ca. alle 2-5 Minuten einen Timeout, ganz sporadisch. Bei der .129 bekomme ich an manchen Tagen gar keinen Timeout. Die .150 teste ich mal.

[reserve85]

V.151: 99,98% success rate, @lumapu das sieht bei mir echt top aus.

[SnakeGER]

Kann ich nach ersten Tests (v151) auch bestätigen. Im Moment keine Fehler bei der Limit-Einstellung.

TOP!!!

[Ollipop030]

Hier bisher auch mit .151, Limit wird jedes Mal angenommen. Hatte allerdings vorhin einen Reboot nach knapp 60 Minuten Uptime (Reason: Panic). Ich hatte aber auch die ganze Zeit die Live-Seite im Browser geöffnet.

[lumapu]

@Ollipop030 gibt es einen coredump dazu?

[Ollipop030]

@lumapu wie bekomme ich den denn? Wenn ich "Download Coredump" anklicke bekomme ich eine leere Browserseite, in der wohl JSON Daten sein sollen.

[blueline13]

@Ollipop030 Das hatte ich auch schon ein paar mal, erst gestern bei meinem DTUFusion Board. Vermutlich ist beim Flaschen etwas schief gegangen und da hat es irgendetwas in den Partitionen zerlegt.

Sichere dir die Config per JASON File. Flashe die DTU mit einem "Erase" neu und lade dann wieder die Config hoch. Klappt bei mir immer!

Nimm am besten diesen Link, da kannst du gleiche die aktuelle BETA flashen.

https://fw.ahoydtu.de/tools/webflasher/

[RealNBB]

V.151: 99,98% success rate, @lumapu das sieht bei mir echt top aus.

Wo kann man das denn nachschauen? Macht ihr das über das Webserial oder gibt's da noch was anderes? :)

[lumapu]

@RealNBB auf der live Seite gibt es pro Inverter unten einen grauen Balken. Darauf klicken, dann kommen die Statistiken

[lumapu]

oder die Statistik stammt von der Limitregelung, die irgendwo extern läuft

[Ollipop030]

@blueline13 Gerade gemacht, bzw. versucht: Nach dem Flashen mit der .151 konnte ich mich verbinden, konnte meine WLAN Daten eintragen und dann nichts mehr. Der AP wurde noch weiterhin angezeigt, aber mit dem Browser kam ich nicht mehr auf 192.168.4.1. An der Fritzbox wurde sie auch nicht angezeigt, also wurde auch keine neue IP vergeben. Habs mehrmals versucht, geht einfach nicht. Nach dem eintragen des WLan Passwortes ist die DTU nicht mehr zu erreichen.

Habe dann die .129 frisch installiert, damit klappte es sofort: Wlan Passwort rein, nach Neustart ist sie direkt mit dem Router verbunden. Nach dem anschlißenden Update auf .151 klappt dann auch der Coredump.

Erstmal danke für den Tipp. Aber irgendwas passt da bei der aktuelle Dev nicht, wenn man eine frische Installation macht, zumindest bei mir nicht.

[RealNBB]

Sauber...kannte ich gar nicht! Danke fürs zeigen!

[reserve85]

Die 151 läuft bei mir mit Nulleinspeisung absolut super. Danke @lumapu

[lumapu]

@blueline13

2024-10-02_12-00-41_v0.8.149_esp32-wroom32_coredump.zip

Habe die Dumps ausgewertet, 2x sehr leer, nur der Watchdog, einmal der bekannte MqTT Fehler: https://github.com/bertmelis/espMqttClient/issues/166

[blueline13]

@lumapu Also ist da "mein dumpfes Gefühl" ja fast der richtige Weg das MQTT und Limits den Zusammenhang bilden. Da es bei mir dann auch extremen auftritt als bei anderen hängt dann an dern 5 Invertern und die dann per MQTT Werte senden. Spiegelt auch meine Erfahrungen von heute wieder. Sobald ich die DTU per MQTT mit Limits versorgt habe hat die DTU fast nur noch 15-30 Minuten überlebt und dann rebootet mit nem ESP32 Board. Nachdem ich wieder auf die API zurück bin hat sich das deutlich beruhigt und sie lief deutlich länger. Viele Limits erzeugt somit dann eine Berg von vielen sich ändernden Werte und damit deutlich mehr MQTT Traffic. Dann schaue ich mal wann die nächste Version da ist, wie es dann mit dienm Patch verhält.

Dann ist es gut das ich gerade versuche alles auf die API zu wechseln um den MQTT los zu werden ..... auch wenn er deutlich komfortabler ist. Ich lasse aber den MQTT Part drin falls der Workaround klappt, dann kann ich testen.

EDIT: Ohhh Schon da .... dann ans Werk und morgen schauen 👍

[knickohr]

In diesem Falle würde ich Dir mal empfehlen auf JSON-Payload zu wechseln und alles unnötige Gelogge über MQTT abzuschalten.

[blueline13]

@knickohr Danke für den Hinweis. Ich nehme an du meintest den Haken für "Payload as JSON" in den MQTT Einstellungen. Doch leider brachte das keine Linderung des Problems. Mit oder ohne Payload konnte ich bei mir keine wirklichen Unterschiede feststellen. Ich hoffe die Umstellung auf die API bis morgen fertig zu haben und das es dann auch läuft 🤣

@lumapu 0.8.152 Leider konnte ich keine Veränderung im Verhalten feststellen. Immer noch Reboots.

[haraldhotzbehofsits]

Ich verwende auch HoymilesZeroExport, ohne MQTT mittels API, habe auch reboots. Wenn die Seite im Browser offen ist scheint es eher zu passieren.

[technics42]

@haraldhotzbehofsits What polling interval are you using? The problem really is the webserver - unfortunately the implementation seems not to run very stable. It might crash if multiple requests come in the same time. Some Ahoy-webpages are also automatically updating the content (e.g. live-page), which is done in the same interval like polling the inverters - you shouldn´t have such webpages open, if not really looking at them. Now when you are using http-API at the same time like Ahoy-webpage itself is doing refresh, you could run into a crash.

@lumapu Did you ever consider of using websockets for refreshing webpage-contents? This would be faster (less traffic-overhead) and make http-API more stable - as webserver would handle less requests.

[blueline13]

@lumapu Nach ein paar Software "rumpeleien" beim ioBroker am Morgen lief das ESP32 Board ohne einen einzigen Reboot den ganzen Tag durch. Alles lief über die API. MQTT in der DTU ist deaktiviert. Damit steht zumindest bei mir fest, MQTT ist für das permanente Booten verantwortlich. Jetzt mal schauen wie lange meine DTU nun durchläuft. Ich konnte heute kein Absacken des freien Speichers feststellen. Die Abfrage Intervalle der DTU sind auch grob gleich geblieben mit dem was beim MQTT in der DTU eingetragen war. Zum Schluss hatte ich dann noch die "Live" Seite offen. Außer einem kurzen Zucken beim Speicher der nach einer Minute wieder auf dem normalen Wert war, gab es absolut keine Auffälligkeiten. Werde das Morgen von Anfang an mit parallel geöffneter Live Webseite laufen lassen. Was deutlich zu sehen ist, das die Fehler in der Kommunikation deutlich nach oben gehen(timeout), wenn ein Browser zusätzlich auf die DTU geöffnet wird.

[haraldhotzbehofsits]

polling is 5 seconds, 3 Inverters

[haraldhotzbehofsits]

with V.152 it stable since 5 days, no restart