ESP RGBWW Wifi Led Controller - Firmware vbs

[vbs]

Ossi-Gender ^^

[lou]

Hm, wäre ein Hack mMn. Stand jetzt gibt es da meines Wissens erstmal kein Problem mit dem Heap. Falls das nochmal hochkommen sollte, dann würde ich mir lieber wieder anschauen, was da den Heap frisst und das entsprechend versuchen zu lösen.

ohne "nerven" zu wollen, ein kleiner kommentar:

es fühlt sich zwar erstmal an wie ein "hack", ist aber die einzige möglichkeit bei ESPs für wirklich stabilen betrieb zu sorgen.

grund:

1) ESP8266 heap-ram kann (sehr) stark fragmentiert werden durch: router reconnects, pings (ICMP), client/master port-open/close etc. das ganze ist auch abhängig und nicht 100% systematisch vorhersehbar durch die typen der WIFI libs die verwendet werden. egal ob sync oder async. bei einfachen (client) tests sieht man das erstmal nicht. daher sind aggressive stress-tests empfehlenswert. (z.b. 100x open/close consecutive). dabei geht es nicht darum ob die firmware das kann, sondern schwachstellen zu finden, die im normalen betrieb definitiv sporadisch auftreten können.

2) ESP8266 wifi states lassen sich nicht 100% detektieren/handlen. es gibt states in denen zwar "connected" reported wird (RSSI ok etc), das wifi modul ist aber offline. es muss also wirklich die effektive verbindung (port) gecheckt werden. (z.b. mit ping-timeout)

werden diese states nicht abgedeckt ist es nur eine frage der zeit bis der ESP in einen deadlock fällt. (permanent "offline"). manchmal 3x am tag. manchmal nur alle 5 tage etc. (je nach lan traffic etc)

beide states/modi kann man mit einem simplen "desaster check" kontinuierlich erfassen (z.B. alle 1000ms) und so bei bedarf automatisch rebooten.
exceptions (z.b. low heap) sind zu 100% zu vermeiden, da der (automatische) reboot hier niemals zuverlässig funktioniert. (verständlich)

mache ich so schon sehr lange für meine ESP devices und erreiche damit 100% uptime (= zero deadlocks) seit >1 Jahr. (leuchten, powermeter, etc)

gruss,
lou

Code Auswählen Erweitern

if ( DESASTER_CHECK_ACTIVE )     // check every 1000ms
        {
            DESASTER_BYTE =      ((micros() - WS_EVT_T) / 1e6 > 5/*sec*/) << 7   // DESASTER 0x80 = LAST WS event > 5 sec
                                 |
                                 (HEAP < 10000) << 6                             // DESASTER 0x40 = HEAP RAM < 10k
                                 ;

            if ( DESASTER_BYTE && !wantReboot )
            {
                logf_P(PSTR("DESASTER %02X ############### \n"), DESASTER_BYTE);
                {
                    SPIFFS_MOUNT = SPIFFS.begin();
                    SPIFF_F0 = SPIFFS.open("/boot.info", "w");
                    log_head(); logf_P(PSTR("LOG SPIFF WRITE FILE ... %s\n"), SPIFF_F0.name());
                    SPIFF_F0.printf_P(PSTR("DESASTER %02X"), DESASTER_BYTE);
                    SPIFF_F0.close();

                    wantReboot = true; // IN MAIN LOOP (1Hz):  if (wantReboot) { delay(200); ESP.restart(); }
                }
            }
        }

[RaspiLED]

Hi Lou,
hast Du Code Schnipsel für uns? Hört sich sinnvoll an!
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[lou]

Hi Lou,
hast Du Code Schnipsel für uns? Hört sich sinnvoll an!
Gruß Arnd

... gerade noch angehängt ... ist natürlich nicht direkt kompatibel zu der firmware die hier verwendet wird, aber die variablen-namen & kommentare sollten halbwegs verständlich sein. I hope
ich verwende bei mir websockets (WS) für den "ping/alive-check". würde natürlich auch mit anderen verbindungstypen gehen.

[balli1187]

Daran wäre ich auch interessiert.


Gesendet von iPhone mit Tapatalk

[vbs]

Klingt schon schlüssig und aber auch recht dramatisch. Bin noch nicht so sicher, wie ich das einordnen soll. Man müsste das wohl mal im Kontext der Firmware bzw. Controller hier bewerten. Ich alleine bin da wohl nicht repräsentativ, aber ich kann mich bei mir an keinen Fall erinnern, bei dem der Controller rebooten wollte und nicht wieder kam. Ich hoffe, ich habe nix unterschlagen, aber ich hab da auch von Usern keine Beschwerden gehört.
Das Problem betrifft dann ja wohl sämtliche ESP-Firmwares. Hab da mal etwas gegoogelt zu dem Thema, aber eigentlich nichts greifbares gefunden. Was nicht heißen soll, dass es da nichts gibt. Vielleicht hast du ein paar Links zum Thema?

