Bastelprojekt WLAN RGB Controller für ca. 6€

[hexenmeister]

Zu dem Thema etwas interessantes von Chinesen: http://forum.fhem.de/index.php/topic,46688.msg384273.html#msg384273
Wie blöd da auch klingt, das wäre bei praktisch fast gleichem Preis eine bessere Option

[mrpj]

Zu dem Thema etwas interessantes von Chinesen: http://forum.fhem.de/index.php/topic,46688.msg384273.html#msg384273
Wie blöd da auch klingt, das wäre bei praktisch fast gleichem Preis eine bessere Option

Das ist nichts neues - wurde von mir schon genannt:
http://forum.fhem.de/index.php/topic,34464.msg362961.html#msg362961

Aber auch da muss Hand angelegt werden, wenn man eine eigene Software drauf haben möchte (pins zum flashen)

Dann kommt noch hinzu, dass ich den teilen auch bei hohen Belastungen nicht trauen würde - am Anfang haben diese Module nicht mehr als 2A (pro Kanal) vertragen, angeblich mittlerweile 4A (pro Kanal). Bezweifel ich sehr wegen der Leiterbahnbreite

Fazit: Bessere Option zum modden eines IR-Moduls wahrscheinlich, bessere Option zu eigenem PCB und Bauteile sehe ich nicht wirklich. Daher habe ich damals auch ein PCB entworfen statt die Module zu nehmen

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

Ich warte auf Bauteile und die PCBs. Ein Teil ist da, der andere fehlt noch

Wie es mit der Software aussieht weiss ich leider nicht? Any news?

[herrmannj]

Moin, Moin,

Wie es mit der Software aussieht weiss ich leider nicht? Any news?

Dauert noch weil andere Projekt vorher anstehen.

Sorry vg
joerg

[mrpj]

Ist es möglich dass du mir den bisherigen Code frei gibst - dann kann ich die Tage vielleicht noch ein paar Zeilen weiter programmieren und es (wenn der Rest von mir ankommt) gleich mal testen?

[mrpj]

Kurzes update:
- PCBs sind angekommen
- die meisten Bauteile sind angekommen (es ist eine Packung der 2er Klemmen und die 3er Klemmen nicht angekommen - obwohl alles gleichzeitig bestellt  )

Das erste Board wurde schonmal zum testen aufgebaut - eventuell komm ich noch dazu heute/morgen eine erste Firmware zu flashen.
Wenn ich es in den nächsten Tagen ins FabLab schaffe, lass ich auchmal ein Probe Gehäuse lasern

Eine Software ist noch nicht geschrieben - jede Hilfe ist hier gerne gesehen

1) Allgemeine Funktionen:

• Protokoll für die Kommuniation entwerfen
• RGB+WW PWM Fader
• Farbübergänge (fade von farbe x zu y, Sonnenaufgang etc.)

2) Esp spezifisch:

• WifiManager (startet AP wenn nicht mit einem Router/AP verbindbar)
• ConfigurationsManager (IP, DefaultFarbe, ??)
• OTA Funktion

Als Firmware Basis greife ich auf den Arduino IDE zurück - habe bisher mehr Erfahrung mit AVRs und C gesammelt und somit kann für 1) eine C library entworfen / genommen werden die dann auch auf anderen Mikrocontrollern einsetzbar ist

Edit:
Für v1.1 kommen mir auch schon Ideen:
- Anordnung der FETs ändern um die möglicherweise flach legen zu können
- alternativ andere FETs mit gleichen Eigenschaften nehmen die an sich flach montiert werden
- Prog Schnittstelle nur zum anlöten für die erste firmware - weitere updates nur noch per OTA

[AndreasHH]

Moin,

Ich bin gerade dabei etwas ähnliches (Keller-Sensor) auf ESP8266-Basis zu programmieren.
Meine Wünsche bzgl. Konfiguration sind mit Deinen Vorstellungen vergleichbar.

Habe als Basis für meine Programmierung auf die Vorarbeit von Andreas Kriwanek zurückgegriffen.

http://www.kriwanek.de/homeautomation/esp8266-chip/532-konfiguration-der-esp8266-geraete-ueber-http.html

