ESP RGBWW Controller - Firmware v5

[vbs]

Der freie Heap ist Teil des Info-Datenblocks (/info) und ist dann auch in FHEM als Reading "info-heap_free" verfügbar. Das ist zumindest in der vbs-FW so, aber vermutlich hier dann auch noch?
Damit könnte man ein bisschen sehen, ob da Memory geleakt wird oder so. Hilft halt nur nix, falls es da nen spontanen, größeren Spike gibt, der den Controller killt.

[pjakobs]

Der freie Heap ist Teil des Info-Datenblocks (/info) und ist dann auch in FHEM als Reading "info-heap_free" verfügbar. Das ist zumindest in der vbs-FW so, aber vermutlich hier dann auch noch?
Damit könnte man ein bisschen sehen, ob da Memory geleakt wird oder so. Hilft halt nur nix, falls es da nen spontanen, größeren Spike gibt, der den Controller killt.

gute Idee!
Den zeigt das Frontend auch unter System settings / System Information an - wenn der unter 10kB fällt wird es kritisch, weil es dann oft nicht mehr genug Speicher ist, um die nötigen Buffer für ip Pakete anzulegen
Du darfst diesen Dateianhang nicht ansehen.

[pjakobs]

noch besser: im "Test" Menü gibt es noch ein (übrig gebliebenes) Heap display, das man schnell und ohne page reload refreshen kann:
Du darfst diesen Dateianhang nicht ansehen.

[weini]

Über die Test Page bin ich bei 22k. Wenn ich die System Info Seite frisch refreshe, dann geht er mir auf 18k runter.
Ich beobachte das mal und versuche, mir ein Logging über FHEM aufzubauen. Mit einem regelmäßigen "get info" sollte das ganz gut funktionieren.

[pjakobs]

ich hab Dir mal eine Testing Version gebaut (also im testing channel) - die hat remote logging aktiviert, allerdings sehr eingeschränkt - wenn weniger als 10k Heap frei sind, werden Log Messages einfach verworfen.
Es kann aber dennoch hilfreich sein, das mal laufen zu lassen. Wenn Du im UI den Log Viewer öffnest (System Settings / Log Viewer) dann siehst Du zumindest einen Teil des Ouput - unter anderem die regelmäßigen Heap free updates. Das hilft.

aber achtung: die Version ist nicht production ready, der Code ist extrem unsicher und crasht oft genug!

Du darfst diesen Dateianhang nicht ansehen.

[pjakobs]

Über die Test Page bin ich bei 22k. Wenn ich die System Info Seite frisch refreshe, dann geht er mir auf 18k runter.

die System Info page zieht mehr Objekte - vor allem, wenn Du einen Browser Reload machst - das kostet kurzfristig Heap für network buffer.
auf der Test Page ist es nur eine Anfrage an /info, damit brauchst Du nur einen Buffer (die json Struktur passt in ein ip Paket)
22k / 18k sind Werte im zu erwartenden Bereich, das ist völlig klar, manchmal geht er auf 26k oder sogar 28k hoch, und vielleicht mal auf 14k runtern - kommt ein bisschen darauf an, wieviele andere Controller im Netz sind (das erhöht den mDNS Traffic, aber der ist zeitlich ziemlich weit gespreizt, bei mir sind es 16 Controller oder so, und ich liege im gleichen Bereich)

[weini]

Ich habe mir jetzt das Logging für die 450 über FHEM konfiguriert (5 Min Intervall).
Welche Nummer hat dein Testbuild, ist das die 459? Muss ich die als Debug oder Release installieren?

Aktuell in ich bei 1,5 Tagen uptime.

[pjakobs]

Ich habe mir jetzt das Logging für die 450 über FHEM konfiguriert (5 Min Intervall).

das ist sicher auch eine gute Idee, fünf Minuten sind zwar ziemlich lang (buffer werden nach, iirc, 90 Sekunden abgeräumt) aber wenn es ein langfristiges Memory Leak gibt, dann sollte es sichtbar sein.

Welche Nummer hat dein Testbuild, ist das die 459? Muss ich die als Debug oder Release installieren?

aktuell die 459, ja. Debug wäre die interessante Version. Ich hab allerdings gerade das multi Stream Logging nochmal in Arbeit, vielleicht lässt sich da noch was verbessern.

Aktuell in ich bei 1,5 Tagen uptime.

Wenn der so lange durch läuft, dann bin ich mir echt nicht sicher, ob es ein Memory Leak ist - zumal ich das bei anderen nicht sehe. In der Info Struktur bekommst Du ja auch die Uptime mit (in Minuten) - wenn Du die schon in fhem hast, kannst Du sie ja mal zusammen mit dem free heap plotten - vielleicht jede Minute. Wäre mal interessant zu sehen.