Replies: 27 comments 73 replies
-
|
Ganz stabil wie auch die Version davor - kein Reboot seit dem letzten Update.
|
Beta Was this translation helpful? Give feedback.
-
|
auch hier alles stabil.
|
Beta Was this translation helpful? Give feedback.
-
|
Regelmäßige Neustarts waren auch hier alle paar Minuten. Nach Umsetzung der Empfehlungen von Bernhard vor einigen Monaten und anschließender Neuinstallation des Systems ohne Wiederherstellung der alten Konfiguration (inkl. Flash-Löschung und Factory Flash) – ein überschaubarer Aufwand bei mir – ist die Funktionalität wieder einwandfrei. Ob dies allein ausreicht und etwaige Reste der alten Konfiguration Probleme verursachen könnten, ist unklar, jedoch hat diese Maßnahme in meinem Fall Abhilfe geschaffen. |
Beta Was this translation helpful? Give feedback.
-
|
Was hast du wir wechselrichter? HM oder HMS/HMT? |
Beta Was this translation helpful? Give feedback.
-
|
Hms/ HM |
Beta Was this translation helpful? Give feedback.
-
|
Meine DTU läuft maximal 2 Tage durch. Muss aber sagen daß alles stabil läuft. |
Beta Was this translation helpful? Give feedback.
-
|
Per usb Kabel und einem externen Gerät. Raspberry oder der PC. Was hast du für wechselrichter? HM oder HMS/HMT? |
Beta Was this translation helpful? Give feedback.
-
|
Ich hab HMS. |
Beta Was this translation helpful? Give feedback.
-
|
MQTT brauchst du da nicht. Nur ssh Zugriff, oder Bildschirm und Tastatur https://github.com/hoylabs/OpenDTU-OnBattery/wiki/Debugging#capturing-the-serial-output |
Beta Was this translation helpful? Give feedback.
-
|
Sorry habs verstanden. |
Beta Was this translation helpful? Give feedback.
-
|
@Polo2Turbo Serielles Log wäre super. Ansonsten würde ich gerne wissen, ob du zufällig ein Huawei R48xx betreibst? |
Beta Was this translation helpful? Give feedback.
-
|
Hallo. Nein ich hab kein Huawei |
Beta Was this translation helpful? Give feedback.
-
|
Was für Einstellungen habt ihr unter Settings > Logging. So weit ich weiß muss der neue, fein-granulare Loghandler im VERBOSE / DEBUG mode viele Daten per Serial I/O und WebAPI zur Verfügung stellen bzw. häufig den Log Level prüfen. Vielleicht belastet das den ESP32 in bestimmten Situationen zu stark ? |
Beta Was this translation helpful? Give feedback.
-
Ich würde das natürlich gerne glauben, denn sonst müssten wir annehmen, dass es noch mehr/andere Probleme gibt 🙈 |
Beta Was this translation helpful? Give feedback.
-
|
Was genau meinst du damit? Kann ich irgendwie versuchen die reboots wieder zu erzwingen? |
Beta Was this translation helpful? Give feedback.
-
|
Das soll heißen, dass das Logging im aktuellen Release zu ineffizient ist und Probleme verursacht. Und ich hätte gerne, dass das die Ursache für deine Reboots war, sodass es sich um keinen anderen/weiteren Fehler handelt. Lass mal laufen, wenn's läuft. Wenn du so einen Neustart wieder siehst und es lag an der Protokollierung, dann ist der Backtrace, falls es einen gibt, eh nicht sonderlich aussagekräftig. Daher lohnt es sich nicht. |
Beta Was this translation helpful? Give feedback.
-
|
Na gut. Dann lass ich es einfach ohne Protokollierung weiter laufen. Und in ner Woche oder so stelle ich es mal zurück auf (E). Und gucke ob die reboots zurück kommen 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
Achso... Stell bitte mal auf I. I muss gehen. Selbst D sollte (je nach Setup) noch gehen. Nur V ist mir bekannt, dass es Probleme macht. Das hängt mit der Menge an Nachrichten zusammen, die dann erzeugt werden. Ich verstehe, dass du auch "aus" gestellt hast, aber das sollte nicht nötig sein. |
Beta Was this translation helpful? Give feedback.
-
|
Jetzt wollte ich schauen wie viele Tage meine schon durch läuft.. DTU nicht erreichbar. Gestern um 19 Uhr rum ausgestiegen. In der FRITZ!box wird sie aber als "online" angezeigt. |
Beta Was this translation helpful? Give feedback.
-
|
da hab ich noch gar njicht nachgeguckt. hab ich grad nachgeholt. Bis zum Firmwareupdate (12.06. 08:50) gab es quasi keine Aktivität im Netzwerk. kein Reconnect, kaum Roaming. Seit dem Update recht viel.
Ich probiere mal darauf zu achten, ob das Roaming vor oder nach dem Neustart passiert. Also, ob das Roaming eventuell der Grund für den Neustart ist, oder andersrum. |
Beta Was this translation helpful? Give feedback.
-
|
DTU ist jetzt plötzlich wieder online erreichbar. Hat heute aber erst 0,3 kWh eingespeist, also hat sie auch wirklich nicht gearbeitet. Habe die Protokollierung jetzt mal komplett auf "keine" gesetzt und schaue nachher mal nach. |
Beta Was this translation helpful? Give feedback.
-
Von wo ist der log genau? |
Beta Was this translation helpful? Give feedback.
-
|
Der log ist aus dem Netzwerk Controller. Ich verwende das System von Ubiquiti. |
Beta Was this translation helpful? Give feedback.
-
|
Wenn ich das mit dem Roaming sehe, kann es vielleicht dam WiFi liegen ich nutze LAN und habe NULL Probleme |
Beta Was this translation helpful? Give feedback.
-
|
Am WLAN selbst sollte es nicht liegen. Dort habe ich nichts geändert. Das WLAN und auch Roaming lief ja vorher super. Dennoch stürzt er jetzt ab oder startet neu. Aber, nicht immer. Zeitgleich zu den letzten beiden Einträgen (0:03 und 0:48) gab es auch Neustarts. ob diese nun die Ursache für das Roaming sind, oder die Konsequenz, kann ich leider nicht sagen. Dennoch: |
Beta Was this translation helpful? Give feedback.
-
|
ich meinte nicht das es an Deinem WiFi liegt, es könnte der Art liegen wie der ESP durch seine Programmierung das WiFi ansteuert. |
Beta Was this translation helpful? Give feedback.
-
|
was ich merkwürdig finde in dem Zusammenhang, ich bekomme jetzt ab und an: |
Beta Was this translation helpful? Give feedback.
-
|
sieht dann so aus |
Beta Was this translation helpful? Give feedback.
-
|
Gibt es irgendwo einen guide was die Protokollierungsstufen bedeuten? |
Beta Was this translation helpful? Give feedback.
-
|
Alles auf W und IDF auf E ist schon korrekt. |
Beta Was this translation helpful? Give feedback.
-
|
Hab heut versucht einen Log zu bekommen. Die DTU rebootet derweil seit ca 10 Uhr vormittags alle 10-30 Minuten. Was passiert da eigentlich und warum macht sie das? Bei wem ist das noch so? |
Beta Was this translation helpful? Give feedback.
-
|
Hast Du versucht Log über: |
Beta Was this translation helpful? Give feedback.
-
|
bitte was. |
Beta Was this translation helpful? Give feedback.
-
|
Du versuchst ein Log zu bekommen. |
Beta Was this translation helpful? Give feedback.
-
|
sorry verstanden |
Beta Was this translation helpful? Give feedback.
-
|
hier noch eins |
Beta Was this translation helpful? Give feedback.
-
|
hier noch zwei |
Beta Was this translation helpful? Give feedback.
-
Deine DTU startet sich neu, weil dein Inverter ums Verrecken nicht auf Kommandos reagiert. Hast du ihn vom Netz getrennt? Das wäre demnächst gefixt. Andernfalls (und ich vermute das trifft hier zu, weil deine Logs voll sind mit Nachrichten, die ich noch nie gesehen habe) hat dein hardwareseitiges Setup eine Macke, behaupte ich. |
Beta Was this translation helpful? Give feedback.
-
|
Hey. Die DTU lief seit gestern abend nun durch bis gerade eben. Jetzt geht das mit den Neustarts wieder los. Es ist so, daß ich gestern abend bereits versucht hab, den einen Inverter (der schlecht ansprechbar ist) per Hoymiles DTU vielleicht einen anderen Funkkanal zuzuweisen. Ich habs leider nicht geschafft. Der Inverter ist die meiste Zeit rot hinterlegt, Wenn allerdings ein Limit gesetzt wird, steigt er ganz normal ein und liefert. Ich hatte das Problem von Anfang an mit dem. Anfang des Jahres war ich noch mit dem SmartMicroSolar und normaler DTU unterwegs, da war alles normal. |
Beta Was this translation helpful? Give feedback.
-
|
Hier das klassische Bild, entweder gelb oder Rot. |
Beta Was this translation helpful? Give feedback.
-
|
Wenn einer von WR nicht mal mit originaler DTU erreichbar ist, würde ich ihn zunächst zurückschicken. Da ist etwas faul. Der Rest ist eine andere Baustelle. Immer ein Problem nach dem anderen lösen, wie beim Auto schrauben:-) |
Beta Was this translation helpful? Give feedback.
-
|
Ich hab die Frequenzen tagelang durch. |
Beta Was this translation helpful? Give feedback.
-
|
Wenn die WR nur an Marstek b2500 dran hängen mit allen 4 MPP-Trackern, dann wundert mich nicht, dass der bei DTU als nicht erreichbar gilt (rot hinterlegt in der Maske). Keine funk/ oder Spannung. Workaround: Meine Art damals, mindestens einen MPP-Tracker mit Solarmodul zu versorgen, dann spricht der HMS auch mit OpenDTU. |
Beta Was this translation helpful? Give feedback.
-
|
Hey. |
Beta Was this translation helpful? Give feedback.
-
|
Ist halt wie bei Politik: Kompromiss :-) Für mich heisst es, keiner ist zufrieden :-) DPL ist dann nicht zuverlässig, aber funktioniert tut es. Support von Jungs kann man nicht erwarten, Mangel an Baustellen haben die ja nicht :-) Du hast die Wahl, an RWE zu verschenken, oder über Marstek an Wärme verschenken; die Module, die Marstek versorgt, sind eigentlich Verlustgeschäft :-) |
Beta Was this translation helpful? Give feedback.
-
|
was ich dabei wirklich als komisch empfinde, ist die Tatsache, daß auch an WR3 nur Marstek hängen. Dieser ist jedoch immer erreichbar und hat eine 1a Funkstatistik |
Beta Was this translation helpful? Give feedback.
-
|
Wenn die verschiedenen Revisionen und Firmwarestände haben, reicht es, das der EMS/BMS andere logik befolgt. HMJ-Serie V4, Firmwarestand 100.8, funktioniert hier sauber mit Zeitprofilen und Bypass. Die HMA-Serie V3 mit Firmwarestand 228 ist zickig. Marstek versucht nun, andere Firmware zu installieren; wenn das nicht funktioniert, erhalte ich ein neues Gerät. So wurde es mit dem Support vereinbart. Edit: |
Beta Was this translation helpful? Give feedback.
-
|
Muss ein Lob aussprechen, bin sehr zufrieden. Läuft seit den Update 7 Tage durch. Reagiert schnell <=3 Sekunden. |
Beta Was this translation helpful? Give feedback.
-
|
Hab das heute nochmal beobachtet. Nichtsdestotrotz, es müsste ja noch mehr Leute geben die ein ähnliches Phänomen haben wenn alle MPPT mit V1 Speichern belegt sind, ob nun hm800 oder größer. |
Beta Was this translation helpful? Give feedback.
-
|
Ist zwar jetzt OT, ganze Marstek- und ODTU-onBattery-Reboot; es bezog sich meinerseits nur auf nicht erreichbare WR (rot hinterlegt) und den Marstek-Zusammenhang. Aber wenn einer die Marstek-BMS-Logik richtig verstanden hat und es öffentlich macht (nicht aus zweiter Hand, sondern wirklich durchleuchtet), bekommt er von mir 5 Kisten Bitburger oder eine Spende an das OpenDTU-on-Battery-Team im selben Wert. Das wird aber dauern, bis wann einer dahinter kommt:-) |
Beta Was this translation helpful? Give feedback.
-
|
kurzes Feedback nochmal meiner seits: die openDTU lief ja dann doch plötzlich, ohne dass ich dafür was gemacht habe (kein erzwungener Neustart, keine AC Trennung, oder so) gut durch, fast 24 Tage! nun ist sie aber doch am Montag abend neugestartet, und seit dem läuft sie wieder sehr instabil. 
aufgefallen ist es mir wieder daran, dass die Verbindung zum HMS abbricht, bzw. die eigentlich geänderte Frequenz scheinbar nach einem Neustart der DTU nicht berücksichtigt wird. (das einfache abspeichern der DTU Einstellungen genügt, wird das CMT Modul dadurch mit der hinterlegten Frequenz neu initialisiert?) ich hab die DTU heute morgen mal kurz vom Strom getrennt und neu gestartet. mal gucken, ob sie sich damit wieder fängt. |
Beta Was this translation helpful? Give feedback.
-
|
Nachtrag: hat nicht geholfen.... :( Also doch mal gucken, wie ich da per USB dauerhaft den seriellen Log mitschneiden kann... |
Beta Was this translation helpful? Give feedback.
-
|
@schlimmchen siehst du ne Möglichkeit, dass man über die Web-Konsole etwas brauchbares geloggt bekommt? ich hab hier bspw. einen Log bekommen Auszug: Log komplett
[08:27:33.816] I (5031416) hoymiles: Fetch inverter: 114183722749 
er ist scheinbar beim Abfragen des HMS-2000 ausgestiegen, zumindest kam das "success" nicht mehr. Konsole geht nach dem Neustart erst nach ~10s los |
Beta Was this translation helpful? Give feedback.
-
|
Interessant ist für mich vor allem dass abwechselnd NRF und CMT zwischen 0/1 alternieren. @spcqike komisch nur dass es in Deinem kurzen Auszug plötzlich (?) NRF 3/1 CMT steht. Wie kommt es dazu und warum nur ? |
Beta Was this translation helpful? Give feedback.
-
ist das nicht normal? Ich habe 2 wechselrichter. Einen HM-600 und einen HMS-2000. also ein NRF und ein CMT.
gute frage. Ich vermute da gab es kurz nach dem Neustart irgendwelche Hänger beim / zum HM-600. der log aus dem UI geht ja erst bei 10s Laufzeit los. Da gab es theoretisch schon mehrere Anfragen. Die ersten waren vielleicht erfolglos wegen der fehlenden Uhrzeit? Oder sowas. vermute ich. |
Beta Was this translation helpful? Give feedback.
-
|
hier noch ein Log, mit der Protokollierung "D"ebug Log
[07:31:15.553] I (72066611) hoymiles: Fetch inverter: 116492305207 Reboot[07:33:03.818] D (10971) hoymiles: RX Channel: 75 --> 95 83 72 27 49 83 72 27 49 89 00 01 27 10 A0 02 00 00 00 00 CB FE BD | -30 dBm Neustart um ~07:32:52.847. |
Beta Was this translation helpful? Give feedback.
-
|
@schlimmchen hilft das hier? Details
|
Beta Was this translation helpful? Give feedback.
-
|
@spcqike naja er scheint ein Problem mit dem aufräumen des Heap zu haben, was für einen ESP hast Du denn ? Die genaue Modellbezeichnung dürfte wichtig sein, damit man Dir sagen kann wieviel Memory das Ding hat ? Und beim anschließenden Neustart beschwert er sich über eine fehlerhafte flash config. |
Beta Was this translation helpful? Give feedback.
-
|
Das Fusion Board habe ich Das mit dem Flash Problem nach dem Neustart hab ich auch gesehen. Deswegen ja der komplette wipe und das neu flashen. Aber, da ist es komischer Weise so geblieben. 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
nachtrag, hier noch n Log von der Nacht. da ist scheinbar der gleiche Fehler, obwohl die Wechselrichter da gar nicht abgefragt werden (sollten) Details
D (18955898) powerMeter: [HTTP/JSON] New total: 394.80 assert failed: multi_heap_free multi_heap_poisoning.c:259 (head != NULL) Backtrace: 0x4037810a:0x3fcc2630 0x4037d669:0x3fcc2650 0x40384579:0x3fcc2670 0x40384191:0x3fcc27a0 0x40378981:0x3fcc27c0 0x403845a9:0x3fcc27e0 0x42133d89:0x3fcc2800 0x42134339:0x3fcc2820 0x4208e471:0x3fcc2840 0x4208a43b:0x3fcc2860 0x4208a447:0x3fcc2880 0x421521b6:0x3fcc28a0 0x421521c8:0x3fcc28d0 0x421521da:0x3fcc28f0 0x4215268f:0x3fcc2910 0x4215280d:0x3fcc2930 ELF file SHA256: 316f8dc98847c801 E (4725) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0 |
Beta Was this translation helpful? Give feedback.
-
|
sooooo. nach viel hin und her hab ich es endlich mal geschaft, das projekt noch einmal lokal zu compilieren und die .elf zu bekommen. liegt es doch nicht am CMT/HMS, sondern am HTTP(S) Powermeter? oder am Laptop, der grade den Log mit schreibt und die |
Beta Was this translation helpful? Give feedback.
-
|
@mathieucarbou can you take a short peek at the above stack trace ? |
Beta Was this translation helpful? Give feedback.
-
|
Lass die mal Jungs zuerst (Andreas, Bernhard, und wer noch dahinter steckt) Urlaub machen. |
Beta Was this translation helpful? Give feedback.
-
|
so, ich hab mal in dem Log alle Backtrace verglichen. es gibt 3 verschiedene. bei allen 3n komm ich am Ende auf http(s) powermeter hab ich aus, also wird es wohl der zugriff per webUI sein. ich schließe mal alle tabs und lasse sie aus. Auch, wenn ich eigentlich nicht dachte, dass |
Beta Was this translation helpful? Give feedback.
-
|
Das kannst Du ggf. mit F12 / Developer Tools im Browser dir genauer ansehen, ob und was die GUI macht. Ich habe mal die o.g. Fehlermeldung Laut KI sind es wohl häufige memory alloc/dealloc Operationen durch den Einsatz von String Klassen die zum korrupten Heap führen. Lösungs-Vorschlag von der KI war anstelle der Strings |
Beta Was this translation helpful? Give feedback.
-
|
hab es nun die Nacht durch ohne aktiver Browsersession laufen lassen. gleiches Ergebnis. Ich verstehe nicht, was da im Hintergrund laufen soll.... ich werd nochmal versuchen das DIng komplett neu aufzusetzen, in der Hoffnung, dass Was mich auch wundert: Was mir auch auffällt. Wenn die dauernden Reboots da sind, habe ich auch viele andere PRobleme. Bspw. kommt im Log der Wechselrichter dann ständig dieser "Zeitabgleich" und der Empfang vom HMS ist sehr gestört. Das mit dem HMS schiebe ich mal noch auf den Punkt, dass ich quasi immer die "DTU Einstellungen" neu speichern muss, bevor die geänderte FRequenz auch genommen wird und es rund läuft. und, scheinbar bin ich der einzige, der diese Probleme so hat? kann das sein :O Demnach muss es ja irgendwie an der Hardware liegen... |
Beta Was this translation helpful? Give feedback.
-
|
kurzes Update. laut ChatGPT könnte es ein Problem mit meiner Art des Zugriffs auf die Weboberfläche sein. ich verwende normalerweise einen lokalen nginx und öffne die Seite eben per lokaler domain. Um das zu testen habe ich alle browser tabs mit der domain geschlossen (also, aufm Rechner und Handy) und direkt die IP aufgerufen. Das sah bis diese Nacht auch ganz gut aus, allerdings stürtzt es so trotzdem auch ab. Der Rechner war seit Tagen aus, kann also so oder so keine Anfragen senden. der Tab auf dem Handy ist im Hintergrund quasi immer da, sollte aber eigentlich auch nur laufen, wenn man ihn aufruft, oder? 
langsam weis ich nicht mehr, woran es noch liegen könnte und was ich anders machen kann.... :( jemand ne Idee? |
Beta Was this translation helpful? Give feedback.
-
|
@stefan123t : it is not clear which versions of AsyncTCP and ESPAsyncWebServer are used, but there has been recently a memory leak found and fixed in latest version of AsyncTCP: everybody should switch to AsyncTCP v3.4.7. Also, another leak was found but this time caused by firefox sending on the background ssl request on http endpoint. this was fixed in ESPAsyncWebServer main branch along with other improvements. I would suggest to switch to:
I will release a new ESPAsyncWebServer version this morning (v3.8.0). note: please test v3.8.0 carefully before because there has been some changes around gzip content encoding and although tested on main for several weeks, there are a few behavior changes (like default content type set, etc). Upgrading only AsyncTCP should be enough to fix the memory leaks found I think. |
Beta Was this translation helpful? Give feedback.
-
Thanks! Kudos to @JosePineiro for all his hard work on gzip, etag, etc. Regarding the DoS attack prevention / limit, this can be implemented with a middleware. There is a |
Beta Was this translation helpful? Give feedback.
-
|
After a few hours of tinkering I managed to compile the firmware against ESPAsyncWebServer 3.8.0. To get it building, I temporarily disabled I’ll update OpenDTU now and monitor whether the unexpected reboots still occur. |
Beta Was this translation helpful? Give feedback.
-
|
@spcqike great 👍, you managed to compile it with the latest ESPAsyncTCP and ESPAsyncWebServer. The ESPAsyncTCP has an updated What are these settings in OpenDTU-OnBattery ? We seem to double the Queue Size but keep the 5 second timeout as we do not change @schlimmchen is your comment in this ODoB discussion suggesting to use a 1 second MQTT and PowerMeter Update Interval for this purpose ? Disabling (commenting out ?) the |
Beta Was this translation helpful? Give feedback.
-
|
IMHO neither CONFIG_ASYNC_TCP_* Parameter will take effect, as they are called ASYNC_TCP_* and also ASYNC_TCP_EVENT_QUEUE_SIZE does not exist. |
Beta Was this translation helpful? Give feedback.
-
|
Short update: it’s running since the update. So 1d 17h and counting. Longest uptime in a month! 🎉 edit: |
Beta Was this translation helpful? Give feedback.
-
|
Guten Tag. Ich hab das mit den reboots jetzt mal so weiterlaufen lassen. Ärgerlich ist, daß jeden Tag dasselbe Bild ist. Die DTU läuft bis etwa spät nachmittag durch. Dann beginnen die Reboots. Leider ist es oft so, daß dies so schnell und lang hintereinander passiert, daß die WR am oberen Limit hängenbleiben und die Batterie bis Mitternacht alles ins Netz speist. Mitternachts dann ist der Spuk vorbei und alles läuft wieder normal. |
Beta Was this translation helpful? Give feedback.
-
|
Also ich kann dazu berichten, das die Release-Version so lange läuft, bis ich auf die Weboberfläche zugreife und irgendwas machen will, dann startet die DTU einmal neu. Danach dauert es Stunden/Tage bis sie beim Aufrufen wieder neu startet. Wenn ich da nicht rauf gehe, dann würde sie Wochen ohne Probleme laufen. Da ich Grafana in Verbindung mit HA nutze, wird ein Zugriff meinerseits eher selten benötigt. |
Beta Was this translation helpful? Give feedback.
-
|
das Gefühl hatte ich anfangs auch. allerdings gucke ich selten (um nicht zu sagen nie) nachts aufs WebUI, und dennoch stürzt meine openDTU mit der aktuellen master Version nachts regelmäßig ab. Wenn es in meinem Fall wirklich am ESPASyncWebServer liegt, bzw. vom ASyncTCP, der ja scheinbar auch bei vom MQTT Dienst verwendet wird, und wahrscheinlich auch vom HTTP(S) Powermeter, und nicht nur vom WebUI, erklärt sich mir das auch :) Bisher läuft sie seit bald 5 Tagen durch. Ich hoffe einfach mal noch, dass es auch wirklich am ASyncTCP liegt, und der Fehler in der neuen Library raus ist. |
Beta Was this translation helpful? Give feedback.
-
|
Ich kann leider erst am Wochenende testen ... |
Beta Was this translation helpful? Give feedback.
-
|
Moin, |
Beta Was this translation helpful? Give feedback.
-
These issues are history now and gone. Since I took over the maintenance of these libs and we moved them in the ESP32Async org with me-no-dev (the Arduino Core lead developer), a lot of contributions and fixes were made to improve stability and perf. The WLED maintainer (Will) is also helping a lot - and he is highly skilled! Also, Firefox is not kind with MCU because each time an http request is made to a mcu, firefox also triggers a bunch of SSL requests on the background to try access this same http port with a secured connection, which leads to many connections opening trying to do a ssl handshake over a normal http endpoint. These impact the the MCU perf. That's what Firefox calls HTTPS-Only mode. That's good for general use case when browsing over internet because it will make FF switch automatically to a ssl connection if available instead of using a non secured one, but for local development or little MCU projects like that, this is a pain. To my knowledge, only FF does that, I never saw that with Chrome and Safari. Most perf issues and crashes with these libs are caused by inappropriate usage. Users often do nasty things in the asyn_tcp task callbacks without any regard of the asynchronous nature of the libs. |
Beta Was this translation helpful? Give feedback.
-
|
Habe gestern auch diese Firmware Version aufgespielt. |
Beta Was this translation helpful? Give feedback.
-
|
Ja ok .. Aber was ich auf jeden Fall noch sagen kann, bei mir wird sehr häufig die Zeitsynchronisation ausgeführt. Da stehen dann schon mal pro WR 15 Synchronisationen drin. Das dürfte auch nicht normal sein. Hab da aber schon verschiedene Server getestet. Alle ohne nennenswerten erfolgt. |
Beta Was this translation helpful? Give feedback.
-
|
Die Meldungen zur Synchronisation habe (hatte) ich auch. Ich weiß allerdings nicht, ob sie das System zum Absturz gebracht haben oder ob sie nach einem Neustart des System kommen. Ich weiß nur: wenn ich die häufigen Neustarts habe, habe ich auch viele Zeitsynchronisationsmeldungen zu beiden wechselrichtern. Jetzt wie gesagt keine. Bisher läuft es stabil (nur leider weiß ich trotzdem noch nicht ob auch die neue Library daran „schuld“ ist. Immerhin habe ich diese Diskussion gestartet weil ich viele viele Neustarts hatte. Dann lief es aus dem nichts heraus nen guten Monat stabil. Und dann fingen die Probleme ebenso spontan wieder an. Vielleicht ist es ja auch hier nur reiner Zufall ….. da meine backtrace jedoch in die Richtung zeigen, denke ich schon, dass da was dran ist. Wenn auch nur ein bisschen :) ) |
Beta Was this translation helpful? Give feedback.
-
|
Waren die Zeitsynchronisationsprobleme jemals in Griff? Ich kenne OpenDTU on Battery fast gar nicht ohne diese Meldung, :-) bei jedem WR 10-15 mal pro Tag. Zusammenhängende Probleme damit könnte ich als wenig Kenner von Code aber nicht erkennen. Ich dachte immer, es muss so sein 😀, und es hat seine Richtigkeit. |
Beta Was this translation helpful? Give feedback.
-
|
Also in Firmware Versionen vom letzten Jahr waren Zeit-Server Probleme bei mir bei weitem nicht so stark ausgeprägt wie jetzt .... |
Beta Was this translation helpful? Give feedback.
-
|
Also Alarm Code 2 ist ein Time Synchronisation Problem zwischen DTU und dem Wechselrichter. Die RealTimeRunData Anfragen um zB den aktuellen Ertrag / die Leistung zu erhalten, die enthalten einen Zeitstempel der DTU für den WR. Und wenn es zu Kommunikationschwierigkeiten zwischen DTU und WR kommt dann vermerkt der WR in seiner Event Liste die o.g. AlarmCode 2 Events. Das ist nicht schön aber auch micht tragisch, da es idR nur ein vorrübergehendes Problem ist. Die Events werden auch schneller durch das Event Log durchgereicht, dh. andere, wichtigere Events können die AlarmCode 2 Events überschreiben und überdauern. Hier geht es aber ausschließlich um das Problem von @spcqike was einen Absturz der OpenDTU Software zur Folge hatte, weil der Speicher nicht mehr ausreichend war. Dazu wurde eine neue Firmware gebaut, die eine neuere und aktuellere ESPAsyncTCP und ESPAsyncWebServer verwenden die ein paar Verbesserungen zum Memory Management enthalten. Also bitte beim Thema bleiben und für allgemeine Diskussionen einen passenden / eigenen Thread aufmachen oder im Discord sich austauschen. Danke ;) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Mahlzeit,
ich wollt einfach mal in die Runde fragen, ob die neue Firmware bei euch stabil läuft oder ob ihr auch ständige Reboots beobachten könnt.
die letzte Version lief bei mir super durch, zuletzt bis zum Update waren es 33 Tage am Stück.
die neuste Version läuft teilweise nur wenige Stunden, bis hin zu < 1h.
in HA sieht es aktuell so aus:
hier nur ab dem 13.06.
wie gesagt, bis zum Firmwareupdate lief es 33 Tage. Die Aufzeichnung in HA hat leider keine älteren Daten :D
seit dem Update läuft sie recht instsabil.
Ich hab noch nicht näher geguckt, woran es genau liegt. also kein USB Log oder so gezogen.
Aufgefallen ist mir das jetzt, da mein HMS-2000 nach einem Reboot der openDTU keine Verbindung aufbauen kann. Ich musste die Frequenz ändern, damit eine stabile Verbindung kommt. Leider vergisst die openDTU das scheinbar nach einem Reboot, so dass ich den Reiter "DTU" jedes mal einfach neu speichern muss. anschließend funktioniert die Kommunikation wieder prima, bis zum nächsten Reboot.
hier am 11.06, noch vor dem Firmwareupdate, saubere Laufzeit, saubere Kommunikation
hier der 12.06., das Update um 8:51. direkt im Anschluss fehlt die Leistung des HMS-2000, bis ich 8:58 den Reiter "DTU" erneut gespeichert habe. Im Laufe des Tages gab es bereits mehrere Neustarts, am Abend nach dem kam dann keine saubere Übertragung mehr zu Stande.
hier sieht man bspw. mehrere nächtliche Neustarts und eben viele Abrisse in der Kommunikation zum HMS.
der HM-600 kann normal erreicht werden.
Das Problem mit der schlechten Verbindung nach einem Reboot habe ich gefühlt schon immer. Seitdem ich nicht mehr die Standardfrequenz am CMT verwende. Das war jedoch kein großes Problem, da die openDTU halt monatelang stabil lief.
seit 2025.06.11 stürzt sie (un-)regelmäßig ab.
zum Setup:
ich hab das FusionBoard
Die 2 Wechselrichter (HMS und HM), beide rein solarbetrieben, der DPL ist im Moment aus (also auch keine erzwungenen Reboots der openDTU, weil der HMS-2000 nicht erreicht oder geregelt werden könnte).
Keine Batterie, kein VE.direct, nichts.
Das Powermeter ist ein Shelly 3EM der per HTTP(S)+JSON aller 5s abgefragt wird. das läuft soweit ich es sehen kann auch sauber.
die DTU fragt mit einem Intervall von 2s ab.
MQTT steht auf 5s Intervall.
die neue Protokollierung steht auf (E) Fehler
Wie sind eure Erfahrungen? Läuft die Firmware genauso stabil wie die alten? Oder sehr ihr ein ähnliches Verhalten wie ich?
Bevor ich bei mir alles auseinander nehme, ggf. neu flashe oder gar im Keller ein USB Logging Setup aufbaue, wollt ich einfach mal in die Runde fragen, wie es da so aussieht :D
Grüße
Beta Was this translation helpful? Give feedback.
All reactions