Bastelprojekt WLAN RGB Controller für ca. 6€

[mrpj]

Danke dir für die Ausführung - das hat wirklich sehr geholfen und ich blicke auch was du meinst - ich schreib kurz meine Gedanken dazu auf um zu verstehen ob das die richtige Richtung ist.

Die Helligkeit über alles muss logarithmisch korrigiert werden. Das macht man am besten zu erst auf dem V Kanal (HSV)

Hier gibt es "nur" den Wertebereich von 0 - 100 oder soll dies auch den 10bit vom PWM entsprechen?

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.

Also haben wir statt 360 einen Wertebereich von 0 - ((6*2^10)-1)
- für die Integration und das sparen von float Berechnung auf dem MC ist es dann auch besser diesen Wertebereich im Protokoll direkt zu übertragen - richtig?

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.

Also dementsprechend eine LookUp Table (oder Berechnung) die für den eigentlich INT Wert ( 0 - ((6*2^10)-1) ) einen "verschobenen" intwert im zurück gibt


Nachtrag:
Ich hab mir das noch etwas durch den Kopf gehen lassen, warum benutzen wird die Metrik des MC PWMs 8bit/10bit?
Wir haben ja für 10bit/8bit keinen linearen Anstieg sondern logarithmisch. Das Versuchen wir ja nun mit der Verschiebung auszugleichen - welchen Vorteil haben 1024 Werte gegenüber den 255 hier? Ist es so merklich bei Leds?

[herrmannj]

Die Helligkeit über alles muss logarithmisch korrigiert werden. Das macht man am besten zu erst auf dem V Kanal (HSV)

Hier gibt es "nur" den Wertebereich von 0 - 100 oder soll dies auch den 10bit vom PWM entsprechen?

Ich schlage vor das am "Eingang" einmalig von 0..100 auf die Metrik des mc umzurechnen und alles weitere (die transitions) dann in der Metrik des mc zu berechnen. Am Eingang 0.100 weil das ja der HSV Norm entspricht. Wenn danach in mc umgerechnet wird ist die fw portabel für verschiedene mc.

- für die Integration und das sparen von float Berechnung auf dem MC ist es dann auch besser diesen Wertebereich im Protokoll direkt zu übertragen - richtig?

Ich denke das ist unabhängig. Im Protokoll würde ich 0..360 lassen (siehe oben)

Also dementsprechend eine LookUp Table (oder Berechnung) die für den eigentlich INT Wert ( 0 - ((6*2^10)-1) ) einen "verschobenen" intwert im zurück gibt

loopkup mach ich das in WifiLight weil ja viele verschiedene Controller unterstützt werden. In der fw würde ich das direkt in den HSV converter nehmen weil dann weichere Übergänge möglich sind. Unten mach ich ein Beispiel.

Ich hab mir das noch etwas durch den Kopf gehen lassen, warum benutzen wird die Metrik des MC PWMs 8bit/10bit?
Wir haben ja für 10bit/8bit keinen linearen Anstieg sondern logarithmisch. Das Versuchen wir ja nun mit der Verschiebung auszugleichen - welchen Vorteil haben 1024 Werte gegenüber den 255 hier? Ist es so merklich bei Leds?

Das sind zwei verschiedene Sachen.

* Die logarithmische Korrektur der gesamten Helligkeit ist erforderlich weil der Seheindruck des Menschen so ist.
* Die Korrektur der gesättigten Farben ist erforderlich weil der Wirkungsgrad der einzelnen LEDs unterschiedlich ist. Also 100% Rot ergibt weniger Lumen als 100% Grün.

Natürlich kann man auch alles in 255 (8bit) rechnen. Dem converter und dem mc ist es in Bezug auf die Geschwindigkeit aber egal - also kann man auch gleich in der PWM Weite rechnen. Richtig ist das die logarithmische Korrektur den maximalen Bereich verringert. Aus 8bit werden dann noch ~170 (plus minus) Werte.

Der Vorschlag zum converter: ich rechne am Beispiel mit 8 bit. Die Berechnungen sind bei 10 oder 12 bit die gleichen - nur die Konstanten ändern sich.

