Wifilight.pm

[herrmannj]

ok, aber das Thema ist nicht das der slider generell nicht funktioniert sondern das er im dashboard nicht funktioniert ? richtig ?

[P.A.Trick]

Genau so ist es! Vielleicht versuchst du mal ein

Code Auswählen Erweitern

define dashtest dasboard und definierst eine Gruppe z.B. Schalter im LED Schalter.
Dann unter Details im Dashboard die Gruppe unter tabgroup1 "Schalter" hinzufügen.
Vielleciht klappt es bei dir ja auch nicht?

[jenscz]

Hi Steffen, Hi Jenscz
Da liegst Du richtig: der LW12 hat einen TCP timeout. Allerdings fange ich das im Modul schon ab. Das re-connect wurde von zwei usern getestet und beide haben ein OK gegeben. Ich schau mir den code Teil nochmal an. Schaut Ihr bitte solange in log:

Bei verbose 3 steht im Fall des re-connects im log:

Code Auswählen Erweitern

"... low level cmd queue send ERROR ... (trying to reconnect)"
und wenn das schief-geht kommt danach (verbose 1)

Code Auswählen Erweitern

"... low level cmd queue send ERROR ... (giving up)"

Schaut mal bitte ob es eine Korrelation der ersten Meldung zu "Befehl kommt nicht an" gibt.

Ich werde das testen. Kann es sein, dass der LW12 auch UDP Pakete annimmt? Ich meine mich erinnern zu können, dass die iPhone App das per UDP macht.
Wäre dann zumindest Verbindungslos und man müsste nicht versuchen die Verbindung zu halten.

[jenscz]

So, verbose 5, LW12 ist "on" und soll auf "off" gehen:

Code Auswählen Erweitern

2014.04.23 23:09:19 3: Licht_WZ_RGB RGB LW12 set off 0
2014.04.23 23:09:19 3: Licht_WZ_RGB RGB LW12 dim 0 0
2014.04.23 23:09:19 4: Licht_WZ_RGB hsv transition without ramp routed to direct settings, hsv 30, 100, 0
2014.04.23 23:09:19 4: Licht_WZ_RGB high level cmd queue add hsv/ctrl 30, 100, 0, ctrl , targetTime 1398287359.2012, qlen 1
2014.04.23 23:09:19 5: Licht_WZ_RGB high level cmd queue exec dropper delay: -0.00163888931274414
2014.04.23 23:09:19 4: Licht_WZ_RGB high level cmd queue exec hsv 30, 100, 0, delay 50, hl qlen 1, ll qlen 0, lock 0
2014.04.23 23:09:19 4: Licht_WZ_RGB RGB LW12 set h:30, s:100, v:0
2014.04.23 23:09:19 5: Licht_WZ_RGB low level cmd queue add 56000000aa, qlen 1
2014.04.23 23:09:19 5: Licht_WZ_RGB low level cmd queue send 56000000aa, qlen 1
2014.04.23 23:09:19 5: Licht_WZ_RGB low level cmd queue add 00, qlen 2
2014.04.23 23:09:19 4: Licht_WZ_RGB high level cmd queue ask next 1398287359.44193
2014.04.23 23:09:19 4: Licht_WZ_RGB processEvent: , progress:

Macht es aber nicht. Erst beim 2. mal:

Code Auswählen Erweitern

2014.04.23 23:13:05 3: Licht_WZ_RGB RGB LW12 set off 0
2014.04.23 23:13:05 3: Licht_WZ_RGB RGB LW12 dim 0 0
2014.04.23 23:13:05 4: Licht_WZ_RGB hsv transition without ramp routed to direct settings, hsv 30, 100, 0
2014.04.23 23:13:05 4: Licht_WZ_RGB high level cmd queue add hsv/ctrl 30, 100, 0, ctrl , targetTime 1398287585.01784, qlen 1
2014.04.23 23:13:05 5: Licht_WZ_RGB high level cmd queue exec dropper delay: -0.00149011611938477
2014.04.23 23:13:05 4: Licht_WZ_RGB high level cmd queue exec hsv 30, 100, 0, delay 50, hl qlen 1, ll qlen 0, lock 0
2014.04.23 23:13:05 4: Licht_WZ_RGB RGB LW12 set h:30, s:100, v:0
2014.04.23 23:13:05 5: Licht_WZ_RGB low level cmd queue add 56000000aa, qlen 1
2014.04.23 23:13:05 5: Licht_WZ_RGB low level cmd queue send 56000000aa, qlen 1
2014.04.23 23:13:05 3: Licht_WZ_RGB low level cmd queue send ERROR 56000000aa, qlen 1 (trying to reconnect)
2014.04.23 23:13:05 5: Licht_WZ_RGB low level cmd queue add 00, qlen 2
2014.04.23 23:13:05 4: Licht_WZ_RGB high level cmd queue ask next 1398287585.26817
2014.04.23 23:13:05 4: Licht_WZ_RGB processEvent: , progress:

[herrmannj]

Kann es sein, dass der LW12 auch UDP Pakete annimmt?

ja, könnte man im lw12 umstellen, allerdings ist die Ursache ja der im lw12 eingestellte tcp - timeout. Wenn man eh auf dem lw12 ist würde ich eher den timeout austellen (wär jetzt ein q&d work-around!). tcp hat ja zumindest den Vorteil das fhem sieht wenn der lw12 aus ist, bei udp bekommt fhem das garnicht mit. Aus User-Sicht wärs schöner wenn das out-of-the box funktioniert - ist ja auch nicht jedermanns Sache da erstmal per web-if drauf zu konfigurieren.

Danke für Dein log!

Da funktioniert der re-connect  fast  wie geplant. Beim zweiten mal schlägt er an und baut die Verbindung neu auf. Ich denke ich verstehe auch warum er das beim ersten mal nicht macht. Aus performance gründen ist der socket non-blocking. Das bedeutet das fhem (bzw modul) nicht erst auf die Rückmeldung wartet sondern schon weitermacht. Aus performance Sicht eigentlich auch gut 

Da ich keinen lw12 habe:

versuch doch mal bitte die Zeilen #161/2 (das gleiche bitte auch in line #1855/6) von

Code Auswählen Erweitern

        Timeout => 1,
        Blocking => 0,

auf

Code Auswählen Erweitern

        Timeout => .01,
        Blocking => 1,

zu ändern. Wobei ich mir so ad-hoc echt unsicher bin wie klein die time-out Angabe sein darf (hier jetzt 10ms).

Bin mal gespannt ob das so geht und welchen Einfluss das auf die performance beim fade hat ..

vg
jörg

[SirUli]

Hi zusammen,

ich habe diesen Thread aufmerksam nun durchgelesen, herzlichen Dank zunächst für das Modul. Heute kam meine Bridge V4 endlich an, dazu hatte ich mir zwei mal den "Milight RGB/Weiß LED Streifen Controller 4 Zonen" (so ist er im Wiki gerade bezeichnet) gekauft. Zum Bestellzeitpunkt hatte ich das Wiki noch nicht gesehen, sonst hätte ich mir die LW12 zugelegt :/

Zunächst hatte ich also meine Controller mit der Bridge gepaart, habe diese Bridge in mein WLAN umgehoben - und nach einer Weile konnte ich keine Änderungen mehr an die Lampen absetzen. Wenn ich die Bridge neu gestartet habe, lief es wieder eine Weile. Das Problem konnte ich dann nicht weiter eingrenzen, da anscheinend meine beiden Controller kurz nacheinander jetzt gestorben sind.

Folgende Befehle hatte ich abgesetzt:

• delete milight1
• define milight1 WifiLight RGBW2 bridge-V3:192.168.133.3
• set milight 1 on -> Kurzer Lichtblitz (hatte ich schon mal bei einem on), dann dunkel
• set milight1 HSV 120,100,0 -> Blieb dunkel

Ich dachte erst, es hätte wieder was mit Kanal 1 und 2 zu tun, daher hatte ich den anderen angeschlossen -> gleiches Schauspiel.

Aktuell kann ich nun weder per App noch per FHEM die Controller steuern, die Bridge kann ich jedoch pingen und ist in der App auch ansprechbar. Zudem Leuchten die Strips nicht mehr wild auf, wenn ich den Strom am Strip Controller einschalte.

Das Netzteil liefert immer noch 12V @ 3300mAh stabilisiert, das wäre also theoretisch nicht schuld. Hatte auch grad ein zweites mit nur 1,5A ausprobiert - half auch nicht.

Habt ihr noch eine Idee, wie man das in den Griff bekommt? Gibt es in den LED Strip Controllern auch einen Hard-Reset? Oder sind die Dinger hinüber?

Vielen Dank im Voraus!

Viele Grüße,
Uli

[herrmannj]

Hi Uli,

herzlich Willkommen! 

die bridge kannst Du resetten (laaaange drücken), bei den controllern ist mir kein Weg bekannt.

Das Netzteil liefert immer noch 12V @ 3300mAh stabilisiert, das wäre also theoretisch nicht schuld. Hatte auch grad ein zweites mit nur 1,5A ausprobiert - half auch nicht.

12V am stripe - nicht an der bridge. Machst Du vermutlich auch so ... zur Sicherheit sag ichs trotzdem.

Aktuell kann ich nun weder per App noch per FHEM die Controller steuern, die Bridge kann ich jedoch pingen und ist in der App auch ansprechbar. Zudem Leuchten die Strips nicht mehr wild auf, wenn ich den Strom am Strip Controller einschalte.

