ESP RGBWW Wifi Led Controller - Support Thread

vbs · 08 September 2023, 13:01:21

Ja, ist für mich alles weiterhin recht mysteriös: also ab und zu bemerke ich, dass bei einem Controller die WebUI nicht mehr geht (Config ist aber da). Dann flashe ich neu aus FHEM und dann ist's wieder ok. Ist ne Sache von 2 Minuten.
Extrem selten hatte ich es, dass ein Controller die Config verliert. Das hatte ich vielleicht in der ganzen Zeit 4 oder 5 Mal insgesamt. In den Fällen ging jedoch immer das WebUI noch.
Ich hatte noch nie den Fall, dass WebUI und Config gleichzeitig weg waren.
Ab und zu hab ich den Fall, dass Controller einfach aus dem WLAN verschwinden, was ich dann per PowerCycle behebe.

Einige der Effekte fielen mutmaßlich auch mit Fritzbox-Reboots oder so zusammen. Also das scheint auch eine Rollte zu spielen.
Also alles schwer greifbar. Ist ja auch extrem schwer wirklich zu analysieren, was da genau passiert oder was die wirklichen Ursachen sind. Ich gehe davon aus, dass wir da nicht nur über eine Ursache (EEPROM) reden. Aber nichtsdestotrotz: das Speichern defaultmäßig auszuschalten - einfach für die Sicherheit - finde ich auch sinnvoll.

pjakobs · 08 September 2023, 13:32:56

@vbs hast Du gesehen, dass ich einen tcp framing bug ziemlich tief im lwip gefixt habe? Ich vermute, das ist das Problem, das wir von Anfang an hatten, bei dem nagelneue Controller zwar ihren AP aufmachten und auch der Webserver auf 192.168.4.1 antwortete, aber keine Daten kamen. Widerwärtiges Ding (der Bug) https://github.com/SmingHub/Sming/issues/2654

Ich muss mich mal noch um das OTA unter SMING5 auf dem ESP8266 kümmern, dann könnte ich zumindest mal eine neue 'testing' releasen, die den Bug behebt.

pj

vbs · 08 September 2023, 13:52:12

Ja, hab ich gesehen, klasse Fund!

kmxak · 31 Oktober 2023, 21:58:27

Weiß einer wo die Technischen Daten der letzten Version zu finden sind? Sagen wir mal so es fab da einen der hat gleich an 2 Controllern die Spannung falsch rum angeschlossen

Vielleicht hat ja auch einer einen Tip oder eine Idee welches Teil da zerschossen sein könnte und um was für ein Teil es sich handelt.

Die letzte Version kam ja fertig geflashed und gelötet da hab ich dann den überblick verloren was wo sitzt

pjakobs · 06 November 2023, 12:50:32

moin kmaxk, sorry, ich hatte das zwar letzte Woche schon gesehen, war aber leider ziemlich beschäftigt.
Ich kann nicht behaupten, dass ich nicht selbst jemanden sehr gut kenne, dem das schon ein oder zwei mal passiert ist. Ich fand die Klemme immer "intuitiv" falsch herum, aber das hatte sich daraus ergeben, dass der +12V Strang ja möglichst breit gleich zu den LED Kanälen rüber sollte.
Der Controller hat keine "reverse protection diode" - die Eingangsspannung geht also direkt auf den Schaltregler (das SO8 auf der rechten Seite). Ich hatte bisher keine Platinen, die bei kurzer falscher Beschaltung die Grätsche gemacht haben, aber ich könnte mir vorstellen, dass eben jener Schaltregler da nach ein paar Sekunden ein Problem bekommt. Ob der ESP dabei was abbekommen hat kann ich nicht sagen, glaube ich allerdings eher nicht, weil die 3.3V Schiene hinter dem MOSFET im Schaltregler hängt und höchstens über den Spannungsteiler für die feedback Spannung negativ beaufschlagt wird.
Aber sein kann das natürlich auch.
Wenn Du noch ein Eagle 7 hast, kannst Du Dir das Design hier ansehen: https://github.com/pljakobs/esp_rgbww_controller/tree/v3.0

tl/dr: sorry, keine Ahnung, hab ich so noch nicht gesehen, aber ich vermute der Schaltregler.

pj

pjakobs · 06 November 2023, 13:03:11

und damit es hier auch gesehen wird: mag jemand an der nächsten Version mitarbeiten?

https://forum.fhem.de/index.php?topic=135661.msg1292213#msg1292213

kmxak · 06 November 2023, 19:24:24

hi, danke für die infos... ich hatte noch keine Zeit mir das näher anzusehen. Das der Chip womöglich einen weg hat dachte ich mir schon bzw. ist erstmal das logische. Weiß nicht was mit dem passieren kann aber so wie ich mein Netzteil deute habe ich nun einen Kurzschluss. Den ESP kann ich ja extern bestromen und testen die Tage.

Zu deinem neuen Projekt: Also das GUI nutze ich tatsächlich häufig bei mir aber das mag ja bei jedem anders sein. Was mich ein wenig an dem alten stört ist: Der verpolungsschutz, keine oder mir unbekannte api, mqtt war nur zwischen den controllern zum synchronisieren gedacht (was man aber auch gut gebrauchen kann) aber damit ließe sich das auch gut in andere Smarthome Systeme einbauen.

Ich hatte auch schon mal Tasmota auf dem Controller drauf das ging auch aber ich bin dann doch zurück. Ich finde das Fading besonders bei längeren Strips mit mehr Stromverbrauch doch recht nützlich.

Ich kann leider nicht so viel zur Softwareentwicklung beisteuern aber wenn du ein Gehäuse brauchst (3D Druck) würde ich wieder etwas beisteuern soweit ich kann.

