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