ESP RGBWW Controller - Firmware v5

[pjakobs]

ich würde mich freuen, wenn viele die Telemetrie eingeschaltet lassen würden, es ist schon sehr nützlich zu sehen, wie lange die Teile laufen, und ob sie Speicherprobleme haben.
Ich lege offen, was ich einsammle und ich glaube, dass da nichts dabei ist, was irgendwie sensibel sein sollte - aber ich verstehe auch, dass ich da um viel Vertrauen bitte.
Ich hab, als ich den Code geschrieben habe, darüber nachgedacht, wie einfach es wäre, damit Schindluder zu treiben, und wie viele Hausautomationslösungen verlangen, dass man irgendein Gerät mit proprietärem Code in's Netz hängt und es mit der Umwelt reden darf. Amazon Alexa vornweg aber auch alle möglichen anderen Geräte.
Das ist einer der Gründe, warum ich bei den Controllern eine Cloud-Unabhängige Lösung schaffen will, alle zusammen zu kontrollieren.

[Mafi]

Seit kurzem sind auch meine Controller 10676771, 6661754, 10982938, 10964371 in der Telemetrie dabei. Mit der Firmware 497 hat einer der vier (6661754) gestern immer wieder Reboots gemacht und dabei das Licht im Süßwasser-Aquarium auf Minimum geschaltet. Mit der alten Version (ich glaube 357)) lief das vorher. Seit heute Nacht sind die meisten Controller auf 505 upgedatet.
Bis jetzt scheint es zu laufen.

Grüße
Markus

[weini]

Mir ist heute auch aufgefallen, dass die Speicherung der letzten Farbe wohl nicht richtig funktioniert.
Die Spezialfavoriten für On & Off gehen jetzt beide. Wenn man aber On wählt, dann kommt nicht die letzte Farbe, sondern ein stark gedimmtes Weiß.
Könnte auch das von Mafi geschilderte Verahlten erklären.

Aber das Free Heap Problem scheint mit der 503 jetzt Geschichte zu sein. Er bricht manchmal kurz ein (wenn ich etas im WebUI mache), aber er kommt dann wieder auf das alte Niveau zurück. Wirklich super!

[pjakobs]

ich sehe gerade, dass 10982936 (192.168.178.202) um 19:42 neu gestartet ist - scheinbar nach einem /config GET. Ich habe da ein paar mal gesehen, dass die Controller nicht genug Speicher haben. Die Config (und Data) json Objekte sind relativ groß geworden, aber eines der Design Goals von ConfigDB war, so große json Objekte problemlos streamen zu können, weil sie nicht als Objekt zusammengebaut werden, sondern quasi on the fly, also während sie gesendet werden.
Jedes Mal, dass eine HTTP response erzeugt wird (also bei einem GET Request), checke ich vorher, ob mindestens 12kB Heap frei sind, wenn das nicht der Fall ist, schicke ich dem Client ein HTTP_TOO_MANY_REQUESTS mit der Bitte, eine Sekunde zu warten.
Wenn aber ConfigDB selbst so viel Speicher braucht, um ein Objekt zu senden, dann kann ich da nicht eingreifen.

Ich muss mal sehen, was ich machen kann.

[pjakobs]

mal sehen, was der Meister sagt:
https://github.com/mikee47/ConfigDB/issues/76

[pjakobs]

Ich habe in der 5.0.507 die Anzahl gleichzeitiger HTTP Verbindungen runter gesetzt (keine Ahnung, wann und wie ich auf die Idee kam, 40 könnten eine gute Idee sein - vielleicht auf dem esp32, aber selbst da ist das imho quatsch)
Das sollte jetzt auch die meisten Abstürze verhindern, die noch passiert sind, wenn man das UI sehr schnell neu geladen hat.
Ich push die in den "testing" branch, wer ein bisschen stabiler (im Sinne von weniger Veränderung) unterwegs sein will, kann dann ja dahin umsteigen.

für jetzt erstmal herzlichen Dank an alle, die mitgeholfen haben! Das war ne coole Aktion.

[pjakobs]

so, ich hab jetzt mit der 5.0.508 auch das on/off Problem behoben und die gleiche Version nach testing gepusht, wer also nicht meine regelmäßigen develop updates will, kann auf den Testing channel umsteigen.
5.0.507/5.0.508 bringt aber nochmal ein bisschen mehr Stabilität, dahin solltet Ihr auf alle Fälle updaten.