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.

[weini]

Nach deiner Rückmeldung habe ich das Intervall gestern auf 1 Min. verkürzt.
Mittlerweile hat er einen weitere Reboot hingelegt und der Graph ist IMHO ganz aufschlussreich. Free Heap nimmt über die Zeit kontinuierlich ab.

Noch ein paar Zusatzinfos:
- ich habe nur diesen einen Controller, es sollte also keine Unterhaltungen im Schwarm geben
- die Steuerung erfolgt ausschließlich via FHEM Modul und zwar am frühen Abend ein, und gegen 23h aus, nicht mehr.
- es ist eine Szene für eine Animation auf dem Controller gespeicher, diese nutze ich aber aktuell nicht.

Soll ich die Config noch hier posten?

[pjakobs]

okay, damit ist das ziemlich klar ein Heap Problem, die Frage ist nur: warum und warum so regelmäßig.
Magst Du mal teilen, wie Du das in fhem implementiert hast? Dann schau ich mal, ob ich sowas hier auch sehe.

Was mich erstaunt ist, dass der Speicherverbrauch plötzlich so rapide zunimmt - in beiden Graphen zu sehen, bei dem einen führt es zum crash, beim anderen wird der Speicher früh genug wieder freigegeben.

Aber: wie Du schon sagst, irgend etwas verbraucht über die Zeit zusätzlich RAM, was dann vermutlich dazu führt, dass wenn was auch immer plötzlich viel Speicher verbraucht, nicht mehr genug da ist.

Eigentlich kann das nichts sein, was nur bei Dir auftritt, vermutlich boote ich meine Controller einfach zu häufig, als dass es bei mir auffallen würde.

[weini]

Ja klar, sehr gerne. Hier die FHEM Definitionen:

Controller

Code Auswählen Erweitern

defmod led_Bartresen EspLedController rgbww1.weinberger.lan
attr led_Bartresen userattr snipsColors:textField-long isDimmer
attr led_Bartresen comment Folgende "mode" werden unterstützt: "manuell", "AA" AllianzArena, "fade" laufendes Überblenden.\
Sicherungsautomat im Sicherungskasten im Zählerraum: ganz rechts
attr led_Bartresen defaultRamp 4000
attr led_Bartresen devStateIcon {Color::devStateIcon( $name, "rgb", "rgb", "val", "state" )}
attr led_Bartresen deviceName rgbww1.weinberger.lan
attr led_Bartresen fp_1OG 552,862,1,led_Bartresen,
attr led_Bartresen group Barbeleuchtung
attr led_Bartresen icon light_led_stripe_rgb
attr led_Bartresen isDimmer 1
attr led_Bartresen room Barzimmer,Snips
attr led_Bartresen snipsColors rot=rgb FF0000\
grün=rgb 00FF00\
blau=rgb 0000FF\
weiß=rgb FFFFFF\
violett=rgb 483D8B\
orange=rgb FFA500\
gelb=rgb FFFF00\
pink=rgb FF34B3\
braun=rgb 8B4726\
rosa=rgb FFAEB9\
türkis=rgb 4EEE94\
rotation=dif_Bartresen_Automatik_fade:manuell Rotation\
demo=dif_Bartresen_Automatik_fade:manuell Demo\
party=dif_Bartresen_Automatik_fade:manuell Party
attr led_Bartresen snipsMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentVal=stateLight,valueOff=off\
SetNumeric:currentVal=pct,cmd=dim,step=20,type=Helligkeit\
GetNumeric:currentVal=pct,type=Helligkeit
attr led_Bartresen snipsName Bar,Bartresen,Tresenbeleuchtung,Tresen
attr led_Bartresen snipsRoom Barzimmer
attr led_Bartresen stateFormat stateLight
attr led_Bartresen verbose 3
attr led_Bartresen webCmd on:off:rgb:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff
attr led_Bartresen widgetOverride rgb:colorpicker,rgb

DOIF zum an-/ausschalten

Code Auswählen Erweitern

