Bastelprojekt WLAN RGB Controller für ca. 6€

[mrpj]

Freu mich gerade dass so viele Leute Interresse haben sich selber die Controller zu basteln. Bin gerade etwas überrumpelt dass gleich so viele eine Platine wollen. Im Moment hatte ich eher gedacht meine nicht benötigten Platinen weiter zu geben (wenn alles getestet wurde und sicher funktioniert  ). Aber wenn so viel Interresse ist, kann man sicherlich auch eine Sammelbestellung danach aufgeben.

Der Haken ist einfach, es wird eine Gewisse Zeit dauern - Die PCBs und Bauteile kommen aus China und da sind schonmal ca 30-40 Tage Lieferzeit drinnen. Ich gehe davon aus das ich alles erst im neuen Jahr bekomme. Erst dann kann ich die Platinen und Schaltung in echt testen - mache mir da noch etwas Sorgen dass die FETs (IRLZ44N) auch wirklich komplett bei 3.3V schalten. Laut Datenblatt sollte es so sein, aber man weiss ja nie 

Lange Rede kurzer Sinn - für mein Bauchgefühl ist es mir lieber eine echte Sammelbestellung zu machen, wenn ich das Board real testen konnte. Wer gerne das Risiko eingehen möchte auch schon davor ein kleines Bastelprojekt zu haben, für den kann ich sicherlich die Bauteile mitbestellen. 

OK, dann ohne Eagle:
- ich würde das Bauteil über GPIO15 anders anbinden (thermisch symmetrisch, d.h. links und rechts gleicher Leiterbahnquerschnitt)
- dito für R4
- dito für CH_PD
- IN+ schöner machen 
- IN- statt 90° zweimal 45°
- Anbindung CW linker Pin ist etwas "unorthodox", würde ich anders machen
- C1 ist zu dicht am Platinenrand, nach rechts verschieben

Vielen Dank dir für die Hinweise
Tut mir Leid dass ich gerade erst so spät darauf antworten kann - musste die Schaltung nochmal zeichnen (die Eagle Dateien waren auf nem Rechner bei mir an der Arbeit und ich hatte vergessen die auf einen USB Stick mitzunehmen  ).
Im Anhang sind die neuen Eagle Dateien + Bilder - deine Anmerkungen sind soweit umgesetzt.

Welchen Leiterbahnabstand nimmt Du? Ich würde min. 0.15 mm nehmen (Design Rule). Ggf. mit den Regeln von dfrobot.com testen (die von ITead sind etwas "laxer").

Im Moment ist es noch auf 6mil eingestellt. Da ich bei dirtypcb die Platinen herstellen lassen, sollte es nach deren Regeln gehen - hab zur Sicherheit auch die von dfrobot angewendet und passt soweit alles. (Bis auf das die Polygon Linien zu schmal sein sollen  )

Die Versionsnummer würde ich in v1.0 ändern und ggf. im Kupfer machen.

Versionsnummer ist geändert - Logo wollte ich auf dem Silkscreen drucken lassen

Gibt es ein Gehäuse dazu?

Ich hatte vor mal den Lasercutter in dem FabLab hier um die Ecke zu testen - dachte mir da an eine einfache Box mit passenden Aussparrungen und Lüftungsschlitzen. Das ganze geht mit Acryl (teurer) oder 4mm MDF. Sobald ich ne Zeichnung davon hab, lad ichs gerne hoch



Irgendjemand hatte noch nach der Auflistung der Bauteile gefragt, finden den Post gerade blos nicht mehr. Aber hier dennoch mal die benötigten Bauteile

• 1x ESP8266, ESP-12 format
• 1x XM1584 Power converter
• 5x IRLZ44N Mosfet (logic level gate threshold)
• 8x 10k resistors, 0603 format
• 1x 470 µF Elko RM 3.5 mm
• 1x 5,08mm 2pin terminal block
• 1x 5,08mm 3pin terminal block
• 1x 5,08mm 4pin terminal block
• 1x 2,54mm 4pin header
• 1x Micro SMD Tact Switch 2 pin 3*6*2.5 mm 

Alles zusammen nicht viel, je nachdem bei welchem Händler auf aliexpress man bestellt komm ich gerade auf ca. 6Euro pro Board


Nachtrag:
Ich habe die Dateien aus dem Beitrag entfernt und auf github verschoben.
Repository ist hier zu finden: https://github.com/patrickjahns/esp_rgbww_controller

[AxelSchweiss]

Lässt sich anstatt des ESP-12 auch ein ESP-07 verwenden?
Der Vorteil wäre das es noch einen Antennenanschluss gibt für besseren Empfang.
Pinkompatibel scheinen sie zu sein.

[mrpj]