Bezogen auf die obige Grafik ist ein Vollkreis (max Helligkeit) also 255 * 6 = 1530. Am "Eingang" also einmalig Dreissatz. 180° = 765.

Die 1530 bestehen aus 6 Segmenten. Im ersten Segment ist ROT bei 100% (=255), Blau 0% und Grün kann aus einem Dreissatz berechnet werden (erst Multiplizieren dann Dividieren um kein float zu benötigen).

Würde man jedes Segment gleich berechnen hätte das erste Segment den Bereich von 0..255, das zweite den Bereich 256..511.

Im ersten steigt Grün linear an, im zweiten wird Rot vermindert.

Die Farbkorrektur setzt jetzt so an:
Das erste Segment bekommt (zum Beispiel) den Bereich 0..350, das zweite 351..511.  Im ersten Segment steigt Grün jetzt (Dreisatz) linear an, erreicht aber erst bei 350 den Wert 255.

Beispiel: am Eingang steht jetzt Gelb -> 60°.
60*1530/360 ergibt in device Metric 255.
Im converter liegt der Bereich im ersten Segment (0..350) daher wird Grün berechnet: 255*255/350 = 185. (overflowgefahr beim multiplizieren beachten)

Ein 60° Eingang (Gelb) wird also, bereits farb-korrigiert, zu RGB 255,185,0. Das ist das gewünschte Ergebnis. ROT soll zu 100% leuchten, Grün aber weniger weil die grüne LED ja von sich aus heller ist. Im Ergebnis kommt jetzt also GELB raus.

Wenn das Gelb noch einen Grünstich hat muss man Grün verringern indem man das erste Segment vergrößern (zB 0..370) und das zweite im gleichen Zugang verkleinern (371..511). (Ergebnis wäre  so 255*255/370 = 175  -> RGB 255,175,0 -> Grünanteil bei GELB weiter verringert.)

Das funktioniert ohne lookup und mit 16- oder 32bit (ke nach PWM) Arithmetik.

Die logarithmische Korrektur der Gesamthelligkeit funktioniert über eine lookup am schnellsten.

vg
joerg

[mrpj]

Hallo Joerg,

ich danke dir für deine Geduld und ausführlichen Erklärungen!

Den Abend habe ich über die Punkte nochmal etwas nachgedacht, mit der Hand berechnet und testcode geschrieben.
Ein paar Fragen sind dabei aufgekommen/geblieben

* Die Korrektur der gesättigten Farben ist erforderlich weil der Wirkungsgrad der einzelnen LEDs unterschiedlich ist. Also 100% Rot ergibt weniger Lumen als 100% Grün.

Soweit verständlich - auch mit deinem Rechenbeispiel. Dazu aber die Frage: wäre es nicht konsequenter, die maximalen Werte von Rot/Grün/Blau zu beschränken? So dass die Lumen äquivalent sind um Helligkeitsunterschiede zu vermeiden?
z.B. Rot maximal 90%, Grün maximal 65%, BLAU maximal 100%

Richtig ist das die logarithmische Korrektur den maximalen Bereich verringert. Aus 8bit werden dann noch ~170 (plus minus) Werte.

Wenn es um die Sättigung geht wollte ich mir es ersparen 1024 Werte im progmem zu speicher, ich denke 256 würden auch reichen. Andere Ideen um die lookup table nicht unnötig groß werden zu lassen? Ich habe grob in Erinnerung das du eine Formel zur Berechnung hattest?

Die Farbkorrektur setzt jetzt so an:
Das erste Segment bekommt (zum Beispiel) den Bereich 0..350, das zweite 351..511.  Im ersten Segment steigt Grün jetzt (Dreisatz) linear an, erreicht aber erst bei 350 den Wert 255.

Beispiel: am Eingang steht jetzt Gelb -> 60°.
60*1530/360 ergibt in device Metric 255.
Im converter liegt der Bereich im ersten Segment (0..350) daher wird Grün berechnet: 255*255/350 = 185. (overflowgefahr beim multiplizieren beachten)