[lou]

1) ... Ich alleine bin da wohl nicht repräsentativ...
2) ... Das Problem betrifft dann ja wohl sämtliche ESP-Firmwares...
3) ... Vielleicht hast du ein paar Links zum Thema?

1) darum die stress-test-empfehlung. bei "echter" entwicklung wird testing oft irgendwann wichtiger als die hard/software entwicklung selbst.
2) würde ich nicht so bewerten. das "problem" ist vielmehr die inhärente challenge von wifi ansich. es geht auch immer um die komplette infrastruktur. niemals nur um ein device selbst.
    das sieht man z.b. wenn man die gleichen devices an qualitativ stark unterschiedlichen routern betreibt.
    robuste devices (z.b. eine fritzbox oder ein handy) führen definitiv reboots/restarts von bestimten submodulen aus (uCs). nur "sieht" das der user nie.
    wifi hat viele komplexe layer. die idee die firmware so gut zu machen daß sie auf jeder ebene in jedem use case (z.b. einem "RX-frame-abriss") alles robust abfängt ist ziemlich aussichtslos.
    darum hat jeder uC - egal wie simpel - auch einen watchdog, brown-out detector, etc. (beim ESP z.b. der LOOP-WDT).
    diese mechanismen sind nicht (nur) für "schlampige programmierer"... auch wenns erstmal so scheint
3) infos im internet zu systeme wie raspberry oder ESP8266 stammen zu 99% von enthusiasten wie schülern, studenten oder eben hobbyisten.
    da geht es so gut wie nie um 100%ige verfügbarkeit sondern eher um machbarkeit und "education".

im "kollektiven bewusstsein" (= google) tauchen echte details dazu so gut wie nie auf. grund:
a) - systeme die derlei probleme haben zeigen diese nur sporadisch z.b. alle paar monate. eine wirkliche analyse und ein nachweis ist also komplex bis unmöglich mit normalen mitteln.
b) - systeme die ein gutes konzept verwenden funktionieren unauffällig. der grund für die robustheit ist aber nicht sichtbar nach aussen oder grossartig dokumentiert.

https://github.com/arendst/Sonoff-Tasmota/issues/1760
tasmota 10-sec-WD ("safe mode System Restart procedure")

https://community.home-assistant.io/t/watchdog-device-using-sonoff-with-tasmota/83587
"If a device crashes randomly every 3 or 6 months, my life is too short to start debugging it."

du hast recht. es "klingt" dramatisch. aber im kern macht der "desaster mode" nur eines. er verwendet "heap-schwelle" und "alive-ping" zusätzlich als kriterium.
der grund ist, daß der WD standardmässig (arduino libs) viel abfängt, aber eben nicht alle states in jeder beliebigen firmware-implementierung. (feature set)
rein technisch gehören dazu auch die wifi-libs selbst. und deren quali schwankt auch von release zu release.

noch ein beispiel aus erfahrung:
jeder "port open" kann so grob 400 bytes from heap abzwacken. wie limitiere ich das?
natürlich denkt man erstmal daran die anzahl der möglichen ports zu limitieren. macht auch sinn.
die meisten libs geben ports/heap ja auch wieder frei wenn länger nix passiert.... (je nach fragmentierung / timing)
aber diese funktion hat eine gewisse latenz / benötig cpu-zeit und ist stark abhängig von den ref-libs. im schlimmsten falls sinkt die robustheit dadurch sogar.
der (zusätzliche) heap-check ist für beide punkte erheblich effizienter. (schnell, zuverlässig, unabhängig von den (wifi)libs)

[vbs]

Ok, danke dir, ist schon interessant.

Nur so richtig Handlungsbedarf sehe ich da ehrlich gesagt (noch) nicht, da es zumindest bei mir wenig/nie auftritt. Wenn es Leute gibt, die da konkret Probleme an der Ecke haben, dann bitte Bescheid sagen. Dann muss man da weiter sehen.

[pjakobs]

Ok, danke dir, ist schon interessant.

Nur so richtig Handlungsbedarf sehe ich da ehrlich gesagt (noch) nicht, da es zumindest bei mir wenig/nie auftritt. Wenn es Leute gibt, die da konkret Probleme an der Ecke haben, dann bitte Bescheid sagen. Dann muss man da weiter sehen.

