Wifilight.pm

[Kuzl]

Hi Jörg,

Jap die Korrektur geht definitiv in die richtige Richtung, das sieht man sogar ohne direktes Hochdimmen über die Funktion
Gute Idee, das als Attribut einzupflegen, so hast du die Unterschiede der Leuchtmittel auch gleich drinnen

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

ja, das sollte sie erledigen oder zuminderst minimieren.

Evtl noch ne kleine Anmerkung zur Umsetzung:
Am besten wäre es, wenn beim definieren des Attributes die Funktion berechnet und abgelegt wird. Bei Transisionen dann praktisch nur noch auf die fertigen Werte zugegriffen werden muss.

ODER

Direkt einfach Alle Funktionen von haus aus ablegen und dann nur noch darauf zugreifen.

Ist zwar nicht die schönste Variante gegenüber der Berechnung "on the fly" aber damit man die Frameraten nicht nochmal nach unten drückt denke ich ist das so sinnvoller. Bei den kleinen Systemen ist einfach CPU wichtiger als Speicher

Lass mich aber gern eines besseren belehren

Viele Grüße
Kuzl

[herrmannj]

probier die version mal aus (shutdown restart!)

das attrib ist gamma

Kannst ja erst mal mit gamma 0.2 und gamma 2.2 testen ob die Anpassung überhaupt greift und dann bei 0.5 starten und in 0.05 er Schritten gegen 1 gehen um zu sehen wo er linear ist.  Als default habe ich erstmal 0.73 hinterlegt, denke das kommt ganz gut hin...

Solltest Du mit dim x xx getestet haben (also nicht transition): beim dim habe ich bei der Gelegenheit noch gesehen das der Intervall noch falsch stand, den habe ich hochgesetzt. Bei transitions ist die timebase unverändert. gamma wirkt auf alle settings (dim, hsv, rgb ...)

vg
Jörg

[Kuzl]

Ich würde sagen am besten waren die Werte zwischen 0.6 und 0.75 also kommt das schon ganz gut hin was du vermutet hast, ich tendiere eher zu 0.65 oder 0.7

Allerdings muss ich sagen, dass es zwar vom Helligkeitsverlauf jetzt sehr viel besser ist, allerdings sind die Frames vom Gefühl her sehr stark eingegangen. Es ist also kein schönes Dimmen sondern eher hakelig getestet habe ich 3 Sekunden und 6 Sekunden.

Bei langen Transisionen (ich hab 30s getestet) wirkt es aber wunderschön und sehr linear

[herrmannj]

an den Frames hat sich bei "set HSV" bzw "set RGB" nix geändert und "dim" ist schneller geworden. Ist das "hakeln" bei dim oder bei set RGB/HSV ?

Der Speciherverbrauch ist gestiegen, haut die da vmem oder swap dazwischen ? Bei den Frames hab ich 'nen Haken dran - wäre schön wenn Du, sollte sich Dein Gefühl da vertiefen, nochmal die alte Version gegen-stellst. Ist ja im ersten post. Beim Gamma bist Du übrigens nicht auf 0.05 er festgelegt, 0.672 oder was auch immer geht natürlich auch. Wobei die Unterschiede vermutlich nur noch messtechnisch relevant sind - aber gehen tuts 

Langsam wirds ja ein Hifi Modul  Gamma- und Farbkorrektur,  bald sind die LEDs besser kalibriert als mein Monitor 

Schön wenn das so funktioniert und Du zufrieden bist. Bei den Milights relativiere iich ein bischen, zumindest den White und den RGBW2 steht ein Gamma von 0.8 gut - bei den RGB und RGBW1 ist es schon ab Werk ok.

Ja - wenn Du dem mit den frames nochmal nachgehst - das wäre cool.

vg
Jörg


edith:
wobei mehr speicher überschaubar ist - 101 x float im array. float sind, glaub ich 4 byte, als 404byte plus das was das array an overhead hat.

[Kuzl]

Jap hast du recht am Speicher liegt es nicht sind bei mir noch fast permanent über 300 MB frei.

Hast recht ist ca. gleichgeblieben nur irgendwie anders davor wars einfach immer bei den dunklen Werten - logisch
Jetzt scheint es teilweise so, als ob es kurzzeitig Stehen würde, was ich aber nicht glaube (CPU passt)

Beim Test hat sich herausgestellt, dass das Hakeln irgendwie vom Gamma abhängig ist. Schwer zu sagen aber ich glaube der erste Sprung ist gleich der erste von 01 aus auf die erste Helligkeitsstufe (kann daran liegen, dass beim Gamma nicht immer mit so kleinen Werten angefangen wird oder?)

