Wifilight.pm

[budy]

Schalte ich den Kontroller  an und wieder aus ... funktioniert FHEM (genauer das Modul) nicht mehr. Einstellungen und Kommandos werden nicht mehr weitergegeben.
Die permanente Connection besteht aber weiterhin.

Oh, das ist bestimmt bei meinem Teil auch so... einschalten, ausschalten... funktioniert nicht mehr. Was die permanente Verbindung angeht, wie lange hast du gewartet. Was sagt netstat zu der Verbindung. Je nach Einstellungen kann so eine Verbindung noch noch einige Minuten bestehen, bis endgültig entfernt wird.

Gruß,
Stephan

[AxelSchweiss]

Nun ja ... ist Ansichtssache.
a) ist das kein offizieller NTP-Server
b) heisst das noch lange nicht das ich da NTP drüber schieben muss
c) kann ich ja nirgends einen NTP einstellen.

[budy]

Klar ist das Ansichtssache... und wenn ich mir's recht überlege, werde ich auch einfach nur kurzerhand den Internetzugriff für das LD382 komplett sperren, brauchts ja eh' nicht. Ich meine nur, dass das Gefahrenpotential nicht soo groß ist - eher die Schlamperei beim Hersteller... Na, sei's drum. 

Was anderes:

Schalte ich den Kontroller  an und wieder aus ... funktioniert FHEM (genauer das Modul) nicht mehr. Einstellungen und Kommandos werden nicht mehr weitergegeben.
Die permanente Connection besteht aber weiterhin.

Du meinst Ausschalten/Einschalten? Was die permanente Verbindung angeht, wie lange hast du gewarte?. Was sagt netstat zu der Verbindung ESTABLISHED/WAIT/FINWAIT/FINWAIT2? Je nach Einstellungen kann so eine Verbindung noch noch einige Minuten bestehen, bis endgültig entfernt und der lokale Socket dann schlussendlich beschlossen wird.

Gruß,
Stephan

[raspklaus]

Hallo Herrmann,

hier ein Zwischenstand von meinen Bemühungen mit der neuen Bulb

Sie lässt sich als RGBW LD382A an und ausschalten sowie dimmen

Wie bei den neuen Milight Bulbs wurde auch hier das Webinterface teilweise entfernt

Es scheint also die neueste Entwicklung des Herstellers zu sein. Der stellt übrigens auch die IWY, milight und Envi her

[AxelSchweiss]

nach Einstellungen kann so eine Verbindung noch noch einige Minuten bestehen, bis endgültig entfernt wird.

Habs eben mal auf die Schnelle gemacht ...
a) LED ausgeschaltet. Kontroller aber eingeschaltet gelassen. (Timestamp 20:17 Uhr)
b) warten bis 20:32 Uhr  also 15 Minuten
c) Connection ist in CLOSE_WAIT
d) Kommando um LED einzuschalten ( Timestamp 20:32 )

Ergebnis: Kommando wird abgesetzt aber der Kontroller macht nix ... auch nach über einer Minute.
Connection war nach ca. 2 Minuten ( 20:35 Uhr ) im Zustand LAST_ACK 
Im Log steht folgender Eintrag: 
EZ.LED_Highboard low level cmd queue send 71230fa3, qlen 1 connection refused: trying to reconnect
EZ.LED_Highboard low level cmd queue send ERROR 71230fa3, qlen 1 (reconnect giving up)

[budy]

Kleiner Pythonserver für den LD382A mit RGBW

Moin,

so - auf mehrfachen Wunsch hänge ich mal mein aktuelles Python-Script an, welches ich verwende, um auf dem LD382A vernüftige Transitions zu bekommen, da die Transitions von Wifilight, zumindest mit dem LD382A, nicht so toll gehen. Die Benutzung ist denkbar einfach...es gibt nur zwei Modes:

- single shot Mode: benötigt die Adresse des Controllers und ein HSI Triplet (HUE,SAT,INT)
- server Mode: benötigt nur die Controller-Adresse, z.B. so: ./ld382a_0.2.3.py -C [IP]

