ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[funclass]

Also ich hab im unteren Bereich bei diesen Werten auch einen leicht "helleren" Farbton (RGBWW), aber mEn nicht so krass wie auf den Bildern von vbs. Aus meiner Sicht könnte es wohl wirklich an unterschiedlichen LED-Stripes liegen.

[pjakobs]

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.

ich würde nochmal mit den Settings des Kontrollers experimentieren.
Welches Calculation Model hast Du eingestellt, welches Output Model? Entsprechen die Farbtemperatur-Settings für WW und CW etwa Deinen Stripes?
Die Beimischung von Weiß kann die Lichtfarbe verändern, ich weiß nicht genau, was @mrpj da rechnet, aber die Farbtemperatur der weißen Dioden ist durchaus wesentlich.

pj

[mrpj]

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 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"}


Wenn du eine Transition möchtest, dann nutze "cmd":"fade" - "solid" bedeutet, zeige Farbe x für Zeit t.

Ich habe solid gestern nicht getestet, sondern nur fade - daher lass doch bitte erstmal eine gemeinsame Basis finden um der Fehlerquelle auf die Spur zu kommen.
Eventuell teste doch mal deinen Controller mit dem von mir geposteten Python script - wenn es damit funktioniert ist die Fehlerursache eine andere

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.

Deine Befürchtung ist sehr unwahrscheinlich - bitte teste es mit dem cmd fade - es kann durchaus sein das "solid" einen Fehler enthält - ich hatte es zuletzt bei Änderungen in der RGBWW Library nicht getestet

Zur Veränderten Reihenfolge hatte ich schon etwas geschrieben:

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).

Der Logeintrag "ApplicationWebserver::onColor" bedeutet, dass dieser Befehl bei der Anwendung angekommen ist (und dieser Befehl an die Verarbeitung der RGBWW Library weitergereicht wird). In welcher Reihenfolge die Befehle ankommen ist nur vorher bestimmtbar, wenn maximal 1 konkurrente Verbindung herrscht und die Befehle sequentiell abgeschickt werden (Erst nach erfolgreiche HTTP Verbindung der nächste Befehl) - andernfalls wirst du immer das Problem haben, dass verschiedene Faktoren (Latenz, Puffer, Paketverluste) die Laufzeit eines Befehls im Netzwerk beinflussen und Befehle in anderer Reihenfolge ankommen.


Eine weiter Möglichkeit in Zukunft wäre "animationset" - eine vorbestimmte Reihenfolge von Befehlen die mit einem API call übergeben wird. (Wenn ich Zeit habe es zu implementieren)

nachreich

Code Auswählen Erweitern


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?

Im Moment nur durch eine rekompilierte Firmware in der SMING Debug angeschaltet ist. Ich hab mal schnell eine angehängt - die Version ist nicht getestet, da ich gerade keinen Controller zur Hand habe

[mrpj]

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.

Das Problem an der Geschichte ist, dass die Weißen LEDs meist wesentlich heller sind als farbige LEDs. Hinzukommt, dass unsere Augen Helligkeit nicht linear, sondern exponentiell wahrnehmen.

In dem Konkreten fall bedeutet es, dass bei dem Wert 14, die Helligkeit der weißen LEDs im Verhältnis zu den farbigen (trotz interner Korrekturkurve) höher ist und somit nehmen wir eine Farbverschiebung war.

Wenn du den weißanteil (Sättigung = 100) weglässt, müsstest du keine Verschiebung mehr wahrnehmen.

[funclass]

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

