ESP RGBWW Wifi Led Controller - Firmware vbs

[PeMue]

So, habe gestern mal bissel mit dem Controllern gespielt:

Hm, ich glaube nicht, dass der Controller als "Discolicht" missbraucht werden sollte. Aber als Test, was so alles machbar ist, bzw. wann was wie ausfällt (falls Du das herausbekommst) ist das ok 

Gruß PeMue

[Shojo]

Hm, ich glaube nicht, dass der Controller als "Discolicht" missbraucht werden sollte.

Das war ja auch nur ein Test (6 Std. lang) ob die Controller auseinander driften!

Und nein das machen sie nicht
Sehr geil!

[vbs]

  Pass mal auf, dass die Nachbarn nicht die Feuerwehr rufen ^^

Nach welcher Zeit hat sich denn dann FHEM verabschiedet? Steht etwas im Log? Ist das reproduzierbar? Controller aber stabil?
Der reine Farbwechsel sollte keine Probleme machen, der Controller sollte nicht öfter schicken als in config-events-color_interval_ms angegeben. Bin mir aber mit dem "tranisitionFinished"-Event unschlüssig. Das muss nach jeder fertigen Animation kommen. Also bei dir immer 2 Stück alle 100 ms

[Shojo]

Nach welcher Zeit hat sich denn dann FHEM verabschiedet? Steht etwas im Log? Ist das reproduzierbar?

Ja ist reproduzierbar, FHEM verabschiedet sich auch nicht wirklich (etwas blöd von mir ausgedrückt) 100% CPU load ist das Problem ^^

Controller aber stabil?

Ja die laufen und laufen und laufen....

[vbs]

Versuch mal bitte die FW im Anhang. Da sind die animationFinished-Events ausgeschaltet. Wenn es daran liegt, bau ich dafür noch nen Filter ein.

Kann es hier gerade nicht testen, da ich hier auf allen Controllern gerade noch Langzeittest laufen habe

[Shojo]

Ja, mache ich heute Abend

[dolittle]

Guten Morgen,
zuerst einmal vielen Dank für die viele Arbeit und die schnelle Kommunikation. Ich versuche gerade die Informationen des Controllers über JSON-RPC mit einer anderen Software ohne FHEM zu nutzen. Wie ich das aus dem Wiki verstanden habe sendet der Controller auf Port 9090 die Infos. Jetzt muss ich gestehen, dass ich damit noch keine Erfahrung habe. Kann ich einen Client mit CURL oder einer anderen Software z.B. REST Client (nicht programmieren) simulieren, damit ich verstehe, was hier passiert? Ich habe zwar jetzt schon einiges über JSON-RPC gelesen, aber ich finde noch nicht den richtigen Zugang dazu.

Vielen Dank schon einmal.

[vbs]

Du kannst einfache eine TCP-Verbindung auf den Port aufmachen und dir die Daten ansehen, die dann reinkommen. Sind einfach Text-Nachrichten. Du kannst z.B. auf der Konsole einfach ein "telnet <IP> 9090" machen, um zu sehen, wie es aussieht.
Dann nimmst du am besten eine JSON-Library deiner Wahl um die Daten zu parsen.

[dolittle]

Du kannst einfache eine TCP-Verbindung auf den Port aufmachen und dir die Daten ansehen, die dann reinkommen. Sind einfach Text-Nachrichten. Du kannst z.B. auf der Konsole einfach ein "telnet <IP> 9090" machen, um zu sehen, wie es aussieht.
Dann nimmst du am besten eine JSON-Library deiner Wahl um die Daten zu parsen.

Vielen Dank. Das hat geholfen. Irgendwie sieht man manchmal den Wald vor lauter Bäumen nicht.

[Shojo]

Versuch mal bitte die FW im Anhang. Da sind die animationFinished-Events ausgeschaltet.

Jo, daran lag es, jetzt steht der Disco nichts mehr im Wege

[vbs]

Jo, daran lag es, jetzt steht der Disco nichts mehr im Wege

Hm, irgendwie seltsam: ich hab es jetzt bei mir mal getestet und ich bin jetzt eigentlich der Meinung, dass das transitionFinished-Event sowieso nur kommt, wenn man der Animation einen Namen gegeben hat. Kann also eigentlich daran nicht liegen (hattest ja keine Namen).
Aber es können doch öfter Color-Events kommen als 500 ms. Nämlich es wird auch immer ein Color-Event außerhalb der Reihe geschickt, wenn eine Animation fertig geworden ist. Das wird vermutlich der Grund sein. Dafür gibt es jetzt den Config-Schalter "config-events-color_mininterval_ms", der generell ein Mindestintervall zwischen zwei Color-Events festlegt (default 500 ms).

Außerdem noch "config-events-transfin_interval_ms", der das gleiche für die TransitionFinished-Events macht (auch wenn es jetzt offenbar an denen gar nicht lag).

Das Ganze zu finden in "vbs27b"...

[vbs]

Achso: und ich hab festgestellt, dass offenbar gar nicht die FW instabil ist, sondern einfach einer meiner Controller einen Wackelkontakt hatte... wenn man ihm zu nahe gekommen ist, hat das auch einen Reboot ausgelöst 
Beim Ausprobieren, wo denn der Wackler steckt hat dann offenbar der ESP den Geist aufgegeben, jedenfalls ging bei dem dann kein WLAN mehr. Auslöten und einen neuen Einlöten hat wieder Spaß gemacht... 

[vbs]

Ich hab außerdem einen Bug im FHEM-Modul festgestellt. Der trat bei mir reproduzierbar auf wenn ich die DEF eines bestehenden Devices geändert habe. Da liefen dann beide Devices (alte und neue DEF) parallel weiter sozusagen. Könnte auch das Problem von @hanswerner1 von vor ein paar Tagen erklären. Wobei da eigentlich nicht die Rede war von DEF ändern...
Naja ist jetzt jedenfalls behoben im Modul, denke ich...

[ext23]

Die Dinger sind allesamt sehr empfindlich wenn man den Schirm etwas zu stark drückt, irgendwie gibt es da ein Kurzen. Ich hab da auch schon einen eingebüßt. Bestimmt irgend eine Charge wo die China Toleranz etwas abgedriftet ist

Und ich hab bei meinen immer noch ein kleinen Abblockkondensator zwischen, schadet nicht. Die DCDC Wandler haben teilweise eine miese Restwelligkeit.

/Daniel

Achso: und ich hab festgestellt, dass offenbar gar nicht die FW instabil ist, sondern einfach einer meiner Controller einen Wackelkontakt hatte... wenn man ihm zu nahe gekommen ist, hat das auch einen Reboot ausgelöst 
Beim Ausprobieren, wo denn der Wackler steckt hat dann offenbar der ESP den Geist aufgegeben, jedenfalls ging bei dem dann kein WLAN mehr. Auslöten und einen neuen Einlöten hat wieder Spaß gemacht... 

[vbs]

Danke für den Tipp, werde ich mal ausprobieren.

Hab gemerkt, dass die Schwellwerte für den Heap-Check in vbs27b etwas zu hoch waren und daher gelegentlich Verbindungen abgelehnt wurden. Hab nochmal eine 28b gemacht, wo das behoben sein sollte, sorry. Ich hoffe, das wärs jetzt erstmal...