ESP RGBWW Controller - Firmware v5

[pjakobs]

@weini - zieh Dir mal den aktuellen Build von heute (V5.0-415-develop) - da sollte das Problem behoben sein, ich habe die Erkennung für aktive Controller stark überarbeitet

[pjakobs]

Ich hab die Synchronisation der Gruppen und Szenen nochmal überarbeitet, das sollte jetzt wesentlich stabiler sein, unter anderem gibt es ein verteiltes Datenbanklock, dass dafür sorgt, dass immer nur ein Synchronisationstask im Netz läuft.

V5.0-424-develop

[weini]

@weini - zieh Dir mal den aktuellen Build von heute (V5.0-415-develop) - da sollte das Problem behoben sein, ich habe die Erkennung für aktive Controller stark überarbeitet

funktioniert, vielen Dank!

[pjakobs]

Mal ein paar neue Snapshots:


Die Controller Konfiguration
und zuletzt

Du darfst diesen Dateianhang nicht ansehen.

Du darfst diesen Dateianhang nicht ansehen.

Du darfst diesen Dateianhang nicht ansehen.

Du darfst diesen Dateianhang nicht ansehen.

Du darfst diesen Dateianhang nicht ansehen.

[pjakobs]

hm... gestern hab ich noch die versprochenen virtuellen presets für "an" und "aus" eingebaut - wobei "an" das letzte Setting vor dem Ausschalten war, und dabei ist mir aufgefallen, dass ich dafür "last_color" nicht wirklich nutzen kann.
Wie schon in der alten Software wird "last_color" immer dann gesetzt, wenn sich die aktuelle Farbe stabil nicht ändert (aktuell für 2 Sekunden). Die wird dann benutzt, um diese Farbe wieder zu laden, wenn der Controller neu gestartet wurde (Stromausfall, Reboot oder über Schalter geschaltet).
Wenn der Controller auf "Aus" gesetzt wird, dann heißt das ja nur, dass die Helligkeit (v) auf null gesetzt wird, und das ist eine valide Farbe, deshalb wird die in "last_color" gespeichert.
Ich muss mir was einfallen lassen, um zusätzlich die Farbe vor dem letzten /off oder /{"v":0} zu speichern.

[weini]

Nur so eine Idee: Jedesmal, wenn du last_color setzt, kopierst du den alten Wert von last_color nach 2nd_last_color. Dann würde beim "off" der Farbwert fürs wieder Anschalten in 2nd_last_color stehen.

[pjakobs]

ich hab das jetzt erstmal als eigene /on und /off API Endpoints gebaut, ganz zufrieden bin ich damit aber noch nicht. Mal sehen.

[weini]

Anfang Oktober hatte ich von der 424 ein update auf den 450 gemacht. Als mein Controller (erste Generation, ESP8266) damit nicht stabil lief, bin ich schrittweise zurückgegangen. Leider haben ich bis runter zur 429 immer noch Reboots und Hänger innerhalb von 24-48h.

Die 424 wird in der WebUI nicht mehr angeboten. Ich habe es daher ein manuelles Downgrade versucht, etweder mit

Code Auswählen Erweitern

curl --header "Content-Type: application/json"   --request POST   --data '{"rom": { "url": "http://lightinator.de/download/develop/V5.0-424-develop/esp8266/release/rom0.bin" },  "spiffs": { "url": "http://rgbww.dronezone.de/testing/spiff_rom.bin"}}'   http://rgbww1.weinberger.lan/update{"success":true}root@nas2:~# curl --header "Content-Type: application/json"   --request POST   --data '{"rom": { "url": "http://lightinator.de/download/develop/V5.0-424-develop/esp8266/release/rom0.bin" },  <ip>/updateoder mit

Code Auswählen Erweitern

curl --header "Content-Type: application/json"   --request POST   --data '{"rom": { "url": "http://lightinator.de/download/develop/V5.0-424-develop/esp8266/release/rom0.bin" }}'   <ip>/update.