Ein 60° Eingang (Gelb) wird also, bereits farb-korrigiert, zu RGB 255,185,0. Das ist das gewünschte Ergebnis. ROT soll zu 100% leuchten, Grün aber weniger weil die grüne LED ja von sich aus heller ist. Im Ergebnis kommt jetzt also GELB raus.

Wenn das Gelb noch einen Grünstich hat muss man Grün verringern indem man das erste Segment vergrößern (zB 0..370) und das zweite im gleichen Zugang verkleinern (371..511). (Ergebnis wäre  so 255*255/370 = 175  -> RGB 255,175,0 -> Grünanteil bei GELB weiter verringert.)

Das Beispiel kann ich gut nachzollviehen - jetzt kommt die Frage aller Fragen, wie geht es im 2 Quadrant (60-120 Grad) weiter.

Das hier war mist:
Ich würde jetzt Grün weiterhin linear hochlaufen lassen....
Meine Berechnung wäre nun wie folgt:
Winkel in mc PWM Weite
85*1530/360 = 361;
Davon ziehe ich den Quadranten mal mc weite ab:
361 - (1*255) = 106;
Und Berechne den neuen Wert
106*255/(370-255) = 235

Falls dieser über 255 ist, dann wird er als 255 festgesetzt

Was für mich offen bleibt:
1) Wie gehe ich hier mit Rot um?
2) Wenn ich nun auch bei Rot eine verschiebung habe, wie berechne ich die dann mit ein? müsste ROT dann im 100% Bereich auch schon ab/zunehmen?


Nachtrag:

Wie ist es so schön - einfach mal ne Nacht drüber schlafen und es gibt neue Erkenntnisse 
Ich versteh jetzt die Verschiebung von Gelb, Cyan und Magenta - der Maximalpunkt von der jeweiligen steigenden Farbe wird nach links/rechts verschoben.

Was ich noch nicht ganz verstehe: wird bei Rot, Grün, Blau der Minimalpunkt verschoben (weiter links/rechts) oder wird der Maximalpunkt nach links/rechts verschoben?


Nachtrag 2:
So nochmals bischen nachgedacht und nachgerechnet:
Statt 6 Abschnitte zu haben, macht es zur Berechnung Sinn nur 3 Abschnitt heranzuziehen. In jedem dieser 3 Abschnitte wird von einem Farbpärchen eine Farbe addiert bzw. weg genommen. Wenn wir jetzt diesen Prozess auf 120Grad statt auf 60Grad ausdehnen und die verschobenen Gradzahlen als Grundlage nehmen, dann lässt sich das einfach berechnen.

Beispiel
Rot/Grün
p = 256 (mc PWM-Weite)

Verschiebung von Gelb um 20Grad nach Rot
Korrigierter Wertebereich:
k1 = p+((20/60) *p) = 256+((20/60)*256) = 341

Grün nimmt von 0 - 120 Grad zu und wird so berechnet:
mcHue = Hue*(p*6)/360 = vereinfacht Hue*p/60


Grün = min((mcHue *p/ k1), p)
Beispiel bei  Hue = 60:
Grün = min((256 * 256/341), 256) = 192

Beispiel bei Hue = 90
Grün = min((384*256)/ 341, 256) = min(280, 256) = 256

Rot lässt sich wie folgt berechnen
Rot = min((2*p - mcHue)/k2, p)

Ich bin mir gerade nur nicht sicher wie effizient diese Berechnung ist?

Dann kommt noch eine andere Frage: wenn ich weniger Grün im Gelb habe, wie sollte die Verschiebung von Gelb in Grad aussehen:
z.B. -20grad oder +20grad. Bevor ich es anders herum wie in wifilight implementiere



Nachtrag 3

Ich bin mir gerade doch nicht sicher ob diese Implementierung mit der Verschiebung übereinstimmt.

Ich hab mir gerade nochmal die fastled Library Implementierung angeschaut und im Wiki dort auch noch was ganz spannendes gefunden:
https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors

[AndreasHH]

Moin,

wie es aussieht geht es vorran,