Der Server öffnet dann einen Socket auf Port 5382 und wartet dort darauf, dass jemand mit ihm spricht. Das muss nicht FHEM sein, aber Sinn machte das natürlich schon. Man kann dem Teil aber auch mal zwischendurch ganz simpel direkt über die Shell was zu tun geben. Z.B. so:

Code Auswählen Erweitern

# Einen HSI-Wert direkt setzen:
echo "s,120,0,100" > /dev/tcp/127.0.0.1/5382
# Eine Transition lin 4s von Aus/rot nach Voll/grün laufen lassen:
echo "t,0,0,0,120,0,100,4" > /dev/tcp/127.0.0.1/5382
# Einen RGBW-Set direkt setzen, wie z.B. "All-On":
echo "r,255,255,255,255" > /dev/tcp/127.0.0.1/5382
# Last but not least: Effekt starten
echo "e,fire,5" > /dev/tcp/127.0.0.1/5382

Ich habe mir für die einzelnen Kommandos jeweils kleine Subs in der 99_myUtils.pm gemacht, welche ich dann entsprechend aufrufe. Das einzige, woran ich ein wenig knacken musste, war der Feuer-Effekt und das aus folgendem Grund:
der Effekt selber darf nicht zu lange laufen, weil der Server ja unabhängig vom FHEM läuft und man ggf. nicht 30s warten möchte, wenn man den Effekt abschalten will. Von daher benutze in den INTERNALTIMER, wenn ich das Feuer starte

Der Server selber arbeitet über einen Ringpuffer mit 16 Slots (kann man aber leicht im Skript ändern), schiebt man mehr Kommandos rein, dann wird er Puffer von hinten überschrieben... Für meine Zwecke reicht das erst mal... und ich suche noch nach einer Möglichkeit ggf. alle Kommandos zu löschen... Irgendwie habe ich neulich, den Contoller mit meiner Feuer-Simulation überfordert und er wollte gar nicht mehr aufhören, obwohl der Server selbst gar keine Daten mehr an den Controller gesendet hat.
Irgendwie hat dann allerdings die iOS App es dennoch geschafft den Controller zu bändigen, da muss ich ggf. noch mal in LAN mitsniffen.

Weiterer wichtiger Punkt betrifft die Farbkorrektur. Bei meinem Gespann ist Rot im Vergleich zu Grünm und Blau deutlich weniger hell. Ich habe mich bei der Kalibration am Vorgehen orientiert, wie es auch am Anfang dieses Threads von Jörg empfohlen wurde. Gelb einstellen und sehen, wie weit man bei Grün runterdrehen muss, damit es auch einigermaßen Gelb wird. Dasselbe bei Magenta...

Die Werte für die Korrektur habe ich als Parameter in der Funktion hsi2rgbw über die Variablen rFactor,gFactor,bFactor eingegeben und da muss ggf. jeweils angepasst werden, aber das sieht man dann ja.

Tja, dann mal viel Spaß und bei Fragen/Problemen werde ich tun, was ich kann. Ach ja... und Verbesserungs-Vorschläge werden gerne genommen, denn Python ist nicht meine Muttersprache...

Gruß,
Stephan

[budy]

Habs eben mal auf die Schnelle gemacht ...
a) LED ausgeschaltet. Kontroller aber eingeschaltet gelassen. (Timestamp 20:17 Uhr)
b) warten bis 20:32 Uhr  also 15 Minuten
c) Connection ist in CLOSE_WAIT
d) Kommando um LED einzuschalten ( Timestamp 20:32 )

Wie meinst du das LED aus, aber Kontroller an? Mein Kontroller treibt die LEDs selber, sprich ich kann die LEDs nicht abschalten...
CLOSE_WAIT bedeutet ja, dass der lokale Prozeß noch den Socket offenhält...  und das OS darauf wartet, dass - in diesem Fall wohl Wifilight, den Socket schließt.

So was sehe ich bei mir bisher nicht, aber ich schalte den LD382a auch nicht ab... bei 0.2W ist mir das den eventuellen Stress nicht wert.

Gruß,
Stephan

[herrmannj]

Hi,

Da stimmt was nicht.