sag mal @vbs, hatten wir eigentlich irgendwann mal Maßnahmen zur Verringerung der Flash Schreibzyklen getroffen? Mein Sorgen-Controller (der regelmäßig über den Bewegungsmelder getriggert wird) hat mal wieder den Geist aufgegeben und ich vermute, er braucht einen neuen ESP bzw. Flash Chip.

pj

[mike.d]

hallo vbs - vielen Dank erstmal für deine Mühen und Einsatz für das schöne Stück Software! :- )

ich hab mit einem der Controller oft das Problem, dass er sich nicht per fhem steuern lässt - beim manuell verbinden klappt es dann eigentlich immer. Im Log sehe ich folgendes:

Code Auswählen Erweitern

2019.03.14 21:51:28 3: S.Bett: EspLedController_CheckConnection: Connection lost! Last data received 86.0636839866638 s ago
2019.03.14 21:51:28 1: 192.168.178.90:9090 disconnected, waiting to reappear (S.Bett)
2019.03.14 21:52:35 1: 192.168.178.90:9090 reappeared (S.Bett)
2019.03.14 21:53:06 2: S.Bett: EspLedController_ParseBoolResult error: connect to http://192.168.178.90:80 timed out
2019.03.14 21:53:37 2: S.Bett: error read from http://192.168.178.90:80 timed out retrieving config
2019.03.14 21:53:56 3: S.Bett: EspLedController_CheckConnection: Connection lost! Last data received 81.6138591766357 s ago
2019.03.14 21:53:56 1: 192.168.178.90:9090 disconnected, waiting to reappear (S.Bett)
2019.03.14 21:54:08 2: S.Bett: error read from http://192.168.178.90:80 timed out retrieving config
2019.03.14 21:54:08 3: S.Bett: got info response
2019.03.14 21:54:08 3: S.Bett: info response data {"deviceid":"13028322","current_rom":"0","git_version":"vbs35","git_date":"2018-08-22","webapp_version":"0.3.3-shojo7","sming":"3.5.1","event_num_clients":0,"uptime":532560,"heap_free":16808,"rgbww":{"version":"0.8.1-vbs5","queuesize":100},"connection":{"connected":true,"ssid":"xxxx","dhcp":true,"ip":"192.168.178.90","netmask":"255.255.255.0","gateway":"192.168.178.1","mac":"xxxx"}}


Ist das am ehesten ein wifi-Problem!?

Dank und Gruß,
Michael

[pjakobs]

Ist das am ehesten ein wifi-Problem!?

Dank und Gruß,
Michael

Moin Michael,

ich hab hier bald 20 Controller am laufen und hatte bisher für die Leuchten auf der Terasse auch immer mal wieder das Problem.

Ein zweiter Wifi Hotspot/Repeater für 19EUR hat es gelöst.

pj

[vbs]

Von hier aus schwer zu sagen, ob es ein Wifi-Problem ist. Wenn der WLAN-Empfang am Controller generell schlecht sein sollte wegen z.B. drei Wänden dazwischen, dann fände ich die Erklärung plausibel.
Kannst ja mal ein Dauer-Ping laufen lassen und gucken, ob da auch Pakete verloren gehen... oder gucken, ob sich der Controller am AP regelmäßig neu anmeldet oder sowas.

[juergs]

..Von hier aus schwer zu sagen, ob es ein Wifi-Problem ist...

Das lässt sich einfach nachvollziehen, wenn man im Syslog des Raspis  (/var/log) zum betreffenden Zeitpunkt nachschaut ...

Jürgen

[pjakobs]

Das lässt sich einfach nachvollziehen, wenn man im Syslog des Raspis  (/var/log) zum betreffenden Zeitpunkt nachschaut ...

Jürgen

darin siehst Du aber nicht, ob die LED Controller ein WiFi Problem haben, und darum geht es ja.

pj

[juergs]

Hallo PJ,
wenn Du sicher bist, dass es ein Controller-WiFi Problem ist....

Wollte nur eine weitere Diagnosemöglichkeit anzeigen, da ich auch Probleme mit Verbindungs-Abrissen habe ...

z.B.:
https://raspberrypi.stackexchange.com/questions/62932/avahi-seems-to-stop-publishing-refreshing-services-after-a-while
https://raspberrypi.stackexchange.com/questions/79359/ethernet-interface-interrupts-connection
Kann das aber noch nicht sauber beurteilen, habe aber zeitliche  Übereinstimmungen mit dem avahi-daemon unter Stretch und den Abrissen.
In meinem Fall allerdings UDP und da gebe ich Dir recht, muss nicht mit Eurem Problem koherent sein 

J.