An sich sollte es kein Problem sein - von den Dimensionen ist der ESP-07 etwas kürzer, aber die Pinouts sollten auf der gleichen Höhe sein (Sofern sich die Hersteller daran halten...)
Ich finde den 12er "praktischer" - viel mehr Antennenfläche ist in einem Laptop auch nicht drin

[ThomasW]

Hallo ,

Bitte vormerken,
ich würde gerne auch zwei haben wollen.
Ruhig auch aus einer späteren Produktion.

Gruß

ThomasW

[StefanW]

Also, um etwas für dein Bauchgefühl zu tun, würde ich zwar das Risiko eingehen, aber dann auf 1 Stück reduzieren.
So ein Bastelprojekt nebenbei ist immer nicht verkehrt.

[herrmannj]

Auch. Oder mehr. Protokoll kann ich vmtl beisteuern.

Danke und vg
Joerg

Hi @all,

Thema Protokoll:

derr Ausgang im thread war je eine MCU die den ld382 emuliert.

Im Kern war das pragmattisch und gut. Im next level sehe ich aber weitere Schritte: Beim ld382 ist es ja so das die Farbüberrgänge in wifilight gemacht werden und dann jeweils als einzelner Farbwert an den controller gehen.

Wenn wir eine eigene fw schreiben sollten die aber imho im controller abegarbeitet werden. Sprich, der controller bekommt gesagt: fade von rot nach blau und dann macht er das unabhängig vom fhem timing und viel flüssiger.

Farbraum würde ich auf HSVK erweitern (sprich HSV plus Weißtemperatur.)

Animationen (automatische Farbwechsel) im controller macht wifilight genau deshalb nicht weil die in jedem controller anders (oder ganrnicht) sind. Da stelle ich mir vor das fhem bei controller anfragt "was kannst Du?" - derf controller liefert eine Liste zurück und dann kann man die starten. So kann man zB auch "Kerzenflackern" ummstzen.

Heist: spezielles "wifilight". Die ganzen Transitions wandern aus dem modul in den controller. Wifilight hat im verlauf der Evolution ja viel drin (Farbkorrektur, Weißabgleich) was es mNn auch so sehr selten Home LED Controllern gibt. Da kann man viel know-how direkt übernehmen.

Andere/mehr Ideen ?

vg
Jörg

[mrpj]

Die Ideen dazu finde ich spannend, hab ein paar Fragen dazu:

- der esp scheint ab und an Pakete zu verlieren - wie handhaben wir das? Muss er ein ACK senden wenn das kommand angekommen ist?
- Thema Weiss und Farbtemperatur - Ich habe ja 2Weißkanäle vorgesehen - für WW,CW leds - wie kann man daraus etwas berechnen?
- Speicherplatz/RAM/Heap - da der ESP auf wenige KB begrenzt ist, müssen wir mal schauen, wieviel an vordefinierten Farbübergängen machbar ist. Hier sollten wir uns zunächst auf die wichtigsten Beschränken. Welche sind das? (Sonnenaufgang, Sonnenuntergang )
- Wie stellst du dir die Farbkorrektur/Weißabgleich vor? Werden die Settings im Wifilight eingestellt und der ESP kriegt es zugeschickt, oder wird es von fhem weiterhin gehandhabt


Das ganze ist gerade noch sehr Abstrackt - das wichtigste beim Protokoll für mich ist das Protokoll selbst, nicht die Funktionen.
Soll es UDP werden? Oder tcp? - Protokoll als RPC? Was ist hier passend?
(Ich denke ein webservice mit einem simplen rpc Protokoll ist am flexibelsten)

Nochmal einen Schritt weiter, auf welcher Basis wollen wir die Firmware entwickeln? Lua mit NodeMCU , oder C via Arduino IDE ?
Gibt es eine webserver Implementation die non-blocking bei einem request ist? (Da PWM bei beidem Softwareseitig gelöst ist, muss der request handler nicht blockierend sein, sonst flackerts bei jedem request....)

@herrmannj

Kannst du eventuell auf der Basis von deinem Wissen aus dem Wifilight Modul eine Skizze für die API/Protokoll erstellen? Also praktisch eine API Dokuementation mit den einzelnen Befehlen schreiben?




Zum Thema bestellen:
Wie oben geschrieben möchte ich hier (noch) keine Sammelbestellung starten. Ich bestell jetzt 10 Testboards aus China mit allen Bauteilen dafür. Sobald die Sachen angekommen sind frag ich nochmal nach wer gerade eins möchte zum testen. Sobald etwas Feedback vorhanden ist kann danach eine Sammelbestellung (in einem eigenen Thread dafür) gestarte werden. Übersichtshalber wäre es schön wenn wir dann hier bei der Diskussion von Hardware und Software bleiben 

[herrmannj]

- der esp scheint ab und an Pakete zu verlieren - wie handhaben wir das? Muss er ein ACK senden wenn das kommand angekommen ist?

