Wifilight.pm

[herrmannj]

Hi,

ich glaub in dem post fehlen Wörter, muss einiges raten.

Hast Recht, kommt drauf an was man möchte. Um die Helligkeit konstant zu halten müsste man mMn den Wirkungsgrad, bzw max lumen, pro Farbe berücksichtigen. Danach wäre es möglich sich nach dem "kleinsten gemeinsamen" zu richten und die anderen (auch im mix) entsprechend runter zu regeln.

Das würde aber dazu führen das bei GELB dann R und G mit vielleicht 20% der möglichen Helligkeit leuchten (weil blau typisch wenig lumen und RG gemischt).

Das finde ich (persönlich!) nicht erstrebenswert. Umso interessanter da auch Deine Erfahrungen zu hören.

vg
jeorg

[budy]

Hi,

ich glaub in dem post fehlen Wörter, muss einiges raten.

Huch... ja... da fehlt was... Ich glaube ich hatte angefangen und bin dann irgendwie von meiner Familie im Schreiben unterbrochen worden... 

Ich verstehe deine Einwände natürlich und habe mich auch zwischendurch immer wieder gefragt, wie ich das finde, dass ich Helligkeit "hergeben" muss, aber irgendwie ist es für mich so logischer. Dazu kommen halt auch noch die Schwankungen bei der verwendeten Hardware. Am schönsten wäre es, wenn alle LED-Farben gleich ab Werk gleich viel lumen abgäben, aber das ist wohl eher nicht zu erwarten.

Ich habe jetzt erstmal alles, was Transition ist, in allen Notifies von Wifilight auf meinen kleinen Python-Server "umgelegt", was mich zuerst einmal mit sehr flüssigen Übergängen und werde das jetzt mal beobachten und dann sehen, ob ich mit den "Einschränkungen" leben kann... Ich muss aber schon ehrlich sagen, dass mich auf meinem Raspi diese ruckeligen Übergänge deutlich mehr gestört haben, als es die derzeitige Problematik mit dem nicht voll ausgenutzen Dynamik-Umfang tut.

Wenn jemand den kleinen Racker mal probieren möchte, stelle ich den Code gerne hier mal zur Verfügung. Das Teil ist einigermaßen leichtgewichtig und kann durch seine "Threadding-Bauweise" auch Transitions queuen, bzw. tut es einfach und arbeitet die dann der Reihe nach ab.

Gruß,
Stephan

[herrmannj]

Einwand ist ein doofes Wort. Ne, iiss schon so, je nach Vorliebe und Erwartungen ist beides gut. Interessanter prove-of-concept !

vg
joerg

[budy]

Einwand ist ein doofes Wort. Ne, iiss schon so, je nach Vorliebe und Erwartungen ist beides gut. Interessanter prove-of-concept !

vg
joerg

Wenn ich mal Zeit finde deine Berechnungen für den HSV Farbraum nachzuvollziehen, dann werde ich den sicherlich auch einbauen, denn so muss ich natürlich schlussendlich alle Aktionen durch Transistions ersetzen, denn ansonsten kommt es natürlich zu unschönen Lichtblitzen, bzw. Abblendungen, weil dein Modell einfach mehr Licht "rausholt", aber ich bin erstmal zufrieden, dass ich sanfte Übergänge bekomme.

Gruß,
Stephah

[herrmannj]

ja, schon cool. Für die ferne Zukunft adaptiere ich das vielleicht. Wenn die Transitions in einem eigenen thread laufen ist der Effekt der gleiche.

Wie gehst Du denn bei den Berechnungen in Bezug auf die abgestufte helligkeit vor ?

vg
joerg

[budy]

Im Grunde ist das zunächst mal eine normale HSI -> RGB Berechnung, in der immer voll gesättigte Farben angenommen werden (H,I). Für RGBW wird die Sättigung dann als linearer Faktor eingerechnet als (1-S) gerechnet. Das ist auf der verlinkten Seite ganz gut erklärt:

HSI, R+B+G = I ->  S*(R+B+G) = S*I. Die weißen LEDs werden dann so eingerechnet: (1-S)*I. Dass bedeutet, dass nicht-gesättigte Farben dieselbe Helligkeit haben, wie gesättigte...

Ich habe in meinen kleinen Pythonserver jetzt noch einen Ringbuffer für die Transition-Kommandos eingebaut, wobei jede Transition in immer in einem Thread läuft. Somit kann der Server bis zur Größe des Ringbuffers - bei mir derzeit 16 - Kommandos aufnehmen und der Reihe nach abarbeiten. Sollten es mehr werden, dann werden die ältesten Kommandos überschrieben. Dadurch bleibt der  Resourcen-Bedarf konstant... Das funktioniert auch für "Langläufer", wie ein Wake-Up Light sehr gut....

Gruß,
Stephan

[raspklaus]

Ich habe mir folgende Bulb gekauft:

http://www.ebay.de/itm/151857702974


Als LD316 lässt sie sich nicht ansprechen aber als LD382 erzeugt sie zumindest Readings, reagiert also im Reading auf set on und set off.

Laut Importeur und Hersteller ist diese Bulb mit der neuesten Hardware gebaut. Beim Webinterface kann man sich zwar anmelden aber es erscheint dann nur 404 Page not found. Ich gehe davon aus, dass dort der Webserver abgeschaltet wurde.

Mit der App Magic Color v2 wird sie als unbekannter Kontroller angezeigt. Mit Magic Home lässt sie sich steuern genauso wie der LD12.

