Wifilight.pm

[MrStonedfire]

Klappt danke

[herrmannj]

auch weiß ? Mischt der ?

[MrStonedfire]

Ja auch weiß, mir ist auch aufgefallen das wenn man länger auf der FB an drückt wird es auch weiß.

[herrmannj]

cool. So war der Plan - schön zu hören das es so auch klappt.

Danke und vg
Joerg

[ext23]

Nabend, ich hab mir auch mal dieses UFO bestellt, LD382A, RGBW.

Zwei Fragen:
- Wenn ich off und anschließend on setze ist danach nicht mehr der alte Farbwert da sondern es wird nur weiß, soll das so?
- Ich habe das UFO kurz Stromlos gemacht, jetzt kann ich mit FHEM das UFO nicht mehr bedienen, was könnte das sein? Nach einem FHEM Neustart geht es wieder.

Gruß
Daniel

[ujaudio]

nach off kommt weiß. das ist schon oft diskutiert worden. anstelle von off dim 0 und dann dim 100 bewirkt das gleiche, nur bleibt die Farbe erhalten

Es geht bei mir auch ohne restart - dauert nur etwas, mal mehr mal weniger (meist leider mehr )

[Dr. Boris Neubert]

Hallo,

- Ich habe das UFO kurz Stromlos gemacht, jetzt kann ich mit FHEM das UFO nicht mehr bedienen, was könnte das sein? Nach einem FHEM Neustart geht es wieder.

ich habe das gleiche Problem. Allerdings bringt ein Neustart gerade nichts. Auch kein Entfernen und Neuanlegen des Device. Das stützt nicht meine Hypothese, dass die Socket-Verbindung abraucht und neu aufgebaut werden müsste. De facto bekomme ich derzeit gar keine Reaktion auf meine Schaltversuche aus FHEM heraus, obwohl das UFO vom FHEM-Server aus pingbar ist. Die Magic-Home-App funktioniert, obgleich diese auch ab und an die Verbindung verliert und dann manchmal nur nach Neustart wieder Kontakt zum UFO aufnimmt. Am Wochenende war das Teil nicht so widerspenstig.

Jörg, ist Dir die Problemstellung bekannt? Kann ich was zur Lösung beitragen? UFO und LED-Streifen sind hier noch in Teststellung auf meinem Schreibtisch.

Grüße
Boris

Code Auswählen Erweitern

define LED1 WifiLight RGBW LD382:led1.example.com
attr LED1 room Beleuchtung
attr LED1 devStateIcon {Color_devStateIcon(ReadingsVal($name,"RGB","000000"))}
attr LED1 webCmd RGB:RGB 000000:RGB FF0000:RGB 00FF00:RGB 0000FF:RGB FFFFFF
attr LED1 widgetOverride RGB:colorpicker,RGB

[ext23]

"Es geht bei mir auch ohne restart - dauert nur etwas, mal mehr mal weniger (meist leider mehr )"

Was heißt denn "mehr"? Also ich kann es immer wieder reproduzieren, aber 5 Minuten warten bringt nichts. Ein Modul reload auch nicht. Mit einem FHEM restart klappte es bis jetzt aber immer (bei mir).

Es gehen auch keine Pakete raus, hab mal ein tcpdump laufen lassen. Netstat sagt:
tcp        0    336 192.168.0.50:40055      192.168.0.91:5577       VERBUNDEN

Das mit on= weiß und dim etc. ist OK, sprich works as designed, habs nur nicht im Wiki gelesen gehabt.

/Daniel

[arne.dien]

Ich habe die Erfahrung gemacht, wenn ich das Ufo mit der App ausgeschaltet habe, konnte ich von Fhem nichts mehr machen. Mit der App wieder eingeschaltet und dann hat's auch wieder mit Fhem geklappt.
Vielleicht hilft's ja...

[ext23]

Wenn ich die TCP Session kille, geht es sofort wieder:

tcpkill -i eth0 port 40055

/Daniel

[herrmannj]

Moin,

ich kann ja mal einen generellen Status geben weil ich im Augenblick so ein wenig in Richtung eines WifiLight 2.0 denke.

Vielleicht erst mal zu den Socket und Stromlos.

Ja, ist bekannt. Leider nicht ganz trivial. Generelle Empfehlung (heute): lasst das Dings am Strom. Verbraucht ausgeschaltet auch nicht mehr als eine Funksteckdose.

Zum "Problem" das dazu führt: Eigentlich besteht es aus zwei Teilen. Der erste liegt in der kruden FW der controller, der zweite im OS. Boris Verdacht ist richtig. In den Fällen die ich untersucht habe bleibt der Socket im wait ack oder time_wait hängen. Aus OS Sicht ist der socket damit noch lebendig. Wenn er richtig tot ist wird er sofort neu aufgebaut - daher hilft es auch einfach einige Minuten abzuwarten dann lässt das OS den Socket sterben.