ja, würde ich so machen wollen.
a: udp verliert halt Pakete, daher tcp
b: das modul würde ich so halten wollen das auch Funkstrecken gehen (rfm69, 2401 etc). Ist für battery device imho angenehmer.

- Thema Weiss und Farbtemperatur - Ich habe ja 2Weißkanäle vorgesehen - für WW,CW leds - wie kann man daraus etwas berechnen?

Wird in Wifilight so gemacht. Zuerst wird der Farbanteil und der Wießanteil getrennt (Saturation). Dann wird die Farbkorrektur auf den Farbanteil angewendet und (derzeit bei RGB) der Weißabgleich durchgeführt. Hier muss man dann nur zwischen CW und WW Channel gewichten um die richtigen Kelvin zu bekommen.

- Speicherplatz/RAM/Heap - da der ESP auf wenige KB begrenzt ist, müssen wir mal schauen, wieviel an vordefinierten Farbübergängen machbar ist. Hier sollten wir uns zunächst auf die wichtigsten Beschränken. Welche sind das? (Sonnenaufgang, Sonnenuntergang )

Ja, erstmall mit einigen anfangen und dann weiter sehen. Das mit dem Speicher sehe ich nicht so kritisch, da werden ja nur Vektoren hinterlegt.

- Wie stellst du dir die Farbkorrektur/Weißabgleich vor? Werden die Settings im Wifilight eingestellt und der ESP kriegt es zugeschickt, oder wird es von fhem weiterhin gehandhabt

Yepp, hier kann man eben viel Wissen aus wifilight transferieren. Der Abgleich muss im Controller gemacht werden weil er ja auf jeden einzelnen Farbwert abgebildet werden muss.

Nach so als Anhang: die Transitions werden in wifilight gradgenau berechnet. Bei einem 8bit PWM erwischt man dmit aber bei voller Helligkeit nicht die komplette Range des PWM. (3 Farben * 2^8 * 2 = 1536 vs 360°). Bei einem 12bit PWM sogar mehr. Das kann man ebenfalls nur im controller abbilden.

Das ganze ist gerade noch sehr Abstrackt - das wichtigste beim Protokoll für mich ist das Protokoll selbst, nicht die Funktionen.
Soll es UDP werden? Oder tcp? - Protokoll als RPC? Was ist hier passend?
(Ich denke ein webservice mit einem simplen rpc Protokoll ist am flexibelsten)

Ich würde auf TCP mit einfachen bytesequenzen setzen. Das skaliert imho am meisten. Einen Webserver würde ich nicht unbedingt sehen. Vielleicht für die config, aber braucht man imho nicht unbedingt (geht auch locker über telnet).

Nochmal einen Schritt weiter, auf welcher Basis wollen wir die Firmware entwickeln? Lua mit NodeMCU , oder C via Arduino IDE ?
Gibt es eine webserver Implementation die non-blocking bei einem request ist? (Da PWM bei beidem Softwareseitig gelöst ist, muss der request handler nicht blockierend sein, sonst flackerts bei jedem request....)

Ich würde C setzen, dann geht das auch gleich für Arduinos. Gibt übrigens eine gut lib (fastLED) dafür.

@herrmannj

Kannst du eventuell auf der Basis von deinem Wissen aus dem Wifilight Modul eine Skizze für die API/Protokoll erstellen? Also praktisch eine API Dokuementation mit den einzelnen Befehlen schreiben?

Gute Idee. Ersmal so als draft, und Grundlage für Ideenaustausch.
vg
joerg

[mrpj]

Danke dir für die Antworten.

Nach so als Anhang: die Transitions werden in wifilight gradgenau berechnet. Bei einem 8bit PWM erwischt man dmit aber bei voller Helligkeit nicht die komplette Range des PWM. (3 Farben * 2^8 * 2 = 1536 vs 360°). Bei einem 12bit PWM sogar mehr. Das kann man ebenfalls nur im controller abbilden.

Ja die Auflösug bei dem PWM des ESP ist da größer - soweit ich es gesehen habe sind es 10bit PWM Kanäle. Einen Haken gibt es jedoch, auch wenn theoretisch mehr Abstufungen möglich sind, so ist die Leuchtstärke von den LEDs nicht linear mit dem PWM Kanälen dimmbar, sondern folgt einer anderen Kurve. Da wäre es sinnvoll eventuell bei den 360grad zu bleiben und eine Umrechnungstabelle zu entwerfen um einen besseren Übergang zu erziehlen?

Leider habe ich bisher von HSV/HSL noch wenig Ahnung

Ich würde auf TCP mit einfachen bytesequenzen setzen. Das skaliert imho am meisten. Einen Webserver würde ich nicht unbedingt sehen. Vielleicht für die config, aber braucht man imho nicht unbedingt (geht auch locker über telnet).Ich würde C setzen, dann geht das auch gleich für Arduinos. Gibt übrigens eine gut lib (fastLED) dafür.

