OpenDTU nicht mehr über Netzwerk erreichbar #928
Comments
Es gibt mit Es gibt aktuell auch noch #836. Weiß nicht ob das deinem beobachteten Verhalten entspricht. |
|
Ich habe genau das gleiche Verhalten wie oben beschrieben. Ich verwende auch die Version v23.5.9. Nach einigen Tagen wird die Web-Oberfläche langsam und reagiert dann gar nicht mehr. Bei mir ist MQTT deaktiviert. Ich verwende das API "/api/livedata/status" um die vier angeschlossen Wechselrichter auszulesen, 3 x HM-800 und 1x HM-400. Da ich HM Wechselrichter verwende habe ich nur ein NRF Module verbaut. Display ist keines angeschlossen. Meistens funktioniert der API call noch einige Zeit nachdem die Weboberfläche den Geist aufgegeben hat, allerdings mit deutlich langsamer Antwortzeit. |
Das würde aber dann mehr nach #836 aussehen... |
|
Ich vermute das beides die gleiche Ursache hat. |
|
Die Meldungen aus #836 hatte ich auch in der Vergangenheit bei einem der drei Inverter gesehen, aber nicht bei meinem gemeldeten Bug, da hatte ich gar keine Möglichkeit die Oberfläche aufzurufen. Aber Danke für die Hinweise bezüglich, dtu/uptime oder [serial]/status/last_update. |
|
Problem besteht auch bei mir. |
|
Definiere nicht erreichbar. Reagiert der Host auf Pings? Geht das Webinterface nicht? Geht MQTT nicht? |
Sorry für die unpräzisen Aussagen im letzten comment |
|
In der Version v23.5.23 hab ich nochmal potentiell kaputten Speicher behoben. |
|
Ich hab scheinbar auch dieses Problem. Habe nur ein nRF Funkmodul dran, ein inverter cofiguriert; Version: v23.5.22 |
|
Dann wäre die Ausgabe auf der seriellen Konsole interessant. |
dazu müsste ich einen Rechner via USB anschließen, das trennt die Stromversorgung und "behebt" "leider" das Problem. |
|
Hatte das gleiche Problem jetzt auch schon zwei mal, im Abstand von ca. 2 Wochen. Kurzes deaktivieren des WLAN am Router hilft. Leider habe ich auch keine Möglichkeit, über USB auf die Konsole zuzugreifen, die DTU ist remote verbaut und nur per VPN erreichbar. Beim ersten MAl kannte ich den WLAN-Trick nicht, da hat sich das Problem nach ca. 1 Stunde von alleine gelöst. |
|
Ich habe wahrscheinlich das gleiche Problem. Die Oberfläche lädt nicht mehr und per ping komme ich auch nicht mehr an das Gerät. Scheint also aus dem WLAN geflogen zu sein.. Ich habe mitbekommen, dass sich das ganze (meist) von alleine erholt (und keine Neustart des Gerätes nötig ist). Irgendwann ist die WLAN Verbindung wieder aktiv und man kann wieder zugreifen. Ich habe kein Display angeschlossen und nur ein Inverter registriert. |
|
Interessant, also scheine ich nicht alleine zu sein. Wenn ich weitere Daten liefern kann, meldet Euch |
|
Ich habe bei 2 von 3 Installationen (verschiedene Häuser) das gleiche Problem:
>> openDTU läuft also lokal scheinbar weiter. Eingesetzte Hardware:
Fehler 1 tritt mit einem HM-700 auf. WLAN-Netzwerk (Fritzbox 7530) ist dort sehr stabil und guter Empfang (-50dBm) In beiden Netzen sind noch weitere ESP32/ESP8266 unterwegs, die stabil laufen. Daran kann es also nicht liegen. Getestet bzw. Fehler sind bisher mit allen 23.6.x Versionen aufgetreten. Die 3. Installation (identische HW, auch ein HM-1500 und mit Unifi AP 6), aber deutlich schlechterem WLAN (-70dBm bis -75dBm) läuft seit Wochen super stabil und hat zwischendurch auch mal Updates bekommen. |
|
Der ESP32 Chip hat wohl sehr oft Probleme mit dem WLAN. Ich habe dieses Problem auch. Es scheint ein Problem mit den WLAN Kanälen zu geben. Das ist bei Mesh natürlich schlecht, wenn der WLAN Kanal sich ändert. Ich habe bei mir die Erfahung gemacht, dass der ESP32 nur gut mit WLAN Kanal 1 funktioniert. In Summe steht das Projekt auf wackeligen Beinen, wenn ich mir so die Probleme ansehe. |
|
Hallo, ich denke, es könnte an einem Speicher-Problem liegen. Ich hatte keine "eingefrorene/nicht erreichbare" WebUI bis ich eines Tages die mqtt-Anbdinung aktiviert hatte.
Meine Lösung: das Intervall für die mqtt-Anbindung erhöhen, z.B. auf 60 Sekunden. @tbnobody könnte man den default Wert für das Aktualisierung-Intervall auf 60 Sekunden erhöhen ? Minuten-genaue Werte sollte die meisten use-cases abdecken, oder ? |
|
Gleiches Problem bei mir. Hier ein paar Infos:
Nachtrag;
|
|
Nachdem OpenDTU anfangs wieder Probleme hatte (siehe Nachtrag vorheriger Post), läuft er nun über eine Woche zuverlässig. Das Web-GUI hat immer schnell reagiert, sämtliche Daten scheinen an den MQTT Server übermittelt worden zu sein. Da die aktuelle Position der OpenDTU im Raum nur provisorisch ist, werde ich eine weitere Stelle im Haus testen und berichte dann wieder. |
|
Ich habe die gleichen Probleme wie oben beschrieben. Nach ein paar Tagen ist kein Zugriff über Web mehr möglich. Wenn ich allerdings den WLAN Kanal fest auf Kanal 1 Stelle funktioniert es dauerhaft. |
|
Auch ich möchte mich der genannten Problematik mit anschließen. SDK-Version v4.4.4 |
|
Nach über 4 Wochen stabilen Betriebs an der provisorischen Position, läuft OpenDTU seid 2 Tagen auch an einer Position zuverlässig, die nun der dauerhafte Platz werden soll.
Ich bin kein Fachmann was das betrifft, aber bei Position 2. und 3. ist kein Bluetooth in der Nähe. |
|
Nachtrag zu meinem Problem mit der Erreichbarkeit (#928 (comment)) Augenscheinlich, wenn der ESP32 sich über einen Accesspoint mit dem WLAN (Fritz Mesh) verbindet kommt es nach einer gewissen Zeit zu den genannten Problemen. Zeit bis zum Auftritt ist willkürlich, von wenigen Stunden bis hin zu mehreren Tagen war schon alles dabei. Während der nicht Erreichbarkeit ist der ESP32 laut FritzBox online und hat seinen Zugangspunkt geändert. Abhilfe mit momentaner erkennbarer Verbesserung ist die Positionierung vom ESP32 unmittelbar bei der FritzBox. Dadurch wählt sich der ESP32 direkt in das WLAN von der FB ein und ist derzeit stabil erreichbar. |
|
Ich habe nun auch eine ähnliche Beobachtung gemacht, die @Linos88 in seinem/ihrem letzten Kommentar genannt hat. Der ESP32 ist bei mir nun in einem Fritz Mesh und macht wieder Zicken. |
|
Ich gebe auch nochmal ein Update. Bei mir ist der ESP32 mittlerweile durchgeängig erreichbar. Bei mir lag es wohl an dem Fritz.Repeater (mit Mesh), der ab und zu das Signal zum Router verloren hat. Ich habe den Repeater jetzt auf eine Kabelverbindung umgestellt, und seitdem habe ich keine Probleme mit der Konnektivität des ESP32. Ich vermute allerdings, dass das ganze eher ein Zusammenspiel zwischen Verbindungsabbrüchen zwischen Repeater zu Router und dem ESP32, der wohl mit kurzen Aussetzern nicht klarkommt, ist. Denn kein anderen Gerät was vorher mit dem Repeater verbunden war, hatte solche Probleme. |
|
@FrodoVDR kannst Du noch etwas zu Deinem WLAN Netzwerk schreiben. Einige der Anderen haben ja konkret Fritz!Box mit Mesh Funktion erwähnt. Es gibt dazu m.W. schon länger Berichte zu Problemen mit dem Wechsel vom Router zu einem Access Point der evtl. kurzzeitig besser zu empfangen ist. Offenbar kann das der TCP/IP Stack des ESP32 nicht so gut ab und verhaspelt sich da ab und zu. Um solche Probleme genauer nachvollziehen zu können braucht es zwingend USB Serial Console Logs von der OpenDTU am Übergang von "geht" zu "geht nicht" und möglichst viele Hintergrund Infos zum WLAN. Auch die MQTT Bibliothek hatte m.W. in der Vergangenheit Schwierigkeiten mit dem Konstruktor wenn die WLAN Verbindung mal weg war, wurde der nämlich nicht zwingend neu initialisiert. Aber das ist m.W. bereits seit längerem behoben. |
|
Habe leider auch das Problem, dass sich der ESP32-Chip mit OpenDTU immer wieder aufhängt. Wlan ist fest auf 1 Kanal, kein Mesh. Nervig
|
|
Ich habe genau das gleiche Problem wie von @FrodoVDR beschrieben. Gibt es mittlerweile einen Workaround? |
|
@MatzeX71 @Powermaniaxx leider kann man mit den bisher verfügbaren Logfiles nicht wirklich das Problem des WiFi Stacks auf dem ESP32 analysieren bzw. dessen Ursache lokalisieren. Dazu sind Eure Angaben bzgl. “Ich habe das selbe Problem” leider zu ungenau. In #2184 und #2185 hat @jstammi einige Hinweise gegeben was wir benötigen um Euer Problem besser eingrenzen zu können. Es scheint wohl mit Fritz!Mesh und dem Verbinden mit dem “besten” Access Point durch OpenDTU zusammen zu hängen, aber Näheres ist noch nicht bekannt. |
|
Bei mir ist die DTU vom Router plötlich nicht mehr erreichbar. Taucht auch in der Netzwerk- Liste des Routers nicht mehr auf. Erst nach Router Neustart. DTU- Hardware ist geblieben, Router ist geblieben. |
|
Die DTU verbindet sich immer noch nicht mit dem Router. Ping ist ebenfalls nicht erfolgreich. Die manuell heruntergeladene Konfig der OPEN DTU scheint nicht aktuell zu sein. |
|
@OttiNC1 die Ursache des Problems ist bisher leider noch unbekannt. Die bisher stärkste Vermutung ist, dass es am Fritz Mesh liegt. Eindeutig validiert werden konnte dies bisher aber nicht. Es scheint aber als sicher, dass der ESP32 Chip auf etwas externes sensibel reagiert. Am besten, wenn noch nicht geschehen, diesen Thread einmal vollständig lesen und nach Möglichkeit am eigenen Netzwerk und Ort der Hardware auf der OpenDTU läuft, zu experimentieren. Aktuell wird dir hier keine konkrete Lösung genannt werden können. Vielleicht hilft dir folgendes... Nach einigen weiteren Monaten nochmal ein Update von mir:
Wer die genannten Probleme dieses Threads hat, sollte, zumindest testweise, den ESP32 mit OpenDTU an einen entlegenen Ort von anderer Hardware positionieren. Bei mir hat dies die Symptome drastisch minimiert. Falls dies auch bei anderen hilft, sollten diese in Erwägung ziehen hier ein kurzes Feedback zu hinterlassen. |
|
We need Logfiles for the issue to be traceable by either support / developers. Follow the link to the documentation to setup for USB / serial logging: |
What happened?
Ich habe das Problem das nach einigen Tagen keine Nachrichten per MQTT gesendet werden und die Oberfläche dann auch nicht mehr erreichbar ist. Ein angeschlossenes Display liefert weiterhin Daten.
Ein restart durch kurzes trennen der Stromversorgung behebt das Problem sofort.
Ich verwende OpenDTU mit dem CMT Modul und einem I2C Display (3 HMS Inverter). Bei Verwendung von CMT und NRF tritt der Fehler häufiger auf.
Deshalb habe ich bereits eine zweite DTU am laufen die nur NRF ohne Display nutzt, dort gab es bisher keine Aussetzer. Scheinbar hat das Problem was mit der CMT Implementierung zu tun oder mit der größeren Anzahl von Invertern.
Leider kann ich anhand der MQTT Daten nicht sehen ob die DTU noch Daten sendet "is_valid = 1" ändert sich nicht mehr wenn die DTU nicht erreichbar ist.
To Reproduce Bug
Ich weiß nicht wie man den Fehler nachvollziehen könnte, scheinbar habe nur ich das Problem.
Expected Behavior
Ich würde mir wünschen das die DTU zusätzlich per MQTT einen Timestamp liefert, am besten in Unixtime. Dann kann man eine Abfrage z.B. in Node-Red erstellen ob die Daten noch aktuell sind und gegebenenfalls die DTU restarten.
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
v23.5.9
Relevant log/trace output
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: