ESP RGBWW Wifi Led Controller - Firmware vbs

vbs · 06 Februar 2019, 12:29:36

@lou Ich meine das Synchronisieren mehrerer LED-Controller (egal ob Wifi oder 433 o.ä.), so dass sie auch bei sehr langen (über Tage/Wochen) programmierten Animationen nicht auseinander laufen.

Die Synchronisierung basiert momentan darauf, dass alle Controller sehr akkurat ihre durchlaufenen Steps zählen und dann mit dem Master abgleichen:
https://forum.fhem.de/index.php/topic,70738.msg742959/topicseen.html#msg742959

Könnte man mit der AVR-Variante etwas ähnliches/gleichwertiges machen?

lou · 06 Februar 2019, 12:47:25

Zitat von: vbs am 06 Februar 2019, 12:29:36
@lou Ich meine das Synchronisieren mehrerer LED-Controller (egal ob Wifi oder 433 o.ä.), so dass sie auch bei sehr langen (über Tage/Wochen) programmierten Animationen nicht auseinander laufen.

Die Synchronisierung basiert momentan darauf, dass alle Controller sehr akkurat ihre durchlaufenen Steps zählen und dann mit dem Master abgleichen:
https://forum.fhem.de/index.php/topic,70738.msg742959/topicseen.html#msg742959

Könnte man mit der AVR-Variante etwas ähnliches/gleichwertiges machen?

der avr macht (bei mir) nur etwas extrem simples. er sorgt für 100% stabile pwm. die leuchten/strips die ich damit ansteuere hängen an der decke oder unter der theke etc.
es geht also nur um das richtige "statische" licht. sonst nix

(dimmen per handy / tablet).
das ist wichtig wenn man z.b. eine grosse led-leuchte mit recht viel power hat. => hauptanspruch: flackerfreiers licht.

die frage ist welche ansprüche du an "synchron" stellst. ms range? us range?

für das von dir angesprochene ziel würde ich auf JEDEN fall digitale ledstrips verwenden (WS2812b etc).
dafür ist der ESP8266 (ohne alles) perfekt per SPI. die synchronisierung findet "on-strip" statt. von led zu led....

ich hab eine etwas grössere matrix so gebaut. klappt super. und prinzipiell kann man beliebig verlänger (=synchronisieren).
gesteuert wird per websockets. die daten könnte man also im lan-backend synchronisieren wenn man will (sync latenz ~ ms range). oder eben per "hardwire" seriell von strip zu strip, plus buffer je nach länge. (sync latenz sub us range).

es gibt sowohl sehr gute strips als auch kaskadierbare matrixdisplays mit dem gleichem onled-controller recht günstig.

ext23 · 06 Februar 2019, 13:12:39

Zitat von: lou am 06 Februar 2019, 12:12:35
für echte digitalstrips/matrix (z.b. WS2812b), ist dagegen der ESP8266 ohne zusätzliche fets oder uC perfekt (per SPI).
wer "nur" ledstrips steuern will sollte hier zugreifen. diese strips sind mittlerweile sehr leuchtstark und auch mit hoher leddichte/m sehr günstig.

Da würde ich kein ESP nehmen sondern richtige TP2 Player, der Sinn dieser Stripes ist ja nicht ein schönes Licht, sondern Animationen bzw. Videowände.

ext23 · 06 Februar 2019, 13:17:47

Zitat von: vbs am 06 Februar 2019, 12:29:36
@lou Ich meine das Synchronisieren mehrerer LED-Controller (egal ob Wifi oder 433 o.ä.), so dass sie auch bei sehr langen (über Tage/Wochen) programmierten Animationen nicht auseinander laufen.

Das ist ja der Sinn eines sync

Da gibt es mehrere Ansätze. Ein Takt übertragen via 433 MHz ist ja ein leichtes und mehr brauchst du ja nicht außer ein Takt. Ansonsten kannst du ja auch auf das PWM Takten, wenn die Controller im selben Raum sind zum Beispiel. Und wenn der Takt nicht reicht, du statt dessen auch Farbinformationen (oder Zeitstempel) als zusätzlichen Sync übertragen musst, kann man das ja in das PWM einarbeiten so das es optisch nicht merkbar, für ein Lichtsensor aber auswertbar ist. Diese Ansätze werden ja schon benutzt um über Licht auch Daten zu übertragen.

Da gibt es durchaus interessante Ansätze.

/Daniel

lou · 06 Februar 2019, 13:23:56

Zitat von: ext23 am 06 Februar 2019, 13:12:39
Da würde ich kein ESP nehmen sondern richtige TP2 Player, der Sinn dieser Stripes ist ja nicht ein schönes Licht, sondern Animationen bzw. Videowände.

für ein mittelgrosses matrix-display das schönes licht macht UND auch die uhrzeit/email-count/aktienticker mal anzeigt "reicht" der esp8266 zu 100%

natürlich nur wenn man lust hat sich um die software zu kümmern

mehr aufwand - aber auch flexibler. altes lied...

die aktuell erhältlichen digitalstrips/matrix sind durchaus attraktiv da sie wirklich ordentlich licht machen.. nicht nur "leuchten".
der unterschied zwischen lampe und display wird also immer weniger...

ext23 · 06 Februar 2019, 13:49:16

Die sind sogar sehr hell. Hab ne Weihnachtsanimation mit 1024 LED Matrix ins Fenster gehangen, das lief auf 10% und war trotzdem noch zu hell

/Daniel

lou · 06 Februar 2019, 13:52:42

Zitat von: ext23 am 06 Februar 2019, 13:49:16
Die sind sogar sehr hell. Hab ne Weihnachtsanimation mit 1024 LED Matrix ins Fenster gehangen, das lief auf 10% und war trotzdem noch zu hell