[mbenker]

Na da kommt man vor lauter Arbeit mal ein paar Tage nicht dazu, hier reinzuschauen und nachzulesen und schon wird es ein HIFI Modul

Ich weiss zwar nicht was du da alles jetzt rein gebaut hast, Jörg, aber ich glaube wir müssen mal wieder ne Stunde telefonieren

[herrmannj]

Beim Test hat sich herausgestellt, dass das Hakeln irgendwie vom Gamma abhängig ist. Schwer zu sagen aber ich glaube der erste Sprung ist gleich der erste von 01 aus auf die erste Helligkeitsstufe (kann daran liegen, dass beim Gamma nicht immer mit so kleinen Werten angefangen wird oder?)

ich verstehe nicht genau wie das gemeint ist - aber die Gefahr ist wohl wirklich genau zwischen Anzahl Frames/Sek und Helligkeitsanpassung zu unterscheiden. Wobei die Frames halt auch von den anderen fhem Prozessen abhängt, das kann mal so mal so sein. Wenn irgendein anderes Modul was "langsames" macht seht man das sofort. Bei 3 Sekunden Transition sind ja 1000 msek schon mal eben ein drittel.

Bei gamma 0.6 sind die ersten Werte (%V auf RGB) :

1   0
2   0
3   1
4   1
5   2
6   2
7   3
8   4
9   5
10   5
11   6
12   7
13   9
14   10
15   11
16   12
17   13
18   15
19   16
20   17

vg
Jörg

Jetzt scheint es teilweise so, als ob es kurzzeitig Stehen würde, was ich aber nicht glaube (CPU passt)

Axo, na das kann schon sein, siehe oben. Lass mal vielleicht (nur Beispiel) das Weather in dem Augenblick seine Daten holen, da machen eininge msek halt optisch schon was.
   

[Kuzl]

hm okay die Werte können es also nicht sein. Naja vll verlange ich einfach zu viel von der Hardware
Kann sein, dass wirklich irgend ein anderer Prozess grad was gemacht hat, aber für mich ist das so jetzt schon mal in Ordnung, muss ich halt langsamere Transisionen machen
Muss nur noch der Colorpicker rein dann bin ich restlos Zufrieden

Mal ne generelle Frage: Was benötigt bei deinem Modul die meiste Rechenzeit? - nur aus Interesse

[herrmannj]

kannst ja gerne profilen, vielleicht findest Du ja noch was.  Ansonsten gibt es keine single source und eine transition ist auch kein vodoo. Zuerst wird die Transition one shot berechnet, optimiert auf die maximalen Framerate die das device kann und abgestuft auf die steps die sinnvoll sind. Da wird dann geschaut wie viele Helligkeitsstufen von HSV a auf HSV b dargestellt werden können und wenn zwei reichen dann werden nur die zwei genommen.

Die werden dann in eine queue (die hl queue) geschrieben und dort timer-gesteuert abgeholt. Wenn fhem ausgelastet ist kommen die timer verspätet. Je nach Situation werden an der Stelle Frames verworfen, konkret wenn der timer so spät kommt das der nächste Frame schon dran ist. Wird der Frame ausgeführt dann kommt er in eine ll queue. Die ist notwendig weil auf milight bridges pro Frame 3 - 10 Befehle im richtigen Timing gesendet werden, im Falle des lw12 sind es nur schlanke 5 byte in einem Rutsch. Die ll queue hat eine Rückkopplung zur hl queue. Je nach Füllstand (sagt fhem bekommt die Daten nicht schnell genug raus) verwirft die hl queue Frames bis in der ll queue alles raus ist.
Spielt beim lw12 keine Rolle.

Das läuft alles ganz schlank und fix ab, braucht selbst auf meinem alten dev nb nada cpu. Aber FB, Raspi und Konsorten haben eben auch ganz schlanke cpu's 

Wie gesagt, ist schon ganz gut optimiert.

Also, wenn das GAMMA passt dann übernehme ich das. Welcher Wert scheint Dir jetzt am geeignetsten beim lw12 ?

vg
Jörg

[Kuzl]

interessant umgesetzt
evtl noch ne Idee, wenns nicht sogar eh schon so gemacht wird:
erst nach dem Berechnen die Ausgabe starten, könnte evtl ein anfängliches "verwerfen" verhindern

ja das stimmt wobei der Raspi inzwischen echt mehr kann als ich am Anfang erwartet habe