Die Readings werden auch bei dimup und dimdown verändert. Wifilight kann also mit der Bulb kommunizieren. Das einzige Problem ist, dass ich sie mit Wifilight nicht ein und ausschalten kann.

Wäre es möglich diese Bulb in Wifilight durch geringe Änderungen einzufügen ?

Mir liegen die komplette WiFi Dokumentation des Herstellers vor. Wenn sonst noch etwas benötigt wird kann ich die Fragen über den Importeur mit dem Hersteller klären.

[herrmannj]

ja, kann man.

So ganz habe ich Deinen post nicht verstanden, reagiert die bulb selber auf irgendwas ? Also Farbe setzen oder so ? Das mit den readings hat nix zu sagen.

Wenn Du das Protokoll hast (Wifi Unterlagen) oder der Importeur das raus rückt ist es Fleißarbeit.
Ansonsten musst Du das Protokoll mit wireshark sniffen ...

Steht denn in Deinen Unterlagen etwas zum Protokoll ? Benötigt werden die ganz konkreten byte Sequenzen und evtl Checksum oder CRC.

Mit Magic Home lässt sie sich steuern genauso wie der LD12.

Mit den gleichen settings ? Dann kann wifilight das auch.

vg
joerg

[raspklaus]

Leider ist die Datei zu lang um sie hier anzuhängen. Wo soll ich sie hinsenden ?

[raspklaus]

möglicherweise kannst Du die Dateien auch selbst runterladen:

https://www.dropbox.com/s/vnsav4iv81lk80l/WiFi%E8%BF%9C%E7%A8%8B%E7%81%AF%E6%B3%A1%E5%8D%8F%E8%AE%AE%E8%8B%B1%E6%96%87%E7%89%88.rar?dl=0

[herrmannj]

He, Danke.

wie biste da denn ran gekommen ?

Auszug (google translator chinese -> deutsch)

1. Wenn der Modus 0x61, wenn, Value1,2,3,4 stellen Wert RGBW und stellt fest, RGBW kann nicht leicht, diesen Befehl, RGBW-Werte, muss eine Partei 0 RGB und W sein, und wenn es nicht zur gleichen Zeit 0 ist, dann W als 0
2. Wenn der Moduswert gleich 0x00, berücksichtigt nicht den Wert Value1,2,3,4 nimmt die Birne RGBW-Wert in seinen ursprünglichen Zustand.

Im Prinzip scheint also drin zu sein was ich brauche. Den geheimnisvollen Worte des chinesischen Weißen muss ich nochmal durchs Orakel schicken. Bitte gib mir so ca 14 Tage, bin recht ausgebucht ...

vg
joerg

[raspklaus]

Das ist die original Doku vom Hersteller direkt. Besser als reverse Engineering, oder ?

[hawkeyexp]

Hi Zusammen,

nach nem Tip von Jörg den LD382 zu nehmen statt den inzwischen bescheidenen LW12 (den letzten hab ich ums verrecken nicht in Fhem integriert bekommen) hab ich jetzt doch ein etwas nerfiges Problem:

Nach etwas probieren hab ich ihn zum Laufen bekommen als LD382A. Allerdings ruckelt der Fade von 100% auf 0% Helligkeit und umgekehrt. Mit dem LW12 ging das flüssiger. Um sicher zu sein, dass es nicht am RPI2 liegt habe ich ein Fhem auf meiner Linux-Kiste mit nem 4GHz 8-Kerner installiert aber ein Leistungsproblem ist es definitiv nicht.
Ich habe auch verschiedene Anschlussvarianten probiert da der Controller bei mir modifizierte LED-Panel (umbau von 48V auf 24V) ansteuert und keine Farbwechsel etc. machen muss. Es war allerdings kein Unterschied ob ich den Anschluss für White benutzt habe oder mich auf einen einzelnen Farbkanal gekelmmt habe.
Hat jemand ne Idee woran es noch liegen könnte oder ob ich vielleicht schon wieder ne neue Evoluttionsstufe erwischt habe ?
Der Chip selbst ist als LW2596S beschriftet im Controller.

Marc

[budy]

Das ist ja interessant. Ich habe auch einen LD382A und auch auf meinem RasPi2 ruckeln die Fades auf dem Controller, wenn ich sie über Wifilight mache. Ich  habe mir dann so beholfen, dass ich einen kleinen Python Server laufen lasse, der sich um die Kommunikation mit dem LD382A kümmert und welcher mir die Fades macht. Dadurch konnte ich Frameraten von 60Hz (oder 64) erzielen und die Fades gehen auch auf dem Raspi2 genauso schön, wie auf meinem MBP mit i7 2,6GHz.

Ich habe mir jetzt sogar am letzten Wochenende ein Kaminfeuer-Effekt eingebaut, der schon ganz gut funktioniert. 
Ich weiß auch nicht, warum Wifilight die Fades mit dem LD382A auf dem RasPi2 nicht ruckelfrei hinbekommt, aber es scheint da eher am FHEM selber zu liegen. Ich habe das auch nicht befriedigend auf einem ansonsten unbenutzten FHEM auf einem RaspiB hinbekommen, so dass ich mir schließlich eine eigene Möglichkeit gebastelt habe. Ist aber ein wenig nervig den Status zwischen zwischen den beiden zu synchronisieren... 

Gruß,
Stephan

[Mumpitz]

Wärst du bereit den Code für das Kaminfeuer hier einzustellen?