Wifilight.pm

[Steffen]

Ansonsten funktioniert die Nachtlichtbeleuchtung im Flur bisher absolut super....Dafür setze ich die RGBW2 Bulbs ein

Hallo!

Ohne jetzt Werbung zu machen aber kannst du mir vielleicht sagen wo du die RGW2 Bulbs bestellt hast?

Zum Thema LW-12, beim Test mit dem Sonnenuntergang aus dem Ersten Post muss ich sagen das der mein PI schon ganz schön zu tun hat und es an manchen stellen schon Ruckelt und einige Übergänge nicht so flüssig sind.
Aber ich Teste noch mal wo genau und wann.

Bin sonst sehr zufrieden und selbst meine Frau die sonst nicht von sowas zu begeistern ist,
konnte man ein kleines "WOW" entlocken !

Mfg Steffen

[Blackcat]

Ansonsten funktioniert die Nachtlichtbeleuchtung im Flur bisher absolut super....Dafür setze ich die RGBW2 Bulbs ja ein...

coole Sache

Ohne jetzt Werbung zu machen aber kannst du mir vielleicht sagen wo du die RGW2 Bulbs bestellt hast?

Hallo Steffen,

vielleicht kann ich dir auch helfen, ich habe meine RGBW2 von hier:
3x Wlan LED Lampe RGB-Weiß, 9 Watt, mit 4-Zonen Fernbedienung, E27, inkl. Wlan Controller von ROCKET LEDS
aber Jörg meinte auf ebay wären sie günstiger, da wäre auch ein Lieferant für mich zu hören interessant.
Vorallem für die RGBW Downlights

@Jörg:
noch ne Frage zu der q: Müssen die Sekunden ein int sein, oder gehen auch Kommazahlen?

[herrmannj]

Hallo zusammen,

Ohne jetzt Werbung zu machen aber kannst du mir vielleicht sagen wo du die RGW2 Bulbs bestellt hast?

Genau, Werbung nur gegen cash !

ebay geht gut, geh mal auf weltweit und gib als Suche "wifi led" ein, dann Sofort Kauf, Kategorie "Beleuchtung" und Preis aufsteigend. 201042235132 sind 6 Watt OEM RGBWW (13,75€). Die 6 Watt sind nicht ganz so hell wie die 8Watt oder 9Watt aber trotzdem schon recht hell. Musst nur dran denken den Wifi Controller mitzubestellen. Die leuchtstärkeren sind immer die mit Alukühlkörper, die mit Kunststoff sind OEM 6Watt.

Downlights wären wohl hier 360807848299 - scheint aber coldwhite zu sein. Zu den chinesischen Händlern kann ich nichts spezielles sagen außer das es bei mir immer geklappt hat, musst halt 4Wochen+ warten. Wenn wirklich mal was defekt ankommt mach ich mir aber keine Hoffnungen wegen Garantie oder so   

Pass nur auf wegen Kaltweiß und Warmweiß und bestell Dir blos keine RGB only mehr.

noch ne Frage zu der q: Müssen die Sekunden ein int sein, oder gehen auch Kommazahlen?

Int. genauer kann fhem/raspi und so das sowieso nicht. Alles was unter 5 Sekunden liegt macht als Transition aber sowie keinen Sinn, da ist fhem an sich zu ungenau / langsam für.

hi mbenker 

Jetzt müssen die Hersteller nur noch für draussen die Farb LED Strahler mit WLAN austatten, dann wüsste ich auch was ich mir in den Garten stelle

Könntest ja überlegen da einen lw12 reinzubauen 

An den Farben muss ich noch  etwas arbeiten, aber das Türkis war gewollt.

