ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[herrmannj]

hmm.. ich hab das gerade nochmal getestet und - ja, irgendwas stimmt mit den queued settings nicht. Vielleicht hat @herrmannj doch recht und wir müssen die API zum Controller serialisieren.
@mrpj hast Du ne Chance Dir mal anzusehen, was der Controller tut, wenn er direkt nacheinander Settings bekommt?
Es scheint, als ob das Verhalten da ein bisschen unvorhersagbar ist - manche Sachen funktionieren ohne Problem, manche werden einfach verschluckt.
Eigentlich will ich kein queueing bauen, weil das ja der Controller schon kann, ich denke, wenn, dann benutze ich ein semaphore internal. Nur wenn es gelöscht ist nehme ich ein set an, wenn ein set bearbeitet wird, wird das semaphore gesetzt und wieder gelöscht, wenn die <success> message vom API zurück kam. Wobei mir daran nicht gefällt, dass wir auf die Weise ggf. fhem komplett blockieren könnten...

ach, @funclass: ich hab Dir noch ein "pause" setting eingebaut. mit
Code: [Auswählen]

set LED pause n q

kannst Du jetzt bestimmen, dass die aktuelle Farbe für n Sekunden gleich bleibt.

Grüße

pj

so kompliziert ist das serialisieren doch gar nicht.

Der set wird, so wie er reinkommt, an ein array gehängt. (push)

Jedesmal wenn eine Antwort des Controllers kommt einmal schauen ob im array noch was drin ist. Wenn ja, vorne (links) raus ziehen und senden. (shift)

Dann ist das Problem, und alle evtl damit verbundenen, vom Tisch.
Wenn Du ein Flag setzt was dann folgende set blockt: was passiert wenn wenn ich über die console sowas absetzte "set LED HSV 0,0,0; set LED HSV 0,100,30 q; set HSV 30,100,60 q" ? Die set kommen ja gar nicht schnell genug raus. Entweder sie werden also verworfen oder blockieren das gesamte fhem ...

vg
joerg

[herrmannj]

super, dann lass uns dafür sorgen, dass wir da gleich bleiben!

danke.

nebenbei Jörg:
Du hast ja für die Milight Bridge Code geschrieben, der die unterschiedlichen "slots" als verschiedene Devices an der selben Bridge anbindet.
Ich hab heute mal überlegt, ob ich zusätzlich zum aktuellen Modell (RGBWWCW immer via HSV) noch einen zweite "modus" anbiete, in dem die fünf Kanäle als fünf einzelne Devices (dann halt nur in der Helligkeit steuerbar) auftauchen.
Wenn ich das richtig gesehen habe, legst Du die Information über schon benutzte slots im internen $defs{} hash ab, richtig? Im Grunde sollte das doch hier auch möglich sein. Ich stelle mir eine Art "bitmap" vor, die die schon belegten Kanäle aufzählt.
Wenn ich ein

Code Auswählen Erweitern

define LED_RGBWW LedController RGBWW <hostname>
konfiguriere, dann würden eben die Kanäle 1,2,3 und 4 als "benutzt" gekennzeichnent, und ich könnte zusätzlich ein

Code Auswählen Erweitern

define LED_W LedController white <hostname> konfigurieren, dass dann den noch freien Kanal für eine einzelne, z.B. weiße Schiene definiert.

Das sollte, äquivalent zum MifiBrige-v3 code möglich sein.
Schwierig wird es dann, einzelne Kanäle zu setzen, denn dazu müsste das RAW Kommando eben auch gezielt für einzelne Kanäle funktionieren (momentan geht, wenn ich das richtig sehe, nur das komplette Set von fünf Kanälen) oder ich müsste den aktuellen Zustand auslesen und eben nur einen veränderten Kanal setzen. Das geht prima, solange keiner der anderen Kanäle gerade in einer Transition ist, dann wären wir wieder bei der Diskussion der letzten Tage, allerdings erschwert durch die Tatsache, dass sich der "laufende" Kanal auch noch zwischen "get" und "set" verändert hätte.

hmm..

Grüße

pj

Das sollte funktionieren. Also, so vom Grundsatz. Man könnte auch ein zweistufiges modul schreiben. Das milight modul wurde ja auch von wifilight geforked- da haben die das dann auch zweistufig umgestellt. Mir ging es darum es dem user so einfach wie möglich zu machen.

Beim controller hier hat das aber einen Haken - die Transitions können ja nicht pro channel abgearbeitet werden. Man müsste über raw gehen und Transitions und queues dann im modul machen. Das wäre dann die Disziplin von WifiLight. Vielleicht sollte man diesen mode in WifiLight abbilden, das würde gehen.

vg
joerg

[funclass]

Anbei mal das Logfile (Verbose 5) beim Senden von 3 Befehlen in die Que. Leider wenig aussagekräftig.

1. per Sub in myUtils

Code Auswählen Erweitern


sub myTest() {
fhem "set rgb_stripe1 HSV 0,100,5 10";
fhem "set rgb_stripe1 HSV 200,100,5 10 q";
fhem "set rgb_stripe1 HSV 0,100,0 10 q";
}

Code Auswählen Erweitern


2016.06.24 22:54:36 5: rgb_stripe1 called with HSV
2016.06.24 22:54:36 5: rgb_stripe1 called with HSV
2016.06.24 22:54:36 5: rgb_stripe1 called with HSV


2. per Kommandofeld

Code Auswählen Erweitern

set rgb_stripe1 HSV 0,100,5 10;set rgb_stripe1 HSV 200,100,5 10 q;set rgb_stripe1 HSV 0,100,0 10 q;

Code Auswählen Erweitern


2016.06.24 22:55:39 5: rgb_stripe1 called with HSV
2016.06.24 22:55:39 5: rgb_stripe1 called with HSV
2016.06.24 22:55:39 5: rgb_stripe1 called with HSV


Beide Male ohne jegliche Reaktion des RGB-Controllers.

[pjakobs]

so kompliziert ist das serialisieren doch gar nicht.

Der set wird, so wie er reinkommt, an ein array gehängt. (push)

Jedesmal wenn eine Antwort des Controllers kommt einmal schauen ob im array noch was drin ist. Wenn ja, vorne (links) raus ziehen und senden. (shift)

Dann ist das Problem, und alle evtl damit verbundenen, vom Tisch.
Wenn Du ein Flag setzt was dann folgende set blockt: was passiert wenn wenn ich über die console sowas absetzte "set LED HSV 0,0,0; set LED HSV 0,100,30 q; set HSV 30,100,60 q" ? Die set kommen ja gar nicht schnell genug raus. Entweder sie werden also verworfen oder blockieren das gesamte fhem ...

vg
joerg

@mrpj hat weiter oben mal geschrieben, dass die <success> Meldung vom API kommt, sobald die Daten übernommen wurden - was aber nicht unbedingt heißt, dass das neue Setting auf dem Controller schon gequeued ist, also weiß ich leider nicht, wann der Controller sicher das nächste Setting entgegennehmen könnte.
und ja, dass ein flag fhem blockieren würde ist mir während des Schreibens aufgegangen, keine gute Idee.
Die Serialisierung über Array würde funktionieren, wenn ich mich darauf verlassen kann, dass die Antwort des Controllers bedeutet "ich bin bereit für den nächsten Befehl".
Da muss Patrick mal was zu sagen.
Wenn Du bei jedem neuen set die Queue checkst - wie stellst Du dann sicher, dass das letzte Setting durchgeführt wird, wenn davor noch eines in der Queue war?
Eigentlich müsstest Du dann doch nach dem letzten "set" nochmal so lange triggern, bis die Queue leer ist.

[pjakobs]

Anbei mal das Logfile (Verbose 5) beim Senden von 3 Befehlen in die Que. Leider wenig aussagekräftig.

1. per Sub in myUtils

Code Auswählen Erweitern


sub myTest() {
fhem "set rgb_stripe1 HSV 0,100,5 10";
fhem "set rgb_stripe1 HSV 200,100,5 10 q";
fhem "set rgb_stripe1 HSV 0,100,0 10 q";
}

Code Auswählen Erweitern


2016.06.24 22:54:36 5: rgb_stripe1 called with HSV
2016.06.24 22:54:36 5: rgb_stripe1 called with HSV
2016.06.24 22:54:36 5: rgb_stripe1 called with HSV


