MQTT-Limit-Einstellungen werden nicht an WR übertragen #1757
Comments
|
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. |
|
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. |
|
Hey. |
|
nein, Fehler ist gefunden und in Bearbeitung, danke für den Hinweis. |
|
Ich kanns nur immer wieder sagen: |
lumapu
added
bug
|
Habe nun die 147 aufgespielt. 12:15:58.100 ----- Die ersten beiden WR melden: ...has accepted Powerlimit... Ich behalte trotzdem die v147 und beobachte weiter. Ich kann den Fehler auch nicht so oft reproduzieren, wie mit der v146. Wenn nochwas gebraucht wird, gerne Bescheid sagen. LG |
|
Hier wurde jetzt der erste WR nicht umgestellt. 12:45:31.295 ----- |
|
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. |
|
beim nächsten Tageslicht können wir einen neuen Versuch starten, ich hoffe diesmal alles erwischt zu haben. |
|
Werde die neue Version morgen testen. |
|
Hallo zusammen. LG |
|
meine Tests sind ohne Absturz. Wie viele WR regelst du? 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) |
|
Es sind 3 WR. Habs auch gerade nach deinem Post nochmal mit der 148 versucht, aber dasselbe Resultat. |
|
@lumapu Ich hänge mal gerade den letzten coredump an. |
|
Ok, ich hab natürlich zum Testen die Limits ca. alle 10-20 Sekunden geschickt. 90%, 80%, 50%, usw... |
|
@blueline13 Für die Insider: 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 |
|
Hehe. Auch wenn ich in dem Fall nur "Bahnhof" verstehe, werde ich die neue Version natürlich ausprobieren, sobald sie online ist. Gute Nacht |
|
Dann warten auf 0.8.149 und morgen wird es sicher auch wieder hell für einen neuen Versuch 😁 Super Job wie immer!!! |
|
@lumapu |
|
Hallo zusammen. 14:41:16.875 I: MQTT got topic: AHOY/ctrl/limit/0 Beim dritten WR wieder mal kein: "...has accepted power limit..." Naja, nochmal zurück zur 129. |
|
So sieht das in der 129 aus: 14:53:01.635 I: MQTT got topic: AHOY/ctrl/limit/0 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. |
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. |
|
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 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. Nach dem Reboot
|
|
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. |
|
Hi. Gute Nacht |
|
es gibt eine |
So mache ich das auch, alle 13 Sekunden wir ein neues Limit gesetzt.
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.
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. |
|
V.151: 99,98% success rate, @lumapu das sieht bei mir echt top aus. |
|
Kann ich nach ersten Tests (v151) auch bestätigen. TOP!!! |
|
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. |
|
@Ollipop030 gibt es einen coredump dazu? |
|
@lumapu wie bekomme ich den denn? Wenn ich "Download Coredump" anklicke bekomme ich eine leere Browserseite, in der wohl JSON Daten sein sollen.
|
|
@Ollipop030 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. |
Wo kann man das denn nachschauen? Macht ihr das über das Webserial oder gibt's da noch was anderes? :) |
|
@RealNBB auf der
|
|
oder die Statistik stammt von der Limitregelung, die irgendwo extern läuft |
|
@blueline13 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. |
|
Sauber...kannte ich gar nicht! |
Die 151 läuft bei mir mit Nulleinspeisung absolut super. Danke @lumapu |
|
Habe die Dumps ausgewertet, 2x sehr leer, nur der Watchdog, einmal der bekannte MqTT Fehler: |
|
@lumapu 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 👍 |
|
In diesem Falle würde ich Dir mal empfehlen auf JSON-Payload zu wechseln und alles unnötige Gelogge über MQTT abzuschalten. |
|
@knickohr @lumapu |
|
Ich verwende auch HoymilesZeroExport, ohne MQTT mittels API, habe auch reboots. Wenn die Seite im Browser offen ist scheint es eher zu passieren. |
|
@haraldhotzbehofsits @lumapu |
|
@lumapu |
|
polling is 5 seconds, 3 Inverters |
|
with V.152 it stable since 5 days, no restart |
|
Soo, ich hatte nun die letzten Wochen die v151 am Laufen und hatte keinerlei Probleme. Keine Reboots und alle Limit-Anforderungen wurden anstandslos angenommen und umgesetzt. Ich hoffe das bleibt so. Hab nun auf v152 geupdatet und es scheint auch weiterhin alles ok zu sein. Danke schonmal an alle Programmierer und die Community, welche hier super mitgewirkt hat. Der Fehler ist jedenfalls erstmal behoben. |
Platform
ESP32
Assembly
I did the assembly by myself
nRF24L01+ Module
No response
Antenna
external antenna
Power Stabilization
Elko (~100uF)
Connection picture
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.
The text was updated successfully, but these errors were encountered: