Bastelprojekt WLAN RGB Controller für ca. 6€

[herrmannj]

Hi mrpj

für die API würde ich statt HSV HSVK empfehlen, zusätzlich die Kelvins für weiß.

Mein Zeichenkünste sind sichtlich noch ausbaufähig, doch so (in etwa  ) sieht es aus wenn GELB um -29° korrigiert wird:
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45572)

Die Rechnung sieht jetzt so aus wenn man 60° "reinkippt, der PWM eine Breite von von 8Bit hat:

Gesamter Farbkreis (0..360) in device umrechnen: 6 * 2^8  = 1536.
1° in entspricht in device: 1536 / 360 * 1 -> 4,266..
Sektor 1 (rot->gelb) ohne korrektur: 0..255

Jetzt korrigieren: (bei negativem Winkel den Sektor "verlängern"). Der Sektor ist nicht mehr 60° sonder 60°+29° = 89° lang.
89° entsprechen 1536 / 360 * 89 -> 379,733 "device Einheiten"
Umstellen (erst multiplizieren dann dividieren damit kein float benötigt wird):
89 * 1536 / 360 -> 379,733 -> als Integer 379.

Im(!) Converter wird jetzt alles von 0..379 als Sektor 1 betrachtet. ROT ist immer 100% und GRÜN steigt linear an.
Der Sektor 2 muss um den Betrag der bei 1 "zu viel" ist vermindert werden. Er "wäre" von 256..511 und ist jetzt von 380..511.

Jetzt zur Rechnung:

(input 60° umrechnen in device, siehe oben. Ergibt 255)

// input * 2^PWM / 360
deviceHue = input * 1536 / 360;

// Sektor finden:

if (deviceHue < 380) { // 0..380 ist der korrigierte erste Sektor
  siehe unten
  exit;
}
if (deviceHue < 512) { // 380..512 ist der korrigierte zweite Sektor
  siehe unten
  exit;
}
usw,

Der input wurde für 60° auf 255 berechnet. Ergo sind wir im ersten if - dem Sektor 1.

R = 2^PWM // ROT ist 100% im ersten Sektor
B = 0 // BLAU ist 0 im ersten Sektor.

Grün:
deviceHue 0 entspricht GRÜN 0
deviceHue 379 entspricht 100% -> 2^PWM -> 255

Dreisatz:
2^PWM / 379 * deviceHue -> 255 / 379 * 255 = 171.
Umstellen
deviceHue * 2^PWM / 379 -> 255 * 255 / 379 = 171

Für 60° mit Korrektur -29°:
R = 255
G = 171
B = 000

Lässt sich so geradlinig für jeden Sektor durchrechnen.

Passt ?

vg
joerg

[mrpj]

Hallo zusammen,

Joerg danke dir für die Beschreibung - solangsam habe ich verstanden was verschoben wird bei der Korrektur die du anwendest.
Danke dir für das Bild - es hat mir geholfen beim verstehen, ich bin doch eben manchmal nen Mensch der sowas sehen/zeichnen muss.Dann gehts schnell mit dem verstehen

Ich war mir bei vollen Farben noch nicht ganz sicher - deshalb hab ich mal kurz blau -30Grad eingezeichnet.

Nach deinen Berechnungen erweitere ich nun den 4 Bereich und verkleinere den 5 Bereich richtig?
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45578;image)


Nachdem ich mir gestern und heute noch einiges zu den Farbbereichen HSV\HSB, HSI, HSL(Lumosity), HSL(Lightness) angelesen habe, möchte ich noch einen genannten Einwand aufgreifen:

Gelb ist theoretisch doppelt so hell wie Grün und Rot (in diesem Modell). Ich bin mir gerade nicht sicher, wie man das in der Berechnung von dir korrigieren kann.
Mit den 3 Sektoren zum berechnen, könnte man das ausgleichen:
Gelb besteht dann aus 100% Farbwert Grün und 100% Farbwert Rot, Aber nur aus 50% Helligkeit Rot und 50% Helligkeit Grün
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45576;image)

Eine Verschiebung der Farbbereiche ist wie du es vorgeschlagen hast immernoch möglich:

(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45580;image)

Hier hat Gelb mehr Rot und weniger Grün. An sich liegt der 50% Punkt im Wertebereich des 2 Quadranten, aber der erste Quadrant erstreckt sich dann von 0-90 Grad und der 2Quadrant von 91-120

Was hälst du von dieser Berechnung?


zum Thema Sammelbestellung:
Wenn es soweit ist, starte ich einen seperaten Thread mit allen Informationen über das Projekt und dort lässt sich das ganze getrennt organisieren.
Um die Übersichtlichkeit zu bewahren, bitte ich euch, diesen Thread nicht weiter für Sammelbestellungsanfragen zu nutzen. Bitte wartet bis es in einem getrennten Topic besprochen werden kann

[herrmannj]

Sieht jut aus.

Die Rechnung bei den Primärfarben ist wirklich genau gleich - da braucht man das aber nur eingeschränkt.

Zu der anderen Variante: ich hab da auch mal mit rumgespielt. Hat mich aber nicht ganz überzeugt. Aber ich ich bin da auch nicht das Maß aller Dinge - warum nicht. Die Berechnung ist ja im Prinzip die gleiche nur die Konstanten sind andere.

Vielleicht ist es eine gute Idee beide Varianten anzubieten und der user kann "sein" Modell wählen. Ich schätze den zusätzlichen Code auf einige dutzend Zeilen und Speicher ist bei den mc ja eigentlich kein Problem mehr.

Unter Umständen könntest Du auch das dritte Modell (die Faktoren auf R,G,B) mit anbieten - rechnerisch ist das ja einfachste der Modelle.

Im Übrigen ist das auch schon echt abgefahren. Mir ist kein Heim LED Controller bekannt der individuelle Farbkorrekturen anbietet (Eigentlich auch kein anderer. Aber ich kenn ja auch nich alle). Zusätzlich noch das Farbmix model zur Auswahl ist echt crazy shity stuff. 

Hat echt Potential das Projekt

vg
joerg

[herrmannj]

... dann könnte man evtl später auch "Rainbow" ergänzen wenn der Sommer um ist 

[mrpj]

Hallo Joerg,

ich bin dir echt dankbar für den Austausch über die Farbmodelle und Berechnungen!

Vielleicht ist es eine gute Idee beide Varianten anzubieten und der user kann "sein" Modell wählen. Ich schätze den zusätzlichen Code auf einige dutzend Zeilen und Speicher ist bei den mc ja eigentlich kein Problem mehr.

Ja das sollte gar kein Problem sein, die Berechnung bei beidem ist ja im Grunde gleich, nur die Formal für die Gerade wird etwas anders berechnet.

Ich wollte eventuell auch noch als Berechnung HSI mit anbieten, der Blog Post von dieser LED Firma fand ich ganz spanned. Am Schluss kann dann ja jeder entscheiden, wie er es haben möchte.

Unter Umständen könntest Du auch das dritte Modell (die Faktoren auf R,G,B) mit anbieten - rechnerisch ist das ja einfachste der Modelle.

Was meinst du mit 3ten Model? einfach nur RGB als Werte übermitteln?

Im Übrigen ist das auch schon echt abgefahren. Mir ist kein Heim LED Controller bekannt der individuelle Farbkorrekturen anbietet (Eigentlich auch kein anderer. Aber ich kenn ja auch nich alle). Zusätzlich noch das Farbmix model zur Auswahl ist echt crazy shity stuff. 

Hat echt Potential das Projekt

Ich sag mal so - die fertigen Lösungen (Hue, Lightify) sind ja schon abgestimmt, da ist es nicht nötig (und Normalkunde möchte die Lampe in die Glühbirne eindrehen und dann direkt auf seinem smartphone mit einer app loslegen ohne große Konfiguration).
Spannend wäre es, wenn man den ESP zusammen mit LEDS und Trafo in E27 Fassungen verpacken kann (ähnlich den MiLights) - ich glaube das würde ne alternative sein können. (Aber: erstmal das Produkt entwerfen, Produktionsprozess planen und noch die ganzen Zertifizierungen bekommen - ich bleib dann doch lieber bei DIY )


Zum Projekt selbst:
- Ich habe mal einiges aufgeräumt und Code auf github geschoben
- Dokumentation (in Englisch) auf Github zu dem Projekt geschrieben

Links:
PCBs und Aufbauanleitung
Firmware (Ist im Moment nur ein Demo Sketch, soll als Basis dienen falls schonmal jemand die Anbindung an FHEM anfangen möchte)
RGBWWLed Library - getrennte ESP Library


Dafür habe ich gerade ein anderes Problem - der nette China Mann hat mir scheinbar kaputte/gefälschte MOSFETs geschickt. Ich hab gestern schön blöd geguckt als die LED Stripes nur leicht geleuchtet haben auf vollem PWM. Nach einigen Messen und hin und her bin ich den FETs auf die Schliche gekommen. Nach dem Datenblatt sollten die eigentlich ab 2.5V schon voll durschalten. Die 3.3v des ESP haben aber nicht gereicht - erst ab ca 4.2-4.5 volt schalten sie durch.

Die FETs aus der Apotheke (conrad) funktionieren einwandfrei - jetzt geht es daran eine neue günstige und zuverlässige Quelle für das Bauteil zu finden.      

[herrmannj]

Hi

Was meinst du mit 3ten Model? einfach nur RGB als Werte übermitteln?

Ne - vorher alle auf gleiche Helligkeit bringen - also vor dem mixen mit einen Faktor x multiplizieren wie in der ersten lib.

Ich sag mal so - die fertigen Lösungen (Hue, Lightify) sind ja schon abgestimmt, da ist es nicht nötig (und Normalkunde möchte die Lampe in die Glühbirne eindrehen und dann direkt auf seinem smartphone mit einer app loslegen ohne große Konfiguration).

Also bei den Hue weiß ichs nichht. Die ganzen anderen (milight, ld316, 382, lw12, sunricher etc) können das alle nicht. Die e27 Milight sind ja auch e27 ...

vg
joerg

[Pf@nne]

Moin,

da ich gerade in der ESP/MQTT-ANBINDUNG drinn stecke.....
Würde es euch helfen, wenn ich euch ein ESP/MQTT-Grundgerüst zur Verfügung stelle?
Ihr bräuchte dann "nur" eure Routinen zu ergänzen.

Gruß
Pf@nne

[mrpj]

Guten Abend/Nacht,

ich hab vorhin noch die Funktionen für HSV2RGB implementiert. Farbkorrektur ist auch schon möglich (hat mich nochmal einiges Gehirnschmalz spät am Abend gekostet  ). Funktioniert soweit prima - ich mach mich gerade mit Unittest schlau um mal die Fehlerrate des Algorithmus zu berechnen. Erste tests zeigten aber dass es im Rahmen von -/+ 2 (bei 10bit) ist.

Aus Spaß hab ich das auch schon auf den esp8266 geschoben und mal nen kleinen "Benchmark" drüber laufen lassen:
im Mittel 25us für die komplette Berechnung. Ich glaube das ist mehr als ausreichend - aber sicherlich geht da noch etwas Optimierung.

Am Wochenende geht es weiter mit der Library - auf dem Plan stehen transitions und die beiden anderen Farbkorrektur Modelle 

Solangsam wirds Zeit für die Anbindung an FHEM

Die ganzen anderen (milight, ld316, 382, lw12, sunricher etc) können das alle nicht. Die e27 Milight sind ja auch e27 ...

Ich meinte ja das bei Hue/Lightify(Osram) es nicht notwendig sein sollte. Zumindest hoffe ich das bei dem Preis den man dafür zahlt

Bei den ganzen Selbstbau/LED (China) geschichten ist es schon was anderes...

da ich gerade in der ESP/MQTT-ANBINDUNG drinn stecke.....
Würde es euch helfen, wenn ich euch ein ESP/MQTT-Grundgerüst zur Verfügung stelle?
Ihr bräuchte dann "nur" eure Routinen zu ergänzen.

Immer gerne - wie davor geschrieben gibts den ersten sketch schon auf github:
https://github.com/patrickjahns/esp_rgbww_firmware
Erstell dir doch einen Fork von dem ganzen und los gehts 
Wie ich mal etwas rumgeschaut habe, ist mir auch diese mqtt/pub-sub library in die Hände gekommen:
https://github.com/knolleary/pubsubclient

Ich weiss nicht inwiefern du die schon kennst bzw. das zu empfehlen ist.


Eine kurze Skizze zu Funktionen/Befehlen für die Anbindung:

http://forum.fhem.de/index.php?topic=34464.msg402346#msg402346
bzw auf Englisch in Github
https://github.com/patrickjahns/esp_rgbww_firmware#api-ideas


Wie die genaue Anbindung aussehen soll/kann, da würde ich Jörg nochmal heranziehen. Er kann sicherlich sagen, was Sinn macht im Bezug auf API & Anbindung. (Und sowie ich es verstanden habe, wollte er sich bereit erklären ja ein Modul bereit zu stellen  )

[matthias soll]

Hallo zusammen,
wie sieht es eigentlich mit dem Layout aus könnte man nicht schon Platinen bestellen?
Oder sind noch Änderungen geplant?
Gruß
Matthias

[Pf@nne]

Immer gerne - wie davor geschrieben gibts den ersten sketch schon auf github:
https://github.com/patrickjahns/esp_rgbww_firmware
Erstell dir doch einen Fork von dem ganzen und los gehts 
Wie ich mal etwas rumgeschaut habe, ist mir auch diese mqtt/pub-sub library in die Hände gekommen:
https://github.com/knolleary/pubsubclient

Ich weiss nicht inwiefern du die schon kennst bzw. das zu empfehlen ist.

Ich nutze auch den Client vom Olleary die läuft mitlerweile recht stabil!
Ich setze mich am WE mal dran. Erstmal aber nur die MQTT-Anbindung.
Ich hab Leerlauf, bis die restlichen Röheren für den ReflowOfen da sind....

Gruß
Pf@nne

[Pf@nne]

Wo finde ich die "RGBWWLed" Library?
Dein Repository ist leer....?

[RaspII]

Hi,
ich lese hier seit einiger Zeit mit, ich bin begeistert .
Gibt es schon eine Liste für die Sammelbestellung?

Gesendet von meinem SM-G900F mit Tapatalk

[mrpj]

Langer Tag, kurz noch bevor ich umfalle

Joerg ich habe nochmal über meine Idee hier nachgedacht:
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45580;image)

Das ganze macht nur Sinn, solange die Sättigung bei 100 ist. Sobald blau dazu kommt, wird die Gesammthelligkeit ja wieder angehoben.
Um das konstant zu halten, müsste man nun die Maximalgrenze der Helligkeit zu (R+B+G)/3 rechnen. Und damit wäre man bei dem HSI Model angekommen.

Somit kann ich gleich den HSI Algorithmus von hier übernehmen.
http://blog.saikoled.com/post/43693602826/why-every-led-light-should-be-using-hsi-colorspace


Eine wichtige Frage für mich
Macht es eigentlich Sinn überhaupt RGB und WarmWeiss und KaltWeiss , also alle 5 Kanäle direkt zu haben. Oder reichen eigentlich die RGB  und 1 WeissKanäle ?

Beim Entwurf vom PCB dachte ich mir, dass es eine gute Sache ist, 2 weißkanäle zu haben. Meinungen? Erfahrungswerte aus dem Alltag?

Gibt es schon eine Liste für die Sammelbestellung?

Nein und ich habe jetzt schon mehrmals darum gebeten, bitte in diesem Thread nicht immer wieder nach einer Sammelbestellung zu Fragen.
Es wird einen getrennten Beitrag dafür geben.
Bitte lasst mir doch auch die Zeit die Informationen zusammen zu schreiben, so dass es später für mich weniger Aufwand ist
(Und ich möchte heute Abend auch mal wieder ne Folge Blacklist anschauen, statt in Code oder dem FHEM Forum zu stecken )

Also Geduld haben und bis dahin Tee trinken. (Und auch gerne bei der Entwicklung der Software helfen!)

Wo finde ich die "RGBWWLed" Library?
Dein Repository ist leer....?

Die Library ist noch nicht hochgeladen - ich hatte gestern noch keine Zeit den Code noch etwas zu bereinigen. (Schnittstelle Library / hardware Code). Die bisherigen calls im Arduino Sketch werden wahrscheinlich rausfliegen und das management der Schnittstelle(PWM) durch die Library erfolgen. Wenn du den jetzigen Stand haben möchtest, schick ich ihn dir gerne zu


Mit diesen Worten Guten Nacht - ich bin ko

[herrmannj]

Hi

HSL und HSV sind unterschiedliche Möglichkeiten eine (Licht) Farbe zu beschreiben.

Wie aus HSV oder HSL dann RGB (oder RGBW, RGBWW ...) wird ist  davon unabhängig. Das überhaupt in RGB umgerechnet wird hängt ja nur damit zusammen das am Ende 3 Leds mit den Primärfarben hängen (die additiv mischen).

