Live-Daten in Version 0.1.19 werden nach einiger Zeit nicht mehr angezeigt about opendtu HOT 22 CLOSED

Glaube ich hab den Fehler gefunden. Sollte hier gefixed sein: 80f7ba8

Ggf. bitte um Rückmeldung ob das jetzt noch auftritt.

from opendtu.

Off-Topic: Ich überlege ob man das als Library "umverpacken" kann (natürlich ohne das Webinterface)

Das komplette Hoymiles Interface ist als Library implementiert. Der RF Teil sowie alle Commands, Parser usw. liegen alle unter lib/Hoymiles. In den anderen Ordnern liegt nur der Kram um ein Interface nach außen zu generieren.

from opendtu.

Passiert das auch, wenn nur ein Stick läuft?
Wenn ich zwei parallel laufen lasse, stören sich auch beide gegenseitig.

from opendtu.

Ja, der Fehler passiert auch bei nur einem laufenden ESP.
Den zweiten ESP hatte ich nur zur Veranschaulichung angeschlossen - sonst läuft bei mir nur einer.

from opendtu.

Hallo und Herzlichen Dank für dieses wunderschöne Tool!

Gestern habe ich ein Update auf die Version 0.1.19 gemacht. Seit dem gibt es allerdings Probleme mit den Live-Daten. Diese werden nach einer gewissen Zeit nicht mehr angezeigt. Ein Reload der Seite hilft nicht. Einzig ein Restart des ESP scheint zu helfen.

Bei der Version 0.1.18 tritt dieser Fehler nicht auf.

Hierzu habe ich ein Video gemacht, auf dem beide Versionen parallel zu sehen sind (2 ESPs). Links: Version 0.1.19 / Rechts Version 0.1.18

Der Fehler ist ab Minute 2:30 zu sehen

Im Serial-Log wird kein Fehler dazu ausgegeben.

Das Update von 0.1.18 auf 0.1.19 habe ich zunächst per OTA durchgeführt (Settings / Firmware Upgrade). Nachdem ich den Fehler bemerkt hatte, habe ich die Firmware noch einmal direkt geflasht. Auch ein löschen des .pio Verzeichnis, kompletter re-build und erneuter upload haben nicht geholfen.

Gruß Sivar2311

Habe exakt dasselbe Problem.

from opendtu.

Ich hatte das Problem hier bisher einmal. Aber habe es heute über den Tag beobachtet und auch bei einer Uptime von >23h trat es nicht mehr auf. Ich habe aber die Erfahrung gemacht, das es speziell nach einem neu-flashen des ESPs auftritt wenn zur gleichen Zeit noch die WebGUI offen war. Nicht das hier im ESPAsyncWebserver und den WebSockets etwas durcheinander kommt.
Wenn das Problem auftritt, was sagt denn die Heap anzeige (Info --> System) in diesem Moment?

from opendtu.

Der war m. E. nicht auffällig.
Genaue Werte kann ich allerdings erst morgen wieder liefern.

from opendtu.

Interessant wäre in diesem Zusammenhang (neben den Heap Daten) dann ebenfalls der Git-Hash der auf der System Seite angezeigt wird.
Hast du MQTT aktiv?

from opendtu.

Nein, MQTT nutze ich (bisher) noch nicht.
Git-Hash ist 778cce2

from opendtu.

Der Fehler tritt auch auf, wenn noch keine Verbindung zum HM besteht - also kann ich doch schon Werte liefern:
Version 0.1.19 zum Zeitpunkt des Fehlers:

Zum Vergleich was der ESP mit 0.1.18 anzeigt:

Beide ESP's wurden ungefähr zur selben Zeit heute morgen eingeschaltet.

from opendtu.

Hm ich muss noch etwas mit Fragen nerven um das genau nachzuvollziehen.
@docklugscheiss verwendest du MQTT?

Aber das Bild mit dem erhöhten Heap verbrauch hatte ich mir schon gedacht. Die Frage ist wo es herkommt.
Nachdem im Serial Log keine Meldung bzgl. "Too many messages queued" erscheint (käme vom WebSocket Server) würde ich das ausschließen.

Die einzige relevante Änderung die zwischen den beiden Versionen eingeflossen ist, ist eigentlich der wechsel des MQTT Clients damit dieser TLS unterstützt.
12df602...778cce2