Generell taucht es eben nur auf wenn man die controller vom Strom nimmt, was die meisten nicht machen. Daher auch keine große Prio.

Ich habe mal in die Richtung gearbeitet den Wait ACK zu erkennen um den Socket dann automatisch zu killen. Ist aber eher tricky und sehr vom OS abhängig. Mittlerweile tendiere ich dazu SO_Linger zu setzen, das hat in ersten Tests ganz gut funktioniert.

Was passiert noch in den Kellerlaboren :

Jürgen hat mal einen Punkt identifiziert der zum aus-bremsen von FHEM führt wenn man Transitions auf einen nicht existierenden (zb stromlosen) TCP controller laufen lässt. Das entsteht weil der connect zwar nur ganz kurz, aber doch blockt. Ich habe eine Möglichkeit gefunden den connect non-blocking zu machen. Wird also eingebaut.

Des weiteren ist Wifilight halt historisch gewachsen. Am Anfang habe ich das ja für die milights geschrieben und dann nach und nach viele weitere controller dazu genommen. Dabei ist aber die Architektur dann ein wenig zu kurz gekommen. Es gibt mittlerweile eine ganze Menge code der unnötigerweise mehr oder weniger redundant ist. Da fege ich mal richtig durch

Der letzte (und eigentliche "2.0") Teil:

Ich habe angefangen die Transitions in einen eigenen thread auszulagern. Bisher teilen sich die Transitions die Rechenzeit mit allen anderen modulen. Daher kommt die häufige Beobachtung das transitions auf jungfräulichen Systemen sauschnell laufen. Im Produktiv System sorgen aber andere Module dann häufig für Ruckler.

An dem Auslagern in einen eigenen thread hängen einige saukomplexe Synchronisationsprobleme. Die gute Nachricht dazu lautet das viele Fragestellungen dazu Überschneidungen zu der Weiterentwicklung von fronthem haben und ich einen echt großen Teil davon auch schon gelöst habe. Von daher sieht das eigentlich ganz gut aus und ist deswegen auch so für die "next version" geplant. Kann natürlich immer noch einiges auftauchen aber grundsätzlich sind die großen Brocken da alle aus dem Weg geräumt.

Wenn das alles so läuft gehe ich davon aus das man jeden controller mit der max framerate und extrem fließend ansteuern können wird. Im Rahmen dessen was halt geht - eine milight bleibt halt eine Schnecke aber die UFOs, die DMX ooder die Sunricher sollten dann alle mit 50Hz plus angesteuert werden können.

Das mal so als "Wasserstandsmeldung". Generell habe ich nie die Menge fhem dev Zeit die ich mit eigenlich Wünsche. Keine Erwartungen für den kommenden Monat bitte

vg
joerg

[ext23]

Generell taucht es eben nur auf wenn man die controller vom Strom nimmt, was die meisten nicht machen. Daher auch keine große Prio.

Nur so als Einwurf, was ist mit "unterbrochenem" WLAN?

Meins geht wegen E-Smog nachts aus, aber gut das ist kein Problem weil da die Sessions eh gekilled werden. Bei mir sowieso kein Problem ich hab mir das UFO nur mal gekauft zum Spielen, ich warte noch auf eine LAN Version, ansonsten bleibt bei mir alles bei DMX Also Prio 3 passt schon

/Daniel

[herrmannj]

Nur so als Einwurf, was ist mit "unterbrochenem" WLAN?

Meins geht wegen E-Smog nachts aus, aber gut das ist kein Problem weil da die Sessions eh gekilled werden. Bei mir sowieso kein Problem ich hab mir das UFO nur mal gekauft zum Spielen, ich warte noch auf eine LAN Version, ansonsten bleibt bei mir alles bei DMX Also Prio 3 passt schon

/Daniel

Hallo Daniel,

Du hast recht, ist das gleiche Ding.

Vereinfacht gesagt behauptet das OS gegenüber Wifilight das der controller über den Socket noch erreichbar wäre obwohl er es nicht mehr ist. Wie gesagt, ich denke das sich da in absehbarer Zukunft Abhilfe schaffen lässt.

vg
joerg

[Dr. Boris Neubert]

ich kann ja mal einen generellen Status geben weil ich im Augenblick so ein wenig in Richtung eines WifiLight 2.0 denke.

Danke, Joerg, für die Ausführungen. Dann werde ich bald den LED-Streifen mit Zuversicht an die gewünschte Stelle kleben.

Das UFO hat dann übrigens gestern abend irgendwann von selbst wieder Befehle angenommen.

Viele Grüße
Boris

[herrmannj]

So ist es. Für alle die über die Suche hier landen: Einfach ca20 min warten wenn es zu dieser Ausnahmesituation kommt.

Vg
Joerg