2. per Kommandofeld

Code Auswählen Erweitern

set rgb_stripe1 HSV 0,100,5 10;set rgb_stripe1 HSV 200,100,5 10 q;set rgb_stripe1 HSV 0,100,0 10 q;

Code Auswählen Erweitern


2016.06.24 22:55:39 5: rgb_stripe1 called with HSV
2016.06.24 22:55:39 5: rgb_stripe1 called with HSV
2016.06.24 22:55:39 5: rgb_stripe1 called with HSV


Beide Male ohne jegliche Reaktion des RGB-Controllers.

Ich hab's nachvollziehen können und glaube zu wissen, was das Problem ist.
Der Controller kommt offenbar durcheinander, wenn man ihm die Settings zu schnell schickt.
Ich überlege noch, was die Lösung dafür ist - siehe die Diskussion mit @herrmanj

pj

edit:

gerade nochmal in den Code der Firmware geschaut - wenn ich das richtig sehe, dann kommt das <success> doch erst, wenn das Ding in der Queue ist.
Ich werd am Wochenende mal serialisieren.

pj

[herrmannj]

Die Serialisierung über Array würde funktionieren, wenn ich mich darauf verlassen kann, dass die Antwort des Controllers bedeutet "ich bin bereit für den nächsten Befehl".

Oh ja, das hatte ich einfach mal angenommen. Du hast völlig Recht, da muss #mprj was zu sagen. Oder einfach ausprobieren ...

Unter der Maßgabe das die Annahme stimmt:

Es braucht in der Tat ein Flag welches anzeigt das ein API Call unterwegs ist. Ich nenne das mal "inflight".

Wenn der Set reinkommt wird er stur an das array angehängt (pop). Danach wird geschaut ob "inflight" true ist.
  Wenn ja: nichts machen.
  Wenn nein: den API Call auslösen, "inflight" setzen

Wenn der API Call beantwortet wird, auswerten. Dann "inflight" löschen, schauen ob was im array ist.
Wenn ja, rausziehen (shift) dann den call auslösen (setzt "inflight").

Und so weiter ...

In Wifilight ist das in der llqueue und der hlqueue so implementiert. Da ist es sogar noch komplexer weil die beiden queue noch miteinander verzahnt sind, das Prinzip ist aber genau das.

vg
joerg

[mrpj]

hmm.. ich hab das gerade nochmal getestet und - ja, irgendwas stimmt mit den queued settings nicht. Vielleicht hat @herrmannj doch recht und wir müssen die API zum Controller serialisieren.
@mrpj hast Du ne Chance Dir mal anzusehen, was der Controller tut, wenn er direkt nacheinander Settings bekommt?

Kannst du mir bitte ein Logfile von der Kommunikation schicken?

Ein kurzes Testscript via python läuft bei mir ohne Probleme

Code Auswählen Erweitern

import requests
import json

url = "http://192.168.2.65/color"
pl0 = {"hsv":{"h":0.0,"s":100.0,"v":100.0,"ct":0},"cmd":"fade", "t":1000, "q": 1}
pl1 = {"hsv":{"h":0.0,"s":100.0,"v":0.0,"ct":0},"cmd":"fade", "t":1000, "q": 1}

if __name__ == '__main__':
r = requests.post(url, data=json.dumps(pl0))
r = requests.post(url, data=json.dumps(pl1))
r = requests.post(url, data=json.dumps(pl0))
r = requests.post(url, data=json.dumps(pl1))
r = requests.post(url, data=json.dumps(pl0))
r = requests.post(url, data=json.dumps(pl1))
r = requests.post(url, data=json.dumps(pl0))
r = requests.post(url, data=json.dumps(pl1))


Nachtrag: @mrpj - Du hattest oben mal geschrieben, dass Du das <200 success> schon schickst, wenn der Controller die Daten übernommen hat, also habe ich auf dieser Seite der API eigentlich keine Möglichkeit, festzustellen, ob der Controller schon wieder neue Daten entgegennehmen kann, oder?