verstehe, Dämmerung. Dann hab ich mich auch nicht verguckt, das danach war grün. Ihr habt ja Sonnenaufgänge da... 
Den Effekt bekommt man mit den RGBW2 leider nicht hin, mit RGB-LW12 oder RGBW1 gehts über die Sättigung. Das Problem ist, wenn Du erstmal bei Türkis / Cyan (180°) bist kommste von da aus nur "rechtsrum" über grün oder "linksrum" über dunkelblau wieder weg. Du hast vermutlich versucht von 180° auf 55° zu gehen. Das wäre ein Fall für das "l" - Flag. Ohne geht er "short" über "Grün" - mit geht er "l" long über blau, pink, rot auf gelb. Ist aber, von türkis aus, beides optisch nicht so dolle... . Wenn Du nochmal beim Video ein update vorhast sag kurz bescheid. Gegen den "Flash" beim umschalten auf Weiß kann was machen, wirkt auf dem Video ja auch viel doller als in echt.

Zum Thema LW-12, beim Test mit dem Sonnenuntergang aus dem Ersten Post muss ich sagen das der mein PI schon ganz schön zu tun hat und es an manchen stellen schon Ruckelt und einige Übergänge nicht so flüssig sind.

Klar: damit die fades optisch flüssig sind brauchts, wie beim TV, irgendwas größer als 15-20 Frames / Sekunde. Perl ist halt keine high-performance Sprache, der raspi ist zwar fix aber far away von modernen Notebook CPUs und zu allem Überfluss kann fhem mein Multitasking. Bedeutet das jedes (!) andere Modul den fade verzögern kann und man sieht eben jede 50msec optisch sofort. Solche (und viel mehr) delays sind bei vielen Modulen die Regel. Die Milights vergeben das mehr weil selber weich faden, der LW12 ist sehr akkurat und da sieht man das sofort.

hast Du mal die Version von vorgestern oder sso ausprobiert ? Der Gamma hilft da weil die Werte "optisch" dichter beieinander liegen. ansonsten klagen wir auf hohem Niveu (im Millisekunden Bereich  ). Uns gehts gut, schau mal bei den HM - die haben fast täglich HM Lans mit disconnect weil ein 25 Sekunden keep alive mit 5 Sekunden Karenz nicht bedient werden kann (das hat nix mit Martins HMLan Modul zu tun, das ist in gut!)

vg
Jörg

[Kuzl]

Hi Jörg,

ich hab gestern nochmal mit der App gespielt und bin auf die Animationen gestoßen Man kann also direkt Transisionen im Controller programmieren. Es scheint auch so, als wären diese leicht im Verlauf korrigiert, wenn auch nicht so perfekt wie das von dir
Allerdings könnte man so alles extrem entlasten und braucht sich keine Sorgen mehr um die Framerate zu machen. Evtl könnte man das so einbauen dass kurz eine Temporäre Animation erstellt wird. Ist jetzt nur eine Entdeckung und ich habe keine Ahnung ob das überhaupt in irgendeiner Weise möglich ist, müsste ja auch der Rückkanal eingebaut werden, damit man weiß wie weit er schon ist^^

Wie gesagt nur ne Idee, aber ich denke nicht, dass wir hierfür Verwendung finden

vg
Kuzl

[Steffen]

Hallo!

Erstmal nochmal danke für deine/eure Tolle unterstützung...

hast Du mal die Version von vorgestern oder sso ausprobiert ?

Wenn es die Aktuelle aus dem Ersten Post ist dann habe ich sie!

Was ist denn nun eigentlich der unterschied zu RGBW1 und RGBW2, so recht sehe ich den Wald vor lauter Bäumen nicht ?

RGB Bulb mit Alu habe ich 2 Stück da, hatte ich damals auch mit der V2(RocketLed) im Set bekommen, aber da bekommt man kein Weiss hin!

Deswegen wollte ich jetzt nochmal neue bestellen mit den neuen Controller v3, damit kann man ja nun auch Zonen bestimmen, was mit V2 nicht ging!

Habe ja auch Phillips Hue(Bulb) was ich auch in Fhem eingefügt habe,
was Klasse ist aber der Preis ist ja für mehr Anschaffung fast nicht machbar!

Mfg Steffen

[Blackcat]

edit
Diese Version ist veraltet!
bitte folgende nutzen:
http://forum.fhem.de/index.php/topic,18958.msg199927.html#msg199927

Diese funktioniert mit dem normalen WifiLight Skript
/edit