a) LED ausgeschaltet. Kontroller aber eingeschaltet gelassen. (Timestamp 20:17 Uhr)

Mit Wifilight ? In dem Fall bleibt der socket offen.

EZ.LED_Highboard low level cmd queue send 71230fa3, qlen 1 connection refused: trying to reconnect

Wifilight sendet asynchron, bekommt hier die Nachricht das die Verbindung defekt ist und

EZ.LED_Highboard low level cmd queue send ERROR 71230fa3, qlen 1 (reconnect giving up)

schließt die Verbindung und möchte sie neu zum ld382A öffnen um das Kommando zu wiederholen, was aber nicht geht.

vg
joerg

[AxelSchweiss]

Wie meinst du das LED aus, aber Kontroller an? Mein Kontroller treibt die LEDs selber, sprich ich kann die LEDs nicht abschalten...

Der Kontroller bleibt unter Strom am Netzteil und ich schalte mittels WifiLight die LED , in dem Fall die Weiße, an und aus.

[AxelSchweiss]

So was sehe ich bei mir bisher nicht, aber ich schalte den LD382a auch nicht ab... bei 0.2W ist mir das den eventuellen Stress nicht wert.

Ich messe da was zwischen 0,4 und 0,6 Watt. Allerdings mit dem LED-Netzteil.
Ist natürlich trotzdem weniger wie eine schaltbare Steckdose.

Mir geht es eigentlich aber darum das ich bei einem Stromausfall , sei es selbst oder fremdverschuldet, die Hausautomation nicht geordnet nach Checkliste a la Enterprise Business hochfahren muss.
Der WAF-Faktor ist da direkt proportional zum Stresspegel und dieser geht dann exponentiel in den Adrenalinpegel ein. 

[AxelSchweiss]

Da stimmt was nicht.Mit Wifilight ? In dem Fall bleibt der socket offen. Wifilight sendet asynchron, bekommt hier die Nachricht das die Verbindung defekt ist undschließt die Verbindung und möchte sie neu zum ld382A öffnen um das Kommando zu wiederholen, was aber nicht geht.

Das Problem hier ist meines Erachtens nach das WifiLight keinen Fehler wirft sondern den Befehl als abgearbeitet quitiert.
Ich würde mir hier wünschen das dann der "Schalter" wieder auf den vorigen Zustand springt und ähnlich wie bei Homematic etwas analoges zu MISSING_ACK kommt.
Darauf könnte ich dann ein Notify setzten und eine Fehlerbehandlung , zum Beispiel ein wiederholen des Befehls oder eine e-Mail, einleiten.

[pula]

Hallo,

störe ungern den Diskussionsfluss hier, aber ich versuche grad, mich in wifilight einzuarbeiten und habe die ca. ersten 40 Seiten des threads sowie die Wiki-Seite gelesen.
Was ich aber nicht verstehe: Was genau bedeuten bei HSV und RGB die parameter

Code Auswählen Erweitern


    ramp
    queue
    direction
    event

und wie werden die genau eingesetzt?
Ich würde evtl. die Infos auch ins Wiki einpflegen, wenn Interesse besteht (und ich einen Wiki-Account bekomme).

Cheers,

Pula

[herrmannj]

Das Problem hier ist meines Erachtens nach das WifiLight keinen Fehler wirft sondern den Befehl als abgearbeitet quitiert.
Ich würde mir hier wünschen das dann der "Schalter" wieder auf den vorigen Zustand springt und ähnlich wie bei Homematic etwas analoges zu MISSING_ACK kommt.
Darauf könnte ich dann ein Notify setzten und eine Fehlerbehandlung , zum Beispiel ein wiederholen des Befehls oder eine e-Mail, einleiten.

Yepp, versteh ich. Das kommt so ein wenig aus der Historie. Zu Beginn hab ich das modul für die milight geschrieben und bei denen gibt es gar kein Feedback. Allerdings habe ich auch von vornherein darauf geachtet das alles skalierbar zu halten. Im Lauf der Zeit habe ich dann jeweils neue Typen ergänzt, so wie sie eben auf den Markt gekommen sind. Das alles immer unter dem Aspekt das die LEDs, aus der Sicht von fhem, alle gleich anfühlen.