Hab`s eben mit meinem Controller auch mal via Python getestet. Funzt. Leuchte blinkt 4 Mal rot auf.

[pjakobs]

ok, dann ist es wohl irgendwas in oder um perl
Ich hab mir gerade mal die Pakete auf dem Kabel angesehen, die kommen in der richtigen Reihenfolge, aber alle innerhalb einer Milisekunde, möglich, dass das einfach zu schnell ist.
@mrpj, da jedes in einer anderen TCP Session kommt, gehe ich mal davon aus, dass die sich im Controller nicht in's Gehege kommen.

Code Auswählen Erweitern


No.     Time        Source                Destination           Protocol Length Info
     95 17.553538   192.168.29.25         192.168.29.58         TCP      74     43934→80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=190056104 TSecr=0 WS=128

Frame 95: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43934 (43934), Dst Port: 80 (80), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     96 17.561169   192.168.29.25         192.168.29.58         TCP      60     43934→80 [ACK] Seq=1 Ack=1 Win=3737600 Len=0

Frame 96: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43934 (43934), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     98 17.821190   192.168.29.25         192.168.29.58         TCP      74     43936→80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=190056131 TSecr=0 WS=128

Frame 98: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43936 (43936), Dst Port: 80 (80), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Length Info
     99 17.825508   192.168.29.25         192.168.29.58         TCP      60     43936→80 [ACK] Seq=1 Ack=1 Win=3737600 Len=0

Frame 99: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43936 (43936), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    100 18.041559   192.168.29.25         192.168.29.58         TCP      74     43938→80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=190056153 TSecr=0 WS=128

Frame 100: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43938 (43938), Dst Port: 80 (80), Seq: 0, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    101 18.050019   192.168.29.25         192.168.29.58         TCP      60     43938→80 [ACK] Seq=1 Ack=1 Win=3737600 Len=0

Frame 101: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43938 (43938), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    103 18.259555   192.168.29.25         192.168.29.58         HTTP     311    POST /color?mode=HSV HTTP/1.0  (application/x-www-form-urlencoded)

Frame 103: 311 bytes on wire (2488 bits), 311 bytes captured (2488 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43934 (43934), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 257
Hypertext Transfer Protocol
    POST /color?mode=HSV HTTP/1.0\r\n
    Host: 192.168.29.58\r\n
    User-Agent: fhem\r\n
    Accept: application/json\r\n
    Content-Length: 90\r\n
    Content-Type: application/x-www-form-urlencoded\r\n
    \r\n
    [Full request URI: http://192.168.29.58/color?mode=HSV]
    [HTTP request 1/1]
HTML Form URL Encoded: application/x-www-form-urlencoded
    Form item: "{"t":"0","q":"false","d":"1","cmd":"solid","hsv":{"h":"19","ct":"2700","v":"14","s":"96"}}" = ""
        Key: {"t":"0","q":"false","d":"1","cmd":"solid","hsv":{"h":"19","ct":"2700","v":"14","s":"96"}}
        Value:

No.     Time        Source                Destination           Protocol Length Info
    104 18.259898   192.168.29.25         192.168.29.58         HTTP     312    POST /color?mode=HSV HTTP/1.0  (application/x-www-form-urlencoded)

Frame 104: 312 bytes on wire (2496 bits), 312 bytes captured (2496 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43936 (43936), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 258
Hypertext Transfer Protocol
    POST /color?mode=HSV HTTP/1.0\r\n
    Host: 192.168.29.58\r\n
    User-Agent: fhem\r\n
    Accept: application/json\r\n
    Content-Length: 91\r\n
    Content-Type: application/x-www-form-urlencoded\r\n
    \r\n
    [Full request URI: http://192.168.29.58/color?mode=HSV]
    [HTTP request 1/1]
HTML Form URL Encoded: application/x-www-form-urlencoded
    Form item: "{"cmd":"fade","hsv":{"s":"96","v":"95","ct":"2700","h":"19"},"t":"5000","q":"true","d":"1"}" = ""
        Key: {"cmd":"fade","hsv":{"s":"96","v":"95","ct":"2700","h":"19"},"t":"5000","q":"true","d":"1"}
        Value:

No.     Time        Source                Destination           Protocol Length Info
    105 18.260477   192.168.29.25         192.168.29.58         HTTP     312    POST /color?mode=HSV HTTP/1.0  (application/x-www-form-urlencoded)

Frame 105: 312 bytes on wire (2496 bits), 312 bytes captured (2496 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43938 (43938), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 258
Hypertext Transfer Protocol
    POST /color?mode=HSV HTTP/1.0\r\n
    Host: 192.168.29.58\r\n
    User-Agent: fhem\r\n
    Accept: application/json\r\n
    Content-Length: 91\r\n
    Content-Type: application/x-www-form-urlencoded\r\n
    \r\n
    [Full request URI: http://192.168.29.58/color?mode=HSV]
    [HTTP request 1/1]
HTML Form URL Encoded: application/x-www-form-urlencoded
    Form item: "{"d":"1","q":"true","t":"5000","hsv":{"v":"34","h":"19","ct":"2700","s":"96"},"cmd":"fade"}" = ""
        Key: {"d":"1","q":"true","t":"5000","hsv":{"v":"34","h":"19","ct":"2700","s":"96"},"cmd":"fade"}
        Value:

No.     Time        Source                Destination           Protocol Length Info
    106 18.283263   192.168.29.25         192.168.29.58         TCP      60     43934→80 [ACK] Seq=258 Ack=139 Win=3842048 Len=0

Frame 106: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43934 (43934), Dst Port: 80 (80), Seq: 258, Ack: 139, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    107 18.296219   192.168.29.25         192.168.29.58         TCP      60     43934→80 [FIN, ACK] Seq=258 Ack=139 Win=3842048 Len=0

Frame 107: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43934 (43934), Dst Port: 80 (80), Seq: 258, Ack: 139, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    108 18.347781   192.168.29.25         192.168.29.58         TCP      60     43936→80 [ACK] Seq=259 Ack=139 Win=3842048 Len=0

Frame 108: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43936 (43936), Dst Port: 80 (80), Seq: 259, Ack: 139, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    109 18.349531   192.168.29.25         192.168.29.58         TCP      60     43936→80 [FIN, ACK] Seq=259 Ack=139 Win=3842048 Len=0

Frame 109: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43936 (43936), Dst Port: 80 (80), Seq: 259, Ack: 139, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    110 18.365941   192.168.29.25         192.168.29.58         TCP      60     43938→80 [ACK] Seq=259 Ack=139 Win=3842048 Len=0

Frame 110: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43938 (43938), Dst Port: 80 (80), Seq: 259, Ack: 139, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    111 18.366424   192.168.29.25         192.168.29.58         TCP      60     43934→80 [ACK] Seq=259 Ack=140 Win=3842048 Len=0

Frame 111: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43934 (43934), Dst Port: 80 (80), Seq: 259, Ack: 140, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    112 18.367208   192.168.29.25         192.168.29.58         TCP      60     43938→80 [FIN, ACK] Seq=259 Ack=139 Win=3842048 Len=0

Frame 112: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43938 (43938), Dst Port: 80 (80), Seq: 259, Ack: 139, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    113 18.374753   192.168.29.25         192.168.29.58         TCP      60     43938→80 [ACK] Seq=260 Ack=140 Win=3842048 Len=0

Frame 113: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43938 (43938), Dst Port: 80 (80), Seq: 260, Ack: 140, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    116 18.478382   192.168.29.25         192.168.29.58         TCP      60     43936→80 [ACK] Seq=260 Ack=140 Win=3842048 Len=0

Frame 116: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43936 (43936), Dst Port: 80 (80), Seq: 260, Ack: 140, Len: 0

No.     Time        Source                Destination           Protocol Length Info
    117 18.568370   192.168.29.25         192.168.29.58         TCP      60     [TCP Retransmission] 43936→80 [FIN, ACK] Seq=259 Ack=140 Win=3842048 Len=0

Frame 117: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: EdimaxTe_85:08:95 (80:1f:02:85:08:95), Dst: Espressi_d6:97:0d (18:fe:34:d6:97:0d)
Internet Protocol Version 4, Src: 192.168.29.25 (192.168.29.25), Dst: 192.168.29.58 (192.168.29.58)
Transmission Control Protocol, Src Port: 43936 (43936), Dst Port: 80 (80), Seq: 259, Ack: 140, Len: 0


Ich habe diesmal als letzten "h" Wert 34 genommen, damit erkennbar wird, ob das Ganze vielleicht verdreht wird.

Ich pack mal spaßeshalber eine kurze Verzögerung rein, ein, zwei Milisekunden würden schon genügen, denk ich.

pj

[pjakobs]

ok, mit zwei Milisekunden Verzögerung vor dem Absenden des http-Requests funktioniert es zwar insgesamt besser, es werden alle Animationsschritte übernommen, dafür  diesmal in nicht definierter Reihenfolge - was an den Paketen auf dem "Kabel" (also dem WLAN Kabel) erkennbar ist.
Die Quelle des Problems ist also der perl http Client.

Ich werd um eine Command Queue wie sie @herrmannj vorschlägt wohl nicht herumkommen.

@mrpj: was mir nebenbei aufgefallen ist, ich hatte versuchshalber ein Kommando "pause" eingebaut, einfach ein Fade vom aktuellen zum aktuellen hsv Wert mit einer Zeit - der Controlelr scheint das wegzuoptimieren. Es wäre, gerade für Animationen, schön, ihm sagen zu können "jetzt mach mal für 5 Sekunden nix!"


Grüße

pj

[vbs]

Bei mir funktionieren Ramp-Times <10 s nicht, es wird dann trotzdem sofort geschaltet.

Also das fadet in 10 Sekunden:

Code Auswählen Erweitern

set ledNeu2 hsv 0,92,100 10

Und das schaltet sofort:

Code Auswählen Erweitern

set ledNeu2 hsv 0,92,100 9

Firmware ist:

Code Auswählen Erweitern

Firmware
0.3.0
  (v0.3.0)
Web Interface
0.3.3
RGBWW Version
0.8.0
SMING Version
2.1.0

Mit 32_LedController.pm von heute mittag.

[pjakobs]

Bei mir funktionieren Ramp-Times <10 s nicht, es wird dann trotzdem sofort geschaltet.

Also das fadet in 10 Sekunden:

Code Auswählen Erweitern

set ledNeu2 hsv 0,92,100 10

Und das schaltet sofort:

Code Auswählen Erweitern

set ledNeu2 hsv 0,92,100 9

Firmware ist:

Code Auswählen Erweitern

Firmware
0.3.0
  (v0.3.0)
Web Interface
0.3.3
RGBWW Version
0.8.0
SMING Version
2.1.0

Mit 32_LedController.pm von heute mittag.

den Bug hatte ich heute Nachmittag behoben, aber noch nicht gepushed. Hing mit der Umstellung auf "float" für den Zeit Parameter zusammen. ich push gleich nochmal.

pj

[vbs]

Danke dir, aber keine Eile, ist ja nicht so wild. Wollte es nur brav melden 

[pjakobs]

Danke dir, aber keine Eile, ist ja nicht so wild. Wollte es nur brav melden 

wenn's mit einem einfachen push getan ist, kann ich's ja auch gleich machen

pj

[mrpj]

ok, mit zwei Milisekunden Verzögerung vor dem Absenden des http-Requests funktioniert es zwar insgesamt besser, es werden alle Animationsschritte übernommen, dafür  diesmal in nicht definierter Reihenfolge - was an den Paketen auf dem "Kabel" (also dem WLAN Kabel) erkennbar ist.
Die Quelle des Problems ist also der perl http Client.

Ich werd um eine Command Queue wie sie @herrmannj vorschlägt wohl nicht herumkommen.

Beachte bei deiner Queue folgendes:
Erst nachdem der HTTP Client die Anfrage abgearbeitet hat, die nächste zu schicken. Nur so kannst du garantieren das kein Befehl vor dem anderen den Controller erreicht.

Andernfalls hast du eben mit der ganz normalen "concurrency" zu tun

@mrpj: was mir nebenbei aufgefallen ist, ich hatte versuchshalber ein Kommando "pause" eingebaut, einfach ein Fade vom aktuellen zum aktuellen hsv Wert mit einer Zeit - der Controlelr scheint das wegzuoptimieren. Es wäre, gerade für Animationen, schön, ihm sagen zu können "jetzt mach mal für 5 Sekunden nix!"

Eine Pause gibt es aus sicht des Controllers nie - zu jedem Zeitpunkt in dem der Controller eingeschaltet ist, gibt er einen definierten Zustand aus. (Auch Value=0 ist ein definierter Zustand).
Für den Fall das du z.B. eine Farbe für 5 Sekunden darstellen willst, gibt es eben das cmd "solid"

[vbs]

Das Problem an der Geschichte ist, dass die Weißen LEDs meist wesentlich heller sind als farbige LEDs. Hinzukommt, dass unsere Augen Helligkeit nicht linear, sondern exponentiell wahrnehmen.

In dem Konkreten fall bedeutet es, dass bei dem Wert 14, die Helligkeit der weißen LEDs im Verhältnis zu den farbigen (trotz interner Korrekturkurve) höher ist und somit nehmen wir eine Farbverschiebung war.

Wenn du den weißanteil (Sättigung = 100) weglässt, müsstest du keine Verschiebung mehr wahrnehmen.

Hm jein, also mein Beispiel war ja schon fast ohne Weißkanal (S=92). Der Effekt tritt aber auch mit 100 Sättigung auf, also zB:

Code Auswählen Erweitern

25,100,100
vs

Code Auswählen Erweitern

25,100,15

Also am Weißkanal liegts demnach nicht. Aber in dem Beispiel sind ja nur die rote und die grüne LED aktiv. Meiner bescheidenen Meinung nach haben, zumindest bei meiner, Stripe die grüne und die rote LED verschiedene Kennlinien, so daß sie bei einer Helligkeit von 100 und 15 nicht im gleichen Verhältnis zueinander stehen und daher der Farbton bei den beiden Helligkeitsstufen unterschiedlich ist.
Ich hab nochmal eine andere Stripe angeschlossen, aber bei der verhält sich das subjektiv genauso. Die Stripe ist aber aus der gleichen Bestellung wie die erste, also evtl. gleiche Charge und daher vermutlich ähnliche Eigenschaften.
So als Featureidee: Wäre natürlich toll, wenn man solche Effekte durch den Controller "rauskalibrieren" könnte.

[pjakobs]

Beachte bei deiner Queue folgendes:
Erst nachdem der HTTP Client die Anfrage abgearbeitet hat, die nächste zu schicken. Nur so kannst du garantieren das kein Befehl vor dem anderen den Controller erreicht.

Andernfalls hast du eben mit der ganz normalen "concurrency" zu tun

Der Plan ist, mit der nächsten Anfrage zu warten, bis die Rückmeldung der vorherigen angekommen ist.

im Moment mag mein Array noch nicht ganz so wie ich mir das vorstelle.

Eine Pause gibt es aus sicht des Controllers nie - zu jedem Zeitpunkt in dem der Controller eingeschaltet ist, gibt er einen definierten Zustand aus. (Auch Value=0 ist ein definierter Zustand).
Für den Fall das du z.B. eine Farbe für 5 Sekunden darstellen willst, gibt es eben das cmd "solid"

ah, solid geht auch mit Zeitangabe? Das hatte ich bisher nicht so verwendet, macht Sinn!

pj

[mrpj]

ah, solid geht auch mit Zeitangabe? Das hatte ich bisher nicht so verwendet, macht Sinn!

Steht doch in der Doku 

cmd - [fade/solid] fade to the new color in time t or show color for period t (cmd=solid)

Wie kann man das umschreiben, so dass es einfacher verständlich ist?

Hinweise zu solid: die Zeitangabe bedeutet "mindestens" - wenn danach kein neues Kommando in der Q ist, bleibt der Controller in dem Zustand. (da er sonst keinen anderen definierten Zustand hätte).

Ich denke mit den beiden Kommandos "fade" & "solid" kann man einiges an Lichtspielerei erstellen 

So als Featureidee: Wäre natürlich toll, wenn man solche Effekte durch den Controller "rauskalibrieren" könnte.

Um dies Sinnvoll umzusetzen müsste man mehr als 2 Koordinaten nutzen, denn auch zwischen den beiden Koordinaten ist die Kennlinie von LEDs nicht linear.  Von meiner Seite aus wird da in den nächsten Monaten keine Implementierung kommen.

Ich freue mich aber immer um Menschen die sich engagieren und Code zu dem Projekt beitragen