ich könnte gut etwas input brauchen um die Grundprogrammierung voran zu treiben.

Speziell Anforderungen an die Speicherung von Werten im EEPROM (Groesse, Variablen-Typ, Bezeichnung, Korrekturwerte etc.) ?

Wie stellt Ihr euch die Grundfunktionen der Web-Oberfläche vor?

Im 1. Schritt (Alpha-Version) würde ich mich gern auf die Grundfunktionen beschränken.
- Grundkonfiguration (WLAN, MQTT-Anbindung, WiFiLight etc. , Konfiguration RGB mit Korrekturwerten)
- Grundlegende Sicherheitsmechanismen (Authentifizierung sowohl für Webserver als auch für MQTT) jeweils optional.
- Speicherung des aktuellen Status im EEPROM (Spannung weg wg. Lichtschalter off etc., like HUE)

Gruss

Andreas

[herrmannj]

Hi Andreas,

ein Moin aus der Hansestadt zurück

bzgl fw ist mrpj im lead. Allerdings habe ich seine edits jetzt erst  gesehen. Besser neuen Beitrag, sonst sieht man das nicht.

FastLED ist mMn die beste lib. Leider auch relativ komplex. Ich hatte die mir mal angeschaut dann aber Abstand davon genommen weil ich annehme das eine Eigenentwicklung der benötigten Teile schneller wäre als Einarbeitung und Anpassung.

Der Rainbow mode macht Sinn (Gelb ist tatsächlich unfassbar schmal). Die Kehrseite ist das andere LEDs das typischerweise nicht so machen (Spektrum) und es daher zu Farb- Unterschieden kommt wenn man "normale" LEDs gleichzeitig und synchron ansteuert. Das wiederum ist durchaus gebräuchlich.

Farbkorrektur 6 vs 3 Segmente. Wenn Du nur 3 Korrekturpunkte nimmst (CMY) stimmen unter bestimmten Umständen die Primärfarben nicht mehr. Beispiel: Magenta und Gelb werden jeweils um -20° korrigiert. Dann ist das komplette Segment verschoben und auch ROT wird um -20° korrigiert - wird deutlich LILA. Deshalb verwende ich 6 Punkte und habe den Bereich auf +/- 29° begrenzt. Bei Gelb reichen -29 gerade eben (bei den Leuchtmitteln die ich in der Hand hatte) wenn GRÜN sehr viel heller ist als ROT. Man kann halt nur einen Tod sterben. Mehr als 29° geht nicht weil man sich die Punkte treffen (ROT + 30° und GELB -30° sind identisch).

- Grundkonfiguration (WLAN, MQTT-Anbindung, WiFiLight etc. , Konfiguration RGB mit Korrekturwerten)

WifiLight würde keinen Sinn mehr machen wenn der controller transitions etc selber kann. Dann bräuchte man nur noch die Oberfläche. Ich würde aber bei Bedarf gern ein dafür angepasstes Modul zur Verfügung stellen.

vg
joerg

[AndreasHH]

Moin,

ein Moin aus der Hansestadt zurück

Ich bin begeistert!
Ich mag kurze Wege.

Dann kann man ja evt. die Entwicklung dieses Projektes auch kombiniert voranbringen (Web, vor Ort)

Ich kann folgendes als Spielwiese anbieten:
- Haus mit rund 350qm Nutzfläche + Garten.
- Gästezimmer
- reaktivierte Elektronik-Ausstattung (lag rund 20 Jahre brach, teilweise aktualsiert)

Meine bisherigen Kenntnisse liegen in Webprogrammierung, SQL, FHEM seit 2010, Elektronik seit 1988.

Ich habe bisher allerdings null Schimmer im Bereich Programmierung von LED-Stripes im aktuellen Kontext. Dieses würde ich gerne Euch überlassen.

Daher meine Fragestellung bzgl. zu reservierender Werte im EEPROM-Bereich.

Vielleicht wäre ein persönliches Treffen (z.B. bei mir) zwecks Brainstorming und testing hilfreich.
Habe mir jetzt enstspr. MosFets bestellt um die Hardware abbilden zu können.