Die LD Typen haben einen firmware bug der (ein wenig) zu dem passt was Du beschreibst. Das tritt aber eigentlich nur auf wenn man die vom Strom nimmt. Das von Dir beschriebene Verhalten passt da nicht ganz rein weil Du den ja eigentlich am Strom lässt. Kann es sein das Du einen WLAN repeater (oder so was) nimmst ?

Ich würde mir hier wünschen das dann der "Schalter" wieder auf den vorigen Zustand springt und ähnlich wie bei Homematic etwas analoges zu MISSING_ACK kommt.

Naja. Wenn das passiert dann ist der status, aus Sicht des moduls, völlig unbekannt. Komplett aus (power), WLAN unterbrochen, von der App "wo anders hin" geschaltet ? Von daher denke ich eigentlich das der alte Status genauso richtig oder falsch sein könnte wie jeder andere auch.

Wenn die LED nicht reagiert ist sie aus fhem Sicht halt "weg" und das aus Gründen die dann auch von fhem Seite aus nicht mehr gelöst werden können. Einen trigger könnte ich setzen, die Frage ist was man als user damit macht.

vg
joerg

[herrmannj]

Hallo,

störe ungern den Diskussionsfluss hier, aber ich versuche grad, mich in wifilight einzuarbeiten und habe die ca. ersten 40 Seiten des threads sowie die Wiki-Seite gelesen.
Was ich aber nicht verstehe: Was genau bedeuten bei HSV und RGB die parameter

Code Auswählen Erweitern


    ramp
    queue
    direction
    event

und wie werden die genau eingesetzt?
Ich würde evtl. die Infos auch ins Wiki einpflegen, wenn Interesse besteht (und ich einen Wiki-Account bekomme).

Cheers,

Pula

Hi,

ramp:
Dieser Parameter steuert einen weichen Übergang zwischen zwei Zuständen und wird in Sekunden angegeben.
Beispiel:
set <name> on : schaltet die LED sofort an.
set <name> on 20 : Die LED wird über einen Zeitraum von 20 Sekunden weich hoch-gedimmt.

queue:
Angenommen das Modul arbeitet gerade intern eine Transition, also dem weichen Übergang zu einem anderen Zustand (siehe ramp), ab. Der user setzt während der Transition einen weiteren Befehl für die LED ab.

Ohne den Parameter "q" wird die laufende Transition sofort unterbrochen und der neue Befehl wird ausgeführt.
Mit dem Parameter "q" wird der neue Befehl in eine interne Queue geschrieben und erst bearbeitet nachdem die laufende Transition, und alle vorher in die Queue geschriebenen Befehle, abgearbeitet wurden.

Dadurch wird es möglich das mit einem Befehl mehrere ganz unterschiedliche Farb- oder Helligkeitswechsel an das modul übergibt die dann nacheinander abgearbeitet werden.

direction:
Im HSV Farbraum entsprechen die Farben einem Winkel (0° Rot, 120° Grün, 240° Blau). Der weiche Übergang von einer Farbe zu einer anderen wird Standardmäßig auf dem "kürzesten Weg" durchlaufen. Der Wechsel von Grün auf Rot sieht also so aus: 120°, 119°, 118°, ... 2°, 1°, 0°.  Das entspricht der default direction "s" für "short" - dem kürzesten Weg.

Mit dem Flag "l" für "long" (langer Weg) wird die gleiche Transition jetzt mit dem "Umweg" über Blau ausgeführt, also so: 120°, 121°, 122°, ... 358°, 359°, 360° ( = 0°).

Für "event" gibt es einen guten Post, den muss ich suchen. "event" benötigt man allerdings selten, da geht es um die Synchronisation mit anderen Prozessen und der Möglichkeit komplexe Farbwechsel programmieren und unbegrenzt wiederholen zu können.

vg
joerg

[pula]

Hi,

wow! Super, danke für die tolle Erklärung!
Ich werde mal schauen, daß ich zu einem Account fürs Wiki komme und das einpflegen, wenns recht ist...

Cheers,

Pula