Wifilight.pm

blixx · 20 Juli 2015, 20:20:25

Hey zusammen,

ich habe bisher zwei milights im Einsatz und überlege zu LD382 (Ufo) zu wechseln.
In meinem Setup ist der Farbübergang relativ ruckelig. Liegt wohl auch an der Latenz zwischen fhem und Controller bzw. Empfänger.
Ist das mit dem LD382 anders? Gibt es einen LED-Controller, der Farbübergänge selbst hinbekommt - also ohne das fhem jede Farbe schickt.
Lasst mich raten: HUE?

herrmannj · 20 Juli 2015, 21:02:37

Hallo blixx,

die milights schaffen max 2-3 Wechsel pro Sekunde. Wenn zwei gleichzeitig faden halbiert sich das nochmal.

Der ld382 schafft 50 pro Sekunde, da hängt es davon ab wie schnell Dein fhem setup das packt. (Nicht nur cpu abhängig! Liegt auch an anderen modulen).

Normalerweise sieht man das bei den milights aber nicht ganz so doll weil die von sich aus ein leichtes faden bei Farbwechseln machen.

vg
joerg

blixx · 20 Juli 2015, 21:38:03

Danke, Jörg! Das ist doch schonmal gut:)

Amenophis86 · 26 Juli 2015, 12:18:00

Zitat von: lukasbastelpeter am 29 Mai 2015, 18:45:17
Also, es muss eigentlich an der Ausgabe von FHEM liegen... ?!

Habe das gleiche Problem. Kann den LD382 einmal zum laufen bekommen, sobald ich ihn allerdings vom Netz nehme und wieder mit Strom versorge, kann FHEM nicht mehr drauf zugreifen. Ich muss FHEM jedes Mal neu starten. Weiterhin kann ich auch nicht auf die WebUI zugreifen. Passwort und User werden akzeptiert, jedoch kommt ein 404 Fehler. Ist das UFO defekt oder mache ich etwas falsch?

Gefühlt liegt es an FHEM und nicht am UFO. Wenn ich das ganze mit der APP steuere funktioniert es einwandfrei. Kann ihn vom Strom nehmen, wieder rein stecken und immer noch steuern. Habe ihn natürlich nach dem Versuch mit der APP wieder mehrfach und lange vom Strom getrennt, dass dieser Zugriff weg ist. Trotzdem will FHEM ihn nach einem Moment ohne Strom nicht mehr ansteuern.

herrmannj · 26 Juli 2015, 12:30:04

Hi,

ping das UFO mal VOM FHEMHOST aus an. Dann vom Strom nehmen, wieder rein stecken und nochmal an-pingen.

vg
joerg

edith: was steht im log wenn es NICHt geht ?

Ascos · 26 Juli 2015, 13:55:46

Das Problem hatte ich auch. Jedesmal, wenn ich die UFOs vom Strom genommen habe, konnte ich sie via FHEM nicht mehr ansprechen.
Habe es dann so gelößt, das ich den Strom nicht mehr wegnehme, sondern via FHEM ausschalte.

Amenophis86 · 26 Juli 2015, 15:36:32

Zitat von: herrmannj am 26 Juli 2015, 12:30:04
ping das UFO mal VOM FHEMHOST aus an. Dann vom Strom nehmen, wieder rein stecken und nochmal an-pingen.

Kein Paket verloren, weder während ich ihn steuern kann, noch danach:
Pingzeit ist zwar relativ lange zwischen 9 - 50ms, aber es kommt alles an.

Zitat von: herrmannj am 26 Juli 2015, 12:30:04
edith: was steht im log wenn es NICHt geht ?

Im Log steht der normale Befehl, als ob alles funktionieren würde. Habe mal ein und ausgeschaltet
über das Lampensymbol und direkt eine Farbe gewählt. Nichts kam an aber im Log steht kein Fehler:

Zitat
2015.07.26 15:34:19 3: WZ.LEDStripe RGBW LD382A set on (0, 0, 100) 0
2015.07.26 15:34:19 3: WZ.LEDStripe set HSV 0, 0, 100 with ramp: 0, flags:
2015.07.26 15:34:21 3: WZ.LEDStripe RGBW LD382A set off 0
2015.07.26 15:34:21 3: WZ.LEDStripe RGBW LD382A dim 0 0
2015.07.26 15:34:21 3: WZ.LEDStripe set HSV 0, 0, 0 with ramp: 0, flags:
2015.07.26 15:34:25 3: WZ.LEDStripe set HSV 124, 72, 100 with ramp: 0, flags:

Zitat von: Ascos am 26 Juli 2015, 13:55:46
Das Problem hatte ich auch. Jedesmal, wenn ich die UFOs vom Strom genommen habe, konnte ich sie via FHEM nicht mehr ansprechen.
Habe es dann so gelößt, das ich den Strom nicht mehr wegnehme, sondern via FHEM ausschalte.

Das kann ja nicht das Lösungsproblem sein

Das Ufo wird hinter eine Schaltbarensteckdose stecken, daher muss es gehen.