Du meinstest oben um 5:xx Uhr, das beide ESPs heute morgen zur gleichen Zeit eingeschaltet wurden. Ich würde daraus schließen das das Problem relativ schnell auftritt? (Frage für eine Nachvollziehbarkeit, wenn ich bei mir MQTT deaktiviere)

Hattest du den Source selbst kompiliert oder ein fertiges .bin verwendet?

from opendtu.

Hilft zwar nicht, aber ich verwende MQTT und die neueste Version und habe dieses Problem nicht

from opendtu.

Hilft zwar nicht, aber ich verwende MQTT und die neueste Version und habe dieses Problem nicht

Hilft auf jeden Fall wenn @docklugscheiss sagt das er kein MQTT verwendet. Dann gibt es nämlich ein Problem bei deaktiviertem MQTT und ich weiß eher wo ich suchen muss :)

from opendtu.

Hallo Zusammen, ich verwende MQTT nicht.

Danke, dass ihr an dem Thema dran seid. VG!

from opendtu.

Hallo,

habe das gleiche Verhalten (noch keine WR in Betrieb).
Der Heap sieht hier im Zeitverlauf so aus:

20 min = 43% OK
34 min = 46% OK
38 min = 47% OK
42 min = 48% OK
46 min = 49% OK
49 min = 50% OK
52 min = 51% OK
56 min = 52% OK
60 min = 53% OK
64 min = 54% OK
68 min = 55% OK
78 min = 57% nur noch Buttons da
80 min = 58% ab hier kommt nix mehr
82 min = 59%
86 min = 59%
87 min = 60%
91 min = 61%
96 min = 62%
98 min = 63%
102 min= 64%
118 min= 68%
127 min= 71%
144 min= 76%
172 min= 79%
175 min= Absturz, Webserver/Ping anwortet nicht mehr

Vielleicht hilft das was.

Grüße an die Programmier-Helden

from opendtu.

@MG850 hast du aktuell MQTT aktiviert?

from opendtu.

MQTT ist nicht aktiviert.

from opendtu.

Du meinstest oben um 5:xx Uhr, das beide ESPs heute morgen zur gleichen Zeit eingeschaltet wurden. Ich würde daraus schließen das das Problem relativ schnell auftritt? (Frage für eine Nachvollziehbarkeit, wenn ich bei mir MQTT deaktiviere)

Als der WR heute früh noch inaktiv war, hat es bei mir auch wesentlich länger gedauert, bis der Fehler aufgetreten ist.
Wenn der WR aktiv ist und Antworten sendet, dauert es nur ein paar Minuten.

MQTT hatte ich versucht zu konfigurieren, aber der Hostname war länger als die max. erlaubten Zeichen. Es ist bei mir also eine halbe MQTT Konfiguration vorhanden, aber nicht aktiv.

Hattest du den Source selbst kompiliert oder ein fertiges .bin verwendet?

Selbst kompiliert.

Nebenbei bemerkt: Du hast einen sehr schönen Programmier-Stil! Gefällt mir richtig gut! 👍
Off-Topic: Ich überlege ob man das als Library "umverpacken" kann (natürlich ohne das Webinterface)

from opendtu.

Glaube ich hab den Fehler gefunden. Sollte hier gefixed sein

Erster Test sieht sehr gut aus!
Der WR bekommt um diese Zeit (20:55 Uhr) gerade noch genug Saft und sendet fleißig Antworten :)
Der Heap-Wert pendelt zwischen 37% und 38%.

Das komplette Hoymiles Interface ist als Library implementiert.

Perfekt, dann werde ich mich mal diesen Teil des Sourcodes bedienen und damit ein wenig spielen :)

from opendtu.

... auch bei mir kann ich vermelden: funktioniert nun tadellos. Danke an das Fixing - und auch für die Mühe und Arbeit, die im gesamten Thema steckt! (und wenn die Leistungsreduzierung in OpenDTU funktioniert, mache ich Luftsprünge!)

from opendtu.

Dann mache ich den Issue hier erstmal zu...

from opendtu.

Sorry, bin gerade erst wieder zu Hause.
Bisher sind keine weiteren Probleme aufgetreten. Vielen Dank für den schnellen fix!

from opendtu.