Habe aktuell unendlich viele Ideen bzgl. Steuerung, WEB-Oberfläche, etc., daher auch meine Anfrage nach zu berücksichtigen Einstellungen.

Gruss

Andreas

[mrpj]

So jetzt wollte ich gerade meinen Post abschicken, dann ging das Forum nicht 

Erstmal ein Hallo in die Runde zurück - ich antworte mal Andreas und danach in nem seperatn Post noch Joerg

Speziell Anforderungen an die Speicherung von Werten im EEPROM (Groesse, Variablen-Typ, Bezeichnung, Korrekturwerte etc.) ?

Der esp8266 kann auf spiffs zurück greifen - die Konfiguration kann dann bequem per datei gespeichert werden (z.B. json).
Erspart das arbeiten mit eeprom. Die Lookup Tables für die Gamma Korrektur würde ich im progmem lassen.

Wie stellt Ihr euch die Grundfunktionen der Web-Oberfläche vor?

Die WifiManager lib bietet im Grunde alle Funktionen zur "Erste Konfigurations" Oberfläche an.
https://github.com/tzapu/WiFiManager

Er ermöglicht es auch eigene Parameter für die Konfiguration zu definieren, siehe:
https://github.com/tzapu/WiFiManager#custom-parameters
Und als InoSketch
siehe Github

Mir persönlich reicht es für das Setup. Der esp8266 scannt nach APS, man connected sich und gibt dabei die Parameter für MQTT an.
Es ist scheinbar auch möglich, dem ganzen eine statische ip bzw. eine dns name zu verpassen. (Ist doch angenehm statt device IP, später nen DNS name nutzen zu können)

- Grundkonfiguration (WLAN, MQTT-Anbindung, WiFiLight etc. , Konfiguration RGB mit Korrekturwerten)

Grundkonfiguration wie oben beschrieben => WifiManager
Sobald der ESP ins heimnetz angebunden ist, finde ich es gut, wenn die Konfiguration via mqtt/fhem erfolgt.
Am wichtigsten wäre mir hier, wenn die Kommunikation (API) zw. FHEM/MQTT/ESP definiert wird bevor eine Implementierung erfolgt.
Zum Thema API/Kommunikation noch etwas weiter unten

Eventuell eine Webpage mit:

• Status (ip,dns,gateway,mqtt, )
• Einstelleung ändern (IP, DNS, Gateway, MQTT etc.)
• reset -> beim nächsten Start wieder das Konfigurationsportal vom WifiManager

Optional (mit wenig Priorität, da dies ja durch die wifilight/mqtt -> esp api geschehen soll)

• Konfiguration des Modus: RGB, RGB+Warm Weiss, RGB+Kalt Weiss, WarmWeiss + Kaltweiss, (RGB + WarmWeiss + KaltWeiss)
• Konfiguration von Weiss Farbtemperaturen
• Konfiguration von Farbkorrektur

- Grundlegende Sicherheitsmechanismen (Authentifizierung sowohl für Webserver als auch für MQTT) jeweils optional.

Wichtig zu sicher ist die OTA webseite des esp - damit nicht jemand unbefugt andere firmware aufspielen kann. Geht via der vorhanden Arduino ESP OTA Lib

Bei MQTT kenne ich mich noch nicht aus - aber wenn es möglich ist die Kommunikation ohne größeren Aufwand (Rechenkosten) zu sichern, dann immer gerne. Aber SSL ist nicht möglich, somit sind eh jegliche Methoden umsonst, denn wenn jemand im Wlan ist, kann er die Pakete mitschneiden und Passwort/Token/Challenge für einen replay nutzen

- Speicherung des aktuellen Status im EEPROM (Spannung weg wg. Lichtschalter off etc., like HUE)

Den aktuellen Status nach jedem command zu speichern würde zu viel Schreibzyklen vom eprom/spiffs verbrauchen. Einziger sinnvoller Außweg ist es, festzustellen ob noch die Versorgungsspannung anliegt, bevor der esp ohne Strom ist. Aber im Moment ist der ADC des esp nicht verbunden. Lässt sich aber mit etwas draht und 2 Wiederstände noch nachmodden falls es wichtig ist.