eine Herausforderung damals bei mir war, dass ich nur 40Mhz zur Verfügung hatte und dann 10kB/s errechnen und über SPI ausgeben musste
Projekt war damals ein 10x10x10 LED-Cube mit relativ aufwändigen Animationen. Wir haben das damals mit Double-Buffering umgesetzt indem wir immer schon das Nächste Frame berechnet haben und anschließend nur noch die Zeiger ausgetauscht haben.

Allerdings ist µC-Programmierung nicht so mit PC-Programmierung zu vergleichen

Ich würde sagen so 0.65 scheint mir ein passender Wert zu sein.

[herrmannj]

ja das stimmt wobei der Raspi inzwischen echt mehr kann als ich am Anfang erwartet habe

wohl war, irgendwie hat er ja auch den Bereich einplatinen computer revolutioniert. Also, meine Meinung. Vor dem raspi waren solche Boards exoten und heute für 'nen schmalen Taler fast mainstream. Schon eine tolle Leistung von den Jungs ..

10x10x10 LED-Cube mit relativ aufwändigen Animationen

schönes Projekt, sieht bestimmt cool aus 

Ich würde sagen so 0.65 scheint mir ein passender Wert zu sein.

Na dann nehm ich das mal so rein 

vg
Jörg

[Blackcat]

Hallo Jörg,

dein Addon ist nun mein Einstieg zu fhem (wollte den Server die ganze Zeit schon testen, kam aber noch nicht dazu ...)

Ich bin selbst Entwickler und will mir ein "Wake-Up Light" nachbauen. Dachte erst an normale HTTP requests direkt an den WLAN Controller und dachte dann hey... warum nicht mit den Rollläden etc. koppeln ... also mit fhem naja dann von fhem php cronjobs zu triggern ist schon umständlich und eher ein Workaround und da bin ich auf dein Perl Script gestoßen.

Werde es morgen ausführlich testen (habe auch einen PI, daher ist die Peformance auch für mich interessant) - will das Projekt morgen umsetzen.

Bin also von nun an auch fließig am mitlesen und freue mich auf die nächste Version.

Viele Grüße
Sandra

[herrmannj]

Hallo Sandra,

Herzlich Willkommen !

Mit dem Wakeup Light haste Dir zum Start ja gleich 'ne kapitale Aufgabe gestellt  . Wegen der performance kannst Du unbesorgt sein, wir "klagen" (arbeiten)  hier gerade auf hohem Niveau. Wie weich Farbübergänge im Sekundenbereich sind und so. Wobei das mit dem Gamma dafür schon eine wichtige Ergänzung war.

Welche Leuchtmittel möchtest Du einsetzen ? Kannst die Version von gestern nehmen, die ist up-to-date.

vg
Jörg

[Blackcat]

Hi Jörg,

danke

Ich habe die Milight RGBW von Rocket LEDs mit WW.
Mal sehen, will aber nur den Farbverlauf ersteinmal bauen, also ohne Ton und Uhr

Digital habe ich schon Tag / Nachtwechsel in DirectX simuliert. (HLSL ist zwar anders als Perl und hex anders als RGB aber mal sehen )

kann bei Interesse auch gerne meine Erfahrungen teilen. Ist bei mir morgen ein Raspberry PI Event in der Firma, ggf. folgt also auch ein Blogeintrag o.ä..
sollte es gut sein gibt es aber auf jedenfall ein Youtube Video

Viele Grüße
Sandra

[herrmannj]

Hi,

brauchst kein Perl um den Farbverlauf zu machen. Wirst Dich vermutlich aber in fhem einarbeiten müssen.

Das Modul ist bisher nur hier im thread dokumentiert. RGB und HSV werden als input genommen. Persönlich komme ich mit HSV besser zurecht, aber sicher eine Frage der Vorlieben.

Einen Farbverlauf baust Du Dir ganz einfach so "set <name> HSV 240,100,0; set <name> HSV 0,100,100 30 q". Der erste Befehl setzt die "Startfarbe": 240 ist im Fabrkreis blau, 100 die Sättigung und 0 (Value) die Helligkeit. Am zweiten Befehl hängen 2 Parameter dran. Die 30 sagt das zu der Farbe innerhalb von 30 Sekunden übergeblendet werden soll und das "q" schreibt das in eine interne Queue. Kannst beliebig viele davon verketten. Vermutlich hast Du Dir das aber ohnehin schon angelesen 

Die Rockets sind RGBW2, können keine Sättigung nur Color oder WW.

An dem Video kommst jetzt nicht mehr vorbei 

viele Grüße
Jörg