Wifilight.pm

[Kuzl]

achso oke dann muss ich mich mit dem colorpicker wohl noch etwas gedulden

Gruß
Kuzl

[Kuzl]

So ich nochmal ich hab grad versucht mir den colorpicker selbst reinzubasteln und hab dabei was gefunden was dir Ärger für die Zukunft ersparen könnte
das set commando MUSS rgb sein und nicht RGB also kleingeschrieben.
auch das Reading muss klein sein

Im Moment wird allerdings noch nichts ausgelöst da du intern ebenfalls mit dem Großgeschriebenen arbeitest.

Gruß
Kuzl

EDIT:

OK geht jetzt man muss doch nur die beiden IF-Abzweigungen um  || ($cmd eq 'rgb') ergänzen... hab als erstes das obere übersehen.

das Attribut widget ist noch nicht implementiert oder? hab jetzt zuminderst nichts gefunden

EDIT 2:

hab jetzt mal nen ausgiebigen Test gemacht also ich bin der Meinung du könntest die Framerates noch etwas hochschrauben ich merke noch ein deutliches Flackern wobei dies bei den Farbübergängen weniger zu sehen ist als beim Aufdimmen einer Farbe von 000001 auf 0000FF.
Außerdem ist mir aufgefallen dass die Eigenheit mit 000000 auch beim Abdimmen zu berücksichtigen ist. Wenn man direkt auf 000000 will, geht er erst auf Weiß und wird dann dunkler.

Außerdem wird bei längeren Fades deutlich sichtbar, dass man die Gammakorrekur noch berücksichtigen muss. (beim Hochdimmen wird für das menschliche Auge erst schnell und dann immer langsamer hochgedimmt und nicht linear; beim Abdimmen wird fürs Auge erst langsam und am Ende immer schneller abgedimmt)
Die CPU-Sparendste Variante ist warscheinlich einfach zu jedem Wert von 01 bis FF den zugehörigen korrigierten Wert in einer Tabelle abzulegen und dann nur immer mit einem Index darauf zuzugreifen. Wenn du das noch reinbaun könntest, wär echt der Hammer kann dir da gerne helfen Hier noch ein Link der das alles nochmal etwas erläutert und eine fertigen Rechner in Form einer Exceltabelle enthält, der dir die Tabelle ausspuckt: http://www.mikrocontroller.net/articles/LED-Fading

[herrmannj]

ich bin der Meinung du könntest die Framerates noch etwas hochschrauben

Ich befürchte da machst Du es Dir etwas zu leicht  Die Transition erbringt der fhem Host und nicht der Controller. Die erzielbaren Frames / Sekunde sind das komplexe Ergebnis aus Controller / LED Device, Host Cpu und den anderen laufenden fhem Modulen. Vereinfacht gesagt verwendet das Modul "freie" Rechenzeit und läßt fhem den Vortritt.

Auf welcher Hardware läuft Dein fhem und welche CPU Load bekommst Du wenn das Beispiel das Hans heute morgen getestet hat laufen läßt ? :

Code Auswählen Erweitern

set LEDstripe HSV 0,0,0; set LEDstripe HSV 0,100,100 3 q; set LEDstripe HSV 0,0,0 3 q; set LEDstripe HSV 60,60,50 3 q; set LEDstripe HSV 180,100,100 3 q; set LEDstripe HSV 180,100,0 3 q;  set LEDstripe HSV 0,100,100 3 q; set LEDstripe HSV 0,0,0 3 q; set LEDstripe HSV 60,60,50 3 q; set LEDstripe HSV 180,100,100 3 q; set LEDstripe HSV 180,100,0 1 q

Wenn man direkt auf 000000 will, geht er erst auf Weiß und wird dann dunkler.

Bei welcher Sequenz genau tritt das auf ?

Außerdem wird bei längeren Fades deutlich sichtbar, dass man die Gammakorrekur noch berücksichtigen muss.

Das ist Aufgabe des Controllers. Wenn da korrigiert werden soll muss das wie die color Korrektur device abhängig implementiert werden. Ich nehme das auf die Liste mit den feature requests. Zusätzlich wird auch die Kennlinie des stripes Einfluss haben. Wie sieht das bei anderen LW12 usern aus ?

vg
Jörg

[Kuzl]

Ich befürchte da machst Du es Dir etwas zu leicht