Ansonsten gibt es 2 Möglichkeiten
-> Via Configuration eine Standard Einstellung setzen -> Da muss mal getestet werden wie der esp auf strom an/aus reagiert
-> Nach dem booten vom ESP und wenn er mit dem Wifi connected ist den letzten Wert vom Server abfragen




API/Kommunikation
Ich hatte bisher folgendes für die Kommunikation im Kopf - Erweiterungen/Vorschläge gerne Willkommen

HSVColor(H,S,V,K,T)
T in Sekunden gibt die Zeitspanne für den Übergang zur neuen Farbe an
Bei T=0 wird die Farbe sofort gesetzt
K = Farbtemperatur von Weiss
Der Controller nutzt als Anfangsfarbe die aktuelle Farbe

HSVColor(H,S,V,K,H',S',V',K',T)
Wie davor - nur diesmal fadet der MC von HSV zu H'S'V' über T (notwendig)

RGBColor(R,G,B,W,K, T)
RGBW Farbe , W Optional
T=0 kein Übergang, sondern Farbe direkt
Falls T>0, wird im MC der HSV Wert berechnet und dann der Übergang erzeugt

RGBColor(R,G,B,W,K,R',G',B',W',K,'T)
Wie zuvor beschrieben

effect(effectname)
Startet einen vordefinierten Effekt (z.B. Sonnenaufgang, Sonnenuntergang, Kaminfeuer, Disco, Farbwechsel)

cancleTransition
Unterbricht einen Farbwechsel/Effekt

setSettings
Einstellungen für die Farbkorrektur übertragen - welche das sind muss noch ergänzt werden

status
gibt die aktuellen StatusWerte zurück (Farbe)

info
gibt Informationen über Konfiguration etc. Preis


Ich überlege auch, den HSI Farbraum mit aufzunehmen - die Funktionen brauchen jeweils kaum noch mehr Platz, wenn ich die Berechnung noch auf 32/8bit Integer Mathematik umrechnen kann, dann hat es auch keine Performance einbußen

[mrpj]

Dann kann man ja evt. die Entwicklung dieses Projektes auch kombiniert voranbringen (Web, vor Ort)

Ich nutze für gemeinsame Projekte immer gerne Github - dort lassen sich die ToDos/Informationen extrahiert in nem WikiSchreiben. Sobald vorzeigbarer/alpha Code vorhanden ist, schieb ich ihn mal hoch. Dann können wir auf unterschiedlichen Branches an der Firmware noch weiter arbeiten.

Generell würde ich hier gerne die LED Library getrennt vom ESP8266 Code halten. Änderungen können somit getrennt nachvollzogen werden

Habe mir jetzt enstspr. MosFets bestellt um die Hardware abbilden zu können.

Wie im Dezember angemerkt, habe ich 5 Platinen (inkl. aller Bauteile) über und geb die zum Selbstkostenpreis (zw. 6-8 Euro) gerne weiter. Leider fehlen noch die 3Pin Terminals und dann kann ichs gerne an interressierte rauschicken

Habe aktuell unendlich viele Ideen bzgl. Steuerung, WEB-Oberfläche, etc., daher auch meine Anfrage nach zu berücksichtigen Einstellungen.

Schreib doch mal alles auf - je mehr Input umso besser - auch gerne Kritik/Vorschläge/Wünsche

[mrpj]

Hallo Joerg

bzgl fw ist mrpj im lead. Allerdings habe ich seine edits jetzt erst  gesehen. Besser neuen Beitrag, sonst sieht man das nicht.

Ich gelobe Besserung 

FastLED ist mMn die beste lib. Leider auch relativ komplex. Ich hatte die mir mal angeschaut dann aber Abstand davon genommen weil ich annehme das eine Eigenentwicklung der benötigten Teile schneller wäre als Einarbeitung und Anpassung.

Da hast du Recht - ich habe es mir nur angeschaut um unnötige doppelte Arbeit zu vermeiden.

Der Rainbow mode macht Sinn (Gelb ist tatsächlich unfassbar schmal). Die Kehrseite ist das andere LEDs das typischerweise nicht so machen (Spektrum) und es daher zu Farb- Unterschieden kommt wenn man "normale" LEDs gleichzeitig und synchron ansteuert. Das wiederum ist durchaus gebräuchlich.

Was meinst du mit andere LEDs? Displays?

Farbkorrektur 6 vs 3 Segmente. Wenn Du nur 3 Korrekturpunkte nimmst (CMY) stimmen unter bestimmten Umständen die Primärfarben nicht mehr. Beispiel: Magenta und Gelb werden jeweils um -20° korrigiert. Dann ist das komplette Segment verschoben und auch ROT wird um -20° korrigiert - wird deutlich LILA. Deshalb verwende ich 6 Punkte und habe den Bereich auf +/- 29° begrenzt. Bei Gelb reichen -29 gerade eben (bei den Leuchtmitteln die ich in der Hand hatte) wenn GRÜN sehr viel heller ist als ROT. Man kann halt nur einen Tod sterben. Mehr als 29° geht nicht weil man sich die Punkte treffen (ROT + 30° und GELB -30° sind identisch).

Ich musste später feststellen, dass die Idee mit den 3 Sektoren im Grunde dem HSV2RGB "spektrun" von Fastled entspricht Link
Mit einer Anpassung der Helligkeit der individuellen R,G,B Werte z.B. R=1, G=0.6, B=0.7 kann man ja auch auf gewissen Maße das ausgleichen.


Ich versuche aber immernoch die Berechnungen von dir zu verstehen. Ich habe mal in nem Bild 2 geraden eingezeichnet und würde gerne Wissen, welchen Werten die Steigung 1 bzw. 2 entspricht? 
(http://forum.fhem.de/index.php?action=dlattach;topic=34464.0;attach=45528;image)
Ist 1)  GELB +30° und 2) GELB -30°? Oder andersherum?