Ich bin mir bei TCP bytesequenzen noch nicht ganz sicher - hab jetzt nochmal bischen quer gelesen und mir erscheint die "webservice" variante schon auch sinnvoll (json-rpc) oder eine message queue variante wie auch bei openhab? Wie siehst du das?

Einen kleinen webserver fände ich zum einfachen setup schon sinnvoll. Der esp kann ja auch als AP agieren. Frei nach dem Motto, wenn kein bekanntes Netzwerk erreichbar ist nach X Sekunden dann mache einen AP auf so dass der eigentliche Router/Ap eingestellt werden kann....

Ich schau mir mal fastLED an - je weniger man selber machen muss umso besser.
Da kommt mir auch der Gedanke, ob es nicht Sinn macht die gemeinsamen Komponenten (PWM, Transitions etc.) in eine eigenen lib zu packen und dann nur noch den Gerätespezifischen Code (esp, arduino) darüber zu packen? Somit kann es auch für andere Komponente (RF, Arduinos etc.) genutzt werden

[mrpj]

Ich hab mir jetzt fastLED angeschaut - wenn ich nicht ganz falsch bin, ist es für andere LEDs gedacht und nicht für RGBWW Stripes geeignet? Vielleicht habe ich auch etwas falsch interpretiert....

Was mir noch zur Software kam: Es wäre sehr angenehm, wenn sich die Module direkt über Wifi updaten lassen. Somit muss man nur einmal am Anfang nen FTDi Kabel anschließen und dann ist gut.

[Kuzl]

Hier auch noch ne schöne idee: kann die hue Livingcolours ersetzen:

http://www.amazon.de/gp/product/B00B545UVE?ref_=gb1h_img_c-4_3647_b81dd0f4

[herrmannj]

Hi,

geht langsam weiter (Zeitmangel)

Die Funktionen zum faden habe ich rudimentär im Test (very early stage!!!).

Der converter rechnet mit der bitweite des PWM und rein integer basiert, also fix.

Erste Funktionen zur Farbkorrektur sind drin. Dies ist notwendig weil die (RGB) LED erstens pro Kanal (und Typ) einen unterschiedlichen Wirkungsgrad haben und zweitens das setup (Vorwiderstand) ja von der Schaltung abhängig ist. Das hat noch nichts mit Weißabgleich oder CW/WW zu tun. Sondern: Gelb zb ist per Definition ja ROT ung GRÜN zu gleichen Anteilen. Da im Normalfall Grün an der LED heller ist bekommt man bei einer 1:1 Mischung von R und G ein Grün mit Gelbstich. Das muss eben korrigiert werden.

Ich schaue als nächstes mal die Gammakorrektur an. Da weiß ich noch nicht genau wie ich das auf dem MC umsetze. In Wifilight gibt es dafür eine lookup table.

Hier sehe ich drei Möglichkeiten die ich untersuche:

- lookup table im progmem. Vorteil: kostet kein RAM / Nachteil: muss zur compile time passend zum pwm und zum setup erstellt werden
- lookup table im ram. Vorteil: kann zur Laufzeit erstellt und angepasst werden / Nachteil: recht groß: 1024 32bit Wörter beim ESP
- on.the-fly Berechnung (integer). Da weiß ich noch nicht wie

Wenn jemand eine elegante Möglichkeit (gern auch Näherungsweise) kennt wie man das mit Integer Math lösen kann, gerne her damit


vg
joerg

[mrpj]

Klingt doch soweit schonmal gut 

Hast du den Code eventuell schon auf github oder ähnlichem das man sich das mal anschauen kann?

Zu deinem Problem - sowie ich das gesehen habe, unterstützt der esp auch das filesystem spiffs.... Somit kann man die table dort auch indirekt als hashtable ablegen. Kommt jezt natürlich darauf an wie schnell der Zugriff erfolgen soll - aber als alternative vielleicht ne Idee

[herrmannj]

bisher nur lokal.

Wenn man so rechnet:

out = in^3 / pwm_size^2
out += (in-out)/32

stimmen die Werte mit +/- 1 mit diesen https://learn.adafruit.com/led-tricks-gamma-correction/the-quick-fix überein. Das geht ohne probleme Integer (32bit bei 10bit pwm) - damit on-the-fly.

Bei RGB zu Weiß Mischung mit Weißabgleich ist das erste bit natürlich bei R auch zuerst sichtbar - das liegt im System. Bei einer separaten white LED würde die ja angesteuert ..

Also, geht doch voran.

vg
joerg

[RappaSan]

Wie ist denn der momentane Stand der Dinge?
Gibt's was neues zu berichten?