Jetzt kommt die komplette Verwirrung noch dazu. Ich habe gerade festgestellt, dass nach etwa 16 Minuten das UFO auf einmal wieder steuerbar ist. Geändert wurde am PI nichts. Ich habe
aus versehen nochmal geklickt und dann gemerkt, dass er angeht und mich gewundert. Also habe ich den Fehler reproduziert und so lange jede Minute geklickt, bis es wieder ging. Und siehe da,
nach ca. 16 Minuten kann ich es wieder normal steuern. Hab zwar keine Ahnung, ob es bei der Fehlersuche hilft, aber interessant ist es alle mal.

herrmannj · 26 Juli 2015, 16:44:13

Hi

die UFO und die LW12 haben in den WLAN Modulen mehrere bugs. Bekannt zb das ein Wechsel des AP Probleme mit sich bringt.

Wenn von Seiten fhem kein Fehler messbar ist (ping geht, Befehle werden vom WLAN Modul des UFOs entgegengenommen) kann man da schlicht von modulseite aus nichts machen.

Die App verhält sich mglw anders weil sie jedesmal eine neue Verbindung aufbaut, das ist jedoch keine option weil das viel zu viel Zeit während einer Transition beansprucht.

Nochmal: wenn es auf fhem Seite messbar ist kann ich es beseitigen - andernfalls nicht.

vg
joerg

Amenophis86 · 26 Juli 2015, 16:52:42

Kann ich verstehen.

Was hälst du von der Idee, dass du über ein Attribut die Möglichkeit einbaust, dass man sich alle X Minuten neu verbindet. Im Sinne, wenn jemand das gleiche Problem bemerkt,
dass er in einem Attribut einstellt, dass ich FHEM alle X Minuten neu verbindet.
Eine andere Möglichkeit wäre, dass man direkt einen Befehl absetzen kann zum neu verbinden. Dann könnte ich quasi meine Schaltung so einstellen:

- FHEM soll meine Steckdose einschalten
- FHEM soll dem Modul sagen verbinde dich neu
- FHEM kann das UFO ab jetzt schalten

herrmannj · 26 Juli 2015, 16:53:15

Ihr könnt nochmal eins probieren. Nach einem "Stromausfall" explizit "on" senden.

vg
joerg

edith: überschnitten. Das geht aber in die Richtung. Das modul checkt ob das UFO den Befehl per TCP/IP entgegennimmt. Wenn nein wird wiederholt, danach wird sowieso schon neu verbunden.

Könnte aber sein das dass UFO intern nach Stromausfall "aus" ist, dann musst Du explizit "on" senden um es einzuschalten. Das könntest Du mit der Steckdose "on" koppeln ...

Amenophis86 · 26 Juli 2015, 17:05:06

Ne, dann scheint es wirklich ein internes Problem des UFO zu sein. Habe es ja jedes Mal direkt mit klicken auf die Lampe zum Einschalten probiert bzw mit direkter Eingabe in die Kommandozeile. Hilf leider nichts.

Habe mir noch ein UFO bestellt, welches die Tage kommen sollte. Ist hier der Fehler nicht, werde ich es einfach zurück schicken und es umtauschen. Aber vielen Dank für die schnelle Hilfe

herrmannj · 26 Juli 2015, 17:13:47

hast Du denn mit "on", evtl mehrfach "on/off" probiert ?

vg
Joerg

DJ_SAMMY190 · 26 Juli 2015, 19:05:25

Haste schon mal.in die.log geschaut ob da irgendwas steht mit no connection. Reconnect giving up?

Gesendet von meinem Z30 mit Tapatalk

anfichtn · 26 Juli 2015, 19:13:30

Erzähle mal was zur ufo-Konfiguration, insbesondere Thema Wlan. Ggf noch dein wlan-Setup insbesondere sind hier repeater gerne mal Schlafmützen....

Ich hatte dieses Phänomen auch mal, da lag es daran, dass das UFO den falschen ap erwischt hat und dann nur bei 10% wlan-signal lag...

Amenophis86 · 26 Juli 2015, 21:47:04

WLan sieht wie folgt aus:

Befindet sich im gleichen Lan wie der PI. Es gibt noch ein weiteres WLan, wo aber kein Zugriff drauf besteht vom UFO aus, das kann es also nicht sein. Laut Speedport ist das UFO auch
immer erreichbar und kann von jedem PC / Pi etc angepingt werden. Egal, ob es das Licht schaltet, oder nicht.

Wie gesagt, im Filelog steht nur, dass der Befehl normal gesendet wurde. Siehe mein anderer Post. Nirgends ist ein Fehler zu erkennen.

Habe auch schon mehrfach on und off gesendet und trotzdem kommt es zu dem Fehler. Manchmal geht es nach einem "Strom Stop" direkt und manchmal macht er es gar nicht. Bzw. wie festgestellt
erst nach einer gewissen Zeit. Letztes Mal waren es 16 Minuten, bis das UFO wieder Steuerbar war.