WIFI LED Controller

[Kuzl]

So hallo
ich hab das ganze jetzt mal eingebaut - mensch das war fuselig

@ Betateilchen: kannst du nochmal druberschaun? bin mir nicht sicher ob das alles so gut ist wie ich es gemacht habe aber es funktioniert zuminderst.

EDIT: Sry vergessen also Anwendung ist: "set <device> animation <rrggbb> <rrggbb> <- bis zu 16 farben <speed 0-255> <mode 0-2>

[betateilchen]

Auf jeden Fall solltest Du in der Syntax die Reihenfolge von mode und speed vertauschen, um zum "set mode" einheitlich zu sein, sonst tappt man als Anwender regelmäßig in die Syntaxfalle. Den Rest im Modul schaue ich mir später an.

[Pythonf]

Zu deinen Änderungen kann ich leider nichts sagen, da ich mich da nicht auskenne. Was mir allerdings aufgefallen ist, wenn ich ich set HSV 30 100 100 eingebe, zieht er beim H-Wert eins ab und macht im Reading 29 100 100 darauß

Grüße
Fabian

[Kuzl]

Hallo zusammen,

@ Pythonf: Ja das wird warscheinlich ein Rundungsfehler sein. Der HSV-Wert muss ja vor dem Senden in RGB gewandelt werden. Anschließend wird der ausgelesene RGB-Wert wieder in HSV gewandelt und in das Reading eingetragen. Bei dem hin- und herrechnen wird da warscheinlich einfach durch das Runden auf ganzzahlige Werte was verschluckt.

@Betateilchen: Ja, das kann ich machen. Wobei zu beachten ist, dass da ja nicht ein echter "mode" ausgewählt wird, sondern nur die Art des Übergangs. Darf man nicht mit den preset-modes verwechseln.

Hab mal die Zeiten gemessen. Beim speed entspricht 1 stufe = ca. 0.106 s damit ist wenn der speed auf 0 ist die Zeit ca 27 s

EDIT: Scheint bei jedem mode anders zu sein die obrigen werte gelten für das "harte" Umschalten. bei strobe ist speed 0 ca. 8 s

[betateilchen]

Den Rest im Modul schaue ich mir später an.

Ich habe seit gestern Abend Besuch, da wird es nun bis Sonntagabend etwas knapp mit fhem-Basteleien. Aber ich habs nicht vergessen.

[Kuzl]

Kein Problem ich hab bis dienstag warscheinlich auch keine oder nur sehr wenig Zeit dafür

[jostmario]

Hallo

nur mal so nebenbei.
gibt es auch einen Controller der wie der Lw-12 funktioniert aber nicht über W-lan sondern über Kabel Lan also eine richtige Lan Buchse hat.
wenn ich jetzt in jedem Raum einen LW-12 setze dann ist mein ganzes Haus voller W-Lan netze das kann nicht gesund sein

Nachtrag:
meine sowas hier nur nicht zu dem preis und unterstützt durch Fhem
http://www.led1.de/shop/solarox-rgb-master-pro-lan.html?gclid=CjwKEAiA4_WjBRCNgf7A_KeE9jwSJADtegYdJWLzll0XpOnGnQBEjLDichT7zuSmbBAelQZHBypJ2BoCmkTw_wcB


Gruß Josty

[Raudi]

Hallo, ich habe mir den LW12 bei Amazon geholt und möchte, wenn mein LED Streifen aus China endlich da ist, das ganze auch über FHEM steuern. Habe bisher FHEM noch nicht installiert, werde dies aber vermutlich auf meinem Intel Atom J1800 System, auf dem Arch Linux läuft die nächsten Tage mal machen. Der Rechner läuft eh 24/7. Habe auch einen Raspberry Pi, an dem nen billiger 433MHz Sender, mit dem ich Elro Steckdosen schalte und ein 1-Wire Temperatursensor hängen. Ich werde dann auch noch ein HomeMatic USB für Heizkörper dran hängen und ich habe aus China schon nen Arduino und nen 433MHz Modul bestellt, um entweder nen FHEMDuino, oder Selbstbau CUL raus zu machen, um dann günstige Thermometer für die Heizungssteuerung verwenden zu können. Aber nun zurück zum Thema:

Wenn ich es richtig verstanden habe, gibt es 2 Möglichkeiten, den LW12 unter FHEM zu benutzen. Wifilight und Wifiled.
Wo liegen die Unterschiede und was sollte ich verwenden? Ich will primär eine einfache Raumbeleuchtung, die sich automatisieren lässt, und ein Wakeup Light daraus bauen.

[Kuzl]

Hallo zusammen,

so jetzt ist die Prüfung rum jetzt kann ich mich wieder richtig fhem widmen

@ jostmario: mir ist jetzt keiner bekannt aber was mir jetzt spontan einfällt ist ein umweg über dmx. Also einen dmx-rgb-controller und dann z.b. ein dmx-lan-interface (teuer) oder ein dmx-usb-interface. Das usb kannst du dann ja z.b. über einen usb-server (gibts für unter 20€) durchs netzwerk tunneln lassen... ist dann insgesammt natürlich teuerer aber einfacher erweiterbar wenn du dmx nutzt