Sein Beispiel bringt bis auf OTA alles mit und erste Tests waren erfolgreich.

Als Protokoll nutze ich MQTT, damit sollte auch die Verwendung von verfügbaren FHEM-Modulen wie z.B. ColorPicker verwendbar sein.


Gruss

Andreas

[mrpj]

Hallo Andreas,

danke dir für den Link - ich habe auch für mich noch eine gute Library gefunden:

https://github.com/tzapu/WiFiManager

OTA lässt sich mit den Standardfunktionen der Arduino Lib implementieren.

Für die RGB (WW, CW) Ansteuerung brauche ich noch etwas mehr Unterstützung.
Ich finde gerade keine vernünftigen Algorithmen mit denen man die Farbtemperatur von WW+CW genauer bestimmen könnte.
Auch bin ich mir unsicher, wie die Konvertierung von HSV/HSI zu RGBW (welches Weiß?) machbar ist.


Ich sehe auch, dass MQTT eine gute alternative zu bytestrings bietet - damit wäre der Controller auch mit anderen Lösungen außerhalb von fhem einfach zu verbinden

[Pf@nne]

So ein Teil brauche ich später auch....

Habe momentan aber zu viele Baustellen um unterstützen zu können.
In jedem Fall würde ich für eine MQTT-ANBINDUNG pledieren!

http://forum.fhem.de/index.php/topic,46022.0.html
http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/113-mqtt-basic-esp8266-mqtt-example

[AndreasHH]

Moin,

Den WiFiManager hatte ich testweise auch genutzt. Habe dann aber den Sketch von Andreas Kriwanek als Basis genutzt, da eben auch EEPROM-Anbindung, Webserver, und MQTT recht übersichtlich implementiert ist.

Habe den Webserver und EEPROM-Bereich jetzt für meine rund 12 Sensoren angepasst.

MQTT läuft, FHEM-Anbindung läuft.

Jetzt kommen noch ein paar Sicherheitsfeatures wie Passwortschutz für Web-Zugriff, Passwortschutz für MQTT und ein paar weitere Kleinigkeiten als auch ein Code-Review.

Schätze mal nächstes WE als Beta vorzeigbar.

Hier ein Beispiel-Sketch um HSV und HSL-Daten zu verarbeiten.

http://www.jerome-bernard.com/blog/2013/01/12/rgb-led-strip-controlled-by-an-arduino/


Da auf meiner Agenda ebenfalls LED-Stripe Anbindung steht würde ich im Rahmen meiner Möglichkeiten unterstützen.


Gruss

Andreas

[herrmannj]

bei den HSV Routinen geht noch was:

das normalisieren der RGB Values ist suboptimal, man verliert viel Gesamthelligkeit.
Besser: die Korrektur in den Segmenten der HSV converters. 0,120,240 konstant. Für Gelb (60°) dann negativ korrigieren auf bspw 33°. Die genauen Werte sind für jede LED spezifisch.

Der HSV converter geht rein integer, float ist nicht notwendig.

Erst danach (HSV zu RGB) Weiß aus RGB rausrechnen (= min(R,G,B)). Dort dann ct (und stripe spezifische Weißkorrektur bei RGB stripe). Danach bei RGB-stripe wieder dazu addieren oder bei einzelnem white auf WW/CW spliten.

vg
joerg

[mrpj]

So - ich hab mal noch etwas herumgespielt und bin ziemlich begeistert wie weit die ESP8266 Arduino Lib ist.
- WifiManager ist super einfach zu integrieren und mit einem Basis Konfigurationsportal zu erweitern
- WebUpdateHttpServer ist auch sehr einfach einzubinden für einfache updates via Browser

Zum Thema Farbraum berechnen habe ich noch folgenden Link gefunden:
http://blog.saikoled.com/post/44677718712/how-to-convert-from-hsi-to-rgb-white

Hier wird vorgeschlagen den HSI Farbraum zu nutzen - irgendwie klingt das ziemlich plausibel. Beim herumspielen mit nem Farbpaletten konvertierer (http://colorizer.org/) fande ich HSI (HSL) "logisch". Sprich je pastellartiger die Farbe werden sollte, desto mehr weiss wird beigemischt. Je purer die Farbe werden sollte, desto weniger weiss ist dabei.

Erst danach (HSV zu RGB) Weiß aus RGB rausrechnen (= min(R,G,B)). Dort dann ct (und stripe spezifische Weißkorrektur bei RGB stripe). Danach bei RGB-stripe wieder dazu addieren oder bei einzelnem white auf WW/CW spliten.

Ich hinke da bei deiner vorgehensweise etwas hinterher - hast du eine konkrete Formel (oder Codeschnippsel) ? Dann kann ich es vielleicht eher nachvollziehen und selber durchrechnen zum implementieren

Moin,

Den WiFiManager hatte ich testweise auch genutzt. Habe dann aber den Sketch von Andreas Kriwanek als Basis genutzt, da eben auch EEPROM-Anbindung, Webserver, und MQTT recht übersichtlich implementiert ist.

Sicherlich nicht verkehrt - ich greife nur persönlich sehr gerne auf vorhandene libraries zurück - habe die Erfahrung gemacht, dass oftmals die Communities bei solchen Projekten sinnvolle Funktionen hinzufügen bzw. Fehlerquellen eliminieren die einem so direkt nicht aufgefallen wären.

Jetzt kommen noch ein paar Sicherheitsfeatures wie Passwortschutz für Web-Zugriff, Passwortschutz für MQTT und ein paar weitere Kleinigkeiten als auch ein Code-Review.

Die Sicherheitsfeatures fände ich sehr spannend - habe da auch schonmal dran gedacht - vielleicht in einer späteren Firmware Version, sofern die LED Treiber sauber funktionieren

Hier ein Beispiel-Sketch um HSV und HSL-Daten zu verarbeiten.

http://www.jerome-bernard.com/blog/2013/01/12/rgb-led-strip-controlled-by-an-arduino/

HSV zu RGB ist ja soweit "kein Problem" - gibt es massig Codeschnippsel für und sehr gute libraries. Wo es schwieriger wird, ist wenn noch weiss (hier dann noch Warm White und Cold White stripes) dazu kommt.

[AndreasHH]

Moin,

Sicherlich nicht verkehrt - ich greife nur persönlich sehr gerne auf vorhandene libraries zurück - habe die Erfahrung gemacht, dass oftmals die Communities bei solchen Projekten sinnvolle Funktionen hinzufügen bzw. Fehlerquellen eliminieren die einem so direkt nicht aufgefallen wären.

Du hast damit völlig recht, achte bei meiner Auswahl von libraries etc. ebenfalls darauf.

Der Beispiel-Code von Andreas Kriwanek nutzt ausschliesslich die "Standard" - Arduino-Libraries.

Beim WiFi-Manager bin ich mir dessen nicht ganz so sicher.


Wie wäre es mit Arbeitsteilung ?

Du konzentrierst Dich auf die Ansteuerung (Programmierung) der LEDs und die Hardware und ich kümmere mich um den "Rest", egal ob nun der WiFiManager oder mein Vorschlag den Zuschlag bekommt.


Evt. ist ja auch hermannj dabei und unterstützt bei der Programmierung des LED-Bereiches. 


Gruss

Andreas

[mrpj]

Ich hab mir das FHEM WifiLight Modul mal etwas genauer angeschaut - so langsam verstehe ich auch was herrmannj in Worten beschrieben hat.
Noch ein paar Gedanken dazu:
Es gibt 4 Kombinationen RGB, RGBWW, RGBCW, oder RGB WW+CW; je nachdem müssten die Farbe anders berechnet werden
- ich denke hier ist der Vorschlag von hermannj gut - wenn weiss vorhanden ist, es rauszurechnen und dann mit ww/cw oder ww+cw hinzuzuaddieren
- Dadurch dass noch extra weisskanäle vorhanden sind brauchen wir wahrscheinlich noch eine Helligkeitskorrektur damit das weiss nicht zu stark/hell wird

Die Einstellungen die ich hieraus ableite sind:
- wie wird der Controller betrieben  (RGB, RGBWW, RGBCW, RGB WW+CW)
- Helligkeitskorrektur (für weisskanäle)
- Farbtemperatur von CW / WW definieren
- Farbkorrektur

Ich denke es ist sinnvoll diese Einstellungen auf dem Controller zu hinterlegen - was meint ihr?

Was für mich noch komplett offen bleibt:
Wie verhalten sich die Farbtemperaturen 2er Lichtquellen - wenn ich nun weiß mit 2700K und weiß mit 5000K habe?
Macht es denn eigentlich Sinn Warmweiße und Kaltweiße Led Streifen gleichzeitig zu benutzen, wenn RGB Leds vorhanden sind? (Mit dem addieren von RGB Farben müsste man ja die Farbtemperatur verschieben können)

Der Beispiel-Code von Andreas Kriwanek nutzt ausschliesslich die "Standard" - Arduino-Libraries.

Beim WiFi-Manager bin ich mir dessen nicht ganz so sicher.

Der Wifi-Manager nutzt nur die Standard Libraries aus dem Arduino esp8266 board. Ich bin echt sehr positiv von dem WifiManager überrascht - auch das es möglich ist bei dem Configurationsportal relativ einfach eigene Variablen zu definieren (z.B. den mqtt broker))