Eine zweite für mich wichtige Frage:
Macht es eigentlich Sinn überhaupt RGB und WarmWeiss und KaltWeiss , also alle 5 Kanäle direkt zu haben. Oder reichen eigentlich die RGB  und 1 WeissKanäle ?

Ich vermute die Frage bezieht sich auf die Ausgabe. Wenn es um die Eingabe (also die API) geht reicht HSV, HSL oder RGB. Da muss (ich sage sogar sollte) kein Weiß extra sein weil alle drei Modelle die Farbe inklusive Weiß beschreiben. Was fehlt ist die Weißtemperatur weshalb ich für HSVK (HSLK, RGBK) plädiere. Erklärung folgt.

Das ganze macht nur Sinn, solange die Sättigung bei 100 ist. Sobald blau dazu kommt, wird die Gesammthelligkeit ja wieder angehoben.
Um das konstant zu halten, müsste man nun die Maximalgrenze der Helligkeit zu (R+B+G)/3 rechnen. Und damit wäre man bei dem HSI Model angekommen.

Das stimmt so nicht ganz.
Wenn die Sättging < 100 ist kommt zwar blau dazu - dafür werden ja Grün und Rot weniger.

Beispiel: HSV ist 0,80,100

Hue 0 ist 100% rot, V "wäre" rot mit 100%. - ABER - nur zu 80% gesättigt.

Bedeutet alle Kanäle (bei RGB) 20% (100-S) an. Der Farbanteil (hier rein rot) sind S = 80%.

Wenn Du jetzt die Ausgabe auf einen reinen RGB Stripe machst rechnest Du Weiß (20%) danach auf alle Kanäle. Damit kommst Du nie über 100% und das passt bei beiden Mixer Modellen.

Alternativ (bei RGBW) wird Weiß auf die weißen LEDs gegeben und ROT leuchtet mit 80%.

Ich vermute das Du im Augenblick V gar nicht oder aber am Ausgang des Mixers berechnest. Wenn am Ausgang dann ist das ineffizient und führt bei der logarithmischen Korrektur sogar zu Fehler. (Die Farbe verändert sich bei einem fade über V).

Die logarithmische Korrektur sollte nur auf V und vor dem Mixer stattfinden.

Im Mixer kannst Du die korrigierte Helligkeit direkt mit in Berechnung einfließen lassen. Für den Sektor 1 steigt GRÜn ja linear von 0 auf 2^PWM an. Anstelle der Konstante 2^PWM muss im realen Mixer eingesetzt werden 2^PWM * (V/100), wobei V hier ohne den vorher subtrahierten Weißanteil ist. Klingt kompliziert, daher mit Beispiel:

HSV 55,80,50:

step 1 (Weiß abziehen):
Farbanteil = V * 100 / S -> umgestellt -> S * V / 100 -> 80 * 50 / 100 = 40.

55° sind Sektor 1:
Rot ist 100% (von Farbanteil) = 40%. Anstelle von
ROT = 2^PWM
im entsprechenden if (oder select):
R = 2^PWM * 40 / 100

Die gleiche Ersetzung im Dreisatz für Grün.

Dann fallen aus dem (beiden) Converter die Werte als R,G,B (evtl plus W) gleich mit der richtigen Helligkeit raus.

Danach kommt dann nur noch die Farbtemperatur für Weiß.
Bei reinen RGB stripes das R und G gewichten. R runter nehmen ergibt kälter, B verringern ergibt wärmer.

Analog bei CW/WW stripes - zwischen den beiden einfach gewichten.

vg
Jörg

[herrmannj]

ich habe gerade mal den verlinkten HSL Blogbeitrag überflogen und bin der Meinung das er das HSL Modell nicht richtig wiedergibt.

Erster deutscher Treffer zu den Unterschieden http://www.wisotop.de/hsv-und-hsl-farbmodell.shtml

Formell wird HSV so definiert wie ich den Mixer vorgeschlagen habe. Die Einwände (bei Y leuchten R und G) sind genauso klar. Daher ist das von Dir vorgeschlagene Modell (genauso wie "Rainbow" in der FastLED lib) mMn jeweils eine andere, von der Definition abweichende*, Art der HSV RGB Konvertierung. Bleibt trotzdem HSV. Mit HSL hat das nichts zu tun.

vg
joerg

Disclaimer
* "vom Standard abweichend" beinhaltet ausdrücklich keine Wertung der Eignung für den angestrebten Zweck (schönes Licht )