die App findet die bridge wenn Du sie neu suchen läßt - richtig ? Dann liegt es vermutlich nicht an der bridge obwohl da theoretisch noch der rf out 'ne macke haben könnte. Das aber gleich 2 controller kaputt sind wär schon komisch. 

hast Du Zugriff auf eine FB ? Die geht ohne bridge direkt auf die controller. Die def sieht ansonsten richtig aus.

schon irgendwie komisch. ...

vg
Jörg

[jenscz]

Auf ein neues. Entsprechende Änderungen vorgenommen, "shutdown restart"

LW12 on

2 Stunden gewartet und ein off gesendet:

Code Auswählen Erweitern

2014.04.25 00:01:12 3: Licht_WZ_RGB RGB LW12 set off 0
2014.04.25 00:01:12 3: Licht_WZ_RGB RGB LW12 dim 0 0
2014.04.25 00:01:12 4: Licht_WZ_RGB hsv transition without ramp routed to direct settings, hsv 30, 100, 0
2014.04.25 00:01:12 4: Licht_WZ_RGB high level cmd queue add hsv/ctrl 30, 100, 0, ctrl , targetTime 1398376872.93851, qlen 1
2014.04.25 00:01:12 5: Licht_WZ_RGB high level cmd queue exec dropper delay: -0.00159096717834473
2014.04.25 00:01:12 4: Licht_WZ_RGB high level cmd queue exec hsv 30, 100, 0, delay 50, hl qlen 1, ll qlen 0, lock 0
2014.04.25 00:01:12 4: Licht_WZ_RGB RGB LW12 set h:30, s:100, v:0
2014.04.25 00:01:13 5: Licht_WZ_RGB low level cmd queue add 56000000aa, qlen 1
2014.04.25 00:01:13 5: Licht_WZ_RGB low level cmd queue send 56000000aa, qlen 1
2014.04.25 00:01:13 5: Licht_WZ_RGB low level cmd queue add 00, qlen 2
2014.04.25 00:01:13 4: Licht_WZ_RGB high level cmd queue ask next 1398376873.13935
2014.04.25 00:01:13 4: Licht_WZ_RGB processEvent: , progress:

LW12 bleibt an

noch mal ein off hinterher

Code Auswählen Erweitern

2014.04.25 00:03:30 3: Licht_WZ_RGB RGB LW12 set off 0
2014.04.25 00:03:30 3: Licht_WZ_RGB RGB LW12 dim 0 0
2014.04.25 00:03:30 4: Licht_WZ_RGB hsv transition without ramp routed to direct settings, hsv 30, 100, 0
2014.04.25 00:03:30 4: Licht_WZ_RGB high level cmd queue add hsv/ctrl 30, 100, 0, ctrl , targetTime 1398377010.13128, qlen 1
2014.04.25 00:03:30 5: Licht_WZ_RGB high level cmd queue exec dropper delay: -0.00206112861633301
2014.04.25 00:03:30 4: Licht_WZ_RGB high level cmd queue exec hsv 30, 100, 0, delay 50, hl qlen 1, ll qlen 0, lock 0
2014.04.25 00:03:30 4: Licht_WZ_RGB RGB LW12 set h:30, s:100, v:0
2014.04.25 00:03:30 5: Licht_WZ_RGB low level cmd queue add 56000000aa, qlen 1
2014.04.25 00:03:30 5: Licht_WZ_RGB low level cmd queue send 56000000aa, qlen 1
2014.04.25 00:03:30 3: Licht_WZ_RGB low level cmd queue send ERROR 56000000aa, qlen 1 (trying to reconnect)
2014.04.25 00:03:30 5: Licht_WZ_RGB low level cmd queue add 00, qlen 2
2014.04.25 00:03:30 4: Licht_WZ_RGB high level cmd queue ask next 1398377010.38452
2014.04.25 00:03:30 4: Licht_WZ_RGB processEvent: , progress:

[SirUli]

Hi Jörg,

zunächst danke für deine Antwort!

herzlich Willkommen! 

Danke danke Bin schon an sich eine Weile FHEM-User und im Wiki auch gelegentlich als Autor unterwegs - die meisten Dinge habe ich bisher ohne Support hinbekommen

die bridge kannst Du resetten (laaaange drücken), bei den controllern ist mir kein Weg bekannt.

Das hatte ich heute sogar schon mal gemacht, da ich diese nicht mehr gefunden hatte. Diesmal finde ich diese wenigstens noch. Habe auch gerade mal zurückgesetzt - finde ich immer noch - Stripe geht aber auch nicht mehr.

12V am stripe - nicht an der bridge.

Genau. 5V USB-Ladegerät an der Bridge und 12V am Stripe-Controller