Im Anhang ist der TestSketch den ich verwendet habe - wenige Zeilen durch die es einfach möglich war den WifiManager zu booten bzw. die Firmware dann über nen Browser upzudaten. War gestern nur eine Spielerei 

Wie wäre es mit Arbeitsteilung ?

Du konzentrierst Dich auf die Ansteuerung (Programmierung) der LEDs und die Hardware und ich kümmere mich um den "Rest", egal ob nun der WiFiManager oder mein Vorschlag den Zuschlag bekommt.

Sehr gerne - im Moment ist mein Verständnis von MQTT und FHEM sehr eingeschränkt.
Für das Protokoll/Funktionen dachte ich an folgendes:

- An/Aus/An mit Farbe x (hsv)
- Farbwechsel zu Farbe x (hsv) in Zeit t
- Status (An/Aus, Farbe?)
- Lese/Schreibe Konfiguration (evtl. zusätzlich via WebPortal, wenn man nicht zur Ansteuerung der Leds Wifilight/Fhem nutzt )

Nachtrag:

Zum Thema Kombination von Farbtemperaturen habe ich folgendes gefunden (Ab Seite 21 ganz interressant)
http://www.cree.com/~/media/Files/Cree/LED-Components-and-Modules/XLamp/XLamp-Application-Notes/LED_color_mixing.pdf

Auch interressant
http://apps1.eere.energy.gov/buildings/publications/pdfs/ssl/led-color-characteristics-factsheet.pdf

Um weiss zu mischen muss man scheinbar von der Ausgangstemperatur auf den CIE Farbraum umrechnen und dann kann man berechnen welche Farbtemperatur von 2 Quellen entsteht.

Beim Flux (Lichtstärke) bin ich mir nicht so ganz sicher wie man das bei den LED Stripes angeben/annehmen soll - Ideen?

[herrmannj]

Evt. ist ja auch hermannj dabei und unterstützt bei der Programmierung des LED-Bereiches.

Yepp, sehr gern. Bin an dem Projekt sehr interessiert. Durch WifiLight bin ich da auch sehr nahe dran. WifiLight macht genau das, aber eben auf fhem Seite. Mir fehlt aktuell die Zeit um das durch zu programmieren. Wenn ich mit Know How helfen darf -> sehr gern!.