Warscheinlich ja
FHEM läuft bei mir auf einem Raspberry Pi und der Test bringt eine Auslastung von ca. 80-90%
Wobei du ja gesagt hast, dass die Frames vorberechnet werden und anschließend nur noch ausgegeben - vll kann man das etwas entzerren

Die Gammakorrektur wird das Flackern aber minimieren da das Flackern daher kommt, dass einfach zu viele der 256 Schritte übersprungen werden und das gleicht die Gammakorrektur etwas aus

Bei welcher Sequenz genau tritt das auf ?

Bei Transisionen von einer Farbe auf RGB 000000 - ist aber eigendlich logisch da 000000 ja eigendlich keine Farbe ist

Außerdem wird bei längeren Fades deutlich sichtbar, dass man die Gammakorrekur noch berücksichtigen muss.
Das ist Aufgabe des Controllers. Wenn da korrigiert werden soll muss das wie die color Korrektur device abhängig implementiert werden. Ich nehme das auf die Liste mit den feature requests. Zusätzlich wird auch die Kennlinie des stripes Einfluss haben. Wie sieht das bei anderen LW12 usern aus ?

Jap sollte es sein, macht er aber nicht Und ich bezweifle , dass die Bridges bzw. die Milights das machen.
Ich denke das muss nicht Device-abhängig immplementiert werden, da sich die Kennlinie des Auges ja nicht ändert du musst nur den Wert den du ausgeben willst nochmal durch die Tabelle jagen - oder eben vor der Berechnung.
Natürlich haben die verschiedenen LEDs Einfluss, wobei der dabei denke ich fast zu vernachlässigen ist. Zuminderst hatte ich bei sehr verschiedenen LEDs von 1mm kleinen SMDs bis zu 10mm immer gute Ergebnisse mit der gleichen Tabelle. Am besten einfach mal ausprobieren und überzeugen lassen

Bitte nicht falsch verstehen ich will dein Modul in keinster weise schlecht machen, im Gegenteil ich finde es genial was du da aus dem Boden gestampft hast und was du da alles mit aufnimmst

Viele Grüße
Kuzl

[herrmannj]

FHEM läuft bei mir auf einem Raspberry Pi und der Test bringt eine Auslastung von ca. 80-90%

Beim Steak würde man sagen "auf den Punkt!" - perfekt. Mehr kann der raspi nicht. Wichtig nochmal darauf hinzuweisen das die Reaktionsfähigkeit von fhem auf Events / Schalter etc auch bei vergleichsweise hoher CPU Usage voll erhalten bleibt weil die nach ganz wenigen Millisekunden der fhem Hauptprozess sofort wieder drankommt. Meiner Schätzung nach dürften in Deiner Config bis zu 20 Aktualisierungen pro Sekunde drin sein wenn die anderen Prozesse Raum dafür lassen. In der Umgebung (fhem, raspi) respektabel und der Weg zu mehr Frames führt nur über eine stärkere CPU.

Bei Transisionen von einer Farbe auf RGB 000000 - ist aber eigendlich logisch da 000000 ja eigendlich keine Farbe ist

Ich habe das nachgestellt und ja - ist so. Liegt, so wie Du richtig vermutest, an der "Farblosigkeit" von Schwarz, bzw noch exakter daran das es keine Sättigung hat. Aber heh: Du wolltest RGB in . Die Transition Funktioniert im RGB nur so:

Code Auswählen Erweitern

set light RGB FF0000; set light RGB 010000 30 q; set light RGB 000000 1 q

Zum Gamma: ich bin da grundsätzlich offen, aber natürlich muss eine Korrektur auf / an dem Ausgabedevice erfolgen. Das ist immer so. Ganz selbstverständlich!!! Beispiel Milight RGBW2: die hat 25 Helligkeitsstufen, RGB und RGBW1 haben 10. Schon diese individuellen Charakteristika zeigen das es per Device erfolgen muss, der "Bedarf" an Korrektur ist genauso unterschiedlich wie bei verschiedenen Bildschirmen ...

Die von Dir vorgeschlagene Lösung, bzw der verlinkte Artikel, scheinen mir falsch. Nimm zum Beispiel ein "GoldenRod": #DAA520, das ist eine HTML named color. Wenn ich jetzt eine nichtlineare Funktion (Gamma) auf die 3 RGB Kanäle ansetze ändern sich jeder Kanal, der Funktion entsprechend, nicht linear. Die Farbwahrnehmung wird aber, unabhängig von der verwendeten Einheit (float, bit, byte) über das Verhältnis von R,G,B zueinander definiert. Da die Funktion per Definition nichtlinear ist ändert sich damit zwangsläufig das Verhältnis der Kanäle zueinander -> und damit neben der Helligkeit auch die Farbe was ja falsch ist.