Beide Versuche enden mit Status 3, OTA failed und die alte Version (429) bleibt aktiv.
Hat sich hier die Syntax geändert oder woran könnte es liegen, dass ich nicht manuell update / downgraden kann?

[pjakobs]

interessant, in einer der Versionen in den 440ern hatte ich ein Memory Leak, das zu dem von dir beschriebenen Problem führte, das sollte aber um den 18. September gefixt worden sein.

die 450 läuft bei mir seit Wochen stabil. Ich nehme an, Du hast keine Möglichkeit, die Logs des Controllers mit V5.450 einzusammeln?

[weini]

Logging geht nicht über WLAN, oder? Der Controller ist schlecht zugänglich verbaut und ich würde es mir gerne ersparen, ihn rauszuholen.
Nutzt du die 450 auch mit einem esp8266? Sonst versuche ich die nochmal. Kann es sein, dass meine Konfiguration das Problem verursacht? Die ist eigentlich nicht exotisch, ich könnte sie aber mal zurücksetzen.

[pjakobs]

Logging geht nicht über WLAN, oder? Der Controller ist schlecht zugänglich verbaut und ich würde es mir gerne ersparen, ihn rauszuholen.
Nutzt du die 450 auch mit einem esp8266? Sonst versuche ich die nochmal. Kann es sein, dass meine Konfiguration das Problem verursacht? Die ist eigentlich nicht exotisch, ich könnte sie aber mal zurücksetzen.

Nee, ich hatte mal lan logging implementiert, aber auf dem Esp8266 ist einfach nicht genug RAM dafür da. Auf dem Esp32 werde ich das vermutlich wieder aktivieren.
Bei mir laufen noch 12 der alten Controller in meiner "normalen" Beleuchtung, das sind aktuell fast alles Controller aus der zweiten Serie (die kleinen, grünen Platinen). - aber es sind eben alles Esp8266 - und die laufen bei mir wochenlang durch.

[weini]

Bin gestern nach deinem Post nochmal auf die 450 gegangen, bisher läuft er stabil.
Das Upgrade war allerdings ein ewiges gefrickle. Ich habe mehr als 5 Versuche gebrauch, ehe es mal durchgelaufen ist. Hatte auch versucht, auf Zwischenversionen zu gehen - ohne Erfolg.
Ich fürchte, dass der Controller mit dem Flash ein Problem bekommt...

Aber jetzt läuft er erst mal 

[pjakobs]

ich hab nicht wirklich viel Error-Handling im OTA Upgrade Pfad. Da, wo noch die ganz alte Firmware läuft, kann ich sowieso nichts tun (da hab ich immer wieder Probleme), aber ich schau mir mal an, ob ich im neuen Copdepfad was einbauen kann.
Im Grunde gibt es zwei Möglichkeiten, warum ein OTA von einer älteren V5 fehlschlägt:
[ul]

• download schlägt fehl (HTTPERR 3xx/4xx)
• fash schlägt fehl

[/ul]
ich habe an anderen Stellen die Möglichkeit, Fehlermeldungen über WebSocket an as UI zu senden, aber weil der Code viel neuer ist als der otaupdate.cpp Code, habe ich das dort nie eingebaut. Sollte ich vielleicht mal nachholen.

gerade mal nachgesehen, der HttpUpgrader gibt mir leider keine wirklich hilfreiche Info:

Code Auswählen Erweitern

void HttpUpgrader::downloadFailed()
{
debug_e("\r\nFirmware download failed..");
if(updateDelegate) {
updateDelegate(*this, false);
}
items.clear();
}
[/clear]
will sagen: ich bekomme nur ein "success" oder "failure", keine Information, *warum* der Download fehlgeschlagen ist
Ich schau mir das mal ein bisschen an.

