WIFI LED Controller

[Kuzl]

Bei welchem reading hat dich denn das gestört? im Moment wird das so bei RGB gemacht.

[Pythonf]

Ich beziehe das vor allem auf das HSV Reading

[betateilchen]

dass die Readings, nachdem ich einen Befehl gesendet habe, erst nach einer Verzögerung geupdatet werden.

Ich sehe nun eine Sekunde Reaktionszeit nicht wirklich als Problem. Das Problem bei Deiner vorgeschlagenen Lösung würde sich dann allerdings anders darstellen:

Wenn man ein reading anhand des Befehels aktualisiert, muss man sich entscheiden, ob man das mit oder ohne Trigger macht. Um den colorpicker "vorzeitig" zu versorgen, müsste man die Variante mit Trigger wählen.

Eine Sekunde später wird dann durch das Update() nochmal ein Trigger für exakt das gleiche Event ausgelöst und die notify-Kette neu gestartet.

Davon würde ich dringend abraten da dies erfahrungsgemäß in Folge viel mehr Probleme hervorruft als eine kurze Wartezeit bis zur Aktualisierung.

Ich würde ein CommandSleep() mit einer Sekunde im Coding direkt vor den Aufruf des Update nach einer Befehlsausführung setzen.

[Kuzl]

CommandSleep() werde ich so einbauen evtl mit übergabeparameter, da z.b. ein sehr schneller moduswechsel keinen Sinn ergibt, kann dann eigentlich direkt die Abfrage aufgerufen werden.

Was hältst du davon, wenn alle errechenbaren Readings gleich beim setzen des Befehls gesetzt werden und dann nur noch korrigiert werden, falls vom Controller was anderes kommt? somit ist auch nur 1 Event erzeugt. Zuminderst für RGB sehe ich das ganz sinnvoll. Teste das mal mit 1 sek Verzögerung das wirkt irgendwie so, als würde FHEM hängen wenn sich der colorpicker so langsam aktualisiert....

Am Wochenende komm ich dann endlich mal dazu das alles umzusetzen

[Pythonf]

@Kuzl das war eigentlich das, was ich gemeint hatte. Würde das dann auch für  HSV gehn?

Grüße  Fabian

[Kuzl]

@Fabian: möglich ist es auf jeden fall, mal sehen was Betateilchen dazu sagt.

[betateilchen]

Was hältst du davon, wenn alle errechenbaren Readings gleich beim setzen des Befehls gesetzt werden und dann nur noch korrigiert werden, falls vom Controller was anderes kommt?

Nichts. Dann bist Du nämlich wieder bei den Unmengen überflüssiger Wertevergleichen, die ja glücklicherweise gerade ausgebaut wurden.

Dann lieber die Variante, die Readings anhand des Befehls zu aktualisieren und auf das erste reguläre Werteupdate (UpdateIntervall) warten. Der Krampf mit dem Update 1 Sekunde nach dem Befehl würde dabei komplett entfallen.

[Pythonf]

Code Auswählen Erweitern

die Readings anhand des Befehls zu aktualisieren und auf das erste reguläre Werteupdate (UpdateIntervall) warten

Diese Variante finde ich eigentlich am attraktivsten für das Modul. Den dann sind Funktionen, die auf die Readings des Wifiled zugreifen am einfachsten umzusetzen. Den externe Änderungen an den Einstellungen des LW12 beruhen häufig auf den Readings. Und wenn diese erst nach 1 Sekunde aktualisiert werden, kann es vorkommen das ein Notify,at,... auf veraltete Readings zugreift und deshalb nicht einwandfrei funktioniert.
Dies ist zumindest bei mir der Fall.

Grüße
Fabian

[Raudi]

Gibt es eigentlich eine Dokumentation der Funktionen von WifiLED? Bin momentan am rumexperimentieren, was alles damit möglich ist. Habe auch eine Pebble APP geschrieben, mit der ich dann jetzt den LW12 über FHEM mit meiner Uhr steuern kann. Falls jemand Interesse daran hat: http://martin-p.blogspot.de/2014/12/wifi-rgb-led-controller-fhem-pebble.html

[basi79]

Hallo Leute,

ich bin ein stiller intensiv verfolger dieses Forums

Ich wollte einfach mal etwas mit euch teilen, was für mich sehr lange auf dem Plan war.
Gestern Abend habe ich es nun endlich fertiggebaut (naja fast).

kleine Schönheitskorrekturen muss ich ggf. noch machen.. aber im großen und ganzen kann sich das sehen lassen..

