Hi,,
hat schon mal jemand den WIFI LED Controller http://www.enledcontroller.com/article/show/21.aspx ausprobiert?
Funzt zumindest mit der iOS App wunderprächtig. Ich versuche gerade rauszubekommen welches Protokoll http/telnet .... er spricht.
Hat ganze 40 Euronen gekostet. Preiswerter geht es kaum.
(http://www.enledcontroller.com/UpLoadFiles/20130423/2013042301500726.jpg)
Als WLAN-Modul wird dieses eingesetzt:
http://www.hi-flying.com/products_detail/&productId=d5dbe15d-4e68-4406-968b-9790b7d77316&comp_stats=comp-FrontProducts_list01-111.html
-Support UART/GPIO/Ethernet Data Interface
Leider habe ich den schon im Schrank verbaut. Sollte ich das nicht per "Fernwartung" herausbekommen werde ich den wohl wieder ausbauen und zerlegen müssen.
laut der Beschreibung macht der sein eigenes WLAN auf... kann man den auch dazu bewegen sich in ein bestehendes Netz einzuklinken?
Die neuere Generation dieser WLAN-Controller hängt sich in bestehende Netze ein.
Richtig, hängt im bestehenden Netz.
Wo hast du Controller besorgt,
bei ebay verlangen sie 60€ dafür.
Hat du es schon hin bekommen, in über fhem zu steuern?
Gruß Hannes
Gesendet von Unterwegs mit Tapatalk 4
Amazon: http://www.amazon.de/gp/product/B00G55329A
Nein, leider noch nicht per FHEM steuerbar.
Ich versuche gerade den Netzwerkverkehr mitzuschneiden.
Hat da jemand ne Lösung wie ich per WLAN (Macbook) sniffen kann.
Hallo,
ich verwende dazu immer Wiresharke,
gibt es anscheinend auch für MAC
http://www.wireshark.org/download.html
Zitat von: jenscz am 05 November 2013, 20:57:57
Ich versuche gerade den Netzwerkverkehr mitzuschneiden.
Hat da jemand ne Lösung wie ich per WLAN (Macbook) sniffen kann.
Schon versucht. Da kommt aber anscheinend nur der verschlüsselte Stream an. Ich verschieb das jetzt mal auf das Wochenende. Dann häng ich zwischen Handy (App) und dem Controller 2 APs die mit einem Netzwerkkabel über einen alten HUB verbunden sind. Damit sollte der komplette umverschlüsselte Verkehr aufgezeichnet werden können.
Handy<------>AP1<-------->HUB<-------->AP2<----------->LED Controller
|
|
|
Wireshark
Moin jenscz,
wenn Du eine Fritzbox hast, dann versuche es mit:
http://fritz.box/html/capture.html
danach den Netzwerkverkehr mit Wireshark analysieren.
Gruß Joachim
Ahh, mit der Fritzbox kommt da schon mehr.
Ha, ich hab es (fast) fertig:
use IO::Socket::INET;
my ($socket,$client_socket);
$socket = new IO::Socket::INET (
PeerHost => '10.16.254.78',
PeerPort => '5577',
Proto => 'tcp',
) or die "ERROR in Socket Creation : $!\n";
# send RGB command
#$data = $ARGV[0];
#RRGGBB
$socket->send("\x{56}\x{FF}\x{FF}\x{FF}\x{AA}");
sleep (1);
$socket->close();
Teilweise übernommen aus http://forum.fhem.de/index.php/topic,13231.0.html .
Wobei die FF jeweils durch ein Byte in Hex zu ersetzen sind. Im Beispiel sind jetzt alle Farben auf 100% on (FF=255).
Reihenfolge: Rot,Gelb,Blau
Wie kann ich das jetzt als Option dem Perlschrift übergeben?
$socket->send("\x{56}\x{$ARGV[0]}\x{$ARGV[1]}\x{$ARGV[2]}\x{AA}");
Ging schon mal nicht!
Schei... wenn man sich den Perl Code immer nur per drag and drop zusammenklaubt.
Am liebsten wäre es mir ja das so zu machen, dass ich direkt die Rückgabewerte des Colorpicker ( http://www.fhemwiki.de/wiki/Color ) übergeben kann.
Wobei ich noch nicht verstanden habe wie man den einbaut, ich steh da ein wenig auf dem Schlauch.
Ich habe heute Unterstützung durch einen Arbeitskollegen bekommen. Er hat das Ganze etwas umgebaut:
use IO::Socket::INET;
if (not defined $ARGV[0]) {
print "Please give color values!\n";
exit 1;
}
my @colors = split(/,/,$ARGV[0]);
if ($#colors != 2) {
print "Please give three color values: red, green and blue!\n";
exit 1
}
my ($socket,$client_socket);
$socket = new IO::Socket::INET (
PeerHost => '10.16.254.78',
PeerPort => '5577',
Proto => 'tcp',
) or die "ERROR in Socket Creation : $!\n";
# send RGB command
#$data = $ARGV[0];
#RRGGBB
$socket->send("\x56" . chr($colors[0]) . chr($colors[1]) . chr($colors[2]) . "\xaa");
sleep (1);
$socket->close();
Allerdings müssen die Werte jetzt dezimal angegeben werden.
Zumindest gibt es jetzt, über VPN getestet, keine Fehlermeldung mehr aus. Ob die LEDs wirklich die Farbe ändern sage ich nachher wenn ich in Sichtweite bin ;-).
Ich versuche gerade die Farben über Slider zu steuern:
define Licht.Bad.RGB.G dummy
attr Licht.Bad.RGB.G devStateIcon 0:off
attr Licht.Bad.RGB.G room Bad
attr Licht.Bad.RGB.G setList state:slider,1,1,255
attr Licht.Bad.RGB.G webCmd state
Das gleiche für R und B
define n_Licht.Bad.RGB notify Licht.Bad.RGB.* { system ("perl /opt/fhem/Licht.Bad.RGB.pl {Value('Licht.Bad.RGB.R')},{Value('Licht.Bad.RGB.G')},{Value('Licht.Bad.RGB.B')} &") };;\
Leider funkt das notify nicht:
Log:
sh: 1: Syntax error: "(" unexpected
2013.11.06 12:38:25 3: n_Licht.Bad.RGB return value: -1
Wie kann ich eine Value an das Script übergeben. Oder den ganzen Kram als Funktion direkt in die myUtils und die Values in Variablen schreiben? Fragen über Fragen ;-)
So, ich hab es jetzt fertig und es funktioniert sogar! ;D Und das für ganze 49 €.
Falls jemand von euch mehr und besser Perl kann wie ich, kann er mir ja sagen wie ich das mit dem Colorpicker umsetzen kann. Würde halt noch mal nen ganzes Stück gei.... aussehen.
Perlscript:
use IO::Socket::INET;
if (not defined $ARGV[0]) {
print "Please give color values!\n";
exit 1;
}
my @colors = split(/,/,$ARGV[0]);
if ($#colors != 2) {
print "Please give three color values: red, green and blue!\n";
exit 1
}
my ($socket,$client_socket);
$socket = new IO::Socket::INET (
PeerHost => '10.16.254.78',
PeerPort => '5577',
Proto => 'tcp',
) or die "ERROR in Socket Creation : $!\n";
# send RGB command
$socket->send("\x56" . chr($colors[0]) . chr($colors[1]) . chr($colors[2]) . "\xaa");
print "RGB $colors[0] $colors[1] $colors[2]\n" ;
sleep (1);
$socket->close();
fhem.cfg
define Licht.Bad.RGB.R dummy
attr Licht.Bad.RGB.R devStateIcon 0:off
attr Licht.Bad.RGB.R room Bad
attr Licht.Bad.RGB.R setList state:slider,0,1,255
attr Licht.Bad.RGB.R webCmd state
define Licht.Bad.RGB.G dummy
attr Licht.Bad.RGB.G devStateIcon 0:off
attr Licht.Bad.RGB.G room Bad
attr Licht.Bad.RGB.G setList state:slider,0,1,255
attr Licht.Bad.RGB.G webCmd state
define Licht.Bad.RGB.B dummy
attr Licht.Bad.RGB.B devStateIcon 0:off
attr Licht.Bad.RGB.B room Bad
attr Licht.Bad.RGB.B setList state:slider,0,1,255
attr Licht.Bad.RGB.B webCmd state
define n_Licht.Bad.RGB notify Licht.Bad.RGB.*:* { system("perl /opt/fhem/Licht.Bad.RGB.pl ".Value('Licht.Bad.RGB.R').",".Value('Licht.Bad.RGB.G').",".Value('Licht.Bad.RGB.B')." &") };;\
attr n_Licht.Bad.RGB room Bad
Damit gibt es jetzt 3 Slider:
Hi ,
Sehr geil. Danke ..
nur wäre es gut wenn man noch die Helligkeit mit einbinden könnte ... aber als noob in Sachen perl und fhem kenn ich mich da zu wenig aus.
Hi jenscz,
wird die Anbindung an den Colorpicker noch realisiert? (tolle Sache!)
Gerhard
Ich glaube dazu reichen meine Perlkenntnisse nicht aus.
Ich hatte mir schon mal ein anderes Modul angesehen, dass den Colorpicker nutzt aber leider check ich das nicht.
Hinzu kommt noch dass die wenige Zeit die ich aufbringen in der 5. Jahreszeit für ein anderes Hobby reserviert ist.
Um verschiedene Farbscenen zu wählen nutze ich im Moment das Modul LightScene.
Mir reicht das erst mal so.
im wiki ist beschrieben wie es geht: http://www.fhemwiki.de/wiki/Color (http://www.fhemwiki.de/wiki/Color). das dunktioniert auch mit einem dummy wenn du das laden und die initialilsierung z.b. in ein notify auf global::INITIALIZED steckst.
gruss
andre
Moin,
mal eine Frage, kann das Teil auch faden? Oder muss man das dann im Falle eines Farbwechslers komplett dauerhaft übers WLAN rotzen?
Gruß
Daniel
Faden, jain. Ich habe bisher nur die Codes zum Setzen von Farbwerten mitgeschnitten. Generell kann man das Erweitern und jede Funktion der Fernbedienung nachbauen.
Ich habe mir halt Scenen mit den verschiedenen Farben gespeichert. Das Ändern der Farbwerte wird dabei "hart" durchgeführt. Ein Faden also langsames Überblenden erfolgt dabei nicht.
Ich setze allerdings in der Regel nur eine Farbe entsprechend zur Stimmung/Situation und belasse es dann dabei
Gesendet von meinem iPhone mit Tapatalk (http://tapatalk.com/m?id=1)
wie wäre es denn dem ding ein 'richtiges' fhem device zu verpassen?
dann wäre es auch einfacher zusätzliche dinge wie faden oder den colorpicker einzubauen.
brauchst du dazu hilfestellung? es ist nicht wirklich schwer. das meiste hast du schon wenn du das ding steuern kannst.
schau dir mal das 35_SWAP_0000002200000003 modul an. das wäre vielleicht ein gerüst zum umbauen. eigentlich muss man da nur ein paar dinge rausschmeissen und dein senden einbauen.
gruss
andre
Ich versuche gerade das FRM_RGB umzubauen als WIFIled_RGB.
<scherz an>
Ich hasse Perl, kann das nicht in PHP sein ;-)
</scherz aus>
Ich glaub ein Mischmasch aus 10_IT.pl (schein das einfachste Modul zu sein) und FRM_RGB werde ich irgendwie hinbekommen.
Als AttrList sollte IP-Address, TCP-Port, Modell reichen.
Modell um später andere, ähnliche RGB-Geräte einzubinden die den Befehl auch per TCP-Socket bekommen. Evtl. auch noch eine Liste der möglichen Kommandos wie z.B. set, fade, dimm usw. wenn es die Hardware direkt unterstützt.
Aber wie gesagt, auf Grund der unterirdischen Perl-Kenntnisse meinerseits kann es etwas dauern.
man sollte wohl schauen, hier die gleichen attribute und parameter wie beim hue und den dimm/schalt modulen zu verwenden.
Hallo jenscz,
ich habe jetzt mein WIFI LED Modul bekommen, aber irgenwie komme ich damit nicht zurecht.
es meldet sich bei mir als server (accesspoint??!!) unter der ip 192.168.10.1.
ich kann mich damit verbinden, und bekomme auch eine html seite für einstellungen.
in deinem .pm programm habe ich auch seine ip-add. eingestellt, aber der notify liefert immer -1.
wie muss der WIFI LED eingestellt sein?, server, client...
Gerhard
muss dich extra mit dem wifi des wifi led moduls verbinden? dann ist es im access point modus und macht ein eigenes wlan von dem dein fhem natürlich nichts weiß. du musst den wifi led controller in den wifi client modus stellen und die zugangsdaten deines normale wifi eintragen.
Hallo,
bin im Augenblick dabei ein entsprechendes device zu erstellen. Das Modul erstelle ich kompatibel zu den bridge v2 bzw dem Wlan LED Stripe Controller und es sieht schon sehr gut aus.
Was habt ihr an Equipment im Einsatz ?
@gerhard
solltest Du nicht weiterkommen biete ich Dir support an, brauche ganz exakt welches Device Du hast, plus einige andere Angaben. Die V3 konnte ich nur mit Hilfe eines eigenen Progs in das bestehende Netz bringen.
Habe eine wifi bridge v3 im Einsatz die sich extrem schwierig ins Fritzbox Wlan nehmen lies. Über das web interface unmöglich weil meine ssid space enthielt, über die App unmöglich weil die App die Verschlüsselung falsch gesetzt hat.
vg
Jörg
Hallo zusammen,
ich habe mir den Controller auch zugelegt und diesen "erfolgreich" in ein zusätzliches WLAN gepackt (alles von FHEM erreichbar).
Leider erhalte ich nach Betätigen des Sliders folgendes Log auf verbose 5:
2013.12.09 07:51:08 5: Cmd: >set LED.Buero.RGB.B 127<
2013.12.09 07:51:08 4: dummy set LED.Buero.RGB.B 127
2013.12.09 07:51:08 5: Triggering LED.Buero.RGB.B (1 changes)
2013.12.09 07:51:08 5: Notify loop for LED.Buero.RGB.B 127
2013.12.09 07:51:08 5: Triggering n_LED.Buero.RGB
2013.12.09 07:51:08 5: Cmd: >{ system("perl /opt/fhem/LED.Buero.RGB.pl".Value('LED.Buero.RGB.R').",".Value('LED.Buero.RGB.G').",".Value('LED.Buero.RGB.B')." &") }<
2013.12.09 07:51:08 5: Cmd: ><
2013.12.09 07:51:08 3: n_LED.Buero.RGB return value: -1
Übers Tablet kann ich alles steuern.
Was hat "n_LED.Buero.RGB return value: -1" zu bedeuten?
Dank und Gruß
Mele
Hallo hermannj,
ich habe ein LW-12 WIFI WLAN LED RGB STRIPS CONTROLLER so wie amazon es auch anbietet (siehe link am Anfang des bloggs, allerdings von ebay gekauft).
http://www.amazon.de/gp/product/B00G55329A (http://www.amazon.de/gp/product/B00G55329A)
meldet sich unter der ip 192.168.10.1 als server (accespoint?) und kann mich über wlan anmelden (connected).
wie du schon schreibst alle einstellungen über den webbrowser (192.168.10.1 -> weboberfläche für Einstellungen) greifen nicht!
wie muss ich weiter vorgehen, was brauchst du noch für Informationen?
Danke, Gerhard
Hallo Gerhard,
hast pm
vg
Jörg
Hallo Jörg,
danke, aber bis jetzt noch nichts in meinem pm von dir??
Gerhard
Hallo Gerhard,
komisch, dann geh ich mal übers forum.
Ich habe meine V3 mit einem selbst geschriebenen script initialisieren müssen. Das hat natürlich keine GUI oder so was. Insofern handelt es sich weder um ein getestetes noch besonders benutzerfreundliches Verfahren :)
Die Verantwortung das es klappt nehme ich sehr ernst, deshalb:
* Magst Du bitte zur Sicherheit den Werksreset an Deiner Bridge testen damit sichergestellt ist das wir immer wieder auf die Factory defaults kommen.
* Würdest Du mir freundlicherweise Screenshots von der Webgui der Bridge senden ? (pm, den wifi Key bitte unkenntlich machen)
* Ich hab in Deiner Sig gesehen das Du eine FB 7390 hast, auf welche SSID soll die Bridge ? Bei der Verschlüsselung gehe ich mal von den defaults aus (WPA2/AES). Den Key musst Du dann in das script direkt eintragen.
Auf dem PC der das init übernehmen soll muss perl laufen, getestet nur unter Linux. Den Rest sollten wir interaktiv machen, ich würde gern step by step vorgehen, versuch Du es mal mit pm.
vg
Jörg
Hallo zusammen,
hier eine kurze "Wasserstandsmeldung" zum Stand der Modulentwicklung, erste Betas werden kommende Woche zur Verfügung stehen.
Unterstützung für LED Stripe RGBW (über Bridge V2/V3) sowie RGB Controller ist implementiert. Die Hardware (RGBW und RGB mit Bridge, hier V3) sieht man zB hier:
http://www.ebay.de/itm/2-4G-LED-RGBW-Wireless-RF-Controller-Touch-Remote-Dimmable-Wifi-phone-adaptor-/111169414951?pt=US_Lighting_Parts_and_Accessories&var=&hash=item19e236a727
Die E27 white Bulbs (dimmbar, Warm oder cold einstellbar) habe ich heute erhalten, (solche zB: http://www.ebay.de/itm/2-4G-Wifi-Dimmbar-LED-E27-Lampe-Strahler-Light-Bulbs-Leuchte-Birne-6W-AC110-240V-/300915817208?pt=DE_M%C3%B6bel_Wohnen_Leuchtmittel&hash=item460ffafaf8 )
Mit ein wenig Geduld und Spucke bekommt mman die sogar noch günstiger, die Lichtqualität nach ersten Test kann sich durchaus sehen lassen. Passende RGB heute ebenfalls eingtroffen. In beiden Fällen Unterstützung über V2 - V3 Bridge.
Für den im Threatstart genannten RGB Controller habe ich aufgrund der Vorarbeit von Jenscz Unterstützung eingebaut; Danke an jenscz!, Tests stehen aus.
Mich würde noch brennend interessieren ob jemand die:
http://www.ebay.de/itm/2-4Ghz-Smart-RGB-Warm-White-LED-Bulb-E27-Wireless-Remote-Control-WiFi-Controller-/200992764218?pt=US_Light_Bulbs&var=&hash=item2ecc1a313a
oder die:
http://www.ebay.de/itm/LED-Bulb-Lampe-Birne-RGB-warm-weis-RGBWW-RGB-W-WIFI-WLAN-APP-E27-9-Watt-/261331512044?pt=DE_M%C3%B6bel_Wohnen_Leuchtmittel&var=&hash=item3cd8926aec
im Einsatz hat. Erstere habe ich zum testen bestellt, die Lieferung wird jedoch noch dauern.
Grundsätzlich erstelle ich 2 Commandsets, eines im Context von Schaltern (on, off, dimup, dimdown, etc) und eines im programmatischen (HSV/B setzen, dim xx %, etc)
Programmierbare color Transitions sind aktuell in Arbeit. Für die Angabe des Farb-Licht-Wertes habe ich HSV/B gewählt.
Die Unterstützung nach aktuellem Stand:
RGBW-Stripe an Bridge (V2/V3): HSV (Saturation über den Weiskanal, 10 Dim-Stufen), 80% fertig
RGB-Stribe an Bridge (V2/V3): HV (Saturation fix 100, 10 Dim Stufen), 25% fertig
RGB an Controller: HSV (S über RGB mix, 100 Dim Stufen), 15% fertig
RGB Bulb (V1) an Bridge: HV (Saturation fix 100, 10 Dim Stufen), 25% fertig
RGBW Bulb (V1) and Bridge: tbd 5% ;-)
RGBWW Bulb (V2) an Bridge V3: tbd, geplant HSV (100 Dim Stufen) 5%
White (warm and cold, V1) an Bridge: 10 Dimstufen, Gruppenunterstützung und colortemp tbd 15%
Über eine kurze Meldung falls jemand hardware aus der beschriebenen Familie im Einsatz hat würde ich mich freuen, unter Umständen gibt es ja noch weitere mir unbekannte.
Die Bulbs und Module arbeiten alle unidirektional (will sagen weder Bridge, Modul, Bulb oder FB geben Rückmeldungen). Weil speziell die V1/V2 Varianten keine absoluten Werte verstehen und teilweise nur trickreich durch Simulation von Tastendrücken gesteuert werden können, darf die original Fernbedienungen nicht gleichzeitig verwendet werden.
vg
Jörg
Hi,
so ich habe mir auch so ein Teil geholt. Geht echt gut ! Ich kann ihm irgendwie nur nicht abgewöhnen sein eigenes WLAN aufzumachen. Er loggt sich zwar brav in das Hausnetz ein zieht aber auch sein privets WLAN hoch.
Ich habe das ganze in eine IKEA Farbwechsel LED Leiste eingesetzt. Einfach den Farbwechsel Controller abzwicken und die Kabel wie folgt verdrahten:
schwarz: V+
blau: V-
rot: rot
weiß: grün
gelb: blau
Der Ausgangsseitige V+ kann offen bleiben, da er mit dem Eingangs V+ zusammen hängt
Somit also für 29,- € Ikea + 35,- € WLAN Controller Farbwechsel LEDs per Smartphone. Unschlagbar günstig wie ich finde.
Integration in FHEM ist noch nicht gemacht
ach so: wenn ich versuche auf die Webseite des Controllers zu gehen (192.168.10.1) dann verlangt er einen Usernamen und ein Passwort. Weiß jemand wie die zu setzen sind? Ich habe schon den Namen, die Netzwerk-Namen, admin, root alles durch. Geht aber nicht.
Hallo,
Bei mir wars "admin" und "nimda".
Das müßte eigentlich dann klappen.
Das eigene WLAN läßt sich wohl nicht abschalten und bleibt parallel bestehen.
Mit adventlichen Grüßen
Reinhard
das eigene wlan hab ich hier auf einem anderen controller (bridge-v3) ausschalten können, geht aber nicht mit bordmitteln. Wer Interesse am how-to hat - kurze pm bitte. Das Verfahren ist auf dem LW12 noch nicht getestet, daher möchte ich es noch nicht posten.
Btw, vom LW12 kenn ich jetzt nur die rgb-codes, der kann aber vermutlich mehr (on-off, modus). Wenn das jemand sniffen könnte wäre das gut. Ich kann von fhem aus HSV setzen und damit auch dimmen etc, frag mich aber was zB passiert wenn er in einem Farbwechselmodus ist und ic dann hsv (-> rgb) setze. Springt der dann auf manuell ?
vg
Jörg
Hi,
@Laffer72: Danke, das war es tatsächlich! Wie kommt man denn auf so was?
@herrmannj: ich spiele da gerne mal Versuchskaninchen. Meine Frau war den neuen Möglichkeiten so begeistert, dass ich mir jetzt halt ein zweites dieser Geräte zum rumspielen hole. Da kann ich dann gerne auch mal sniffen.
Ansonsten kleiner Denkanstoss: im Zuge der NSA Sache, schaue ich mir die Berechtigungen der Apps genauer an. Warum braucht die LED App eigentlich Zugriff auf das Mikrofon und meine Kontakte? Ein Schelm der Böses dabei denkt ...
Hi Zusammen,
sehr cool ich nutzen den gleichen WIFI-RGB-Controller wie er zu Anfang des Beitrags vorgestellt worden ist.
FHEM läuft bei mir auf einer Synology DS211.
Wo genau legt Ihr denn die .pl-Datei ab? Ich finde in <root> zwar /opt jedoch dort kein /fhem.
Habe den Ordner mal angelegt und die Datei abgelegt, dann kommt unter FHEM nach speichern der .cfg folgende Fehlermeldung:
ERROR:
Licht.Treppe.RGB.R: unknown attribute devStateIcon, choose one of room group comment alias eventMap loglevel:0,1,2,3,4,5,6 setList icon webCmd or use attr global userattr devStateIcon Licht.Treppe.RGB.G: unknown attribute devStateIcon, choose one of room group comment alias eventMap loglevel:0,1,2,3,4,5,6 setList icon webCmd or use attr global userattr devStateIcon Licht.Treppe.RGB.B: unknown attribute devStateIcon, choose one of room group comment alias eventMap loglevel:0,1,2,3,4,5,6 setList icon webCmd or use attr global userattr devStateIcon
Meine Datei heißt natürlich Licht.Treppe.RGB.pl weil dort unsere Außentreppe über die iPhone-App gesteuert wird.
Würde mich sehr über Eure Erfahrung bzw. Hilfe freuen.
Herzliche Grüße
kirschrother_lump
Hallo,
wollte mich nur kurz auch melden. Ich warte auch schon gespannt auf die Einbindung. Meine Controller sind letzten Samstag angekommen.
@herrmannj: Auch ich bin sehr an der Anleitung zum WLAN Abschalten Interessiert.
Ich habe die V1 der Controller vom ersten Artikel.
Nico
Hallo Leute,
so meine Frau meinte, die Einbindung des Lichtes sei wichtig und ich solle das jetzt mal machen. Hier ist mein Modul zur Ansteuerung des WLAN Interfaces. Netter Nebeneffekt: ich weiss jetzt wie man mit der Fritzbox snifft und wie Wireshark geht.
Modul einbinden mit
define <name> WIFILED <ip-adresse>
Bsp:
define myled WIFILED 192.168.38.17
Das Modul kann folgende set Kommandos
on --> schaltet ein
off --> schaltet aus
color rot grün blau --> setzt die Farbe (Bsp.: set myled 255 127 53). Farbwerte jeweils 0..255
brightness wert --> setzt die Helligkeit (in Prozent also 0..100) Bsp. set myled brightness 55
Da der Controller keinen Rückkanal hat, kann man die aktuell eingestellte Farbe nicht abfragen. Sprich wenn ihr also parallel mit der App rumspielt, stimmen die Farben nicht. Es gewinnt immer der letzte, der die Farbe gesetzt hat (also FHEM oder die App).
Der Colorpicker aus auch eingebaut, geht aber noch nicht. Falls da ein Experte für Colorpicker mal drüber schauen könnte würde mich das freuen. Oder falls jemand ein Modul kennt, bei dem der eingebaut ist und der Modul Programmierer auch lesbaren Code produziert hat, kann ich da gerne drüber schauen.
Die verschiedenen Blinkmodi habe ich nicht eingebaut, da ich die eh nervig finde. Falls das aber jemand braucht, die Codes dafür habe ich auch mit gesnifft.
So und nun erstmal viel Spass mit dem Modul
Super, vielen Dank für die Mühen.
Hat sofort funktioniert.
Schönes Weihnachtsfest
Reinhard
damit der colorpicker geht brauchst du ein 'set <device> rgb rrggbb' kommando in deinem device.
bei 'set ?' muss dieses mit rgb:colorpicker,RGB deklariert sein.
für die farbigen icon brauchst du ein ein 'get <device> rgb' in deinem modul.
gruss
andre
@justme1968: ok teste ich mal. Ich hatte aber testhalber die Ausgabe der commands drin und sagt er mir: command = RGB, argument colorpicker? Sprich ich bekomme die Farbwerte nicht mitgeteilt sondern nur dem Mode?
@Laffer72: freut mich dass es geht. Wie gesagt Haupteffekt war für mich eher, dass ich nun Wireshark kann :-)
Ansonsten anbei eine neue Version, die nun auch die Built-In Modes unterstützt:
neue Set Kommandos hierzu:
next --> schaltet in den nächsten Mode (wie in der App das Wählrad)
prev --> schaltet einen Mode zurück
mode x --> wählt einen Mode direkt an. x darf dabei eine Zahl zwischen o und 19 sein
Um Verwirrung zu vermeiden lösche ich die Version aus dem originalen Post.
wie der colorpicker und die farbigen icons integriert werden ist hier: http://www.fhemwiki.de/wiki/Color (http://www.fhemwiki.de/wiki/Color) beschrieben.
ein 'rgb:colorpicker,RGB' in der commando liste definiert ein kommando rgb für das ein colorpicker im RGB mode (andere gehen noch nicht) verwendet werden soll. das Kommando rgb selber kannst du dann in der webCmd liste auf zwei arten verwenden. nur ...:rgb:... um den interaktiven colorpicker darzustellen oder als ...:rgb rrggbb:... um einen festen preset anzuzeigen. natürlich auch beliebig gemischt:attr <device> webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off
sobald eine farbe über den colorpicker eingestellt wird wird automatisch ein 'set <device> rgb rrggbb' aufgerufen.
gruss
andre
so, nun geht auch der Colorpicker.
Neu:
dim --> gleich wie brightness
der Staus des Moduls (on/off wird akualisiert
Colropicker ist drin.
ich betrachte das Modul jetzt funktional mal als komplett. Wenn ihr Bugs habt, dann her damit
Viel Spass damit
Sehr Geil . Danke
Gesendet von meinem HTC One X mit Tapatalk 2
Genial, funktioniert hier gut.
Kann es sein, das die Farbigen Icons nicht wie im Colorpicker beschrieben funktionieren?
Bei readings_val bleibt es grau und bei commantget wird kein Icon angezeigt.
Oder habe ich hier einen Fehler?
Nico
Danke nochmal für das tolle Modul.
Hab die neueste Version gleichmal installiert und es geht alles.
Auch das Einbinden des Colorpickers klappt. Allerdings merkt er sich nicht die eingestellte Farbe. Bei erneutem Aufruf des Devices steht im Farbfeld immer FFFFFF. Hab ich da was falsch gemacht? (attr <device> webcmd rgb:on:off)
Eine andere Baustelle sind die farbigen Icons, klappt bei mir auch nicht wie im WIKI beschrieben.
Hat jemand eine andere Lösung?
Danke
Reinhard
ich glaube das modul hat zur zeit weder ein reading rgb noch ein kommando get rgb. deswegen gehen die beispiele im wiki natürlich nicht.
versucht es mal mit:attr <device> devStateIcon {Color_devStateIcon(InternalVal($name,"RGB","000000"))}
weil es kein 'get rgb' gibt zeigt der colorpicker beim neu aufruf auch immer FFFFF.
gruss
andre
Bei mir geht der Colorpicker nicht bzw. er geht auf, die Farbe ist wählbar jedoch übernimmt das Modul die Farbe nicht
define test_RGB WIFILED 10.16.254.78
attr test_RGB room Wohnzimmer
attr test_RGB timeout 2
attr test_RGB webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off
LOG:
WIFILED_Set: unsupported command given rgb 8cff7a
@justme1968
Danke für den Tipp mit InternalVal aber geht leider auch nicht.
Nico
steht irgendetwas im log?
gruss
andre
Sorry, hatte die falsche 98_WIFILED.pm . Mit der richtigen Version geht es.
Falls ich gemeint war.
Ich kann im Log nichts sehen was damit zu tun hat.
Evtl muss ich da aber debug oder so aktivieren.
Hi,
Ja das Modul hat keine Get Methode für RGB, da das so im Wiki nicht ersichtlich war. Stört mich selbst, dass die Presets nicht gehen. Es hat aber schon Readings rgb und RGB.
Losging Einstellungen zu ändern bringt nicht viel, da vergleichsweise wenig Log Meldungen durch das Modul erzeugt werden (gibt ja auch nicht viel zu loggen)
warum bzw. was geht an den presets nicht?
gruss
andre
ich hab gerade mal die icons und die presets probiert und bei mir geht beides.
attr w webCmd rgb:rgb ff0000:rgb 00ff00:rgb 0000ff:toggle:on:off
attr w devStateIcon {Color_devStateIcon(InternalVal($name,"RGB","000000"))}
das einzige was nicht geht ist das das text feld des colorpickers beim seitenaufbau richtig gefüllt ist. dazu ist das get rgb nötig.
für die farbigen icons müssen die svg icons aktiviert werden:attr WEB iconPath fhemSVG:openautomation:default
gruss
andre
kann ich da irgendeine RGB Stripes nehmen? Die Stripes gibt es wohl auch immer nur mit passendem Controller? Nur die Stripes habe ich noch nicht gesehen.....
Hallo,
also bei mir gehts jetzt auch. Habe die Zeilen von Andre übernommen und jetzt klappt es.
Keine Ahnung, was ich da vorhin falsch gemacht habe.
Danke.
Reinhard
Hi Zusammen,
super geil und gleich ein Modul für FHEM, dass wird meine Frau auch überzeugen ;-)
Habe mir das letzte Modul runtergezogen und dann im Ordner FHEM/share/fhem/FHEM zu den anderen Modulen gelegt.
Dann habe ich FHEM-Server (5.3-mfr-1.1-syno-88f628x) auf meiner DS211 runter- und wieder hochgefahren.
Mit einem reload 98_WIFILED.pm habe ich versucht das Modul noch einmal zu laden.
Jetzt kommt immer folgende Fehlermeldung:
Zitat2013.12.27 14:42:41 0: Server started (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 1996 2012-10-20 07:11:56Z rudolfkoenig $, pid 7258)
2013.12.27 14:42:53 1: reload: Error:Modul 98_WIFILED deactivated:
Global symbol "$readingFnAttributes" requires explicit package name at /usr/local/FHEM/share/fhem/FHEM/98_WIFILED.pm line 60.
Color.pm habe ich mir ebenfalls runtergeladen und zu den Modulen gelegt.
Was mach ich falsch. Irgendwie läuft es bei Euch allen runder - bin am Verzweifeln hatte heute auf den großen Durchbruch gehofft.
Beste Grüße
Joachim
deine fhem version ist zu alt.
du solltest in fhem ein update machen. Color.pm ist dann auch automatisch dabei.
gruss
andre
Hi,
so ich hatte noch ein paar Minuten gerade Zeit und habe das Get eingebaut. Es geht nun get rgb und get dim.
Somit hat der colorPicker auch die zuvor gewählte Farbe als Einstellung. Auch der Slider für den Dimmer hat nun den zuletzt gesetzten Wert.
Bei mir hat es gerade eben einwandfrei funktioniert. Ich bin nun aber ein paar Tage weg zum Boarden und kann ergo keine Bugfixes machen. Wenn was am Modul ist, bitte hier posten, ich schaue das nach meiner Rückkehr durch.
Supi, Andre.
Habe mit der Update-Funktion ein Update gemacht und es funktioniert.
Ihr seit echt super.
Beste Grüße
Joachim
Hi Tobias,
Du kannst jeden RGB LED Strip nehmen.
Ich habe eine beleuchtete Außentreppe mit einem wasserdichten RGB LED Strip. Die LED Strips und den WIFI LED Controller habe ich von unterschiedlichen Händlern gekauft.
Beste Grüße
Joachim
Danke nun scheint alles zu funktionieren. Nun mal weiter in FHEM einarbeiten.
Nico
Wollte mich gerne noch bedanken für das super Modul.
Gruss
Remo
Ebenso ein Danke für das Modul, funzt wunderprächtig.
Hi,
Es gibt ein RGB-Modul für Panstamps. Jetzt ein RGB Modul für den WIFI-Controller.
Kann man nicht dieses Modul hier als Backend konzipieren und das vorhandene RGB-Frontend-Modul für die Panstamps für dieses WIFI Modul anpassen?
1. würde das auch in das FHEM Konzept Devices Konzept passen
2. würde dann auch FHEM2FHEM funktionieren.
Gruss
die 'intelligenz' für die komplexeren funktionen steckt bei den hues und dem panstamp modul in der hardware. die fhem module Steuern diese nur an. der gemeinsame teil ist der colorpicker, die farbigen icons (und demnächst farbraum konvertierungen) sind schon in ein Color.pm modul ausgelagert das auch der controller hier verwendet.
die beiden module oben verwenden auch beide schon eine backend/frontend aufteilung. vor allem weil sie bidirektional arbeiten. im panstamp modul auch weil der panstick in einem anderen rechner stecken kann. die hue bridge ist aber eh per netzwerk erreichbar. da ist fhem2fhem eigentlich nicht nötig.
der wifi controller hier ist ja auch übers netzwerk erreichbar. also eher auch kein fhem2fhem kandidat. und bidirektional so viel ich weiß ist er auch nicht.
gruss
andre
hallo zusammen,
coole sache! der will-haben-effekt ist eingetreten :D
kann man mit einem wifi adapter mehrere controller separat ansteuern? gemeint ist das, wurde hier mal erwähnt:
http://www.ebay.de/itm/2-4G-LED-RGBW-Wireless-RF-Controller-Touch-Remote-Dimmable-Wifi-phone-adaptor-/111169414951?pt=US_Lighting_Parts_and_Accessories&var=&hash=item19e236a727
hat evtl. jemand eine quelle für ein set mit streifen und netzteil?
danke!
Hallo sku,
an dieser bridge kannst Du einen RGB/RGBW (stripe) controller plus 4 Räume e27 White plus 4 Räume e27 RGB+White betreiben. Passendes fhem Modul ist gerade im Test.
Beim stripe Empfehlung zu einem RGB+W (und dem RGBW Modul) weil die bridge nur einen Farbkreis aber keine RGB-zu-Weiss-Lichtmischung unterstützt. Das wiederum geht mit dem Modul von bugster und dem LW12 controller
vg
Jörg
hallo jörg,
das ging ja fix, keine 2 stunden :D danke!
@alle
habe inzwischen das rgb panstamp board gefunden, klingt auch sehr interessant: http://forum.fhem.de/index.php/topic,13890.0.html
gibt es sonst noch alternativen mit 4A/kanal, wlan/lan/funk und einfacher fhem-integration mit colorpicker?
gruß
@justme1968: kleine Anmerkung zum Colorpicker: auf dem iPAD mit iOS7.0.4 und Safari wird im Colorpicker nur der Rahmen angezeigt aber der Farbverlauf innerhalb des Rahems leider nicht.
Ist auf dem iPAD mit Google Chrome leider das gleiche (muss ja, ist ja dank Apple der gleiche Renderer)
Ansonsten ist das Gerät nicht bidirektional: sprich die aktuelle Farbe etc. wird nicht zurück gemeldet.
auf meinen iphone mit ios7.0.4 geht der colorpicker auf port 8083 und 8085 im dark style und im ios style. auf einem ipad 1 mit ios5 auch. welchen style verwendest du ?
der farbverlauf ist jeweils ein png bild. eventuell hat es mit dem png problem das an anderer stelle schon besrprochen wurde zu tun. ich schaue mal ob ich das irgendwie reproduzieren kann.
gruss
andre
Hi,
ich verwende den standard style (touchpad) auf Port 8085
VG
Hallo!
Ich habe diesen Controller: http://www.amazon.de/gp/aw/d/B00BDQHZO4/ref=redir_mdp_mobile?ascsubtag=mqxm8zZjwo3D05P-ySGDvg&camp=1638&creative=6742&creativeASIN=B00BDQHZO4&linkCode=asn&smid=A2VG2L5LR6HZG5&tag=preisvergleich-idealode-21
ist es möglich auch damit das Wifiled modul zu steuern?
Habe mal versucht in fhem zu definieren doch es reagiert auf kein Befehl.
Ip von wifi controller 192.168.178.77, über diese Adresse ist es auch im Web-browser und per Android app zu finden und zu steuern.
Würde mich sehr freuen wenn es möglich wäre:-)...
Mfg steffen
Ich habe folgendes SET bestellt
http://www.amazon.de/gp/product/B00FFGJV7C/ref=oh_details_o02_s00_i00?ie=UTF8&psc=1
und stehe für Tests hier gerne zu Verfügung.....
------
FHEM auf FB7390...
HMLAN
RFX/TRX
Hallo Steffen,
welche Leuchtmittel hast Du dran ?
@mbenker,
bekommst morgen eine beta
vg
jörg
Zitat von: herrmannj am 06 Januar 2014, 20:10:51
Hallo Steffen,
welche Leuchtmittel hast Du dran ?
Also das sind E27 RGB-LED Bulb, habe sie damals im Set bestellt!
Mfg Steffen
Bin auch am überlegen mir die iwy Dinger zu bestellen.
Gesendet von meinem HTC One X mit Tapatalk 2
@Noice
Also die IWY Teile geben ein super Licht. Satte kräftige Farben, Helles schönes weiss.....
Und im Set mit dem WIFI Controller UND der Fernbedienung für 100 Euro.....ein recht guter Preis...
Jetzt mal schauen das ich die in FHEM eingebunden bekomme mit dem Modul von hermannj, wo ich dann heute mal Beta Tester spielen darf ;)
Und wenn dann noch mein StripeController irgentwann endlich ankommt, hab ich wieder viele Sachen mit denen ich rumspielen kann :) :) :)
Dann werde ich mir wohl noch weitere der Bulbs zulegen....
Hallo
Langsam verliere ich den Überblick......
Schaue schon einige Zeit hier mit rein, aber im Moment weiß ich nicht was für Lampen oder steuerungen Unterstützt werden.
Stemmt73
Zitat von: mbenker am 07 Januar 2014, 09:17:03
@Noice
Also die IWY Teile geben ein super Licht. Satte kräftige Farben, Helles schönes weiss.....
Und im Set mit dem WIFI Controller UND der Fernbedienung für 100 Euro.....ein recht guter Preis...
Jetzt mal schauen das ich die in FHEM eingebunden bekomme mit dem Modul von hermannj, wo ich dann heute mal Beta Tester spielen darf ;)
Und wenn dann noch mein StripeController irgentwann endlich ankommt, hab ich wieder viele Sachen mit denen ich rumspielen kann :) :) :)
Dann werde ich mir wohl noch weitere der Bulbs zulegen....
Danke für die Info. Na dann hoffen wir mal das das klappt :-)
Den Stripe Controller hab ich schon in betrieb.. Lässt sich gut mit Fhem steuern
Zitat von: herrmannj am 06 Januar 2014, 20:10:51
Hallo Steffen,
welche Leuchtmittel hast Du dran ?
@mbenker,
bekommst morgen eine beta
vg
jörg
Könnte ich eine beta bekommen oder geht das nicht mit meinem system??
Mfg Steffen
Hallo Steffen,
doch, gern.
Bisher habe allerdings erst den RGBW Stripe, die E27 White und RGBW auf der V3 Bridge drin. Die V2 Bridge ist nicht so das Thema, die E27 RGB ( = RGB stripe) muss aber noch rein.
Bitte noch etwas Geduld, ich möchte noch etwas mehr Stabilität und stelle die Beta hier in den threat sobald ich denke das sie vom alpha ins beta gehen kann.
Die firmware hat leider viele Eigenheiten die in der Programmierung mehr aufhalten als ich gehofft hatte.
vg
Jörg
Zitat von: herrmannj am 07 Januar 2014, 19:34:13
Hallo Steffen,
doch, gern.
Bisher habe allerdings erst den RGBW Stripe, die E27 White und RGBW auf der V3 Bridge drin. Die V2 Bridge ist nicht so das Thema, die E27 RGB ( = RGB stripe) muss aber noch rein.
Bitte noch etwas Geduld, ich möchte noch etwas mehr Stabilität und stelle die Beta hier in den threat sobald ich denke das sie vom alpha ins beta gehen kann.
Die firmware hat leider viele Eigenheiten die in der Programmierung mehr aufhalten als ich gehofft hatte.
vg
Jörg
Ok vielen dank für deine mühe,
mache ganz in ruhe und freue mich dann aufs Testen.
Mfg Steffen
Hallo zusamen
Ich hab diesen controller:
http://www.aliexpress.com/snapshot/307554169.html
erfolgreich mit dem 98_WIFILED.pm im Einsatz!
Vielen Dank erstmal an den Entwickler! gute Arbeit!!
Folgende Fragen dazu, die Du mir evtl. beantworten kannst:
(done s.u.) - Offensichtlich ist der Controller doch bidirektional, resp. es muss ein Kommando geben, mit dem der aktuelle Status abgefragt werden kann.Hast Du evtl. das Kommando schon sniffen können?
- Falls ja, könnte man das evtl. einbauen ins Modul, damit der aktuelle Stand vor einem Wechsel abgefragt wird anstatt vom letzten abzuleiten. So wäre es auch möglich die LED's von einer 2. Quelle zu steuern, ohne einfluss aufs FHEM
(eg. wenn ich sie im FHEM auf Rot stelle, dann via app auf Grün und danach im FHEM dimme, dann springen sie wieder auf Rot (gedimmt), anstatt das Grün zu dimmen)!
Gerne helefe ich auch beim debuggen oder programmieren (soweit meine Fähigkeiten das zulassen ;)
kleiner Nachtrg: ich konnte endlich sniffen ;)
Init Kommando:
0xef 0x01 0x77
Als Antwort kommen 11 bytes zurück, muss ich noch irgendwie "decodieren"...
Geschwindigkeit setzen für die automatik-modi:
0xbb 0xMODE 0xSPEED 0x44
wobei SPEED zwischen 0 und 255 resp 0x00 und 0xff Hex ist.
und MODE = 37+Modus (0-19) (0x25+Modus).
Also kann man Modus und Geschwindigkeit in einem setzen!
Nachtrag 2:
Die Antwortbytes sind wie folgt:
01: Init (0x66)
02: Init (0x01)
03: Off (0x24) / On (0x23)
04: Mode (0x25 - 0x38)
05: Running (0x21) / Stopped (0x20)
06: Speed (1/10th seconds?) (0x00 - 0xff)
07: Red (0x00 - 0xff)
08: Green (0x00 - 0xff)
09: Blue (0x00 - 0xff)
10: User Memory used (0xFF) / not used (0x51)
11: Termination (0x99)
Nachtrag 3:
Program User Memory (53 Bytes, Mode 0x39):
01: Init (0x99)
02: Color 1 Red (0x00 -0xFF)
03: Color 1 Green (0x00 -0xFF)
04: Color 1 Blue (0x00 -0xFF)
05: Color 2 Red (0x00 -0xFF)
06: Color 2 Green (0x00 -0xFF)
07: Color 2 Blue (0x00 -0xFF)
08: Color 3 Red (0x00 -0xFF)
09: Color 3 Green (0x00 -0xFF)
10: Color 3 Blue (0x00 -0xFF)
.
.
.
.: Red = 0x01 for empty
.: Green = 0x02 for empty
.: Blue = 0x03 for empty
.
.
.
47: Color 16 Red (0x00 -0xFF)
48: Color 16 Green (0x00 -0xFF)
49: Color 16 Blue (0x00 -0xFF)
50: Speed (0x00 -0xFF)
51: Fade (0x3a), Jump (0x3b), Flash (0x3c)
52: Termination (0xff)
53: Termination (0x66)
Hoffe das hilft weiter...
PS: falls jemand interessiert ist: ich hab ein kleines perl-script geschrieben, mit dem man die funktionen setzen und auslesen kann...
Hallo zusammen :D
Ich hab mir den WIFI-LED-Stripe Controller aus dem ersten Post geholt und mit dem Modul von bugster auch ans laufen gebracht :)
allerdings wird mir kein Colorpicker oder ähnliches angezeigt. Ich hab nachgesehn das Modul Color.pm ist vorhanden.
Woran könnte das liegen?
EDIT: OK habs hab nur vergessen das Atribut webcmd zu setzen :D
erstmal vielen Dank an hermannj für die Beta...so langsam wird das System rund und funktioniert immer besser ;)
Neben dem Bulbs kommt jetzt noch ein WLAN Stripe Controller ins System....:)
Und dann kann weiter getestet werden :D
hallo,
ich bin ein Frischling...Wie bekomme ich diese scripts zum laufen?wo muss ich sie hinlassen und wie rufe ich sie auf?
Zitat von: coyote8219 am 10 Januar 2014, 22:00:32
hallo,
ich bin ein Frischling...Wie bekomme ich diese scripts zum laufen?wo muss ich sie hinlassen und wie rufe ich sie auf?
Da gibt es den Download:
http://forum.fhem.de/index.php/topic,16130.msg118963.html#msg118963
Enfach in den Modulordner kopieren (bei mir /opt/fhem/FHEM)
dann in die Config:
define Licht_WZ_RGB WIFILED 192.168.178.150
attr Licht_WZ_RGB devStateIcon {Color_devStateIcon(ReadingsVal($name,"rgb","52e093"))}
attr Licht_WZ_RGB event-on-change-reading state
attr Licht_WZ_RGB timeout 2
attr Licht_WZ_RGB webCmd rgb:rgb dd0000:rgb 00dd00:rgb 52e093:rgb 0000dd:rgb a020f0:rgb dddddd:on:off
Licht_WZ_RGB durch den gewünschten Devicenamen ersetzen und die IP 192.168.178.150 durch die deines Controllers ersetzen.
Die bereits gestzen Farben im webCmd können gegen eigene Kombinationen ausgetauscht/erweitert werden.
So hab ich es in meiner Config.
event-on-change-reading kann man weglassen. Brauche ich aber aus bestimmten Gründen (HMlan overload bei diversen notifys durch mehrfaches setzen meines LED-Displays). Mit event-on-change-reading werden notifys nur ausgelöst wenn sich der Status wirklich ändert.
vielen dank...
habe jetzt alles so gemacht, also die Datei in diesen ordnet gelegt und in die fhem.cfg den code kopiert und meine ip und Namen verwendet....aber es passiert nichts, wenn ich light on drücke geht nichts an...
PS:muss die wifibridge V3 von dem led controller via usb an die fritzbox oder reicht es wenn sie im wlan ist?
ich verzweifle wirklich...jetzt habe ich gelesen, das man wohl eine ip mit .255 Endung an das Modul vergeben muss, damit man udp befehle senden kann. nur noch eine dumme frage, brauche ich noch weitere hardware, damit das so wie bei euch allen funktioniert? brauch ich noch einen CUL? oder reicht der wifi sender von dem rgb set?
Das mit der 255 als viertes Oktett der IP ist Schwachsinn. Richtig ist, dass diese IP in der Regel als Broadcastadresse genutzt, und dann nur mit UDP gesendet wird. Hat aber nichts mit dem WIFI-Led Controller zu tun.
Du solltest auch eine Farbe setzen. Wenn als Farbe 000000 gesetzt ist sind alle LEDs aus. Setz mal als Farbe FFFFFF und mach dann "on".
"off" setzt intern im Controller auch nur alle Farben auf 00 wobei er sich die letzte eingestellte Farbe merkt und bei on wieder setzt.
ich bekomme das nicht zum laufen?
ich habe das gefühl das ich gar keine Verbindung zu dem sender hergestellt bekomme.... sondern alle befehle ins leer gehen.
ich habe als erstes den sender in mein n Netzwerk aufgenommen...das geht ja über die iphone app automatisch. über diese app kann ich auch alles wunderbar steuern...nur über fhem nicht.
dann habe ich diesen define Befehl gemacht und ich habe nun diesen menüpunkt. dann habe ich diesen code in die fhem.cfg eingefügt und gespeichert...aber es passiert nichts?
muss ich vorab vielleicht noch andere sachen adden? habe fhem ganz frisch auf die fritzbox installiert....
und wenn ich bei color FFFFFF kommt "WIFILED_Set: wrong number of arguments for set color"
ZitatPS:muss die wifibridge V3 von dem led controller via usb an die fritzbox oder reicht es wenn sie im wlan ist?
V3 Bridge support coming soon. :-)
Im Augenblick alpha Test in geschlossener Runde, offene Beta steht in den Startlöchern. Welche Leuchtmittel setzt Du ein ?
vg
Jörg
@coyote8219: ich glaube du hast die Version von bugster genommen, die soweit ich das nachlesen kann, nur für den Controller vom ersten Post funktioniert. Das Modul von herrmannj wird, wenn es fertig ist den vom ersten Post UND die Bridges unterstützen.
vg Kuzl
Ahhhh....
Wann gibt es diese Version zum download? Ich setzte led Stripes in meinen Heimkino ein. Ziel ist es das ganze über http befehle zu sturen, da ich mit einer App mein ganzes Heimkino steuert und diese braucht diese Befehle. Das habe ich auch schon so weit fertig, so das ich jetzt schon in fhem alles an und ausschalten kann(zumindest in der fhem Ansicht). Nur das noch nichts passiert. @herrmannj
@mbenker
Hallo. Du hast von den IWY geschrieben. Sind das die bulbs mit dem IWY Gate?
Schaue mich gerade um was ich nun nehmen soll......
Stenny73
Anmerkung: Wäre vielleicht gut wenn man im Ersten Post reinschreiben könnte welche Controller bisher Unterszützt werde...
Wie ich soeben erfahren habe, habe ich sogar die Wifi Bridge V4....Also wenn ich was testen soll, gebt einfach bescheid...
huch, V4 ??? das naming ist ja nicht offiziell aber V4 wäre mir jetzt neu. Hast Du mal einen Link ?
danke Jörg
http://www.limitlessled.com/dev/
Habe zu 100% die V4
Schau an, danach wäre v4 == V3 - Web Interface. Das ist gut, wird also unterstützt. Danke für die Info.
Ich finde gerade nicht ob ich dich das schon gefragt hatte: welche leuchtmittel hast du dran ?
Vg
Jörg
Hi...
Habe einen LED Stripe dran...Noch ein Alpha Platz frei?
RGBW oder RGB stripe?
Hauptsächlich RGB...ist im Einsatz im Heimkino, aber im Wohnzimmer habe ich auch noch nen kürzeren RGBW Stripe
Hallo zusammen.
ich bin mir grade noch nicht sicher ob ich das hier richtig verstehe und hoffe einer von euch kann mir auf die Spruenge helfen. Der sog. Wifi Controller wird in das eigene Wifi Netz eingebunden (wie jeder andere Wifi-Client auch) und bekommt eine eigene IP. So koennen IPhone, Android Client oder eben fhem auf den Controller zugreifen und darueber die Lampen steuern. Wie aber werden die LEDs mit dem Controller verbunden? Ist dafuer zwangslaeufig eine Fernbedienung notwendig oder haben Lampe und Controller "pairing Knoepfe"?
Kann man die LEDs von verschiedenen Herstellern mischen, arbeiten die mit einem Standard? Und als letztes, welche Controller funktionieren mit fhem? Koennte ich dieses Set hier nehmen und das mit dem fhem Modul aus diesem Thread betrieben?
http://www.amazon.de/RGB-Wei%C3%9F-Fernbedienung-Controller-ROCKET-LEDS/dp/B00GKKYBIG/ref=sr_1_25?s=lighting&ie=UTF8&qid=1389721917&sr=1-25&keywords=wlan+led
VIELEN Dank schonmal fuer eure Antworten.
dieses Kombination setze ich ein,
vg
jörg
Gibt es denn schon ein Release Date für die Beta? Oder die Möglichkeit an der alpha teilzunehmen? Bin schon ganz hibbelig...möchte mein Heimkino fertig programmieren... ;D
Zitat von: herrmannj am 14 Januar 2014, 21:21:44
dieses Kombination setze ich ein,
vg
jörg
Ich glaube da fehlt etwas ;)
@hillbicks
Zitat... Koennte ich dieses Set hier nehmen ...
...
Zitatdieses Kombination setze ich ein,
-> V3 bridge und 4x RGBW 9W.
nö, fehlt nix ;-)
@coyote8219
in Kürze...
vg
jörg
Zitat von: herrmannj am 14 Januar 2014, 22:28:34
@hillbicks
...nö, fehlt nix ;-)
@coyote8219
in Kürze...
nö, fehlt nix
ach, und ich dachte das Komma am Ende bedeutet da kommt noch was. Vielen Dank. Dann werde ich das mal bestellen!
Hallo zusammen,
habe mir jetzt auch die Milight Teile besorgt, (also WIFI COntroller und RGBW LED Controller mit 2,4GHz Fernbedienung). Scheinbar habe ich auch eine neuere Version also V3 oder gar V4 (lt. limitless Webseite). Jedenfalls hat sich hier die Portnummer (8899) und scheinbar auch die Kommandostruktur geändert. Das Ändern des Ports im Modul hat keine Wirkung. Ich habe hier eine Beschreibung gefunden:
http://www.limitlessled.com/dev/
und auch ein Kommandozeilen Tool das einwandfrei funktioniert (nicht auf einem Raspberry, aber das ist ja egal), http://iqjar.com/jar/home-automation-using-the-raspberry-pi-to-control-the-lights-in-your-home-over-wi-fi/
Leider reichen meine Perl Kenntnisse bei weitem nicht um das bestehende Modul anzupassen, aslo wäre ich auch sehr interessiert eine Testversion zu bekommen.
Gruss
Was heißt in Kürze? In den nächsten 2-3 Wochen oder sogar den nächsten Tagen? ::)
Hi,
ZitatWas heißt in Kürze? In den nächsten 2-3 Wochen oder sogar den nächsten Tagen? ::)
vermutlich zum Wochenende.
Geplant war ja schon die letzte Woche 2013 aber wie es so ist, es sind noch gute Ideen dazugekommen und denen lag dann auch gleich der eine oder andere Stein im Weg. Im großen und ganzen bin ich jetzt recht zuversichtlich das der Termin zu halten ist.
Sorry für die Verzögerung.
vg
Jörg
Cool ;D
Aber brauche ich noch weitere Hardware damit die Steuerung funktioniert?
Oder reicht meine fritz box mit FHEM und das RGB Set mit dem Wifi Empfänger?
Wenn du kurz einen link zu Deinem Set posten magst schau ich gerne ob das passt.
Vg
Jörg
Hallo,
Ich möchte gerne RGB Strip 2x 10meter Länger mit 30 Led/m betreiben. Und zwar mit diesem Set
http://www.ebay.de/itm/261374127288?var=560273590641&ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649
Ist das mit einem controler möglich? oder besser auf 2 Controller verteilen.
vielen Dank
Benni
Das ist ja witzig, der Controller ist auch neu. Ich habe noch kurz vor weihnachten den Vorgänger erhalten ...
Zu deinen Fragen: ob das mit einem Controller möglich ist kann ich dir nicht sagen, das hängt ja vom Netzteil und der Leistung der stripes ab. 10m erscheint mir aber doch lang genug um das auf 2 zu verteilen. Netzteile brauchst du separat, die Bridge braucht ein 5v USB Netzteil.
Du brauchst auf alle Fälle 2 Controller (und eine Bridge!) wenn du die stripes getrennt ansteuern möchtest. Ohne den Controller bisher in der Hand gehabt zu haben gehe ich davon aus das er mit fhem funktionieren sollte, sieht kompatibel zu den rgbw bulbs aus.
Was du wissen solltest ist das diese Controller keine RGB zu Weiß Mischung unterstützen, dafür ist der Weiß Channel vorgesehen. Im Betrieb schalten die dann auf entweder Farbe aus dem HSV kreis oder weiß.
Vg
Jörg
Zitat von: cbvo am 16 Januar 2014, 12:27:32
Hallo,
Ich möchte gerne RGB Strip 2x 10meter Länger mit 30 Led/m betreiben. Und zwar mit diesem Set
http://www.ebay.de/itm/261374127288?var=560273590641&ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2649
Ist das mit einem controler möglich? oder besser auf 2 Controller verteilen.
vielen Dank
Benni
Ich habe mit dem Controller aus dem 1. Post 18m fehlerfrei laufen.
Hier der link:
http://www.amazon.de/gp/product/B00E94IWQM/ref=oh_details_o00_s00_i00?ie=UTF8&psc=1
Hallo,
bei amazon steht: "NEUER LW-12 WIFI WLAN LED RGB STRIPS CONTROLLER für iPhone, iPad, iOS, Android 24V *Weiß*"
Sind damit wirklich 24 Volt gemeint? Ich wollte das Teil gerade bestellen, aber die alles Strips sind auf 12V ausgelegt. Welche RGB-LEDs Strip (brauche 2 x 3m) könnt ihr mir empfehlen? und 60 LEDs pro Meter sollten es schon sein, oder?
Danke und Gruß,
a200
12-24 V
Zitat von: jenscz am 16 Januar 2014, 18:12:30
Ich habe mit dem Controller aus dem 1. Post 18m fehlerfrei laufen.
Hallo
Auf wieviel Controller hast du die verteilt?
mfg Benni
Hallo
Also, jetzt gehts ins Wochenende.... Die Lieferung ist da..... Und Hoffen das was geht.....
Ich habe über Amazon
http://www.amazon.de/gp/product/B00G8AJDDQ/ref=oh_details_o01_s00_i00?ie=UTF8&psc=1
geholt.
Wo finde ich eigentlich raus welche Version ich habe?????? V3 oder V4
Eigene Netz des MiLight war anfangs 10.10.100.254
Anlernen Fernbedienung ist gemacht
Umstsllung ins eigene WLan ist gemacht.
Steuerung per Handy geht.
Aber von FHEM leider noch nicht
FHEM auf Ubuntu Server (12.04), FHEM update heute
define myled WIFILED 192.168.6.29
attr myled devStateIcon {Color_devStateIcon(ReadingsVal($name,"rgb","52e093"))}
attr myled event-on-change-reading state
attr myled loglevel 4
attr myled room 02-Beleuchtung
attr myled timeout 2
attr myled webCmd rgb:rgb dd0000:rgb 00dd00:rgb 52e093:rgb 0000dd:rgb a020f0:rgb dddddd:on:off
In der Hoffnung das mir bald ein Licht aufgeht ;D
stenny73
Zitat von: cbvo am 17 Januar 2014, 12:56:42
Hallo
Auf wieviel Controller hast du die verteilt?
mfg Benni
1 Controller:
http://www.amazon.de/NEUER-STRIPS-CONTROLLER-iPhone-Android/dp/B00G55329A/ref=sr_1_21?s=lighting&ie=UTF8&qid=1389960424&sr=1-21&keywords=led+rgb+controller
Der macht 10A am Ausgang wenn das richtige Netzteil am Eingang hängt.
Zitat von: jenscz am 17 Januar 2014, 13:13:39
1 Controller:
http://www.amazon.de/NEUER-STRIPS-CONTROLLER-iPhone-Android/dp/B00G55329A/ref=sr_1_21?s=lighting&ie=UTF8&qid=1389960424&sr=1-21&keywords=led+rgb+controller
Der macht 10A am Ausgang wenn das richtige Netzteil am Eingang hängt.
Hey super,
Vielen Dank für die Info.
Bekommst du auch die farbe weiss?
Vielen Dank Benni
Zitat von: cbvo am 17 Januar 2014, 13:17:06
Hey super,
Vielen Dank für die Info.
Hast du den mit dieses Modul an Fhem am laufen?
Bekommst du auch die farbe weiss?
Vielen Dank Benni
Jup, habe ich. Samt Colorpicker.
Genial :D :D
Sieht super aus..
@jenscz
Ja, ist den noch Weihnachten :o
...
Sieht super aus
@stenny73
gesten mal in "meine Mitteilungen geschaut" ;-) ?
vg
Jörg
@herrmannj
und wie sieht es aus, gibt es dieses WE ein Release?
Zitat von: herrmannj am 17 Januar 2014, 13:52:04
@stenny73
gesten mal in "meine Mitteilungen geschaut" ;-) ?
vg
Jörg
Scheinbar nicht :-[ Die freude auf das Paket halt.....
@stenny73
na dann kannste das doch nachholen. Klartext, hatte Dir einen Link geschickt.
@coyote8219
we are on track.
Bin schon ganz gespannt...
Ps: möchte endlich auch probieren ob es funktioniert :-)
Mein WL12 in Aktion (vorerst noch mit einem selbst geschrieben perl-script, mit dem (fast) sämtliche kommandos gesendet werden können):
http://www.clumsy.ch/rgbled/VID_20140112_193934.mp4
etwas überbelichtet, aber ich denke man sieht den effekt ;)
@herrmannj
Wann ist mit dem Release zu rechnen?
Hi Coyote :
schau mal hier
http://forum.fhem.de/index.php/topic,18958.msg126693.html#msg126693
da ist das Beta Release :)
@herrmannj:
SUPER GROßES DANKE ;D ;D
Es funktioniert super....
Nun hätte ich noch eine Frage, da ich alles über http befehle aufrufe, wollte ich mal fragen, ob mir jemand helfen könnte zwei, drei weitere Buttons einzupflegen, mit denen ich bestimmte Farben und Dimmlevel ansteuern kann?
Dann wäre meine Lichtsteuerung im Heimkino perfekt...
Heute habe ich einen LW-12 völlig problemlos in Kombination mit dem Modul in Betrieb genommen.
Lediglich die Sache mit dem Color-Picker habe ich noch nicht hinbekommen, aber das ist mir ohnehin nicht so wichtig. (erledigt)
Tolle Arbeit - danke!
Jetzt muss ich nur noch ein geeignetes Gehäuse für die Montage auf dem Balkon finden :)
Die Sache mit "set <device> mode <n>" habe ich noch nicht ganz durchschaut.
Die Android App zeigt mir 20 vordefinierte Modes von 1-20 an.
Aber ein set device mode 5 bewirkt einen anderen Mode als wenn ich in der App die Nr. 5 auswähle.
*grübel*
Zitat von: bugster_de am 27 Dezember 2013, 17:39:10
so ich hatte noch ein paar Minuten gerade Zeit und habe das Get eingebaut. Es geht nun get rgb und get dim.
Somit hat der colorPicker auch die zuvor gewählte Farbe als Einstellung. Auch der Slider für den Dimmer hat nun den zuletzt gesetzten Wert.
Ausgehend von dieser Version (es war hier im Thread das aktuellste, was ich zur Nutzung finden konnte) hätte ich noch folgenden Patch vorzuschlagen, damit die SetExtensions funktionieren und man auch Dinge wie on-for-timer nutzen kann.
(http://up.picr.de/17964481wn.png)
Index: 98_WIFILED.pm
===================================================================
--- 98_WIFILED.pm (revision 65)
+++ 98_WIFILED.pm (working copy)
@@ -42,6 +42,7 @@
# for the color picker module
use Color;
+use SetExtensions;
# ----------------------------------------------------------------------------
# Initialisation routine called upon start-up of FHEM
@@ -138,14 +139,15 @@
return( "$name: set needs at least one parameter" );
}
+ my $cmdList = "" .
+ "on off next:noArg prev:noArg mode " .
+ "color brightness:slider,0,1,100 dim:slider,0,1,100 " .
+ "rgb:colorpicker,RGB ";
+
# now parse the commands
if( $cmd eq "?" ) {
# this one should give us a drop down list
- my $res = "Unknown argument ?, choose one of " .
- "on off next:noArg prev:noArg mode " .
- "color brightness:slider,0,1,100 dim:slider,0,1,100 " .
- "rgb:colorpicker,RGB ";
- return( $res );
+ return SetExtensions( $hash, $cmdList, $name, $cmd, @arg );
} elsif( $cmd eq "on" ) {
WIFILED_Write( $hash, "\x{CC}\x{23}\x{33}" );
# and update the state
@@ -283,9 +285,10 @@
readingsSingleUpdate( $hash, "dim", $bright, 1 );
}
} else {
- my $msg = "WIFILED_Set: unsupported command given $cmd @arg";
- Log( $attr{$name}{loglevel}, $msg );
- return( $msg );
+# my $msg = "WIFILED_Set: unsupported command given $cmd @arg";
+# Log( $attr{$name}{loglevel}, $msg );
+# return( $msg );
+ return SetExtensions ($hash, $cmdList, $name, $cmd, @arg);
}
return( undef );
Hi,
ist das 98_WIFILED.pm im contrib eingecheckt? Sprich steht diese Änderung nun allen zur Verfügung oder muß das noch gemacht werden?
In contrib ist doch das Modul derzeit noch gar nicht vorhanden?
Ich habe nichts eingecheckt. Ich hatte nur am vergangenen Wochenende hier im Thread die letzte Version gesucht und heruntergeladen, da das Ganze irgendwie hier etwas unübersichtlich ist.
Zitat von: bugster_de am 16 April 2014, 08:03:15
ist das 98_WIFILED.pm im contrib eingecheckt? Sprich steht diese Änderung nun allen zur Verfügung oder muß das noch gemacht werden?
Willst Du denn das Modul demnächst irgendwann nach contrib einchecken, damit es mit dem nächsten major-Release von fhem mit ausgeliefert wird? Ich fände das gut.
um ehrlich zu sein: eigentlich möchte ich das nicht einchecken. Und das aus zwei Gründen:
- es gibt das Modul von HerrmanJ. Das kann die Übermenge an Controllern (also den LW12 und sonstige China LED Dinger). M.E. das bessere Modul
- mein Modul ist mal schnell an einem Abend auf genau den LW12 entstanden. Ich habe mittlerweile den Überblick verloren, wieviele China Dinger es da so gibt. Sprich ich habe auch nicht die Hardware, um das Modul an alle möglichen Controller und FW Stände anzupassen
Und uasserdem komme ich ja schon mit der Pflege der Squeezebox Module nicht hinter her :-) Die Jungs&Mädles hier haben immer wieder Ideen für neue und gute Features .-)
Na dann gib das Modul doch an einen freiwilligen ab.... :)
Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk
gerne ! Hast Du jemanden, der hier sich meldet?
Ich will halt nicht den Leuten sagen "ja ich kümmere mich um die Wartung" wenn ich diese Zusage nicht einhalten kann. Momentan ist beruflich viel los und da steht FHEM halt hinten an.
Ich war mal so frei und habe heute das Modul 98_WIFILED.pm in der bei mir seit Wochen problemlos laufenden Version (inkl. Setextensions) nach contrib eingecheckt.
Damit ist und bleibt es "as is" und niemand wird tatsächlich auf einen zeitaufwändigen Support pochen.
Hallo,
ich benutze das Modul seit einigen Monaten mit 2 LW12 Controllern. Um den Controller besser auszunutzen habe ich 98_WIFILED.pm ein wenig erweitert.
Ich habe den internen Offset für mode Auswahl so angepasst, dass jetzt die "modes" gleich durchnummeriert sind wie bei der AndroidApp "Magic Color v2".
Ferner habe ich den set mode Befehl um den Argument speed erweitert so dass der Aufruf jetzt 2 Argumente verlangt z.B.:
set mein_wifi_L12_led mode 0 128
mode ist 0 ... 19
speed ist 0 ... 255 (0 am schnellsten, 255 am langsamsten)
Zur Kontrolle ist auch ein Reading speed dazugekommen.
Bei mir läuft das Modul seit Wochen ohne Probleme. ABER:
Ich bin ein absoluter Perl noob und ich hab mit Turbo Pascal als letztes aufgehört, also ist die Verwendung auf eigene Gefahr, und mit meinen Perl Kenntnissen kann ich wohl auch keine Hilfe leisten falls es doch nicht läuft.
Unten einmal der Patch und das geänderte Modul
--- 98_WIFILED.pm 2014-10-07 20:44:17.000000000 +0200
+++ 98_WIFILED2.pm 2014-10-07 21:19:11.000000000 +0200
@@ -11,7 +11,7 @@
# ############################################################################
#
# we have the following readings
-# state on|off
+# state on|off speed
#
# ############################################################################
#
@@ -26,6 +26,7 @@
# IP the IP of the device
# RGB for the RGB Values of color-picker
# MODE the last number of the built in modes
+# SPEED the last speed value
#
# ############################################################################
# TODO: the speed of the animation: 0xBB, ??, ??, 0x44
@@ -91,6 +92,7 @@
$hash->{GREEN} = 255;
$hash->{BLUE} = 255;
$hash->{MODE} = 0;
+ $hash->{SPEED} = 128;
if( !defined( $attr{$name}{timeout} ) ) {
$attr{$name}{timeout} = 2;
@@ -123,6 +125,12 @@
$hash->{READINGS}{dim}{TIME} = $tn;
}
+ if( !defined( $hash->{READINGS}{speed}{VAL} ) ) {
+ $hash->{READINGS}{speed}{VAL} = 128;
+ $hash->{READINGS}{speed}{TIME} = $tn;
+ }
+
+
return( undef );
}
@@ -169,30 +177,44 @@
} elsif( $cmd eq "stop" ) {
WIFILED_Write( $hash, "\x{CC}\x{22}\x{33}" );
} elsif( $cmd eq "next" ) {
- my $offset = 38;
+# change the offset to match the modes like in the android app
+ my $offset = 37;
my $mode = $offset + $hash->{MODE};
if( $mode > ( $offset + 20 ) ) {
$mode = $offset;
}
$hash->{MODE} = $mode;
- WIFILED_Write( $hash, "\x{BB}" . chr( $mode ) . "\x{19}\x{44}" );
+ WIFILED_Write( $hash, "\x{BB}" . chr( $mode ) . "\x{AA}\x{44}" );
} elsif( $cmd eq "prev" ) {
- my $offset = 38;
+ my $offset = 37;
my $mode = $offset + $hash->{MODE};
if( $mode < $offset ) {
$mode = $offset + 20;
}
$hash->{MODE} = $mode;
- WIFILED_Write( $hash, "\x{BB}" . chr( $mode ) . "\x{19}\x{44}" );
- } elsif( $cmd eq "mode" ) {
- my $offset = 38;
+ WIFILED_Write( $hash, "\x{BB}" . chr( $mode ) . "\x{AA}\x{44}" );
+ } elsif( $cmd eq "mode" ){
+ if( @arg != 2 ) {
+ my $msg = "WIFILED_Set: wrong number of arguments for set mode";
+ Log( $attr{$name}{loglevel}, $msg );
+ return( $msg );
+ } else {
+ my $offset = 37;
if( ( $arg[ 0 ] < 0 ) || ( $arg[ 0 ] > 19 ) ) {
my $msg = "WIFILED_Set: wrong mode number given";
Log( $attr{$name}{loglevel}, $msg );
return( $msg );
}
$hash->{MODE} = $arg[ 0 ] + $offset;
- WIFILED_Write( $hash, "\x{BB}" . chr( $hash->{MODE} ) . "\x{19}\x{44}" );
+ $hash->{SPEED} = $arg[ 1 ];
+
+ WIFILED_Write( $hash, "\x{BB}" . chr( $hash->{MODE} ) . chr ( $hash->{SPEED} ) . "\x{44}" );
+ # and update the speed reading
+ readingsSingleUpdate( $hash,
+ "speed",
+ $hash->{SPEED},
+ 1 );
+ }
} elsif( $cmd eq "color" ) {
if( @arg != 3 ) {
my $msg = "WIFILED_Set: wrong number of arguments for set color";
@@ -309,11 +331,15 @@
return( $msg );
}
+
if( ( $a[ 1 ] eq "rgb" ) || ( $a[ 1 ] eq "RGB" ) ) {
return( ReadingsVal( "$name", "rgb", "F0F0F0" ) );
} elsif( ( $a[ 1 ] eq "dim" ) || ( $a[ 1 ] eq "DIM" ) ) {
return( ReadingsVal( "$name", "dim", "50" ) );
- } else {
+ } elsif( ( $a[ 1 ] eq "speed" ) || ( $a[ 1 ] eq "SPEED" ) ) {
+ return( ReadingsVal( "$name", "speed", "128" ) );
+ }
+ else {
my $msg = "WIFILED_Get: unkown argument";
Log( $attr{$name}{loglevel}, $msg );
return( $msg );
Grüße Andreas
Hallo,
das sieht ja gut aus. Hast Du den Code nach Contrib eingecheckt?
Übrigens: ich habe mal vor ewiger Zeit den Netzwerkverkehr des Moduls mitgeschnitten, da es ja auch ein Rückwärtsinterface unterstützt. Sprich das Modul sendet ja auch den aktuelle Status etc. zurück. Ich komme aber einfach nicht dazu, dieses mal zu implementieren.
Anbei mal meine Analyse aus dem Netzwerkmitschnittes, falls sich jemand findet, der das implementiert. Das sind die Kommandos und deren Bedeutung, die der LW12 wieder zurück schickt. Sprich man müsste auf dem Port 49389 lauschen, und die Rückmeldungen entsprechend auswerten. Vorteil wäre halt, dass man per App und per FHEM gleichzeitig bedienen kann.
Hallo
Zitat von: bugster_de am 08 Oktober 2014, 10:37:54
das sieht ja gut aus. Hast Du den Code nach Contrib eingecheckt?
davon habe ich leider keine Ahnung :-[
Grüße Andreas
Hallo,
Wie genau kann man denn so einen socket auslesen?
Hab im Forum von Homematik gelesen, dass der LW12 das auch auf dem gleichen Port zurückschickt, auf dem man die Befehle schickt, stimmt das?
vg
Kuzl
Hallo,
weis jemand ob dieses Set auch mit Fhem funktioniert.
http://www.amazon.de/STRIPS-CONTROLLER-Fernbedienung-Android-Schwarz/dp/B00G5602NI/ref=pd_rhf_se_p_img_2
Da ich die RGB Strips ins Kinderzimmer bauen wollte wäre es gut wenn die Kinder sie dann auch mit dieser Fernbedienung steuern könnten.
Gruß josty
Hallo
gibt es auch eine art Commandref für das Modul
welche befehle man wie eingeben muss ?
Gruß Josty
Was unterscheidet dieses modul von dem wifilight? Der controller aus post 1 ist der den ich bisher mit http://forum.fhem.de/index.php/topic,18958.msg215066.html#msg215066 betreibe
Wiki http://www.fhemwiki.de/wiki/WifiLight
Welches bietet mehr?
Das Wifilight-modul bietet nicht nur die Unterstützung für den lw12 und hat daher nicht alle funktionalitäten (wie die hardwareanimationen)
Außerdem scheint es mitlerweile recht buggy zu sein (einschalten funktioniert nicht immer etc) außerdem wird der standard colorpicker von fhem darin noch nicht unterstützt. Ich würde mir wünschen, dass das modul hier weiterentwickelt wird.
danke für die Info, das bedienen scheint in der tat hier einfacher, gerade mit dem colorpicker
wenn es denn stabil läuft, warum liegt es noch in contrib... cmdref und / oder wiki wären zu begrüßen.
eh man zb mal die funktion blinking ertüftelt hat....
Da bin ich ganz deiner Meinung, allerdings muss dafür dann jemand den support übernehmen und das will anscheinend keiner, keine ahnung warum
Zitatkeine ahnung warum
Die Antwort findet sich einen Post weiter vorne:
Zitatcmdref und / oder wiki wären zu begrüßen
wenn jemand die Doku macht ...
Kann ich mich mal dran setzen, allerdings weiß ich nicht welches format das haben muss. Ich mach mich morgen mal schlau.
Würdest du das Modul weiterentwickeln? Bei mir scheitert es leider an mangelnden perl-kenntnissen für den rückkanal. Als weiteren schritt wär eine idee, dass man die benutzerkonfigurierbaren animationen über fhem steuerbar macht. Das denke ich kann ich vll sogar machen.
gruß Kuzl
Hallo
ja mir gefällt das Modul auch recht gut benutze es seit 2 Wochen.
bis jetzt keine schwierigkeiten damit.
Hoffe das es weitergeht.
Gruß Josty
@Kuzl:
Zitatdass man die benutzerkonfigurierbaren animationen über fhem steuerbar
das ist doch schon drin! Ich habe aber gerade gesehen, dass ich vergessen habe die Optionen auch für FHEM sichtbar zu machen. Hole ich noch nach.
Mode direkt anwählen
set myled mode 0..19Nächster / Vorheriger
set myled prev
set myled nextAnimation starten / stoppen
set myled run
set myled stopZitatWürdest du das Modul weiterentwickeln?
wie bei Radio Eriwan: im Prinzip ja, aber .... Ich kenne halt meinen momentanen Grad an Freizeit, deshalb tue ich mich mit Zusagen etwas schwer. Will halt keine Erwartungshaltung schüren, die ich dann nicht halten kann.
Rückkanal habe ich ja schon mal extrahiert, was dazu notwendig ist. Im Prinzip muß man dazu (leider) das Modul kräftig umbauen, so dass die Rückantworten verarbeitet werden können, ohne dass FHEM komplett stehen bleibt. Das kann man auf zwei Arten machen (zweistufiges Modul wie meine Squeezebox Module oder mittels parallem Thread). Beides ist einiges an Codierarbeit.
Zitatallerdings weiß ich nicht welches format das haben muss
das Format ist im Prinzip HTML. Beispiele finden sich bei jedem offiziellen Modul ganz am Ende der Datei. Alles nach der Zeil 1; ist dann die zugehörige Doku.
Hallo bugster,
Zitatdass man die benutzerkonfigurierbaren animationen über fhem steuerbar
das ist doch schon drin! Ich habe aber gerade gesehen, dass ich vergessen habe die Optionen auch für FHEM sichtbar zu machen. Hole ich noch nach.
ich hab damit die Animationen gemeint, die man mit der App auch selber zusammenstellen kann. Wenn das auch über FHEM machbar ist kann man praktisch wie beim WIFILIGHT-Modul Farbverläufe Programmieren, mit dem Vorteil, dass alles auf der Hardware abläuft.
Mir ist aufgefallen, dass der "Mode" in den Internals mit dem Offset angezeigt wird. ich Weiß nicht inwieweit man die Anzeige vom Tatsächlichen Wert beeinflussen kann.
Das Problem mit der Freizeit kenne ich :D
Zwengst dem Rückkanal: Kann man da nicht einfach einen Socket öffnen und davon lesen?
Außerdem hab ich im Homatic-Forum gelesen, dass er auch auf dem gleichen Port eine solche Antwort zurückschickt, dann könnte man ja direkt den gleichen Socket verwenden. Leider kenn ich mich da nicht so gut aus.
Zwengst der Doku werd ich mich heute Abend mal ran machen wenn ich Zeit finde, danke für die Info
So Hallo zusammen,
hier hab ich mal die Doku für das Modul gemacht, ist ehrlich gesagt noch gar nicht so viel :D
# DO NOT WRITE BEYOND THIS LINE
1;
=pod
=begin html
=end html
=cut
=pod
=begin html
<a name="WIFILED"></a>
<h3>WIFILED</h3>
<ul>
Define a WIFI LED Controler.
<br><br>
<a name="WIFILEDdefine"></a>
<b>Define</b>
<ul>
<code>define <name> WIFILED <ip></code>
<br><br>
Example:
define myled WIFILED 192.168.38.17
<ul>
</ul>
</ul>
<br>
<a name="WIFILED_Readings"></a>
<b>Readings</b>
<ul>
<li>dim<br>
the brightness of the device. The value can be betwen 1 and 100</li>
<li>RGB/rgb<br>
the current color in format rrggbb</li>
<li>speed<br>
the current animation speed</li>
<li>speed<br>
the current state (on|off)</li>
</ul><br>
<a name="WIFILED_Set"></a>
<b>Set</b>
<ul>
<li>on </li>
<li>off </li>
<li>toggle </li>
<li>color <red> <green> <blue><br>
set color to the given decimal-number per channel. range is 0-255</li>
<li>brightness/dim <value><br>
set brighness to <value>; range is 0-100.</li>
<li>mode <mode> <speed> <br>
set controller animation mode to <mode> with <speed>; mode-range is 0-19 speed-range is 0-255</li>
<li>next<br>
set next controller animation mode </li>
<li>prev<br>
set previous controller animation mode </li>
<li>run<br>
run controller animation </li>
<li>stop<br>
stop controller animation </li>
<li>rgb <rrggbb></li>
<li><a href="#setExtensions"> set extensions</a> are supported.</li>
<br>
</ul><br>
<a name="WIFILEDget"></a>
<b>Get</b> <ul>N/A</ul><br>
<a name="WIFILEDattr"></a>
<b>Attributes</b> <ul>N/A</ul><br>
=end html
=cut
@bugster: Das kannst du dann gleich in die ausgebesserte Version anhängen
Grüße
Kuzl
Gibt es eigentlich eine Möglichkeit den Lw12 nicht RGB sondern HSV werte zu übermitteln, die Fuktion gibt es in Wifilight, abe rin Wifiled leider nicht, ich habe einen externen wandschalter der nur Sättigung bzw farbwert ändert, was über RGB leider nicht so einfsch möglich ist. Unterstützt wifiled eigentlich den Rückkanal des LW12?
Ich möchte hier auch noch meinen Dank aussprechen, welch tolle Arbeit hier geleistet wird!
Grüße
Fabian
Hallo Fabian
ich habe es bisher mit HSV werten nur geschafft - die jeweilige Farbe einzustellen - jedoch mit einem Farbwechsel als Gesamtbefehl, habe ich so meine Probleme
gruss tagedieb
irgendwie finde ich keine rückmeldung vom LW12 im Netzwerkverkehr... muss man das erst einschalten?
Das kann ich dir leider nicht sagen. Ich weiß nur, dass es einen Rückkanal gibt, denn die mitgelieferte App kann die Farbwerte des Kontrollers auslesen. Man müsste wohl irgendwie die Kommunikation zwischen der App und dem LW12 mitschneiden.
Gruß
Fabian
Das hab ich gestern versucht mit der Fritzbox und Wireshark. Allerdings hab ich das vorher noch nie gemacht, keine Ahnung ob ichs einfach nicht gefunden hab. Ich hab nur den Befehl an den LW12 gefunden aber keine Rückmeldung. Kann mir jemand sagen wie man das richtig mitschneidet und dann die Strings auch rausliest aus Wireshark?
@bugster: Hast du die Kommunikation mit der App aufgenommen oder mit FHEM? evtl. aktiviert die App ja irgendwas.... oder ich bin zu blöd dafür
Okay jetzt glaub ich bin ich schlauer :D
Ich hab mal im Internet gestöbert und der LW12 gibt nicht immer seine Informationen Preis sondern muss dazu aufgefordert werden.
Wenn man ihm das Kommando schickt, schickt er 11 Bytest zurück. Ansonsten gar nichts. Deshalb war auch bei mir sowas nicht zu finden, weil ich nicht den Netzwerkverkehr mit der App sondern mit dem WIFILED-Modul mitgeschnitten habe und das sendet ja den Request nicht. Ich werd das heute Abend mal testen.
EDIT: Funktioniert! :) mit dem Kommando ef0177 lässt sich alles abfragen.
EDIT2: Hab jetzt mal ein paar Sachen decodieren können. Allerdings die ersten beiden und die letzten beiden Bytes nicht das würde mich noch interessieren, was das ist :D
Zitat
Beispiel: Port 5577
66:01:24:41:21:19:ff:f2:3d:51:99
66:
01:
24: 23 = on; 24 = off
41: MODUS: Offset +37; also 4
21: Animation Pause 20 = Pause; 21 = Run
19: SPEED
ff: RED
f2: GREEN
3d: BLUE
51:
99:
@bugster: der Rückkanal ist übrigens auch auf 5577
Viele Grüße
Kuzl
So Hallo in die Runde,
in der Hoffnung dass noch jemand mitliest:
Ich hab einige Bugs behoben (next und prev gingen nicht, Der Offset der Modi wird nicht mehr im Reading mit angezeigt) und den Rückkanal eingebaut.
Dazu noch eine Frage an euch: wie oft soll sich die Anzeige aktualisieren wenn von FHEM aus nichts geschaltet wird? Also wenn z.b. mit der App geschaltet wird wie oft soll sich das Modul dann den aktuellen Status holen... habs jetzt mal auf 60 sec gestellt
ich muss noch einige Timingsachen ändern das gefällt mir noch nicht so ganz. Aber die funktionalität ist gegeben :)
Gruß
Kuzl
Super. Es tut sich wieder was ... danke
Hallo,
ebenso: Danke!
Ich fand' es schade um das eigentlich gut gestartete Modul.
Gruß
Hans
Hallo,
ich finde es auch super, dass Du das Modul weiter vorantreibst, ich habe auch schon früher versucht die prev/next zu fixen, aber bei meinen Perl Kenntnissen ging das leider schief :-[
Btw. gibt es das Modul irgendwo zum Download? Die Version auf github ist noch die, die betateilchen im Juni eingecheckt hat.
Grüße
Andreas
Hallo, die Version ist noch nirgens zu finden, weil sie noch nicht so ganz das ist, was ich mir vorstelle. Ich will euch keine halb fertige Sache geben :) aber ich komme am sonntag abend wieder nach hause dann mach ich weiter und ich denke dann kann ich euch eine erste Version zur Verfügung stellen
Gruß
Kuzl
Gute Arbeit - bei mir ist das Modul auch im Einsatz.
Zitat von: Kuzl am 20 November 2014, 10:13:39
EDIT2: Hab jetzt mal ein paar Sachen decodieren können. Allerdings die ersten beiden und die letzten beiden Bytes nicht das würde mich noch interessieren, was das ist :D
Irgendwo sollte vermutlich noch die brightness stecken.
Das hab ich mir auch gedacht aber es hat sich nur 1 mal das vorletzte byte verändert, konnte ich aber nicht nachstellen. Hab bestimmt 100 schaltvorgänge gehabt und alles ausprobiert.
ich denke ich muss mir die helligkeit aus den RGB-Codes ausrechnen. Weis zufällig wer wie das geht? Mir ist aufgefallen, dass der colorpicker das korrekt auswertet und sich die helligkeit ausrechnet.
@betateilchen: vor 1 oder 2 seiten hat bugster auch mal verschiedene farben und helligkeiten gepostet. Evtl. Kannst du daraus ja noch was rauslesen.
Viele Grüße,
Kuzl
http://de.wikipedia.org/wiki/HSV-Farbraum#Umrechnung_RGB_in_HSV
http://stackoverflow.com/questions/596216/formula-to-determine-brightness-of-rgb-color
im Color modul gibt es routinen dafür.
gruss
andre
Hallo zusammen,
hier wie versprochen das geänderte Modul, hab recht viel umgeschmissen und will auch noch mehr ändern, allerdings ist jetzt funktional mal alles so fertig wie ich es wollte. Ich bitte um Tests :) Das Updateintervall ist jetzt mal auf 60 sek gestellt. zusätzlich 1 Sek nach dem letzten Befehl. Der Grund dafür ist, dass man ansonsten nicht mehrere Befehle schnell hintereinander senden kann (z.b. aufdimmen). Soll ich diese beiden Zeiten noch per Attribut einstellbar machen?
@Andre: Danke, die Routine funktioniert wunderbar. Ich will jetzt auch noch deine "BrightnessToChannels" verwenden. Kannst du mir da die Verwendung erklären? Blicke da leider nicht so ganz durch:/
Viele Gruße
Kuzl
EDIT: jetzt mit Log3 und verbose anstatt loglevel
Läuft soweit gut, ein paar Sachen sind mir schon aufgefallen:
- Das Attribut loglevel ist schon länger deprecated, stattdessen gibt es verbose und das nur mit Werten von 0 bis 5.
- Anstatt Log() sollte Log3() verwendet werden.
Alles klar, danke dir.
Mit den Ausgaben hab ich mich noch nicht beschäftigt, sind noch komplett vom original.
Das ist ja mein erstes Modul, an dem ich bastle. Wie ist das mit den globalen variablen?
ich würde gerne den "offset" global für alle funktionen bekannt machen. geht das so einfach oder muss ich da was beachten?
Gruß
Kuzl
Ich hab für meine LEDs einen Wandschalter mit 6 Tasten. 2 für die Helligkeit, 2 für die Sättigung und 2 für den Farbton, alles läuft also im HSV Farbraum ab. Dafür hab ich bis jetzt das wifilight modul verwendet. Jetzt wo das wifiled modul den Rückkanal des LW12 unterstützt - schaut sehr gut aus:)! - würde mich noch interessieren ob die Integration vom HSV Farbraum eine weitere Option zur Ergänzung des Moduls wäre.
Beste Grüße und vielen Dank für das Modul
Fabian
Zitat von: Kuzl am 23 November 2014, 22:59:39
Das ist ja mein erstes Modul, an dem ich bastle. Wie ist das mit den globalen variablen?
Kein Problem, da helfe ich Dir gerne weiter :)
Zitat von: Kuzl am 23 November 2014, 22:59:39
ich würde gerne den "offset" global für alle funktionen bekannt machen. geht das so einfach oder muss ich da was beachten?
Das kannst Du relativ einfach bewerkstelligen, indem Du ein "my $offset = 728;" (oder was auch immer) in das Modul VOR die _Initialize Funktion packst.
Hallo zusammen,
@betateilchen: Dankeschön, funktioniert wunderbar :)
@Fabian: ich wollte es einbauen mit der Umwandlung aus dem colorpicker. Hab da aber glaub ich einen Fehler entdeckt und werde Andre darauf anschreiben. Brauchst du auch ein Reading dazu?
Viele Grüße
Kuzl
So war nur ein Verständnisfehler von mir :)
Hier die Version mit unterstützung für hsv in den Intervallen von H: 0-360, S und V: 0-100
Viel Spaß damit :)
Die Frage mit dem Reading steht noch :D
Gruß Kuzl
Zitat von: Kuzl am 23 November 2014, 22:07:24
Das Updateintervall ist jetzt mal auf 60 sek gestellt. zusätzlich 1 Sek nach dem letzten Befehl.
...
Soll ich diese beiden Zeiten noch per Attribut einstellbar machen?
Die Aktualisierung 1 Sekunde nach dem Befehl ist ok. Ich würde aber ein Attribut für das generelle Updateintervall begrüßen, da mir grundsätzlich längere Intervalle völlig ausreichend wären. Ein Intervall von 0 sollte die automatische Abfrage auch komplett abschaltbar machen.
Hab jetzt noch nicht nachgesehen, gibt es ein "get <device> status" damit man die Information "bei Bedarf" abrufen kann?
Zitat von: betateilchen am 24 November 2014, 15:28:44
Die Aktualisierung 1 Sekunde nach dem Befehl ist ok. Ich würde aber ein Attribut für das generelle Updateintervall begrüßen, da mir grundsätzlich längere Intervalle völlig ausreichend wären. Ein Intervall von 0 sollte die automatische Abfrage auch komplett abschaltbar machen.
Alles klar werde ich versuchen einzubauen.
Zitat von: betateilchen am 24 November 2014, 15:28:44
Hab jetzt noch nicht nachgesehen, gibt es ein "get <device> status" damit man die Information "bei Bedarf" abrufen kann?
Es ist eine get-routine vorhanden die wohl intern irgendwas mit dem colorpicker macht, da blicke ich nicht ganz durch. Und die ist auch nicht sichtbar. Wie muss ich da vorgehen um ein "sichtbares" get-kommando einzubauen?
Gruß
Kuzl
vielleicht kannst du die syntax der hue devices für das aktualisieren nach einem set verwenden.
der colorpicker brauchte bis vor ein paar tagen ein get um das textfeld beim seitenaufbau mit dem aktuellen wert zu versehen. inzwischen reicht wie sonst in fhem üblich auch das reading mit gleichem namen.
die get bekommst du 'sichtbar' in dem du auf get ? mit der liste der möglichen kommandos antwortest. genau so wie bei set und attr.
gruss
andre
Ein Reading wäre echt super praktisch, weil ich das Reading auslese und darauf addiere - somit kann ich quasi eine Taste lange drücken und er geht alle farben druch :D
WOW - Bin begeistert :D Vielen Dank!!
Grüße
Fabian
Hallo wieder mal,
anbei die Version mit dem hsv-Reading, ein get zum manuellen anstoßen des updates und einem attr zum einstellen des updateintervalls.
Die Syntax der HUE verstehe ich leider nicht so ganz, das ist mir noch zu hoch ich hab nur irgendwas "update_timeout" gefunden aber da blicke ich nicht ganz durch.
Auch Brightness2Channels kapier ich noch nicht so ganz :D
By the way: wie bekomm ich das zweite RGB-Reading weg? wenn ich eins davon weg mache funktioniert der colorpicker nicht mehr richtig
Aber bis da hin viel Spaß damit :)
Gruß
Kuzl
Ich hab die HSV-Readings mal auseinander gezogen. Es funktioniert allerdings bis dato recht unschön - Ich poste das nur deshalb hier, weil ich mich mit Perl kaum auskenne und nicht weiß, wie ich weiter verfahren sollte.
Meine Änderungen:
- HSV in 3 Readings geteilt (erleichtert es, die Readings weiter zu verwenden um z.B. nur auf HUE etwas aufzuaddieren)
- HSV Readings auf Integer umgerechnet (Nachkommastelle wird einfach abgeschnitten)
Was noch fehlt.
HSV Werte im SET [..] HSV [..] sind nachwievor mit Nachkommastellen.
Bin mir nicht sicher, hab nur die Updatefunktion bearbeitet, kann sein, dass noch wo anders eine Ergänzung statt zu finden hätte.
Zusätzlich ist mir aufgefallen (was für mich allerdings kein Problem ist) das im Dropdownmenu von set [...] RGB keine Möglichkeit zur Werte eingabe besteht.
Grüße
Fabian
bei den hue wird der update timeout im set mit angehängt. und wenn wärend eines laufenden update timers ein neues set kommt der timer neu gestartet. so kann man dein timer zum ausschalten auf 0 setzen wenn man einen kontinuierlichen effekt steuert oder etwas höher wenn man per taster und notify interaktiv alle lampen dimt damit das update nicht zwischen rein funkt.
du brauchst ein reading und ein set. beide müssen gleich heißen. wenn es nicht RGB ist brauchst du zusätzlich noch ein event RGB damit die longpoll updates des colorpicker gegen. die kannst du bekommen indem du im modul ComnandTrigger zusätzlich zum ReadingsUpdate verwendest.
gruß
andre
Jetzt glaub ich hab ich es verstanden. Du setzt z.b. bei dimup und dimdown den timer höher. Ansonsten ist es der im Reading.
Ok aber wie löst du das problem, wenn jemand einfach ganz schnell hintereinander befehle schickt, wenn er auf sofortigen update gestellt hat?
Das war mein eigentlicher Beweggrund dafür. Wenn jemand z.b. farbübergänge in einem notify drin hat würde das ja alles sehr verzögern wenn auf sofortigen update gestellt ist. Man könnte es natürlich per optionalen parameter ausschalten...
@pythonf: also das HSV in einzlne readings aufzutrennen halte ich nicht für nötig, kann jeder selber in den notifys machen wenn er es braucht ist ja mit rgb das gleiche.
Das mit dem Dropdownmenü ist mir auch schon aufgefallen, keine ahnung wie man das herbekommt wenn der colorpicker verwendet wird.
HSV-Reading ist mitlerweile gefixt
Stimme ich dir zu, ich werd mich mal i Forum umschaun, wie ich es mit fhem hinbekomme, dass ich ein Reading in 3 variablen aufteile:)
Wie sieht denn so ein Reading aus und wie möchtest Du es gerne geteilt haben?
Das Reading aktuell schaut so aus:
HSV: H-Wert " " S-Wert " " V-Wert.
für meine Anwendung bräuchte ich die Werte allerdings einzeln.
Grüße
Fabian
Du hast meine Frage nicht verstanden.
Gib mir doch mal bitte einen KONKRETEN reading-Inhalt (also echte Werte) und nicht irgendwas symbolisches.
alles muss man sich hier selbst zusammansuchen...
my $hsv = ReadingsVal('blaDevice','hsv','');
my ($h,$s,$v) = split(/ /,$hsv);
Und ausserdem interessieren mich Fußballmannschaften nicht die Bohne.
Ich hätte da noch eine Anregung:
Im _Define sollte die erste Aktualisierung nicht erst nach 60 Sekunden stattfinden, damit nach einem "shutdown restart" oder einem "rereadcfg" die aktuellen Werte sofort zur Verfügung stehen.
Sind diese vielen get wirklich noch notwendig?
2014.11.25 19:09:04.285 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:09:50.169 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:10:02.817 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:10:35.867 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:11:21.793 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:12:07.505 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:12:53.034 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:13:38.981 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:14:24.687 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:15:02.570 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:15:13.555 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:15:59.727 3: get Licht_Balkon rgb : 7F4200
2014.11.25 19:16:45.690 3: get Licht_Balkon rgb : 7F4200
Alles klar mach ich so :)
In der aktuellen version werden die readings nur noch aktualisiert, wenn sich der wert ändert. Kann sein, dass das logging noch an der falschen stelle sitzt.
Zitat von: Kuzl am 25 November 2014, 20:18:13
Kann sein, dass das logging noch an der falschen stelle sitzt.
Nein, sorry. War mein Fehler aus der "alten" Version.
Deine Änderungen sind übrigens nicht abwärtskompatibel 8) Früher konnte man mit "get <device> rgb" einfach den rgb Wert auslesen - das gibt jetzt jede Menge Fehler im Log.
Vielen Dank für die Erklärung :D - funktioniert genau so, wie ich es brauche und erspart sogar noch Schreibarbeit:)
Grüße
Fabian
Stimmt das gwht jetzt nicht mehr jetzt muss man sich das aus dem reading holen. Soll ich das noch einbauen?
Nein, brauchst Du nicht. Da das Modul noch nie "offiziell" war, ist das kein Problem ;)
Ich glaube, da müssen noch ein paar Aufräumarbeiten gemacht werden, so ganz tut das alles noch nicht so wie geplant.
- in den Internals sollten die Werte für R G B speed und mode entfernt werden
- nach dem Setzen eines mode sollte ein entsprechendes Reading aktualisiert werden, bisher gibt es dafür gar kein Reading
- beim setzen eines mode sollte der zweite Parameter optional sein
Mein Controller hatte irgendeinen Mode mit einem langsamen Farbwechsel durch das gesamte Farbspektrum. Irgendwie finde ich diesen Mode nicht nicht mehr :(
Okay ja da geb ich dir recht. Allerdings würde ich die internals für die einzelnen farben zur internen verarbeitung gern behalten. Gibts da ne möglichkeit das ganze "unsichtbar" zu machen?
Der sache mit der verschwundenen animation gehe ich auf den grund ;)
EDIT: müsste der mode 0 sein
Das mit dem Mode 0 stimmt. Aber in der magic color app ist das der mode 1 - vielleicht sollte man das noch synchronisieren. Die Modes sind alle um 1 verschoben.
Warum Du die RGB Werte in den Internals brauchst, wo sie doch in den readings stehen, verstehe ich zwar nicht, aber Du könntest das z.B. so lösen:
$hash->{helper}{RED} = 255;
$hash->{helper}{GREEN} = 255;
$hash->{helper}{BLUE} = 255;
$hash->{helper}{MODE} = 0;
$hash->{helper}{SPEED} = 128;
und dann immer auch so verarbeiten (also immer mit {helper} davor) Auf diese Art und Weise sollten die Werte nicht mehr in Internals auftauchen.
Verwirrend finde ich übrigens die "umgekehrte Logik" beim speed-Wert: je höher der Wert, desto langsamer der Farbwechsel...
Genau danach hab ich gesucht danke :)
Ja die modes beginnen in der app bei 1 und hier im modul bei 0. Das kann ich ebenfalls korrigieren.
Zitat von: Kuzl am 26 November 2014, 20:05:48
Ja die modes beginnen in der app bei 1 und hier im modul bei 0. Das kann ich ebenfalls korrigieren.
Das würde ich begrüßen :)
Fragen aus Neugier:
Wie werden eigentlich die benutzerdefinierten Modi angesprochen?
Einfach weiterzählen?
Woher weiß das Modul wieviele Modi es insgesamt gibt?
Die benutzerdefinierten hab ich mir noch nicht angesehen. Da muss ich mal schauen wie die von der app angesprochen werden... und auch das ganze erst mal sniffen.
aber wär natürlich der hammer wenn ich das noch einbauen könnte
Zitat von: Kuzl am 26 November 2014, 20:21:43
Die benutzerdefinierten hab ich mir noch nicht angesehen.
Es scheint tatsächlich so einfach zu sein - einfach weiterzählen. Wenn ich mode=19 (in der app=20) setze, komme ich in den ersten selbst definierten Modus.
Hallo,
Ich habe die Informationen von der Seite
http://blog.stedmeister.co.uk/2014/05/controlling-the-wifi370/ (http://blog.stedmeister.co.uk/2014/05/controlling-the-wifi370/)
verwendet um die benutzerdefinierten Modi des LW12 von FHEM aus zu definieren. Vielleicht erspart dir dies einiges an Sniffen.
Grüße,
ChrisD
super :) danke für die Info.
warum hab ich diese seite nicht gefunden :-[ :'(
Danke dir für die Seite die erspart mir durchaus einiges denke ich :D aber eins nach dem andern :)
So hab mal alles was dir aufgefallen ist korrigiert und noch zusätzlich den Befehl "speed" hinzugefügt mit dem man die Geschwindigkeit ändern kann ohne den mode zu beeinflussen.
Ich würde noch gerne die Zählrichtung des Speeds umkehren, reicht es da wenn ich den Speed bitweise invertiere? bin mir da irgendwie nicht sicher :-\
EDIT: ich idiot ich muss nur 255-speed nehmen :D bau ich noch kurz ein
EDIT2: So Version im Anhang hat nun den speed "richtig rum"
ähm... zum Thema speed... bist Du Dir sicher, dass es so einfach ist?
Ich denke dass es so passt, ja. Aber teste es bitte lieber nochmal :D Version oben - kann sein dass du es nicht mehr gelesen hast hab sie erst ca. 30 sec vor deinem Post hochgeladen.
Es passt nicht.
bisher (vor Deiner heutigen Änderung) war die Zuordnung von "fhem speed" -> "app speed" folgende:
0 -> 32
10 -> 22
20 -> 12
30 -> 2
32 -> 0
40 -> -8
50 -> -18
60 -> -28
70 -> -38
80 -> -48
90 -> -58
100 -> -68
110 -> -78
120 -> -88
128 -> -96
130 -> -98
die Formel war: app = -1 * (fhem-32)
Jetzt ist die Zuordnung folgende:
0 -> -223
10 -> -213
50 -> -173
usw.
In der App gibt es nur Werte von 1-31, je höher der Wert, umso schneller der Farbwechsel
app = 1 -> fhem =224
app = 15 -> fhem = 238
app = 31 -> fhem = 254
Also wenn Du von Deinem aktuellen Reading noch 223 abziehst, passt das Ergebnis. Aufgefallen ist mir, dass das speed-Reading erst nach zweimaligem get updateStatus aktualisiert wird.
Achja: Wieso hat das reading "mode" eigentlich keinen Timestamp? Arbeitest Du nicht mit den readings*Update() Funktionen?
der grund ist, dass es (zuminderst glaub ich das) mehr als diese 32 Helligkeitsstufen nimmt. die App nimmt sich nur die schnellsten 32 raus. (bin mir allerdings nicht sicher, ob der controller auch 255 geschwindigkeiten unterstützt aber mir scheint es schon so)
doch ich arbeite mit readings*Update(), update allerdings nur, wenn sich das reading auch ändern würde. daher ist warscheinlich der timestamp so "alt".... OK mir ist grad aufgefallen bei der definition oben hab ich da was übersehen ich aktualisiere die Version oben um diesen kleinen fix
ui ui ui... da ist aber eine Menge durcheinander im Coding...
Zitat
# Preset our readings if undefined
my $tn = TimeNow();
if( !defined( $hash->{READINGS}{state}{VAL} ) ) {
$hash->{READINGS}{state}{VAL} = "?";
$hash->{READINGS}{state}{TIME} = $tn;
}
if( !defined( $hash->{READINGS}{rgb}{VAL} ) ) {
$hash->{READINGS}{rgb}{VAL} = "FFFFFF";
$hash->{READINGS}{rgb}{TIME} = $tn;
}
if( !defined( $hash->{READINGS}{hsv}{VAL} ) ) {
$hash->{READINGS}{rgb}{VAL} = "0 0 100";
$hash->{READINGS}{rgb}{TIME} = $tn;
}
if( !defined( $hash->{READINGS}{dim}{VAL} ) ) {
$hash->{READINGS}{dim}{VAL} = 100;
$hash->{READINGS}{dim}{TIME} = $tn;
}
if( !defined( $hash->{READINGS}{mode}{VAL} ) ) {
$hash->{READINGS}{mode}{VAL} = 1;
$hash->{READINGS}{speed}{TIME} = $tn;
}
if( !defined( $hash->{READINGS}{speed}{VAL} ) ) {
$hash->{READINGS}{speed}{VAL} = 250;
$hash->{READINGS}{speed}{TIME} = $tn;
Lass mich mal ein bisschen basteln, ich bau Dir das mal "state-of-the-art" um.
oh ja stimmt da hab ich was übersehen :D das mit dem mode hab ich grad korrigiert
das wär cool von dir nimm dir bitte die aktuelle version von oben.
wegen dem speed... habs grade nochmal verglichen es gibt definitiv mehr als die 32 geschwindigkeiten von daher würd ich sagen das passt so.
aktualisiert sich bei mir schon beim ersten updateStatus :o
Dass es mehr als 31 Geschwindigkeiten gibt, mag schon sein, aber dass die App negative Werte anzeigt, ist Kacke. Das kann nämlich der Slider in der App nicht darstellen.
Im _Define kannst Du alle Prüfungen weglassen, ob es attr oder readings schon gibt. Im Define KANN es die noch nicht geben. Und die Readings brauchst Du dort überhaupt nicht setzen, die werden von _Update gesetzt.
Probier mal mit folgendem _Define:
sub WIFILED_Define( $$ ) {
my ( $hash, $def ) = @_;
my $name = $hash->{NAME};
my @a = split("[ \t][ \t]*", $def);
# do we have the right number of arguments?
if( @a != 3 ) {
Log3 $name, 3, "WIFILED_Define: falsche Anzahl an Argumenten";
return( "wrong syntax: define <name> WIFILED <serverip> " );
}
# preset the internals
$hash->{IP} = $a[ 2 ];
$hash->{helper}{RED} = 255;
$hash->{helper}{GREEN} = 255;
$hash->{helper}{BLUE} = 255;
$attr{$name}{timeout} = 2;
$attr{$name}{updateIntervall} = 60;
$attr{$name}{verbose} = 3;
WIFILED_Update($hash);
return undef;
}
Bei updateIntervall solltest Du das zweite l am Ende streichen (Achtung: Auch im Initialize anpassen!)
Ausserdem brauchst Du eine Forward-Deklaration der _Update:
#global Variable
my $offset = 36;
sub WIFILED_Update($);
hab ich geändert und funktioniert wunderbar dankeschön :)
also meine App zeigt dann einfach geschwindigkeit 1 an. Abgesehen davon finde ich es nicht gut, wenn wir den funktionsumfang des Moduls aufgrund der App einschränken. Ich finde auch Geschwindigkeit 1 der App immer noch zu schnell für angenehm fließende Übergänge
PS: Version oben ist aktualisiert
EDIT: Meine App-Version ist 2.1.0; was hast du für eine?
Du hast die Funktion der readings*Update Funktionen noch nicht verstanden, deshalb gibt es eine Menge Warnungen im Log.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 461.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 466.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 467.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 468.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 469.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 433.
Beispiel:
sub WIFILED_UpdateRGB( $ ) {
my ( $hash, @rest ) = @_;
my $name = $hash->{NAME};
my $buf = sprintf( "%02X%02X%02X",
$hash->{helper}{RED},
$hash->{helper}{GREEN},
$hash->{helper}{BLUE} );
if ( $hash->{READINGS}{rgb}{VAL} ne uc($buf)){
readingsSingleUpdate( $hash, "rgb", uc($buf), 1 );
CommandTrigger( "", "$hash->{NAME} RGB: $buf" );
}
return;
}
macht keinen Sinn.
- Du brauchst nicht prüfen, ob der Wert sich geändert hat, das macht readingsSingleUpdate() automatisch
- Du brauchst kein CommandTrigger absetzen, das macht der Parameter 1 als vierter Parameter beim Funktionsaufruf readingsSingleUpdate
Also einfach so:
sub WIFILED_UpdateRGB( $ ) {
my ( $hash, @rest ) = @_;
my $name = $hash->{NAME};
my $buf = sprintf( "%02X%02X%02X",
$hash->{helper}{RED},
$hash->{helper}{GREEN},
$hash->{helper}{BLUE} );
readingsSingleUpdate( $hash, "rgb", $buf, 1 );
return;
}
Die Konvertierung in Großbuchstaben
uc($buf)kannst Du auch weglassen, das erledigt sprintf() bereits, da Du dort mit dem großen X bereits festgelegt hast, dass Du Großbuchstaben in HEX-Werten haben willst.
Ähnliche Punkte gibt es in diesen Zeilen zu ändern:
readingsSingleUpdate( $hash, "hsv", $hsv_reading, 1 ) if ( $hash->{READINGS}{hsv}{VAL} ne $hsv_reading);
readingsSingleUpdate( $hash, "mode", hex( $colors[ 3 ] ) - $offset, 1 ) if ( $hash->{READINGS}{mode}{VAL} ne hex( $colors[ 3 ] ) - $offset );
readingsSingleUpdate( $hash, "dim", $dim->{bri}, 1 ) if ( $hash->{READINGS}{dim}{VAL} ne $dim->{bri} );
readingsSingleUpdate( $hash, "speed", 255 - hex( $colors[ 5 ] ), 1 ) if ( $hash->{READINGS}{speed}{VAL} ne 255 - hex( $colors[ 5 ] ) );
Aber den korrekten Umbau kriegst Du nach meinen obigen Hinweisen sicher selbst hin ;)
Habs ausprobiert, wenn ich die if-Abfrage weglasse, wird bei jedem update das Reading aktualisiert, auch wenn es bereits das gleiche beinhaltet. Das erzeugt dann unnötig events jede Minute (wenn es auf 60 sec gestellt ist). Ich denke die Warnungen kommen, wenn das reading noch nie gesetzt war und ich mit dem Reading vergleichen will weil dann mit dem undefinierten Reading verglichen wird.
Also doch wieder im define die Readings mit Standartwerten beschreiben?
CommandTrigger benötigt der colorpicker, da er im moment noch explizit ein "RGB" event benötigt (RGB muss großgeschrieben sein).
das uc wird rausgeschmissen - hab ich nicht gewusst danke.
Sorry, Du hast recht mit den events, da war ich in Gedanken an einer anderen Stelle.
Trotzdem:
Zitat von: Kuzl am 27 November 2014, 10:44:12
Also doch wieder im define die Readings mit Standartwerten beschreiben?
Auf keinen Fall. Und auch bitte die Vergleiche nicht wieder einbauen!
Falls sich ein Anwender an den events stört, kann er die jederzeit individuell mit "event-on-change" begrenzen. Genau DAS ist ja der Sinn der readingsFnAttr und readings*Update Funktionen. Bei mir steht das Updateintervall ohnehin auf 900 Sekunden, mich stört das nicht, zumal ich ja nach einer Änderung per Befehl ohnehin ein update bekomme. Und ohne Steuerbefehel sollte sich an den readings ohnehin nichts ändern.
Zitat von: Kuzl am 27 November 2014, 10:44:12
CommandTrigger benötigt der colorpicker, da er im moment noch explizit ein "RGB" event benötigt (RGB muss großgeschrieben sein).
Dafür muss es auch eine bessere Lösung geben. Ich schau mal nach.
Zitat von: Kuzl am 27 November 2014, 10:44:12
CommandTrigger benötigt der colorpicker, da er im moment noch explizit ein "RGB" event benötigt (RGB muss großgeschrieben sein).
Ich hab die Frage mal weitergeleitet: http://forum.fhem.de/index.php/topic,29656.msg224037.html
um den colorpicker auf einer bereits sichtbaren seite aktualisieren zu können muss fhem ein event erzeugen das dann per longpoll an den browser geht. dieses event zu erzeugen ist zur zeit auf zwei arten möglich: entweder ein reading aktualisieren oder ein per trigger eines erzeugen.
im colorpicker ist zur zeit der name des events noch hart kodiert. ich werde das noch ändern bin aber nicht dazu gekommen.
gruss
andre
Zitat von: betateilchen am 27 November 2014, 11:09:23
Falls sich ein Anwender an den events stört, kann er die jederzeit individuell mit "event-on-change" begrenzen.
Stimmt, das hatte ich total vergessen.
Die Lösung für den colorpicker, die mir einfallen würde, ist das set und das reading auch "RGB" zu nennen aber das passt dann halt nicht mehr so richtig zum rest
@andre: Dankeschön dann kann man den trigger bald mal rausschmeissen
Ich denke, ich/wir könnten anfangen die userdefinierten animationen einzubauen.
die überlegung ist nur WIE kann man das halbwegs angenehm für den anwender machen.
Ich hab an sowas gedacht wie "set anim FF0000 00FF00 0000FF 2 20" wobei die farben zwischen 2 und 16 sein können, "2" der Modus ist also strobe hart oder faden und 20 die geschwindigkeit wieder optional.
Was denkst du?
Kann man schon so machen. Aber in diesem Fall würde ich die Geschwindigkeit nicht optional machen, sie beschreibt die Animation grundsätzlich und gehört deshalb immer dazu.
Ich überlege grade, ob es nicht irgendwo auch noch einen Parameter für die "Pause" zwischen der Animationswiederholung gab, kann aber sein, dass ich das grade komplett mit etwas anderem verwechsle.
Mit dem Thema "speed" bin ich übrigens immer noch nicht ganz glücklich. Irgendwie arbeitet der Controller nach einem "off" und anschließendem "on" zwar den eingestellten Modus weiter ab, aber mit einer unterschiedlichen Geschwindigkeit als vor dem Ausschalten.
ich hab eben eine geänderte version des colorpicker eingecheckt. damit kann das trigger auf RGB entfallen wenn es ein reading gibt das genau so heisst wie das set kommando.
für die animationen ein vorschlag. ich weiss aber nicht ob das auf euer device passt:
für das swap rgb board habe ich 16 'register' im device definiert. jedes register enthält eine rgb farbe und die zeit die bis zum erreichen der farbe verstreichen soll. diese register kann man jetzt von fhem aus als einfache presets verwenden oder man kann sagen starte eine loop über alle register von r1-r2.
gruss
andre
Hallo Andre,
man kann vieles machen, aber lassen wir doch Kuzl erstmal noch ein bisschen mehr Verständnis für Programmierung in fhem aneignen, man ist da glaub ich grade auf einem guten Weg, wenn eigene Ideen umgesetzt werden und Erfolgserlebnisse eintreten. Verbessern kann man so ein Modul immer. Im Moment finde ich den Ansatz mit dem "set anim ..." schonmal sehr gut.
Danke für die Änderungen am colorpicker.
Danke für die schnelle Änderung :)
die Idee mit den Registern ist echt ganz gut, nur für mich glaub ich nicht so schnell ohne sehr viel Hilfe umsetzbar :D
Ich werde jetzt erst versuchen das mit dem einfachen set hinzubekommen und dann anschließend kann man es ja noch auf die Register umbauen :)
Bezüglich speed- also bei mir bleibt die vorher eingestellte geschwindikeit erhalten. nur wenn ich in der app den mode ändere wird auch die geschwindigkeit mit der aus der app überschrieben.
einen Pause-Parameter konnte ich nicht finden. Mich würde allerdings interessieren wie man einen anderen Speicherplatz des controllers für die animation belegt. standardmäßig wenn man es nicht "abspeichert" ist es ja anscheinend 21; also einfach die nächste nach den voreingestellten.
So hallo :)
ich hab das ganze jetzt mal eingebaut - mensch das war fuselig :D
@ 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 :D also Anwendung ist: "set <device> animation <rrggbb> <rrggbb> <- bis zu 16 farben <speed 0-255> <mode 0-2>
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.
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
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
Zitat von: betateilchen am 27 November 2014, 14:42:52
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.
Kein Problem ich hab bis dienstag warscheinlich auch keine oder nur sehr wenig Zeit dafür ;)
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
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.
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
Zitat von: Kuzl am 03 Dezember 2014, 08:48:42
@betateilchen: Bist du schon dazugekommen ein bisschen drüberzuschaun?
Bin grade dabei.
Den CommandTrigger() in Zeile 492 kannst Du entfernen.
Und das hier solltest Du besser so machen:
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:
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.
Dankeschön werd ich berichtigen (vorraussichtlich leider erst am freitag bin davor nicht zuhause)
Kein Problem.
Ich bin sogar der Meinung, das hier:
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 ;)
} else {
return SetExtensions ($hash, $cmdList, $name, $cmd, @arg);
}
WIFILED_Update( $hash );
return( undef );
}
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 :D
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
Bei welchem reading hat dich denn das gestört? im Moment wird das so bei RGB gemacht.
Ich beziehe das vor allem auf das HSV Reading
Zitat von: Pythonf am 04 Dezember 2014, 11:15:20
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.
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 :)
@Kuzl das war eigentlich das, was ich gemeint hatte. Würde das dann auch für HSV gehn?
Grüße Fabian
@Fabian: möglich ist es auf jeden fall, mal sehen was Betateilchen dazu sagt.
Zitat von: Kuzl am 05 Dezember 2014, 11:24:37
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.
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
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
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
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.
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 :D 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
Danke für die neue Version! :D
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
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 :D
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.
Du hast recht, ist mir das vorhin nicht aufgefallen oder ist das wirklich schon immer so?
Wenn eine statische Farbe gesetzt ist, wird vom LW12 für den Mode "29" zurückgegeben. Wenn die benutzerdefinierte Animation gesetzt ist 21.
Ich kam auf meine Frage, da ich die 29 für statische Farbe schon ein paar Tage kenne - und als Kriterium nutze.
Wenn die Animation die 21 hat, ist doch schon alles geklärt :)
Eventuell müsstest Du nur dafür sorgen, dass beim Setzen einer Animation der mode=21 als Reading erstmal direkt bei der Befehlsausführung geschrieben wird, damit der Wert bis zur ersten Aktualisierung schon stimmt.
Hast recht das fehlt dann noch
kann man den internal-timer eigentlich anhalten? damit mir der Statusupdate nicht bei einer Befehlsausführung reinpfuscht bzw. verlangsamt.
Ansonsten ist gestern einiges aufgeräumt worden :D so hat man jetzt auch keine Probleme mehr, wenn man die automatische aktualisierung ausschaltet. Auch heading und Doku hab ich aktualisiert somit wär dann alles fertig oder? Oder hat noch jemand Vorschläge / Ideen?
EDIT: Da fällt mir noch was ein: Das "dim" würde ich gerne mit der routine vom colorpicker machen, allerdings verstehe ich die Struktur die da verwendet wird nicht ganz.
was meinst du mit dim möchtest du mit dem colorpicker machen?
für dim wird normalerweise ein slider verwendet. dazu müsstest du in der antwort auf das 'set ?' das dim kommando so zurück geben:dim:slider,0,1,100das bedeutet dann das für dim ein slider mit einem bereich von 0-100 und schrittweite 1 verwendet werden soll.
gruss
andre
Bezüglich dim: Mir gefällt die jetzt bereits bestehende Lösung mit dem Slider ganz gut. Eine Kombination mit dem colorpicker halte ich nicht für sinnvoll, da sich mit dem Verändern des sliders automatisch auch der rgb-Wert ändert, was bisher korrekt funktioniert. Da sehe ich keinen Handlungsbedarf.
Zitat von: Kuzl am 10 Dezember 2014, 10:04:58
kann man den internal-timer eigentlich anhalten? damit mir der Statusupdate nicht bei einer Befehlsausführung reinpfuscht bzw. verlangsamt.
Ist doch ganz einfach:
Beim Betreten der _Set() löscht Du mit RemoveInternalTimer() den Timer und vor dem Verlassen setzt Du ihn einfach neu.
ich will das dim schon so beibehalten wie es ist, ich will nur die routine durch die im color.pm ersetzen. Hab mich falsch ausgedrückt. Andre hat schon mal versucht mir das zu erklären :D
Es wird bei set dim 20 ja der zugehörige RGB-Wert berechnet. Das würde ich gerne durch die Routine in der color.pm ersetzen.
Zitat von: betateilchen am 10 Dezember 2014, 12:13:46
Beim Betreten der _Set() löscht Du mit RemoveInternalTimer() den Timer und vor dem Verlassen setzt Du ihn einfach neu.
okay das würde gehen mach ich dann so rein :)
Mir ist auch ein Fehler im Modul aufgefallen:
Beim Setzen der Sättigung oder der Helligkeit bzw Dimmung über
set [..] hsv 30 0 100
set [..] hsv 30 10 0
set [..] dim 0
werden die Werte für den Farbton bzw auch für die Sättigung auf 0 gesetzt. Deshalb bleibt der Farbton bei komplettem runterdimmen auf 0 nicht erhalten, ebenso verhält es sich mit der Sättigung. Die Readings werden beim Übergang von 1 auf 0 auf 0 zurück gesetzt.
---
Ist eigentlich eine Implementierung einer Zeitkomponente z.B. für set [..] dim 100 10 vorgesehen oder gibt es die schon?
Grüße
Fabian
Da hast du recht, da ja dann keine farbe mehr angezeigt ist sondern alles aus ist, kann auch nicht auf eine Farbe zurückgerechnet werden. Ich werde mir da sobald ich Zeit finde mal was einfallen lassen. Zeitkomponenten sind bis jetzt noch nicht eingeplant oder gebaut dazu müsste dann wie beim wifilight modul über fhem permanent gesendet werden. Muss ich mir mal überlegen aber das würde wenn dann erst im weihnachtsurlaub kommen da hab ich bisschen zeit für sowas :D
Ich bin gegen die Zeitkomponente. Wer das haben will, soll seinen LW12 mit wifilight.pm betreiben. Ich bevorzuge WIFILED gerade deshalb, weil es bisher schlank, schnell und ressourcenschonend war - und auch bleiben sollte.
@Betateilchen - Das ist ein gutes Argument.Da Wifiled und Wifilight ja problemlos parallel betrieben werden können stimm ich dir da zu.
Bin ich mit euch einer Meinung dann lassen wirs weg ;)
Aber dem Problem mit dim0 nehm ich mir an, ich werd die Farbwerte wohl irgendwo zwischenspeichern müssen.
Hallo,
ich hab das ganze Modul jetzt mal auf die in der color.pm genutzten Struktur umgebaut. Dadurch sind die {helper} entfallen und die Brightness2Channels wird jetzt verwendet.
Wenn ich die auskommentierten Zeilen oben und unten (Timer löschen und setzen) einkommentiere, funktioniert die Aktualisierung nicht mehr. Mir ist schleierhaft warum, weiß wer rat?
Außerdem ist das mit dem dim 0 wohl doch nicht so einfach wie gedacht. Wenn mit der app ausgeschaltet wird haben wir ebenfalls keine Farben die wir speichern können. Hat da wer eine Idee wie das zu lösen wäre?
Viele Grüße
Kuzl
Moin,
ich hoffe, nicht irgendwo einen Hinweis übersehen zu haben ... wenn doch, dann bin ich für sachdienliche Links sehr dankbar :-).
Ich habe mir zwei iwy-Lampen (http://iwy-light.de/de/led-beleuchtung) geleistet. Diese kann ich über WIFI LED an- und abschalten und im Web-Interface kann ich die korrekten RGB- und HSV-Werte ablesen. Beim Ausführen eines Set-Kommandos á la fhem.pl 7072 "set LED_lampe rgb FF0000" ändert sich zwar der Wert im Web-Interface, aber die Farbe der Lampe ändert sich nicht. Bei anderen Kommandos (z.B. animate oder run) stürzt der komplette FHEM ab.
Habt Ihr einen Tipp für mich oder kann ich Euch irgendwelche helfenden Daten liefern?
Danke vorab und viele Grüße,
Andreas
Mich wunderts dass überhaupt so viel geht :D Wifiled ist für den lw12 geschrieben. Deine lampen könnten aber evtl von wifilight unterstützt werden.
Das hatte ich auch erwartet - aber mit WifiLight geht gar nichts.
Am besten schreibst du im thread von wifilight. Jörg baut dir das vll ein. WIFILED ist allerdings nur auf den lw12 spezialisiert
Danke. Ich habe das hier mal gemacht: http://forum.fhem.de/index.php/topic,18958.msg230092.html#msg230092 ...
Andreas
Hm, die IWY Lampe funktioniert ja genau wie die LW12 mit der App Magic Color. Sollte es da nicht ohne größeren Aufwand möglich sein sie mit WIFI LED zu betreiben ?
Finde die Lampe auch sehr interessant weil man sie direkt ohne zusätzliche Geräte ins WLAN Netz integrieren kann.
Gruß Holgi
Achso das hab ich nicht gewusst. Dazu würde ich die Daten benötigen, die die Lampe sendet. Aber von Wifilight wird sie anscheinend schon unterstützt. Wenn ich mal viel Zeit habe, kann ich mir natürlich den Quellcode von dort mal ansehen ;)
Vorsicht: Von der Magic Color App gibt es nicht ohne Grund zwei Versionen, die untereinander nicht austauschbar sind!
Sollten wir das Modul nicht einfach in 98_LW12.pm umbenennen, um solche Diskussionen zu beenden :P
Keine Schlechte Idee :D
Ich glaub das mach ich schnell - kleinen Moment
Denke dran, die entsprechenden Funktionsnamen auch zu ändern 8)
Sooooo geändert :D
Es muss jetzt natürlich de definition geändert werden, da das device jetzt vom Typ LW12 ist und nicht mehr WIFILED
@betateilchen: wenn du Zeit hast, kannst du mal über die zwei auskommentierten Bereiche schaun? ich finde keinen Fehler, aber wenn ich sie verwende geht die automatische Aktualisierung gar nicht mehr.
schau ich mir an, vermutlich aber erst morgen.
Das Problem hat was mit Deinem Umbau auf das COLOR.pm zu tun. Solange Du die Detailansicht eines LW12-Devices NICHT aufrufst, funktioniert auch der InternalTimer() problemlos.
Erst ab dem Moment, ab dem Du die Detailansicht im Browser hast, bricht die Aktualisierung ab.
Da musst Du wohl nochmal ran - sorry, bei dem COLOR-Modul kann ich Dir nicht weiterhelfen.
aha...
Durch den Umbau z.B. von set ... dim hast Du dafür gesorgt, dass vom color-Modul die LW12_Set() aufgerufen wird. Dabei wird als erstes der InternalTimer() gelöscht und nicht mehr neu gesetzt.
Du müsstest also dafür sorgen, dass dieses Löschen des Timers nicht erfolgt, wenn die _Set() aus dem color aufgerufen wird. Vermutlich betrifft das den colorpicker und dim
Okay dass das color-modul die _Set() aufruft klingt logisch. Allerdings sollte das doch eigentlich egal sein von wo die aufgerufen wird oder nicht? es wird doch so und so erst der Timer gelöscht und am ende wieder gestartet. Evtl hab ich da auch was nicht verstanden.
Allerdings was mir grad einfällt wenn die _Set() vorzeitig durch ein return verlassen wird, wird er nicht mehr gesetzt.
Das bedeutet ich müsste das löschen des Timers in jedes cmd am Anfang nach der Überprüfung setzen oder?
Viel einfacher wäre es vermutlich (ungetestet), den Timer direkt nach dem RemoveInternalTimer() beim Betreten der _Set() einfach wieder neu zu setzen. Die _Set() wird mit Sicherheit nicht länger laufen als das Updateintervall vorgibt ;)
Können wir die Diskussion im "neuen" Thread weiterführen? Der ist viel kürzer und das Forum reagiert dort mit kürzeren Antwortzeiten :)
http://forum.fhem.de/index.php/topic,30460.0.html