Wie verhält sich ROT bei +/- 29° - im 6 und 1 Quadrant ist es doch auf maximum - wie kann ich dort also den Rotanteil verschieben?
Eventuell kannst du mir ja kurz die Gerade von Rot und Grün bei jeweils ROT+/- 29° und GELB +/- 29° in einer Grafik skizzieren?

[Pf@nne]

Auch von mir ein Moin!

wenn ich euch so zuhöre, dann freue ich mich schon auf das fertige Produkt!
Ich lese immer mit Spannung wie viele Möglichkeiten es gibt eine LED anzusteuern....
Habt ihr denn auch vor ein PCB zu erstellen?


Viel Erfolg weiterhin.....

[mrpj]

Moin

Habt ihr denn auch vor ein PCB zu erstellen?

Schon geschehen 
http://forum.fhem.de/index.php/topic,34464.msg368845.html#msg368845
bzw. auf Github die Dateien
https://github.com/patrickjahns/esp_rgbww_controller

Da der Ursprüngliche Thread nicht von mir war, sondern ich es nur gekapert hatte, ist es wahrscheinlich Untergegangen.
Ich werde die Woche nochmal einen seperate Thread aufmachen - eventuell in Kombination mit einer Sammelbestellung für weitere Platinen

[Pf@nne]

Super, dann kann es ja gleich losgehen.....

Ich wäre auch an einer Sammelbestellung interessiert......

[uniqueck]

Ich auch

Gesendet von meinem GT-N7100 mit Tapatalk

[AxelSchweiss]

Ich hätte Interesse an 3 bis 5 Platinen
Möchte mein Wohnzimmer fachgerecht "iluminieren" 

[Pf@nne]

Ich werde die Woche nochmal einen seperate Thread aufmachen - eventuell in Kombination mit einer Sammelbestellung für weitere Platinen

solche Sätze sind hier immer sehr gerne gelesen.....der letzte hat eine mittelschwere Lawine ausgelöst.... 

Ich möchte auch diverse sachen illuminieren, bin daher schon jetzt begeistert....