Der Controller schickt ein OK wenn der Befehl abgearbeitet wurde (bei /color eben wenn der Befehl an die interne Verarbeitung weitergegeben wurde) - bedeutet aber nicht dass dazwischen keine Verbindung aufgebaut werden kann.
Der Verbindungsaufbau und Abarbeitung in SMING ist asynchron - zu jedem Zeitpunkt können TCP (HTTP) Verbindungen aufgebaut* werden, die Abarbeitung dieser erfolgt sequentiell (und nicht deterministisch).

* Sofern genug Puffer im LWIP TCP Connection Stack vorhanden ist - irgendwann ist der auch ausgeschöpft

@mrpj hat weiter oben mal geschrieben, dass die <success> Meldung vom API kommt, sobald die Daten übernommen wurden - was aber nicht unbedingt heißt, dass das neue Setting auf dem Controller schon gequeued ist, also weiß ich leider nicht, wann der Controller sicher das nächste Setting entgegennehmen könnte.
und ja, dass ein flag fhem blockieren würde ist mir während des Schreibens aufgegangen, keine gute Idee.

Siehe oben - die API meldet "success" wenn die Daten (an die Queue) übergeben wurden - aber nicht wenn die Daten (die Queue) abgearbeitet wurde. Ich denke da hast du mich vorher missverstanden

Die Serialisierung über Array würde funktionieren, wenn ich mich darauf verlassen kann, dass die Antwort des Controllers bedeutet "ich bin bereit für den nächsten Befehl".

Siehe oben - der Controller kann zu jedem Zeitpunkt weitere HTTP Verbindungen annehmen



Ich kenne mich nicht gut genug mit den interna von FHEM aus - aber wenn jeder Befehl (set ?) des Nutzers in einem eigenen Thread/Worker läuft, ist nie sichergestellt, dass Befehle der Reihe nacht abgearbeitet werden. Eine Serialisierung mit einer einfachen Q ist zu empfehlen.

Wenn es Probleme gibt, wäre ich wie gesagt über ein Log sehr dankbar. (Am besten von FHEM und vom Controller parallel - so dass ich nachvollziehen kann welche Befehle angekommen sind und wo der Controller Probleme haben könnte)

[vbs]

Die Farbkalibration findet im Controller statt - nicht in Wifiligt.
Bitte berichte doch ob es bei dir auch bei dem Controller aus dem Projekt vorkommt (du schreibst vom LD382 und nicht von dem Projekt) -
Ich kann keine Farbänderung bei unterschiedlichen Helligkeiten erkennen ....

