ESP RGBWW Wifi Led Controller - Firmware vbs

[vbs]

Ok, super.

@pjakobs
das ist interessant, danke. Werde ich im Hinterkopf behalten für den Fall der Fälle.

[vbs]

Oh Mann, hab eine neue Version gemacht (6.0.2-rc1) mit ein paar Fixes. Änderungen ggü 6.0.0-rc5:

* die 6er-Serie hat (hatte) ein Memory Leak, so dass irgendwann der Speicher vollgelaufen ist. Das ist hiermit behoben.
* neues Info-Feld "heap_largest_free_block", das angibt, wie viel Speicher unfragmentiert frei ist
* Heap-Speicher optimiert, so dass etwas mehr Speicher frei ist
* Color-Control in der WebUI funktioniert wieder
* neues Feature: falls der Controller beim OTA-Update hängenbleibt, resettet er sich selbst nach 5 Minuten, damit er dann wieder ansprechbar ist und nicht ewig in diesem Zustand verharrt

Zu finden auf http://rgbww.dronezone.de/testing/version.json

Das Verrückte: Ich hatte in der letzter Zeit sporadisch das Problem, dass Controller beim Update-OTA hängengeblieben sind und dann ewig in dem Zustand stecken geblieben sind. Ich hatte erst ein Speicher-Problem im Verdacht und daher die Verbesserungen in dem Bereich eingebaut.
Bin aber recht sicher mittlerweile, dass das alles ne falsche Fährte war und dass das Hosting auf Github das Problem ist. Meine beste Theorie dazu ist, dass Github das Timing nicht mag, in dem die Controller die Firmware laden und dann die Verbindung kappen. Klingt komisch... Aber: ich hoste die Files jetzt selbst (testweise) und seitdem ist das Problem nicht mehr aufgetreten.

Naja egal - mehr freier Speicher und stabileres OTA kann ja trotzdem nicht schaden, auch wenn es am Ende gar nicht das Problem war...

[Cybers]

Bei deinem Update-Link bekomme ich leider einen Netzwerkfehler.

[vbs]

Ich vermute mal, dass es um das Update per Webinterface der Controller geht? Ich hab da was gefixt jetzt, also könntest du nochmal probieren. Aus FHEM heraus ging es meiner Meinung nach vorher schon.

[vbs]

Und nochmal neue Firmware: 6.0.3-rc1

Ich hatte jetzt mehrfach das Problem, dass in der WebUI bei der Ersteinrichtung keine WLAN-Netze angezeigt wurden (sehr unschön, weil man dann erst einmal nicht weiterkommt). Das konnte passieren, wenn die Liste zu lang wurde (oder z.B. zu viele lange WLAN-Namen dabei waren). Das ist jetzt hiermit behoben.

[vbs]

Ui, das ist groß! (also für mich zumindest  )

Ich hab mal wieder an der Firmware geschraubt und ich glaube, ich hab endlich das Problem in den Griff bekommen, dass sich die Controller nicht immer sauber wieder zum WLAN connectet haben, nachdem sie die Verbindung verloren hatten.

Bei mir war die Konstellation wohl so: ich hab eine Fritzbox und auch einen kabelgebundenen Repeater zusammen als Mesh-WLAN. Und wenn die Fritzbox rebootet wurde, haben sich die Controller mit dem WLAN des Repeaters verbunden. Da die Fritbox jedoch gerade noch rebootet, konnten die Controller dann darüber per DHCP keine IP beziehen. Ich denke, das hat sie dann in einen Deadlock befördet auch wenn dann die Fritbox wieder kam.

Ich hab dann jedenfalls den WLAN-Code in der FW großflächig umgearbeitet (ich glaube, es gab auch einige andere Szenarien, wo der Reconnect fehl schlug). Ich könnte mir vorstellen, dass das jetzt stabil laufen könnte. Vom Feeling her hab ich ein gutes Gefühl.

Das läuft jetzt so:
Wenn ein Controller die Verbindung verliert, versucht er sich neu zu verbinden. Nach einer gewissen erfolglosen Zeit (konfigurierbar per "config-network-ap-fallback_delay" - default 600 -> 10 Minuten), spannt er dann seinen eigenen AP auf, so dass man sich von außen mit dem Controller verbinden könnte. Aber er versucht dann dauerhaft weiter, sich wieder mit dem Original-AP zu verbinden. Jedoch nur, wenn kein Client mit seinem aufgespannten AP verbunden ist (die würden die Verbindung verlieren bei einem Kanal-Scan).

Das ist jetzt so drin in der Firmware 6.1.0-rc1