pjakobs · 07 November 2023, 10:09:46

Ich hab mal die Dokumentation der Hardware, an der ich gerade arbeite upgedatet. https://github.com/pljakobs/RGBWW32C3/tree/Ureg

kmxak · 07 November 2023, 20:36:56

Zitat von: pjakobs am 07 November 2023, 10:09:46Ich hab mal die Dokumentation der Hardware, an der ich gerade arbeite upgedatet. https://github.com/pljakobs/RGBWW32C3/tree/Ureg

dort steht überall 12V? Warum nicht 24V? Ich habe noch nie 12V Stripes verbaut.

pjakobs · 07 November 2023, 21:59:32

wird, ich hab MOSFETs gefunden, die 30V und 11A abkönnen

pj

vbs · 09 November 2023, 08:27:57

Zitat von: kmxak am 06 November 2023, 19:24:24Was mich ein wenig an dem alten stört ist: Der verpolungsschutz, keine oder mir unbekannte api, mqtt war nur zwischen den controllern zum synchronisieren gedacht (was man aber auch gut gebrauchen kann) aber damit ließe sich das auch gut in andere Smarthome Systeme einbauen.

Selbstverständlich hat der bestehende Controller eine API. Diese API kann per HTTP, aber auch gleichermaßen per MQTT angesteuert werden - wie im Wiki beschrieben. Jedes Smarthome System, das HTTP oder MQTT sprechen kann, kann den Controller steuern. FHEM und auch die WebUI machen auch nichts anderes als diese API zu nutzen.

kmxak · 10 November 2023, 21:46:53

Zitat von: vbs am 09 November 2023, 08:27:57
Zitat von: kmxak am 06 November 2023, 19:24:24Was mich ein wenig an dem alten stört ist: Der verpolungsschutz, keine oder mir unbekannte api, mqtt war nur zwischen den controllern zum synchronisieren gedacht (was man aber auch gut gebrauchen kann) aber damit ließe sich das auch gut in andere Smarthome Systeme einbauen.
Selbstverständlich hat der bestehende Controller eine API. Diese API kann per HTTP, aber auch gleichermaßen per MQTT angesteuert werden - wie im Wiki beschrieben. Jedes Smarthome System, das HTTP oder MQTT sprechen kann, kann den Controller steuern. FHEM und auch die WebUI machen auch nichts anderes als diese API zu nutzen.

Früher hieß es doch das der Mqtt nur zum Controller Sync ist? Oder hat sich da Firmwaretechnisch was geändert?

pjakobs · 11 November 2023, 11:30:09

Zitat von: kmxak am 10 November 2023, 21:46:53
Zitat von: vbs am 09 November 2023, 08:27:57
Zitat von: kmxak am 06 November 2023, 19:24:24Was mich ein wenig an dem alten stört ist: Der verpolungsschutz, keine oder mir unbekannte api, mqtt war nur zwischen den controllern zum synchronisieren gedacht (was man aber auch gut gebrauchen kann) aber damit ließe sich das auch gut in andere Smarthome Systeme einbauen.
Selbstverständlich hat der bestehende Controller eine API. Diese API kann per HTTP, aber auch gleichermaßen per MQTT angesteuert werden - wie im Wiki beschrieben. Jedes Smarthome System, das HTTP oder MQTT sprechen kann, kann den Controller steuern. FHEM und auch die WebUI machen auch nichts anderes als diese API zu nutzen.

Früher hieß es doch das der Mqtt nur zum Controller Sync ist? Oder hat sich da Firmwaretechnisch was geändert?

Du kannst jeden API Endpoint über mqtt ansprechen, Du musst soweit ich weiß nur den Endpoint mit in die entsprechende json Struktur einbauen, weil Du ja nicht den http Endpoint /color aufrufst, sondern das mqtt Topic <prefix>/<name>/command. Die API ist hier dokumentiert.

Aber Du hast recht, aktuell steht da "is currently used to synchronize multiple devices" - das ist ein bisschen irreführend. Der nächste Satz ist aber "can be used to control the exact same JSON command messages..."

pj

vbs · 11 November 2023, 12:42:24

Zitat von: pjakobs am 11 November 2023, 11:30:09Du kannst jeden API Endpoint über mqtt ansprechen, Du musst soweit ich weiß nur den Endpoint mit in die entsprechende json Struktur einbauen, weil Du ja nicht den http Endpoint /color aufrufst, sondern das mqtt Topic <prefix>/<name>/command. Die API ist hier dokumentiert.

Ja, genau so in der Art. Ich fürchte, wie das genau geht mit Steuerung über MQTT ist nirgends dokumentiert. Der Content in der MQTT-Nachricht muss gemäß JSON RPC 2.0 sein. Also mit einem Feld "method" für den Namen des Endpunkts und dann in dem Feld "params" müssen dann genau die Parameter stecken, die man sonst direkt per HTTP schicken würde. So zumindest meine vage Erinnerung.
Wenn es da Interesse dran gibt oder konkrete Fragen, kann ich da nochmal reinschauen.

kmxak · 11 November 2023, 17:08:24

Ich habe jetzt schon seit einiger Zeit alles aus Fhem nach ioBroker umgezogen und es läuft quasi nur noch die Leds da drüber, ich suche schon eine weile eine Lösung wie ich das dort direkt machen kann. Per Mqtt und Api hatte ich es noch nicht probiert. Die Wiki hatte ich irgendwie immer übersehen

Ich hatte schon mal Tasmota auf dem Controller das ging auch irgendwie. Ich müsste mich mal richtig damit auseinandersetzen. Über Weihnachten hab ich mehr Zeit