Ich hab das nochmal mit diesem Controller hier nachvollzogen (32_LedController.pm von heute: https://raw.githubusercontent.com/patrickjahns/esp_rgbww_fhemmodule/dev-pj/32_LedController.pm) und der Effekt ist derselbe. Hier mal Bilder dazu (Handy natürlich farbverfälscht, aber die Grundaussage wird mMn deutlich):

So siehts aus mit "set ledNeu2 hsv 19,96,94":
https://forum.fhem.de/index.php?action=dlattach;topic=48918.0;attach=54113
* DSC_0032.JPG

Wenn ich nun nur die Helligkeit ändere auf 14 (also "set ledNeu2 hsv 19,96,14"), dann siehts so aus:
https://forum.fhem.de/index.php?action=dlattach;topic=48918.0;attach=54111
* DSC_0031.JPG

Nach meinem Verständnis hätte der Farbton unverändert bleiben sollen, wenn man die Helligkeit anpasst, oder? Darum dachte ich, man könne das evtl. über eine Farbkalibration (Mehrpunkt) hinbekommen.

[pjakobs]

@mrpj

folgendes hab ich mal getestet:

Code Auswählen Erweitern


set LED_Sc on ; set LED_Sc pause 5 q;set LED_Sc off q


ergibt als fhem log output:

Code Auswählen Erweitern


2016.06.25 13:10:17 5: LED_Sc called with on
2016.06.25 13:10:17 5: LED_Sc defaultColor: 120,40,70
2016.06.25 13:10:17 5: LED_Sc setting VAL to 70, SAT to 40 and HUE 120
2016.06.25 13:10:17 5: LED_Sc args[0] = , args[1] =
2016.06.25 13:10:17 5: LED_Sc extended args raw: a=, b=
2016.06.25 13:10:17 5: LED_Sc t= 0
2016.06.25 13:10:17 5: LED_Sc extended args: t = 0, q = false, d = 1
2016.06.25 13:10:17 5: LED_Sc: called SetHSVColor 120, 40, 70, 2700, 0, solid, false, 1)
2016.06.25 13:10:17 4: LED_Sc: encoded json data: {"hsv":{"s":"40","h":"120","ct":"2700","v":"70"},"cmd":"solid","d":"1","q":"false","t":"0"}
2016.06.25 13:10:17 4: LED_Sc: set HSV color request
2016.06.25 13:10:17 5: LED_Sc: calculated RGB as 6bb36b
2016.06.25 13:10:17 4: LED_Sc: begin Readings Update
2016.06.25 13:10:17 5: LED_Sc called with pause
2016.06.25 13:10:17 5: LED_Sc extended args raw: a=5, b=q
2016.06.25 13:10:17 5: LED_Sc t= 0
2016.06.25 13:10:17 5: LED_Sc a is numeric (5), t= 5000
2016.06.25 13:10:17 5: LED_Sc extended args: t = 5000, q = true, d = 1
2016.06.25 13:10:17 5: LED_Sc: called SetHSVColor 120, 40, 70, 2700, 5000, fade, true, 1)
2016.06.25 13:10:17 4: LED_Sc: encoded json data: {"cmd":"fade","hsv":{"ct":"2700","h":"120","v":"70","s":"40"},"t":"5000","q":"true","d":"1"}
2016.06.25 13:10:17 4: LED_Sc: set HSV color request
2016.06.25 13:10:17 5: LED_Sc: calculated RGB as 6bb36b
2016.06.25 13:10:17 4: LED_Sc: begin Readings Update
2016.06.25 13:10:17 5: LED_Sc called with off
2016.06.25 13:10:17 5: LED_Sc setting VAL to 0, keeping HUE 120 and SAT 40
2016.06.25 13:10:17 5: LED_Sc extended args raw: a=q, b=
2016.06.25 13:10:17 5: LED_Sc t= 0
2016.06.25 13:10:17 5: LED_Sc extended args: t = 0, q = true, d = 1
2016.06.25 13:10:17 5: LED_Sc: called SetHSVColor 120, 40, 0, 2700, 0, solid, true, 1)
2016.06.25 13:10:17 4: LED_Sc: encoded json data: {"cmd":"solid","hsv":{"s":"40","h":"120","ct":"2700","v":"0"},"q":"true","t":"0","d":"1"}
2016.06.25 13:10:17 4: LED_Sc: set HSV color request
2016.06.25 13:10:17 5: LED_Sc: calculated RGB as 000000
2016.06.25 13:10:17 4: LED_Sc: begin Readings Update
2016.06.25 13:10:18 4: LED_Sc: got HSV color response
2016.06.25 13:10:18 5: LED_Sc: HSV color response data {"success":true}
2016.06.25 13:10:18 4: LED_Sc: got HSV color response
2016.06.25 13:10:18 5: LED_Sc: HSV color response data {"success":true}
2016.06.25 13:10:18 4: LED_Sc: got HSV color response
2016.06.25 13:10:18 5: LED_Sc: HSV color response data {"success":true}


sprich: die api calls werden schneller abgesetzt als abgearbeitet.
Das Ergebnis: anstatt an - 5s warten - aus blitzen die LED nur kurz auf, offenbar überschreibt das dritte Setting sofort das zweite.

Controller debug reiche ich nach.

pj

[pjakobs]

nachreich

Code Auswählen Erweitern


ApplicationWebserver::onColor HSV  H 120. S 40. V 70. CT 2700
APPLedCtrl::led_callback
APPLedCtrl::save_color
ApplicationWebserver::onColor HSV  H 120. S 40. V 0. CT 2700
APPLedCtrl::led_callback
APPLedCtrl::save_color
ApplicationWebserver::onColor HSV  H 120. S 40. V 70. CT 2700
APPLedCtrl::led_callback
APPLedCtrl::save_color

hmm.... kann ich ihn dazu bringen, hier gesprächiger zu sein?

pj

nach-nachreich:

Code Auswählen Erweitern