Beim herumspielen mit nem Farbpaletten konvertierer (http://colorizer.org/) fande ich HSI (HSL) "logisch". Sprich je pastellartiger die Farbe werden sollte, desto mehr weiss wird beigemischt. Je purer die Farbe werden sollte, desto weniger weiss ist dabei.

Das gilt genauso für HSV und eigentlich hat sich HSV in dem Bereich auch durchgesetzt. Die Unterschiede zwischen den beiden sind im übrigen graduell. Schau mal hier http://fhem.de/commandref_DE.html#WifiLight_Farbkreis

Zitat von: herrmannj am Gestern um 23:48:04

Erst danach (HSV zu RGB) Weiß aus RGB rausrechnen (= min(R,G,B)). Dort dann ct (und stripe spezifische Weißkorrektur bei RGB stripe). Danach bei RGB-stripe wieder dazu addieren oder bei einzelnem white auf WW/CW spliten.

Ich hinke da bei deiner vorgehensweise etwas hinterher - hast du eine konkrete Formel (oder Codeschnippsel) ? Dann kann ich es vielleicht eher nachvollziehen und selber durchrechnen zum implementieren

Gern. Lass mich vorher kurz ausholen:

Folgende Funktionalität braucht es gesamt:

Die Helligkeit über alles muss logarithmisch korrigiert werden. Das macht man am besten zu erst auf dem V Kanal (HSV)
Die gesättigten (Misch-) Farben müssen korrigiert werden. Das geht am besten im HSV->RGB Konverter.
Weiß muss angepasst werden. Das Funktioniert am besten am Schluss. Dort kann man das "ausleiten" und auf WW/CW umrechnen. Das war Deine Frage, ich komm gleich dazu.

Der Konverter HSV->RGB ist eine Kernkomponente. Empfehlung, nimm ihn NICHT aus einer LIB. Das folgende Bild ist ccc von Wikipedia:
(https://upload.wikimedia.org/wikipedia/commons/5/5d/HSV-RGB-comparison.svg)
Wenn Du Dir den Bereich 0°-60° (ROT->GELB) anschaust siehst Du das ROT auf 100% bleibt und GRÜN linear von 0% bis 100% ansteigt. Das gilt analog dann für die anderen 5 Segmente. Eine Primärfarbe ist 0°, eine 100° und die dritte steigt oder fällt.

Jetzt muss man sich den PWM anschauen. Beim ESP hat er 10bit. Ergo hat jedes der 6 Segmente eine "Breite" von 2^PWM. Die Gesamte "Breite" sind also 6*2^PWM (das entspricht 360°).

Auf FW Ebene arbeitet der Converter am effizientesten wenn man ihm in der Metrik (also der PWM Weite) des mc arbeiten läßt. (Arduino = 6*2^8 / ESP =  6*2^10). Deshalb benötigt man eben auch kein float.

Korrektur gesättigter Farben: (ich habs in der Wifilight cmdref eigentlich gut erklärt, daher nur in kurz hier)
Nimm mal 60° (GELB). Da soll ROT und GRÜN gleich stark leuchten. Machts aber nicht - die grüne LED ist meist viel heller. Also darf 60° nicht aus 100% ROT und 100% GRÜN gemischt werden sondern vielleicht 100° ROT und 60° GRÜN.

Das geht am effizientesten indem man (siehe bild) den Bereich von 0° bis 60° (immer in der Metrik des mc) "verlängert" und den Bereich danach um den gleichen Betrag "verkürzt". Anders ausgedrückt. ROT bleibt länger auf 100% und GRÜN steigt weniger steil an.

Jetzt zum Weiß:
Wenn ich einen RGB Wert habe (der ja am Ausgang des HSV2RGB rauskommt) dann ist der Anteil weißen Lichtes genau die kleinste einzelne Primärfarbe.

Beispiel (Wertebereich 0..100 zur Einfachheit):
RGB:  50,80,100.
Rot 50 ist die kleinste Zahl. Also besteht diese Mischfarbe zu 50% aus Weiß. Raus rechnen aus ALLEN Kanälen macht RGB 0,30,50 PLUS 50 Weiß.

Das kann jetzt einzeln weiterverarbeitet werden.

vg
joerg

[herrmannj]

Nchtrag: rein technisch fällt Weiß schon vorher raus: im HSV2GB nimmt man den Anteil S (HSV) ja schon raus und addiert ihn am Ausgang wieder dazu.

Beispiel:

bei HSV 0,50,100 leuchten alle Kanäle mit 50% (wegen S=50). Am Ausgang eines HSV2RGB nach obigem Beispiel würde man auf die 3 RGB Kanäle 50% aufaddieren. Das würde man in der Praxis bei HSV2RGBW also schon dort aus-leiten. Das Beispiel im vorherigen Post zeigt die Theorie dahinter

vg
joerg