/Daniel

bei 5% hats geflackert ?

spass muss sein....

ext23 · 06 Februar 2019, 14:02:43

Zitat von: lou am 06 Februar 2019, 13:52:42
bei 5% hats geflackert ? spass muss sein....

Nö da flackert nichts, aber die Farben weichen dann einfach zu sehr ab. Hab das nur mit Jinx gemacht.

stefanru · 07 Februar 2019, 00:28:17

Hi vbs,

habe deine Testversion geflashed.
Leider nur die RC1 die du verlinkt hattest.
Dachte ich könnte dann per OTA auf RC3 die es ja auf github gibt.
Die option gibt es aber leider nicht.
Kann ich RC3 irgendwie flashen?
Klar ich könnte jetzt selbst kompilieren.
Vielleicht kannst du die testing Firmware bei Gelegenheit mal updaten.

Erstmal hat alles super geklappt. Flashen ging Problemlos, sonst hatte ich mit der alten Firmware öfters Probleme.
Scheint auch stabil zu laufen, hatte öfter mit resets zu kämpfen, konnte auf die schnelle keine feststellen.

Der OTA Screen zeigt bei der Firmware Version etwas komische Werte an:
Current 4.0.0-rc1
OTA 0.4.0-rc1

Siehe Screenshot.

Ich berichte über weitere Erfahrungen.

Danke,
Stefan

vbs · 07 Februar 2019, 09:55:31

Ich hatte auf meinem Testcontroller mit der RC1 und der neuen PWM-Implementierung sporadisch beim Dimmen sehr kurze und sehr subtile Blitzer/Flackereien. Die RC3 ist zwar mit dem neuen Sming aber wieder mit der alten PWM-Implementierung. Hatte ich im Prinzip nur mal für mich gemacht um zu gucken, ob damit das Flackern auch auftritt.

Kannst du ja vlt. mal drauf achten, ob es bei dir auch vorkommt. Ich fürchte, dass ich dann mittelfristig wieder zum alten PWM zurück gehen werde, da ich nicht sehe, dass das Problem zeitnah gelöst werden wird.

Danke fürs Testen! Werde mir auch anschauen, was da mit den Versionsnummern los ist!

stefanru · 07 Februar 2019, 14:34:14

Ok, ich werde das mal genau anschauen.
Gestern bei einem schnellen Test ist mir nichts aufgefallen.

Ich werde heute mal etwas hin und her dimmen

Gruß,
Stefan

vbs · 07 Februar 2019, 15:34:24

Ich meine ich hatte zum Testen eine 5 Sekunden-Rampe immer von 0% auf 100% und dann wieder zurück in einer Schleife. Evtl. war dann die Unregelmäßigkeit immer beim 50%-Übergang.

Versionsnummern müssten jetzt passen. Danke für den Hinweis.

stefanru · 07 Februar 2019, 21:45:47

Ich habe mal etwas hin und her gedimmt und habe extra drauf geachtet.
Ja es flackert etwas, besonders gut bei unter 10% erkennbar. Z.b. von 5% auf 3%.
Man merkt es auch von 0% auf 100%.

Ich muss aber sagen ich habe vorher nie so genau drauf geachtet und es wäre mir wohl auch nicht aufgefallen.
Mich stört es nicht sonderlich, aber ich verstehe schon wenn man das perfekt haben will

Ansonsten kommt es mir bisher stabiler vor.
Ist vielleicht auch Einbildung, oder ich habe es noch nicht lang genug drauf.
Mit der vorherigen Version hatte ich so 1x am Abend ein reboot des ESP.

P.S.: Versionsanzeige passt jetzt auch.
Das flashen war auf jedenfall super, es hat einfach alles auf Anhieb geklappt.
Vorher waren meine Erfahrungen beim Flashen etwas durchwachsen

Gruß und Danke,
Stefan

lou · 08 Februar 2019, 10:02:00

Zitat von: stefanru am 07 Februar 2019, 21:45:47
...Mit der vorherigen Version hatte ich so 1x am Abend ein reboot des ESP....

noch ein gedanke:

ein robustes system das den ESP8266 verwendet MUSS zwingend alle möglichen states von WIFI und CPU im betrieb abdecken/abfangen.
d.h. es muss möglich sein dass der ESP reconnects oder reboots ausführt und sporadisch hohe (lan) latenzen o.ä. handhabt, ohne dass der "normale" betrieb des systems drastisch beeinflusst wird.
das liegt in der natur von wifi/lan, und wird z.b. auch von jedem android OS so gehandhabt (modem-restarts etc).

hat man z.b. eine high-power deckenlampe, will man natürlich nicht daß die PWM bei einem wifi reconnect o.ä. gestört wird.

ein weiteres argument für einen dedizierten (hardware) PWM chip.
der ESP kann so autark im wlan werkeln, und auch mal 1-2 sekunden reconnecten/rebooten, ohne dass es die (aktuelle) PWM beeinflusst.

bei "stimmungslicht" mag das nicht besonders relevant sein. bei "beleuchtung" schon eher.

der obige anspruch wird auch erfüllt wenn die PWM/RGB daten IN den strips gespeichert werden. (z.b. digital strips = langes digitales schieberegister)

ext23 · 08 Februar 2019, 10:14:45

Zitat von: lou am 08 Februar 2019, 10:02:00
der obige anspruch wird auch erfüllt wenn die PWM/RGB daten IN den strips gespeichert werden. (z.b. digital strips = langes digitales schieberegister)

Richtig, aber wie gesagt, die wird niemand um sein Bett wickeln, dafür sind die einfach viel zu teuer. Das ist ja wie wenn ich mir ein LED TV hole und das als weißes Lichtpanel an die Decke nagel

/Daniel