set LED_Sc val 14;set LED_Sc val 95 5 q;set LED_Sc val 14 5 q


sollte, bei gegebenem H und S erst V auf 14, dann über 5s auf 95 und danach wieder über 5s auf 14 dimmen.

das Modul macht folgendes:

Code Auswählen Erweitern


2016.06.25 13:42:18 5: LED_Sc called with val
2016.06.25 13:42:18 5: LED_Sc setting VAL to 14, keeping HUE 351.7 and SAT 45
2016.06.25 13:42:18 5: LED_Sc extended args raw: a=, b=
2016.06.25 13:42:18 5: LED_Sc t= 0
2016.06.25 13:42:18 5: LED_Sc extended args: t = 0, q = false, d = 1
2016.06.25 13:42:18 5: LED_Sc: called SetHSVColor 351.7, 45, 14, 2700, 0, solid, false, 1)
2016.06.25 13:42:18 4: LED_Sc: encoded json data: {"d":"1","q":"false","t":"0","hsv":{"s":"45","v":"14","ct":"2700","h":"351.7"},"cmd":"solid"}
2016.06.25 13:42:18 4: LED_Sc: set HSV color request
2016.06.25 13:42:18 5: LED_Sc: calculated RGB as 241416
2016.06.25 13:42:18 4: LED_Sc: begin Readings Update
2016.06.25 13:42:18 5: LED_Sc called with val
2016.06.25 13:42:18 5: LED_Sc setting VAL to 95, keeping HUE 351.7 and SAT 45
2016.06.25 13:42:18 5: LED_Sc extended args raw: a=5, b=q
2016.06.25 13:42:18 5: LED_Sc t= 0
2016.06.25 13:42:18 5: LED_Sc a is numeric (5), t= 5000
2016.06.25 13:42:18 5: LED_Sc extended args: t = 5000, q = true, d = 1
2016.06.25 13:42:18 5: LED_Sc: called SetHSVColor 351.7, 45, 95, 2700, 5000, fade, true, 1)
2016.06.25 13:42:18 4: LED_Sc: encoded json data: {"t":"5000","q":"true","d":"1","cmd":"fade","hsv":{"s":"45","h":"351.7","ct":"2700","v":"95"}}
2016.06.25 13:42:18 4: LED_Sc: set HSV color request
2016.06.25 13:42:18 5: LED_Sc: calculated RGB as f28596
2016.06.25 13:42:18 4: LED_Sc: begin Readings Update
2016.06.25 13:42:19 5: LED_Sc called with val
2016.06.25 13:42:19 5: LED_Sc setting VAL to 14, keeping HUE 351.7 and SAT 45
2016.06.25 13:42:19 5: LED_Sc extended args raw: a=5, b=q
2016.06.25 13:42:19 5: LED_Sc t= 0
2016.06.25 13:42:19 5: LED_Sc a is numeric (5), t= 5000
2016.06.25 13:42:19 5: LED_Sc extended args: t = 5000, q = true, d = 1
2016.06.25 13:42:19 5: LED_Sc: called SetHSVColor 351.7, 45, 14, 2700, 5000, fade, true, 1)
2016.06.25 13:42:19 4: LED_Sc: encoded json data: {"hsv":{"v":"14","ct":"2700","h":"351.7","s":"45"},"cmd":"fade","d":"1","q":"true","t":"5000"}
2016.06.25 13:42:19 4: LED_Sc: set HSV color request
2016.06.25 13:42:19 5: LED_Sc: calculated RGB as 241416
2016.06.25 13:42:19 4: LED_Sc: begin Readings Update
2016.06.25 13:42:19 4: LED_Sc: got HSV color response
2016.06.25 13:42:19 5: LED_Sc: HSV color response data {"success":true}
2016.06.25 13:42:19 4: LED_Sc: got HSV color response
2016.06.25 13:42:19 5: LED_Sc: HSV color response data {"success":true}
2016.06.25 13:42:19 4: LED_Sc: got HSV color response
2016.06.25 13:42:19 5: LED_Sc: HSV color response data {"success":true}


am Controller sehe ich

Code Auswählen Erweitern