Aber: freut mich, wenn der Controller jetzt läuft. Du sagtest, das ist einer der frühen, die schwarze Platine vermute ich? Dann läuft der ja auch schon seit acht, neun Jahren. @vbs und ich sind uns ja über die Haltbarkeit / Resilienz der Flash Chips immer ein bisschen uneinig, aber meines Erachtens sind einige der Flash Blöcke im SPIFFS Bereich nach langem Betrieb und häufigem Schalten nicht mehr brauchbar, wenn die letzte Lichtfarbe immer wieder in den Flash geschrieben wird.

Altes Layout:
[code]
 * layout pre partition change                       * layout post partition change
 *                                                   *
 *                                                   *
 * 0x00000000   +-------------------------+          * 0x00000000   +-------------------------+
 *              |                         |          *              | partition Table         |
 * 0x00002000   +-------------------------+          * 0x00002000   +-------------------------+
 *              | rom0                    |          *              | rom0                    |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 * 0x000FA000   +-------------------------+          * 0x000FA000   +-------------------------+
 *              |                         |          *              |                         |
 * 0x00100000   +-------------------------+          * 0x00100000   +-------------------------+
 *              | spiffs0                 |          *              | lfs0                    |
 *              |                         |          *              | extended from 768kB     |
 *              |                         |          *              | to 1000kB               |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 * 0x001C0000   +-------------------------+          * 0x001FA000   +-------------------------+
 *              |                         |          *              |                         |
 * 0x00202000   +-------------------------+          * 0x00202000   +-------------------------+
 *              | rom1                    |          *              | rom1                    |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 * 0x002FA000   +-------------------------+          * 0x002FA000   +-------------------------+
 *              |                         |          *              |                         |
 * 0x00300000   +-------------------------+          * 0x00300000   +-------------------------+
 *              | spiffs1                 |          *              | lfs1                    |
 *              |                         |          *              | extended from 768kB     |
 *              |                         |          *              | to 1000kB               |
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 * 0x003C0000   +-------------------------+          * 0x003FA000   +-------------------------+
 *              |                         |          *              |                         |
 *              |                         |          *              |                         |
 * 0x003FFFFF   +-------------------------+          * 0x003FFFFF   +-------------------------+
[code]
das Partitionslayout hat sich zwar geändert, aber da, wo die SPIFFS Partition war liegt heute halt einfach die lfs Partition, und wenn dort Blöcke nicht lesbar sind, werden die von lfs einfach transparent remapped, das sollte nie zum Reboot führen.
Nachdem der Controller bei Dir ja schon auf einer V5 Version läuft, hat das OTA Update auch nicths mehr am Flash Layout ändern müssen (das passiert nur beim ersten Mal von älterer Firmware auf die V5). Ich glaube eher nicht, dass der Flash Chip ein Problem hat, auch wenn das sonst ein Fehler Mode ist, den ich für wahrscheinlich halte.

Seltsam. Wie gesagt: zu doof, dass es extrem RAM aufwendig ist, über das Netz zu loggen, ich schau mir auch das nochmal an. Tasmota kriegt's schließlich auch hin.

pj

[weini]

Mein Controller hat mit der 450 jetzt über Nacht leider wieder einen Reboot hingelegt.
Bin mir aber nicht sicher, ob es an der Software liegt oder ob er einfach altersschwach wird...

[pjakobs]

wirklich seltsam.
die wahrscheinlichste Ursache für sporadische Reboots ist, dass dem Controller der RAM ausgeht oder ... sonst gibt es in der Software eigentlich nicht so sehr viel, wenn sie grundsätzlich läuft.

Es wäre wirklich super, wenn Du den seriellen Log Output einsammeln könntest.
Ich schau gerade mal nochmal in das logging über websocket rein, aber das Ergebnis war damals nicht vielversprechend: 20kB RAM sind halt nicht viel und die debug Version erzeugt ziemlich viel log output.