Der Artikel beschreibt ja verschiedene, mehr oder weniger komplexe, Formeln zur Adaption an das physiologische Sehen (mit marginalen Unterschieden zur bekannten Gamma-korrektur). Nur: entweder ich arbeite an einer Anpassung an das physiologische Sehvermögen dann muss ich das auf dem V Channel machen (siehe oben: sonst Farbe falsch  )   - oder - ich korrigiere die Physik des Wandlers: Charakteristik des PWM externer Beschaltung plus Kennlinie der LEDs. Das wäre per Cannel richtig - allerdings bringt dann der Bezug auf das physiologische Sehvermögen nichts. Dann muss ich die Charakteristik der Ausgabekette kennen und ausgleichen.

Meine Vermutung ist jetzt das der Bedarf beim LW 12 tatsächlich Gamma (auf V Channel!) ist. So würde ich das auf die feature request Liste setzen.

Wäre schön wenn der eine oder andere LW12 Besitzer seine Beobachtungen noch mit in die Diskussion wirft, das würde mir möglicherweise helfen noch genauer zu verstehen was ich fixen soll.

Danke und Grüße
Jörg

[herrmannj]

... um da gleich nochmal anzuknüpfen:

um mal zu überprüfen ob die Theorie stimmen kann und die normale Gamma Funktion zur Korrektur geeignet ist:

Bei Gamma 0,5 wäre folgendes richtig: (V auf % Helligkeit)
HSV 0,0,50 -> 25%
HSV 0,0,71 -> 50%
HSV 0,0,86 -> 75%

Gamma 0,6
HSV 0,0,44 -> 25%
HSV 0,0,66 -> 50%
HSV 0,0,84 -> 75%

Gamma 0,7
HSV 0,0,38 -> 25%
HSV 0,0,61 -> 50%
HSV 0,0,82 -> 75%

Geht einer von denen in die richtige Richtung ?

edith: also um die Funktion zu prüfen wäre wichtig das alle 3 Punkte der Funktion so ungefähr passen ... logisch oder 

vg
Jörg

[breezybadger]

Hallo ihr, ich habe nun wirklich alles gelesen und schäme mich ein wenig. Da ich leider recht neu im fHEM bin, hab zwar das Modul geladen bekommen und auch eine Lampe mit Wohnzimmer angelegt, aber es passiert einfach nix wenn ich on/off trigger. Gibts evt ein HowTo durch das ich mich arbeiten kann? App und FB klappen wunderbar mit den Lampen. Muss ich die evt mit Fhem nochmal pairen?

*duck* und danke für den Input.

[Kuzl]

Ok war mein Fehler da hab ich mich etwas falsch ausgedrückt die Korrektur betrifft nur die Helligkeit allerdings NICHT das Verhältnis der einzelnen Kanäle zueinander, das muss linear bleiben. => V
Daher passt meine verlinkte Seite schon, da sie nicht von einer RGB-LED sondern von einer Einfarbigen ausgeht.

Hab nicht gewusst dass die Milights das haben ich kann natürlich nur vom LW12 sprechen und ehrlich gesagt ist mir das bei so billigen teilen noch nie untergekommen wundert mich jetzt echt Dann musst du es natürlich im Device machen. Hab mich ehrlich gesagt mit Milight nicht beschäftigt und wusste nicht, dass dort solche Unterschiede sind.

Meiner Meinung nach ist von deinen zwei vorgeschlagenen Wegen der erste der Zielführendere.

Zur CPU-Usage kann ich nur zustimmen das find ich so auch ok sodass noch genügend Reserven für andere Prozesse vorhanden sind.
Bei den angenommenen 20 Frames sind es bei 3 Sekunden von 0 auf FF bei einer linearen Transision 4er Schritte, was bei den dunkleren Werten für das Auge richtig große Sprünge sind. Für Farbübergänge ist das ok da das ja mehr oder weniger durch die andere LED ausgeglichen wird.