ApplicationWebserver::onColor HSV  H 351.700012207 S 45. V 95. CT 2700
ApplicationWebserver::onColor HSV  H 351.700012207 S 45. V 14. CT 2700
ApplicationWebserver::onColor HSV  H 351.700012207 S 45. V 14. CT 2700
APPLedCtrl::led_callback
APPLedCtrl::save_color


nur ein led_callback und die Befehle in veränderter Reihenfolge. Ich fürchte, hier werden API resourcen überschrieben, bevor sie freigegeben sind oder sowas.

pj

[pjakobs]

Ich hab das nochmal mit diesem Controller hier nachvollzogen (32_LedController.pm von heute: https://raw.githubusercontent.com/patrickjahns/esp_rgbww_fhemmodule/dev-pj/32_LedController.pm) und der Effekt ist derselbe. Hier mal Bilder dazu (Handy natürlich farbverfälscht, aber die Grundaussage wird mMn deutlich):

So siehts aus mit "set ledNeu2 hsv 19,96,94":
https://forum.fhem.de/index.php?action=dlattach;topic=48918.0;attach=54113
* DSC_0032.JPG

Wenn ich nun nur die Helligkeit ändere auf 14 (also "set ledNeu2 hsv 19,96,14"), dann siehts so aus:
https://forum.fhem.de/index.php?action=dlattach;topic=48918.0;attach=54111
* DSC_0031.JPG

Nach meinem Verständnis hätte der Farbton unverändert bleiben sollen, wenn man die Helligkeit anpasst, oder? Darum dachte ich, man könne das evtl. über eine Farbkalibration (Mehrpunkt) hinbekommen.

ich hab das gerade mal mit genau Deinen Werten getestet und sehe da keine deutliche Verschiebung des Farbtons.
Verwendest Du RGB+W oder nur RGB? Wenn Du weiße LED dabei hast, sind die kaltweiß oder warmweiß?

Ich kann bei mir keine Verschiebung des Farbtons erkennen, wohl aber eine mit geringerer Helligkeit abnehmende Sättigung, was meines Erachtens auf den prozentual zunehmenden Tageslichtanteil zurückzuführen ist.
Mal sehen, vielleicht hab ich noch einen Karton irgendwo, um mal nachprüfbare Bedingungen zu schaffen.

Grüße

pj

[vbs]

Ja sorry, guter Punkt: sind bei mir RGB + WarmWeiß Stripes!
Ich hatte das ganze (allerdings beim LD382) auch ohne Tageslicht (nachts) nachvollziehen können. Ich kann das gerne heute abend auch mit diesem Controller hier nochmal machen, um herauszufinden, ob es mit Tageslicht etwas zu tun hat.

[pjakobs]

Ja sorry, guter Punkt: sind bei mir RGB + WarmWeiß Stripes!
Ich hatte das ganze (allerdings beim LD382) auch ohne Tageslicht (nachts) nachvollziehen können. Ich kann das gerne heute abend auch mit diesem Controller hier nochmal machen, um herauszufinden, ob es mit Tageslicht etwas zu tun hat.

ich hab mal eine Rolle LED in einen Karton gesteckt und durch einen Diffusor (ok, einen Pringels Deckel) abfotografiert. Ich denke, das Ergebnis liegt im Rahmen dessen, was die Kamera kann. (Olympus E-PL2, Weißabgleich Kunstlicht).

Grüße

pj

PS: sollten die Farben bei Euch bräunlich dargestellt werden - ich habe das png mit eingebettetem ProFotoRGB Profil gespeichert, die meisten Browser ignorieren das geflissentlich. Ggf. im Bildbearbeitungsprogramm öffnen.

[vbs]

Das sind die gleichen H- und S-Werte wie in meinem Fall auch, oder? Sieht dann auch für mich erstmal ok aus.
Liegt das dann an meinen LED-Stripes, wenn sich das bei mir anders verhält? Könnte mir denken, dass verschiedene Stripes auch zu anderem Farbverhalten neigen. Sind bei mir güsntige AliExpress-Stripes.

[herrmannj]

Das wäre möglich wenn die Kennlinie der LED sehr unterschiedlich ist.

Probier doch mal einen anderen Stripe bei Gelegenheit ...

vg
joerg