defmod dif_Nachtlicht_Timer DOIF (([({sunset(-1800)})-23:45] and [dif_Presence] eq "present" and ([xmasMaster] eq "off" or [xmasMaster] eq "half")) or ["$SELF:manuell: on"]) (set led_Bartresen on, set Flur_SideboardLichtleiste on, set ArZi_Lichtbaum pct 30, set ArZi_HyperCube on, set ArZi_HyperCube next_ps, set led_Bartresen on) DOELSEIF ([({sunset(-1800)})-23:45] and [dif_Presence] eq "present" and [xmasMaster] eq "on") (set Flur_SideboardLichtleiste on, set ArZi_Lichtbaum pct 30, set ArZi_HyperCube on, set ArZi_HyperCube ps 9) DOELSEIF ([23:46] or [dif_Presence] eq "absent" or ["$SELF:manuell: off"]) (set led_Bartresen off, set Flur_SideboardLichtleiste off, set ArZi_Lichtbaum off, set ArZi_HyperCube off, set led_Bartresen off)
attr dif_Nachtlicht_Timer alias Nachtlicht
attr dif_Nachtlicht_Timer cmdState on|on|off
attr dif_Nachtlicht_Timer readingList manuell
attr dif_Nachtlicht_Timer room Arbeitszimmer,Flur
attr dif_Nachtlicht_Timer setList manuell:on,off
attr dif_Nachtlicht_Timer webCmd manuell
attr dif_Nachtlicht_Timer widgetOverride manuell:uzsuSelectRadio,on,off
Sieht mega kompliziert aus, schickt aber letztlich nur einen normalen "on/off" an led_Bartresen.

Timer für das Logging

Code Auswählen Erweitern

defmod tmr_Bartresen_upd at +*00:01 get led_Bartresen info
attr tmr_Bartresen_upd group Barbeleuchtung
attr tmr_Bartresen_upd room Barzimmer
Der ist neu, damit jede Minute das Log geschrieben wird.

Ehrlich gesagt kann ich mir nicht vorstellen, dass es an der Ansteuerung via FHEM liegt.
Spannend finde ich den deutlichen Rückgang im Free Heap heute morgen zwischen 6:20 und 7:10. Da wurde der Controller definitiv nicht angesteuert und auch nicht manuell abgefragt (außer natürlich durch den FEHM Timer, aber der läuft ja dauernd).

[pjakobs]

Ehrlich gesagt kann ich mir nicht vorstellen, dass es an der Ansteuerung via FHEM liegt.
Spannend finde ich den deutlichen Rückgang im Free Heap heute morgen zwischen 6:20 und 7:10. Da wurde der Controller definitiv nicht angesteuert und auch nicht manuell abgefragt (außer natürlich durch den FEHM Timer, aber der läuft ja dauernd).

genau, das kann ich mir aktuell auch nicht vorstellen, ich würde nur gerne Deine Funktionalität, den free heap in einen Graphen zu fassen auch bei mir einbauen und mir ehrlich gesagt, die Denkarbeit dafür ersparen

[weini]

Ach das wolltest du....
Sorry, hatte ich falsch verstanden.

FileLog

Code Auswählen Erweitern

defmod log_ledBar FileLog /var/log/fhem/log_ledbar-%Y-%m.log led_Bartresen:.*
attr log_ledBar archiveCompress 1
attr log_ledBar archivedir /var/log/fhem/archive
attr log_ledBar nrarchive 0

at (wie oben schon angegeben)

Code Auswählen Erweitern

defmod tmr_Bartresen_upd at +*00:01 get led_Bartresen info

SVG

Code Auswählen Erweitern

defmod SVG_log_ledBar_1 SVG log_ledBar:SVG_log_ledBar_1:CURRENT

gplot

Code Auswählen Erweitern

# Created by FHEM/98_SVG.pm, 2025-10-23 08:24:06
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Free Heap"
set y2label "Uptime"

#log_ledBar 4:led_Bartresen.info-heap_free\x3a::
#log_ledBar 4:led_Bartresen.info-uptime\x3a::

plot "<IN>" using 1:2 axes x1y1 title 'Free Heap' ls l0 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'Uptime' ls l1 lw 1 with lines


[rippi46]

Hallo,

Habe bei mir seit Jahren ca. 18 Controller (von der Ersten bis zur letzten Generation) im Einsatz.

Habe dann irgendwann auf die neue Version gewechselt und dann auch immer regelmäßig auf das neueste Release gewechselt.

Leider waren dann bei manchen Versionen die Controller auch nach einem reboot nicht mehr erreichbar. Habe dann alle möglichen Versionen getestet
und habe mich dann entschlossen wieder auf die Ursprungsversion aus dem ersten Post zu gehen.

Seither läuft es nahezu stabil. Ab und zu passiert es das der ein oder andere Controller mal die Helligkeit kurz ändert.

Habe seither nichts mehr verändert, da natürlich auch der WAV-Faktor darunter leidet und ich immer wieder Zeit investiere.

Wäre aber bereit weitere Tests durchzuführen.

Gruß rippi

[weini]

Hier noch ein Nachtrag, am Nachmittag hat es ihn wieder erwischt.
Auch zu diesem Zeitpunkt erfolgte kein Schaltvorgang.

Kann das evtl. am WLAN Roaming liegen? Ich habe mehrere Access Points als Mesh am laufen (aktuelles OpenWrt) und habe heute zu ungefähr dieser Zeit meine Access Points upgegraded, so dass die Geräte roamen mussten.