@Raudi: Prinzipiell kannst du beides verwenden. WIFILED ist speziell für den LW12 ausgelegt und kann z.b. den rückkanal. d.h es zeigt auch wirklich den aktuellen Zustand an, auch wenn du ihn z.b. durch die app änderst. Außerdem werden die Hardwareanimationen einschließlich der Benutzerdefinierten Animationen unterstützt. Diese sind allerdings (bezogen auf dein wakeup-light) nicht für so langgezogene farbübergänge von einigen Minuten ausgelegt. Da musst du entweder selber alle paar minuten die farbe einstellen oder du nutzt Wifilight. Du kannst auch beides in kombination nutzen, solange du Wifilight nicht abhängig von einem aktuellen Farbwert steuerst, den kennt dann nämlich nur WIFILED durch den Rückkanal. Für schnellere Animationen ist WIFILED besser geeignet, da diese vom LW12 selbst verarbeitet werden und so das Netzwerk und  den FHEM-Server sehr viel weniger belasten. Außerdem ist dann auch kein Ruckeln erkennbar.

@betateilchen: Bist du schon dazugekommen ein bisschen drüberzuschaun?

Viele Grüße
Kuzl

[betateilchen]

@betateilchen: Bist du schon dazugekommen ein bisschen drüberzuschaun?

Bin grade dabei.

[betateilchen]

Den CommandTrigger() in Zeile 492 kannst Du entfernen.

Und das hier solltest Du besser so machen:

Code Auswählen Erweitern


      readingsBeginUpdate( $hash );
        readingsBulkUpdate( $hash, "hsv", $hsv_reading );
        readingsBulkUpdate( $hash, "mode", hex( $colors[ 3 ] ) - $offset );
        readingsBulkUpdate( $hash, "dim", $dim->{bri} );
        readingsBulkUpdate( $hash, "speed", 255 - hex(  $colors[ 5 ] ) );
      readingsEndUpdate( $hash,1 );


Wenn man mehrere readings gleichzeitig aktualisiert, muss man nicht bei jedem reading den Trigger auslösen, das macht das EndUpdate dann automatisch.

Das hier:

Code Auswählen Erweitern


  RemoveInternalTimer($hash);
  InternalTimer(gettimeofday()+ 1 , "WIFILED_Update", $hash, 0);
  WIFILED_UpdateRGB( $hash );


würde ich in eine eigene Funktion packen, da Du diesen Codeschnipsel unzählige Male verwendest.
Darüberhinaus würde ich WIFILED_UpdateRGB() direkt aus WIFILED_Update() aufrufen.


Ansonsten schaut das ganz gut aus.

[Kuzl]

Dankeschön werd ich berichtigen (vorraussichtlich leider erst am freitag bin davor nicht zuhause)

[betateilchen]

Kein Problem.

Ich bin sogar der Meinung, das hier:

Code Auswählen Erweitern


RemoveInternalTimer($hash);
InternalTimer(gettimeofday()+ 1 , "WIFILED_Update", $hash, 0);
WIFILED_UpdateRGB( $hash );


durch einen Aufruf von "WIFILED_Update"  ersetzen.

Das erste, was WIFILED_Update nämlich tut, wenn es aufgerufen wird, ist ohnehin das Löschen des InternalTimer(). Das "manuelle" Löschen vor dem Aufruf kannst Du also weglassen. Und wie schon gesagt, das WIFILED_UpdateRGB() würde ich mit in die WIFILED_Update packen, dann brauchst Du auch das nicht mehr gesondert aufrufen.

Ausserdem brauchst Du den Aufruf dann nur ein einziges Mal ins Coding schreiben, nämlich nach direkt vor dem "return (undef)" in der WIFILED_Set und nicht in jeden einzelnen Befehl. Hat den zusätzlichen Vorteil, dass bei Befehlserweiterungen das update nicht vergessen werden kann

Code Auswählen Erweitern


  } else {
      return SetExtensions ($hash, $cmdList, $name, $cmd, @arg);
  }
  WIFILED_Update( $hash );
  return( undef );
}


[Kuzl]

Du hast recht das mit dem updaten gefällt mir noch nicht so richtig. Ich hab das ursprünglich in 2 Funktionen gepackt, damit der colorpicker schon die gewünschte farbe erhält, bevor die Abfrage vom LW12 beantwortet wird. Mich hat nämlich die ca. 1 Sekunde gestört die er dafür benötigt hat.

Wie würdest du das dann lösen mit dem "verzögerten" abfragen des LW12 bei einem befehl lösen? Die Lösung von Andre hab ich wenn ich ehrlich bin nicht ganz verstanden, auch wenn sie warscheinlich eine der saubersten ist.

Auf die Idee- den Aufruf unten hin zu schreiben hätte ich selbst auch kommen können ich Idiot

[Pythonf]

Zum Thema der Verzögerung der internen Readings hätte ich eine Idee:
Mir geht es nämlich so, dass es mich eigentlich eher stört, dass die Readings, nachdem ich einen Befehl gesendet habe, erst nach einer Verzögerung geupdatet werden.
Eine Möglichkeit die mir dann einfallen würde, wäre die Readings beim Senden des Befehls über die eingegebenen Werte zu updaten und wenn alle Befehle gesendet wurden am Schluss nochmal ein Update über den Rückkanal durchzuführen, müsste ja in den allermeisten Fällen übereinstimmen. Dann wäre auch das Problem mit dem Colorpicker gelöst.

Grüße
Fabian