Zu den 3 Funktionen:
Ich hab mir alle 3 angesehen und muss zugeben dass ich nicht sagen kann, welche eher zutrifft. Das ist subjektiv echt schwer zu sagen, da die Werte auch sehr ähnlich sind. Ich glaube das könnte man eher bei einem direkten Verlauf sagen.

Außerdem hab ich das mal mit der Formel aus dem Link getestet, die komischerweise sehr viel andere Werte liefert:
25% => 30
50% => 45
75% => 68
Und auch diese Funktion scheint mir vom Verlauf her relativ gut zuzutreffen (ich trau mich jetzt nicht zu sagen besser als die anderen)
Allerdings kann ich halt aus persönlicher Erfahrung sagen dass sie sehr gut zutrifft, was man beim Hoch- und Runterdimmen auch schön sieht.
Direktes Gamma hab ich damals nie ausprobiert.

Würde mich mal interessieren, was andere LW12-Besitzer dazu meinen.

Find ich super dass du das einbauen willst

@breezybadger: Kannst du uns bitte etwas mehr Infos geben, welche "Lampen" du benützt?

Viele Grüße
Kuzl

[breezybadger]

Hallo Kuzl,
ich benutze genau diese hier http://www.amazon.de/gp/product/B00G8JR08C/ref=oh_details_o06_s00_i00?ie=UTF8&psc=1 , das ist soweit ich vermute eine V3. Die Brigh ist schon im Wifi und läuft auch per Iphone.

[herrmannj]

Hi breezybadger,

alles gut, must Dich nicht ducken gibt ja noch keine vernünftige Doku für das modul.

Nimmst Du alle 4 Bulbs als eine Gruppe und wenn ja ist das Gruppe 1 ? also linke Taste in der App ?

vg
Jörg

[breezybadger]

Hallo Jörg,

das geht ja echt fix hier, wow! Ich hab im Moment auf der Hardware-Fernbedinung und App verschieden Konfigurationen, die Lampen sind in 3 Gruppen organisiert ( für je einen Raumen ) von links nach rechts auf der Fernbedinung ( genau wie in der App, hier allerdings verschiedene). Habe also 2 in Gruppe 1, 1 in Gruppe 2 und 1 in Gruppe 3.

[herrmannj]

Hi Kuzl,

ok, die Werte dir Du geschrieben hast gehen grob in Richtung von Gamma 0,9. Ich werde das Gamma ohnehin als attrib reinnehmen dann kann man das individuell einstellen. Logisch, rein optisch schwer, wie linear das ist würde man dann auch beim hoch dimmen am besten sehen können.

Aus Deiner Sicht geht die Korrektur aber in die richtige Richtung ? Welches Gamma man dann für sich einstellt kann ja sogar noch am stripe hängen. Mal schauen ob noch 'ne zweite Meinung dazu reinkommt - aber dann habe ich ja schon mal eine Richtschnur.

Nachtrag:

was bei den dunkleren Werten für das Auge richtig große Sprünge sind

Das würde sich mit der Gamma Korrektur ja erledigen - oder ?

vg
Jörg

[herrmannj]

die Lampen sind in 3 Gruppen organisiert ( für je einen Raumen ) von links nach rechts auf der Fernbedinung ( genau wie in der App, hier allerdings verschiedene). Habe also 2 in Gruppe 1, 1 in Gruppe 2 und 1 in Gruppe 3.

in der Definition sind das drei Device in der Form:

Code Auswählen Erweitern


define Raum1 WifiLight RGBW2 bridge-V3:192.168.178.42
define Raum2 WifiLight RGBW2 bridge-V3:192.168.178.42
define Raum3 WifiLight RGBW2 bridge-V3:192.168.178.42


Wenn die schon über die app mit der bridge gepairt sind brauchst Du nnicht mehr neu zu pairen. Die Gruppen werden in der Reihenfolge zugeordnet in denen die defines angelegt werden. Sollte da was nicht passen kannst Du die device ja einfach so umbenennen das es passt.

Nimm keine punkte in die device namen.

vg
Jörg

[breezybadger]

Hallo Jörg,

ich habe keine Ahnung wie du das gemacht hast! Ich hatte vorher nur einen Eintrag, evt. schreibst du noch dazu, dass man für jede Gruppe einen eigenen, neuen Eintrag braucht. Mir ist jedenfalls geholfen und ich bin dann jetzt stiller zuhörer. Besten Dank!

Breezy

[herrmannj]

sehr gern 

ps
Kannst gerne auch "laut" zuhören, Fragen gehem immer