Die App findet die bridge wenn Du sie neu suchen läßt - richtig?

Genau. Ich habe auch grad mal die Bridge zurückgesetzt - wird sofort auch ein WLAN gefunden, jedoch koppelt sich da nix mit dem Controller - weder mit lange halten von einem Kanal-Ein/Ausschalter noch mit vielen Klicks auf den gleichen Schalter noch mit dem Koppeln-Button... :/

hast Du Zugriff auf eine FB ?

Die hatte ich dummerweise weggelassen - wollte von diesen Fernbedienungen weg - im Nachhinein eine dumme Idee. Die paar Euro wären auch noch drin gewesen.

Was ich mittlerweile noch gemacht hatte:

• LED Strip Controller geöffnet - nix böses zu sehen
• LED Stripe Controller mal durchgemessen - am Stripe kommt nix an
• LED Stripe mal an einem normalen Controller angeschlossen -> Funktioniert

Interessanterweise (weiss nicht ob das so rauskam): Die ersten paar Minuten lief noch alles - die Fehle kamen erst später

Danke schon mal für deine Mühen!

Viele Grüße,
Uli

[herrmannj]

@jenscz

dasch ja doof ... 

in diesem fall würde das os beim ersten mal nicht melden das kein ack zurück kommt .... ich schau mir den code an dieser ecke nochmal genau an und bau eine extra logging funktion ein um das return vom send zu sehen.

Welches host-os hat fhem bei Dir ?

Ich kenn das web-if vom lw12 nicht - hab mir aber sagen lassen das man im web-if den timeout ausschalten kann. Das beseitigt erstmal das Thema bei Dir.

Wär toll wenn Du trotzdem für Tests zur Verfügung setehn würdest.

vg
Jörg

[herrmannj]

Hi Uli,

na, viel kannste da vermutlich nicht machen. Das pairen bzw die fw der bridge sind zwar echt bescheiden - aber wenn gar-nichts geht ist defekt möglich.

Die bridge muss, wenn der reset funktioniert, aus Deinem wlan verschwunden sein und wieder ihr eigenes wlan aufmachen. Dann hast Du dort definitiv Werkszustand und kannst mit der App nochmal draufgehen (also das smartphone in das adhoc der bridge nehmen). Auf den controllern selbst lässt sich nichts konfigurieren. Wenn das also nicht hilft und der Händler in DE war, tausch sie aus.

vg
Jörg

[jenscz]

@jenscz

dasch ja doof ... 

in diesem fall würde das os beim ersten mal nicht melden das kein ack zurück kommt .... ich schau mir den code an dieser ecke nochmal genau an und bau eine extra logging funktion ein um das return vom send zu sehen.

Welches host-os hat fhem bei Dir ?

Ich kenn das web-if vom lw12 nicht - hab mir aber sagen lassen das man im web-if den timeout ausschalten kann. Das beseitigt erstmal das Thema bei Dir.

Wär toll wenn Du trotzdem für Tests zur Verfügung setehn würdest.

vg
Jörg

Kein Problem, immer gerne.

OS: RasBMC (XBMC abgeschaltet) auf natürlich Rasberry

Timeout kann auf 600 Sec hochgestellt werden. Um anderen Usern zu helfen würde ich aber gerne erst mal weiter mit dir testen. Wenn es gar nicht anders geht können wir am Timeout rumspielen.

[herrmannj]

Timeout kann auf 600 Sec hochgestellt werden. Um anderen Usern zu helfen würde ich aber gerne erst mal weiter mit dir testen. Wenn es gar nicht anders geht können wir am Timeout rumspielen.

ja genau, Danke. Soll nur temporär sein damit du nicht Abends/ morgens immer zweimal drücken musst. 600 sekunden sind ja aber zu wenig um den Effekt in der Praxis zu nehmen.

Schauen wir mal.

Am Ende wird alles gut und wenn noch nicht alles gut ist, dann ist es nicht das Ende.

Danke nochmal für Tests
Jörg

[der-Lolo]

ich kann das von Jenscz beschriebene problem hier übrigens auch sehen mit einem LW12.
Bei mir war es aber bis jetzt so das zuverlässig abgeschaltet wird - an blieb das Licht noch nie, es dauert aber ne weile bis der Controller ausschaltet.

[SirUli]

Hi Jörg,

danke dir für deine Hilfe!

Die bridge muss, wenn der reset funktioniert, aus Deinem wlan verschwunden sein und wieder ihr eigenes wlan aufmachen.

Das hat soweit geklappt. Leider kann man die LED-Strip Controller wohl nicht resetten... schade.

Wenn das also nicht hilft und der Händler in DE war, tausch sie aus.

Leider nein :/ Sieht mir momentan eher danach aus, als wenn der Mist in den Müll fliegt...

Viele Grüße,
Uli