RGBW1 und RGBW2, so recht sehe ich den Wald vor lauter Bäumen nicht ?

Das ist eine gute Frage ... die Antwort würde ich auch gerne wissen.

@Jörg:
Mir ist aufgefallen, dass Pakete oft verloren gehen
Du sprichst bis jetzt die V3 nur mit UDP an. Es ginge aber auch mit TCP wenn man den Controller so einstellt. Das wäre doch auch eine nette Verbesserung

PS: anbei meine Änderungen für den die on mit HSV Methode (damit man auch ein Schalter drücken simuliert wird, sonst muss man in der Weboberfläche für das Bedienen immer vorher nochmal on drücken um dann off drücken zu können)


Anbei mein WakeUp Skript für bis zu 4 Devices
Video:
https://www.youtube.com/watch?v=dX2tNeN0RmA

- Aufruf: wakeUp(<Zeit in Minuten>,"<Devicename>"),wakeUp(<Zeit in Minuten>,"<Devicename1>","<Devicename2>") ...bis max. 4 Devices
Beispiel:

Code Auswählen Erweitern

define Morgens notify Morgens {wakeUp(30,"sz_WakeUpLight_1","sz_WakeUpLight_2")}
- nutzt die angehängte Änderung der Wifilight.pm
- Installation: Kopieren des Codes in die MyUtilities.pm (ggf. anlegen

[herrmannj]

Hi Sandra, hi Steffen,

RGBW1 ist eine seltener LED stripe controller aus der gleichen Generation wie die RGB, zB hier http://www.led-discount.ch/product_info.php/info/p885_mi-light-rgbw-controller.html.

Der RGBW1 unterstützt einen White Channel und mit trickreicher Ansteuerung kann er auch Sättigung. Obwohl sich durch den Weiß Kanal schönere Farben als beim RGBW2 erzeugen lassen kann ich den nicht empfehlen weil die Ansteuerung kompliziert, langsam (bis 2Sekunden pro Frame) und fehleranfällig ist. Die RGBW2 sind im an den "4 Zonen" erkennbar / unterscheiden sich. Gibt es als E27 und als stripe Controller.

@Steffen: die Version mit der Gammakorrektur noch nicht im ersten Post, Du findest sie einige Posts vor diesem. Kuzl hat zu Recht folgendes reklamiert: das menschliche Sehvermögen (Helligkeitsempfinden) ist nicht linear. Bei Dunkelheit reagiert das Auge auf minimale Helligkeitsschwankungen sehr empfindlich. Daher habe ich eine Gammakorrektur eingebaut die dem Rechnung trägt und dafür sorgt das die Transitions unabhängig von der Framerate weicher wirken. Das kommt daher das eben bei geringer Helligkeit die einzelnen Helligkeitsschritte filigraner sind 

Sandra: noch schöneres Video !

( wo sind Musik und Darmstädter Bier ?    )

Du sprichst bis jetzt die V3 nur mit UDP an. Es ginge aber auch mit TCP wenn man den Controller so einstellt. Das wäre doch auch eine nette Verbesserung

Kann ich mit aufnehmen, TCP erzeugt gegenüber UDP allerdings overhead und die V4 bridge hat kein webinterface mehr über die man das einstellen kann. - aber:

Mir ist aufgefallen, dass Pakete oft verloren gehen

Worauf gründet sich diese Aussage ? Bei UDP ist der Transport doch Einbahnstrasse ? Ist es möglich das Du Frames die ausgelassen werden beobachtest ? In Deinem script steuerst Du die device getrennt mit der gleichen sequenz an. Das würde ich nur in echter Not machen (wenn beide getrennt geschaltet werden müssen). Bei einer Milight RGBW2 braucht ein Frame 200-300 msec: PRO DEVICE PER BRIDGE!. Das reicht für maximal (!) 3-5 Frames pro Sekunde für EIN DEVICE. Wenn Du über die gleiche Bridge 2 DEVICE mit der gleichen Sequenz ansteuerst muss die bridge die gleiche Sequenz an Device A (300 msec) dann an Device B (300 msec) geben -> halbe Framerate und pro Device wird minimum jeder zweite Frame verworfen.  Wenn Du beide Lampen als EINE Gruppe betreibst hast Du sofort doppelte Framerate.

anbei meine Änderungen für den die on mit HSV Methode

Da ist noch irgendwo eine falsche Annahme.  In Deinem script kannst Du den Durchlauf über die Schleifen "off" und "on" komplett  rausnehmen. "off" sollte die Lampe doch morgens ohnehin sein und "on 240,100,0" ist ein "off", damit sogar redundant Das "on" bezieht sich nicht auf dn physikalischen Zustand der Lamp sondern auf "jetzt kommt da Licht raus". (exakt: jetzt kommt da weißes Licht mit 100% raus. Alternative Formen zu "mache Licht": "dim xxx", "set HSV", set "RGB")

"local @farben" muss im ersten Eintrag "240,100,0" bekommen (Startwert, noch kommt kein Licht raus). Dann ist der Loop über "set HSV" alles was notwendig ist - es braucht kein "on"! 

in fhem lässt sich das noch weiter reduzieren wenn Du alles in ein "at" oder "notify" packst.

edith:
beinahe vergessen:
In Deinem Script stehen auch
["90,100,14",1],
["70,100,16",1],
sollen die so oder ist das so weil ",0" nicht ging. Das hab ich vorhin noch als Bug erkannt, fix ich in kommender Version damit in der Queue wieder "hart" geschaltet werden kann...
vg
Jörg

[Blackcat]

Hi Jörg,

Sandra: noch schöneres Video !

( wo sind Musik und Darmstädter Bier ?    )

Nachmittags doch noch nicht Musik ist jetzt auch da. Mal was klassisches

Worauf gründet sich diese Aussage

Ich drücke in Fhem auf aus und nichts passiert (auch nach 30sek nicht) und das gefühlt fast bei jedem 3. mal

Wenn Du beide Lampen als EINE Gruppe betreibst hast Du sofort doppelte Framerate.

Ist aber dann auch nicht mehr getrennt schaltbar. Wenn einer abends noch lesen will und der andere nicht.

Da ist noch irgendwo eine falsche Annahme.  In Deinem script kannst Du den Durchlauf über die Schleifen "off" und "on" komplett  rausnehmen. "off" sollte die Lampe doch morgens ohnehin sein und "on 240,100,0" ist ein "off", damit sogar redundant Das "on" bezieht sich nicht auf dn physikalischen Zustand der Lamp sondern auf "jetzt kommt da Licht raus".

Mir ist aufgefallen, dass sich Fhem sonst bei mir nicht aktualisiert, daher diese Befehle. --> vielleicht ein Bug?

in fhem lässt sich das noch weiter reduzieren wenn Du alles in ein "at" oder "notify" packst.

Da fehlt mir aber dann die Flexibilität der einstellbaren Zeit, der Devices etc.

Ich habe jetzt 30 Minuten bei mir eingestellt und 2 Devices mit einem:

Code Auswählen Erweitern

define Wecken at *05:15 {wakeUp(30,"Device1","Device2")}

In Deinem Script stehen auch
["90,100,14",1],
["70,100,16",1],

Die Werte werden nachher mit der eingestellten Zeit anteilig multipliziert es ist also ein Gewichtungswert der Dauer

Viele Grüße
Sandra

[herrmannj]

peer gynt oder ?, Sonntag halt   

ch drücke in Fhem auf aus und nichts passiert (auch nach 30sek nicht) und das gefühlt fast bei jedem 3. mal

möglich, wenn ja beseitige ich das. So aber zu unspezifisch. Kann auch Funke (bridge -> bulb) sein. Zum prüfen brauche ich aber eine genauere Beschreibung, evtl log verbos 5.

Ist aber dann auch nicht mehr getrennt schaltbar. Wenn einer abends noch lesen will und der andere nicht.

korrekt. Das ist die "notwendigkeit"

Mir ist aufgefallen, dass sich Fhem sonst bei mir nicht aktualisiert, daher diese Befehle. --> vielleicht ein Bug?

nix versteh. wie eben, gern genauer beschreiben. Aber wie gesagt, nicht notwendig, redundant

Die Werte werden nachher mit der eingestellten Zeit anteilig multipliziert es ist also ein Gewichtungswert der Dauer

ok. Hinweiß: gibt im Augenblick einen Fehler (Transition stoppt) wenn div 0 ergibt. Fixe ich.

5:15h, sportlich! Der frühe Vogel den Wurm

vg
Jörg

[Steffen]

Guten Abend!

@Steffen: die Version mit der Gammakorrektur noch nicht im ersten Post, Du findest sie einige Posts vor diesem. Kunzl hat zu Recht folgendes reklamiert: das menschliche Sehvermögen (Helligkeitsempfinden) ist nicht linear. Bei Dunkelheit reagiert das Auge auf minimale Helligkeitsschwankungen sehr empfindlich. Daher habe ich eine Gammakorrektur eingebaut die dem Rechnung trägt und dafür sorgt das die Transitions unabhängig von der Framerate weicher wirken. Das kommt daher das eben bei geringer Helligkeit die einzelnen Helligkeitsschritte filigraner sind

So habe die Version gefunden und bin gerade im Testen, was mir sofort aufgefallen ist das gleich zum Start sagen wir von:

Code Auswählen Erweitern

set LW12 HSV 0,100,0 30; set LW12 HSV 350,100,100 30 ql(wie drücke ich es am besten aus) doch viele Verzögerungen sind und es ein wenig stockt, dann sind aber die Farbübergänge sehr flüssig!
Beim zweiten Ablauf genau so, immer von sagen wir "0,0,0 30" zu "0,100,100" stockt es genau am Anfang,
kann man da noch was machen? Aber wie du sagst, jammern auf Hohen Niveau

Danke für den Erklärung mit RGBW1&RGBW2 jetzt sehe ich die Bäume wieder...

Wollte jetzt für unsere Einfahrt am Haus damit ein Projekt starten was die Farbe bei gehen verändert(in gewissen Abständen),
wenn man auf das Haus zu geht. Wenn fertig kommt hier sofort das Video!

Mfg Steffen

[herrmannj]

Hi Steffen,

(wie drücke ich es am besten aus) doch viele Verzögerungen sind und es ein wenig stockt, dann sind aber die Farbübergänge sehr flüssig!

Teil 2 ist sehr schön, da ist auch wirklich viel Optimierung rein geflossen.
Teil 1 hat Kuzl ähnlich diffus (sorry) beschrieben, ich kann mir noch nicht richtig was drunter vorstellen, anders formuliert: hmmmm 

Der LW12 ist ja wirklich sehr schnell und genau, seid ihr Euch halbwegs sicher das wir das wir das bei den Frames einsortieren sollten ? Ich hätte noch die Idee den Start der Transition um einige ms zu verzögern - das würde zu Beginn etwas CPU Luft schaffen und wenn es zu Begin der Transition noch ein wenig hakelt - später nicht mehr, vielleicht sind das die 110%? Was denkt Ihr ?

vg
Jörg

[Blackcat]

Mir ist gerade noch eine Idee gekommen:
Man könnte für jedes Device eine Standardstartfarbe definieren. Dann brauch man im Floorplan nur noch on drücken und schon hat die Lampe z.B. ein gedimmtes Gelb, anstatt weiß.

Zu der Ansteuerung: lampe ist an, ich klicke z.B. auf Off -> nichts passiert, ich klicke nochmal - nichts, ich klicke on und dann Off.... Siehe da es geht. Genaue Ursache weiß ich aber nicht..  Deswegen auch die Redundanz weil der erste Befehl teils auch nicht angekommen ist

@Steffen
Auf das Video freue ich mich schon. Wie machst du die Personenerkennung?

[Steffen]

@herrmannj
Ja dachte ich mir schon und ist aber auch sehr schwer zu beschreiben mit Worten,
deswegen mache ich Morgen mal ein Video davon.
Aber trotzdem sehr zu frieden mit der neuen Version...

@Blackcat
Zum einem mit Presence über Bluetooth und Bewegungsmelder, das ganze klappt schon im Haus mit Flur Licht nun aber draußen mit Led stripes!

Mfg Steffen

[herrmannj]

Mir ist gerade noch eine Idee gekommen:
Man könnte für jedes Device eine Standardstartfarbe definieren. Dann brauch man im Floorplan nur noch on drücken und schon hat die Lampe z.B. ein gedimmtes Gelb, anstatt weiß.

Gute Idee, beim slider will ich sowieso noch was machen um den fhem Standard color picker zu nehmen und den slider der jetzt drin ist skinnable und optional zu machen (wegen floorplan). Dabei möchte ich die 6 presets per attrib anpassbar machen (der color picker hat ja schon presets) und da kann ich gern eine Standard Farbe in die attribs nehmen.

Ja dachte ich mir schon und ist aber auch sehr schwer zu beschreiben mit Worten,
deswegen mache ich Morgen mal ein Video davon.

Ja das wär cool. Was ich mir vorstellen könnte ich folgendes Szenario: im Augenblick wird die Transition berechnet (dauert je nach Transition auf einem raspi eine x0 - x00 msec). Gleichzeitig startet die Transition in der Ausführung und ist damit in Konkurrenz um die CPU Zeit. Wenn ich den Start um einige x00 msec verzögere entspannt es das. Allerdings lässt sich das nicht sinnvoll dynamisch regeln, deshalb würden dann halt alle Transitions leicht delayed starten. Bedeutet: wenn ich einen Schalter drücke der eine Transition auslöst hat fhem schon eine eigene delay und da kommen dann eben nochmal 'ne halbe sekunde drauf. Aber wir können ja mal testen ob es das "Anfangs-Hakeln" wegnimmt. Heute hab ich keine Lust mehr dazu, ich schau mal das ich morgen eine Testversion dazu baue.

Zu der Ansteuerung: lampe ist an, ich klicke z.B. auf Off -> nichts passiert, ich klicke nochmal - nichts, ich klicke on und dann Off.... Siehe da es geht. Genaue Ursache weiß ich aber nicht..  Deswegen auch die Redundanz weil der erste Befehl teils auch nicht angekommen ist

nach fhem Neustarts oder wenn Du die milight app nimmst ? Das modul optimiert die Auslastung auf der bridge dadurch das es commands die keine Änderung auf der bulb bewirken nicht sendet. Spart mehrere 100msec. Bedeutet aber auch das die bulb den Status haben muss den das Modul kennt. Wenn das Modul den Status "off" für die bulb annimmt, die bulb aber per fb oder app eingeschaltet wird oder ein fhem neustart den state ändert und Du dann über fhem "off" sendest schaut das Modul welchen Status es kennt: user will "off", bulb ist schon "off", das passt - danke, der nächste bitte 

Im Zusammenhang mit purem "on" "off" erscheint das nicht viel, aber gerade bei den Transitions (die an der gleichen Mechanik hängen) und wo es um jede msec geht ist das wesentlich.

Wenn das nochmal auftritt schau mal bitte in die Readings ob der Status im Modul mit der Wirklichkeit an der bulb übereinstimmt Passt aber genau auf die description ...

vg
Jörg

[Kuzl]

Hallo zusammen,

ja ich könnte mir wirklich vorstellen, dass das die ganze Sache etwas entzerrt
Für ein dynamisches Regeln fällt mir jetzt auf Anhieb auch nichts ein. Evtl irgendwie so eine Art "Mindestframerate".
Die Framerate wird ja dynamisch je nach CPU-Auslastung gewählt... Hab jetzt keine Ahnung wie die Auswertung da aussieht aber vll kann man das schon vor beginn überprüfen und erst loslegen, wenn eine gewisse Framerate erreicht werden kann. Aber erst mal müssen wir testen ob das überhaupt Abhilfe schafft

Eine Startfarbe finde ich auch interessant aber bitte optional als Attribut wie du es eh wolltest

Viele Grüße
Kuzl