habe folgendes Device zur RGB-LED Steuerung benutzt: LW12 (http://www.amazon.de/NEUER-STRIPS-CONTROLLER-iPhone-Android/dp/B00G55329A/ref=sr_1_1?ie=UTF8&qid=1418047568&sr=8-1&keywords=lw12)


fhem.cfg:

define WiFi.LED.WZ.02 WIFILED wifiled01.fritz.box
attr WiFi.LED.WZ.02 devStateIcon on:light_led@green off:light_led@red
attr WiFi.LED.WZ.02 icon light_led_stripe_rgb
attr WiFi.LED.WZ.02 room Wohnzimmer
attr WiFi.LED.WZ.02 timeout 2
attr WiFi.LED.WZ.02 updateInterval 60
attr WiFi.LED.WZ.02 verbose 3
attr WiFi.LED.WZ.02 webCmd rgb:dim 10:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off

das mit attr WiFi.LED.WZ.02 devStateIcon {Color_devStateIcon(ReadingsVal($name,"rgb","f00000"))} hat bei mir leider noch nicht funktioniert

##### Fernbedienung Signalisierung
define Notify.WZ.LED.Signaling.Fernb notify Fernb_Taste_.* {\
   my $varState = (ReadingsVal("WiFi.LED.WZ.02","state","off"));;\
   my $varStateRGB = (ReadingsVal("WiFi.LED.WZ.02","rgb","000000"));;\
   fhem ("set WiFi.LED.WZ.02 on");;\
   fhem ("set WiFi.LED.WZ.02 animation ff0000 0000ff 250 1");;\
   fhem("define at.WZ.LED.Signaling at +00:00:01 set WiFi.LED.WZ.02 $varState ;;;; set WiFi.LED.WZ.02 rgb $varStateRGB");;\
   }
attr Notify.WZ.LED.Signaling.Fernb room _Notifys_

##### Jemand ruft mich an
define Notify.WZ.LED.Signaling.Call notify FBCM:event:.ring { \
   my $varState = (ReadingsVal("WiFi.LED.WZ.02","state","off"));;\
   my $varStateRGB = (ReadingsVal("WiFi.LED.WZ.02","rgb","000000"));;\
   fhem ("set WiFi.LED.WZ.02 on");;\
   fhem ("set WiFi.LED.WZ.02 animation 00ff00 000000 250 1");;\
   fhem("define at.WZ.LED.Signaling at +00:00:10 set WiFi.LED.WZ.02 $varState ;;;; set WiFi.LED.WZ.02 rgb $varStateRGB");;\
   }
attr Notify.WZ.LED.Signaling.Call room _Notifys_

Und habe noch eine Frage: Wann/Wird der Support im Modul WIFILED für das Device LD382 (http://www.amazon.de/dp/B00Q7STR4E/ref=sr_ph?ie=UTF8&qid=1418046881&sr=1&keywords=ld382) geben..??



Das ganze läuft bei mir auf dem Raspberry-Pi

[Pythonf]

das Device LD382 wird gerade im Modul Wifilight mit entwickelt. Beide Module unterstützen den LW12, Wifiled unterstüzt allerdings keine andere Hardware und ist auf den LW12 spezialisiert. Wifilight untersützt noch einige andere Geräte.

[Kuzl]

Sry Leute, hatte einfach keine Zeit bis jetzt.

Anbei findet ihr die aktuelle Version jetzt mit den Verbesserungsvorschlägen und mit der entfernten 1-Sekunden-Geschichte.
Die Readings werden jetzt sofort aktualisiert und unabhängig davon immer im eingestellten Intervall.

Frage dazu: Wie kann ich ausschließen, dass ein Intervall-Update in eine Reihe von Befehlen (z.b. abdimmen) fällt?

Ich bitte um Tests und durchsehen des Codes Aber ich glaub langsam wird das ganze
Soll eigentlich noch ein Reading eingeführt werden, das anzeigt ob gerade eine Animation läuft?

@Raudi: Eine Doku findest du am Ende des Moduls.
Viele Grüße
Kuzl

[Pythonf]

Danke für die neue Version!

Zum Thema des Readings ob eine Animation läuft oder nicht. Ich persönlich bräuchte das nicht zwingend, aber ich würde es wenn, dann vielleicht über "state" regeln, bis jetzt nimmt state ja nur on und off an, da aber der Controller immer an ist, wenn eine Animation läuft, könnte da dann z.B. "on:animation" oder expliziter für z.B. Animation "on:4" stehn. Nachteil des ganzen wäre, man müsste beim auslesen des State die Variable am doppelpunkt splitten, wenn man auf ein on oder off reagieren müsste.

Grüße
Fabian

[Kuzl]

Kein Ding ich wills ja auch verbessern

Bezüglich des States will ich noch abwarten, was da mit dem devStateIcon rauskommt, Andre hat da irgendwas vor so wie ich gelesen hab.
Ansonsten evtl einfach als Reading, ist ja gut da

[betateilchen]

Ich hab es noch nicht getestet, aber welchen mode meldet denn der LW12 zurück, wenn eine Animation läuft? Vermutlich könnte das doch schon als Indikator ausreichen.