Wifilight.pm

[herrmannj]

Kann man drüber nachdenken. Wobei das Modul es in diesem Fall ja schon selber mehrfach versucht. Mein Gedanke ist immer, wenn er nicht erreichbar ist dann ist es halt so

Vg
Jörg

[t1me2die]

Stimmt es gibt leider nur einen Logeintrag wenn das Modul den Controller nicht erreichen kann. Schön wäre es, wenn es auch einen Event mit der Fehlermeldung geben würde.
Zu Deinem Problem: Die Frage ist, warum dein Controller nicht erreichbar ist. Trennst Du ihm vom Strom?
Als quick&dirty Lösung würde ich den Befehl mit einem sleep 1 noch einmal schicken!

Nein, er hängt durchgehend am Strom, sollte also auch immer erreichbar sein.

@Jörg: Prinzipell gebe ich Dir recht. Nur ich würde gerne auf so einen "ERROR" reagieren. Mir ist es nämlich aufgefallen, dass wenn der Controller "nicht erreichbar" war, der Error in die Logfile geschrieben wurde und der Status von der LED trotzdem auf "on" springt, obwohl die LED aus ist. Da ich beim verlassen der Wohnung unteranderem auch drei dieser Controller automatisch ausschalte, muss ich immer in den Log schauen, ob sich ein Error eingeschlichen hat, da ich mich auf die Anzeige in FHEM / HomeKit nicht verlassen kann.

Gruß
Mathias

[Shardan]

Hat jemand evtl. eine bessere Lösung zum Synchronisieren zweier LD382A?

Hallo zusammen

dieser Tage habe ich zwei LD382A mit RGBWW-Stripes eingebunden, ging weitgehend problemfrei - tolles Modul, danke dafür.

Derzeit habe ich ein Problem, bei dem ich nicht weiter komme:
Beide Streifen sind im gleichen Raum, leider so weit auseinander, dass ich sie nicht einfach verbinden kann
(jaja, Kabel und der WAF...  )

Ich hab die beiden Controller dann mit einem notify synchronisiert:

Code Auswählen Erweitern

SZ_Wand:RGB.* set SZ_Decke RGB $EVTPART1

Der erste Streifen erzeugt mit jedem Wechsel der Werte ein Event, das notify nutzt den Event, um den zweiten Streifen zu setzen.

Solange ich direkt bestimmte Farben setze, z.B. mit den Slidern geht das ohne weiteres.
Sobald ich "ramp" nutze, um einen Farbverlauf zu steuern, läuft der direkt gesteuerte Streifen einwandfrei,
der "mitsynchronisierte" flackert jedoch mitunter unschön.
Als Ursache konnte ich ermitteln, dass das Synchronisieren die Werte direkt schreibt, aber nicht in eine Queue aufnimmt.
Dadurch "überholen" sich mitunter wohl einige Settings gegenseitig, da eines noch nicht (ganz?) abgearbeitet ist, wenn das nächste kommt.

Gibt es eine Möglichkeit, mit dem obigen notify den "q" Parameter mit zu übergeben?
Ich hab schon einiges probiert, aber nichts will so richtig funktionieren.

Schönen Rest-Ostermontag
Shardan

[igami]

Hat jemand evtl. eine bessere Lösung zum Synchronisieren zweier LD382A?

structure

[Shardan]

Dankeschön... Werde ich umgehend testen

Grüße
Shardan

[sebastianbieber]

Hallo, Jörg, Hallo, Gruppe,

ich hatte vor einiger Zeit darauf hingewiesen, dass bei einem Device

>define mi1 WifiLight RGBW2 bridge-V3:172.20.10.5
>attr mi1 colorCast 3,-19,12,-20,16,29

die colorCast-Einstellung nicht wirksam wird. Jörg, Du meintest, das wäre ein Bug im Modul, hattest aber damals keine Zeit, Dir das anzuschauen. Magst Du das mal machen? Eine Korrektur dieses Bugs wäre echt schön - die Farben liegen aktuell schon schwer neben der Spur ><


So long, Sebastian

[herrmannj]

Hallo Sebastian

Ja, bin unterwegs aber kommende Woche zurück

Vg
Jörg

[daniel2311]

Hallo Jörg,

wir hatten vor längerer Zeit schon einmal über scheinbar verloren gehende Pakete uns unterhalten.

Damit meine LD382A verlässlich immer an und ausschaltet, manipuliere ich jedes mal WifiLight_LowLevelCmdQueue_Send und erstelle jedes Mal einen neuen Socket. Dann habe ich definitiv keine Probleme mehr.

Meinst du es wäre möglich, ein neues Attribut wie alwaysReconnect oder ähnliches einzuführen, womit er den Reconnect automatisch immer ausführt? Alternativ so etwas, dass man sagt, mache immer einen neuen Socket auf, wenn du x-Sekunden nichts mehr gesendet hast?

Ich würde dich auch bei der Programmierung oder einem Vorschlag unterstützen und gerne selbst etwas programmieren, was du dann vllt. offiziell in eine Version aufnehmen könntest.

[herrmannj]

Moin Daniel

zuerst: sehr gern.

Ich denke aber das Du das Pferd damit falsch aufzäumst.

Der Verbindungsaufbau kostet im Verhältnis viel Zeit. Gerade bei transitions ist die knapp. Wenn Du jetzt jedes mal den Socket neu aufbaust geht das ganz fix sehr auf die performance.

Ich glaube das Problem liegt beim shutdown/close der sockets.

Wenn Du magst schlage ich eher folgendes vor:
der tcp socket müsste per select überwacht werden und vor allem: wenn man ein shutdown/close an der richtigen Stelle einbaut sollte das Problem beseitigt sein.

vg
joerg

[daniel2311]

Hi Joerg,

ja stimmt schon, wenn man sauber erkennt, dass die Verbindung weg ist, dann könnte man das besser hinbekommen. Gerade bei TCP sollte das ja kein Problem sein. Aber wer weiß, ob da ein schlecht implementierter TCP-Stack auf dem Gerät oder aber auch Perl da einem einen Strich durch die Rechnung macht, denn wer weiß, was in Wirklichkeit das select macht.

Ich werde jetzt mal zumindest erst mal serverseitig Wireshark eine ganze Zeit laufen lassen. Ich installiere es gerade. Das schwierige ist nur natürlich mitzubekommen, jetzt hätte es geschaltet werden müssen, ist es aber nicht und dann passend einen Fehler mitzubekommen. Vllt. bekommt man es aber auch raus, wenn man sieht, dass irgendwann ja ein Reconnect gemacht wird und somit ein neuer Socket inkl. Handshake durchgeführt wird...
Diese can_read vom IO-Select ist mir auch ein wenig suspekt - aber ich muss sagen, Perl traue ich auch nicht ganz Aber wieso sollte es am shutdown/close der sockets liegen? Du meinst am Shutdown vom Remote Device?Oder das der close nicht erkannt wird? Was ich gleichzeitig laufen lassen könnte, wäre regelmäßig nen netstat laufen lassen und tracken, wann die Verbindung verschwindet - aber bin mir nicht sicher, ob in meinem Falle Windows den Shutdown mitbekommt. Wenn ja, und der nicht mehr gebunden wäre, könnte man das ja ggf. gegenprüfen - aber alles leichter gesagt als getan. Weil es funktioniert ja gefühlt nur manchmal nicht und nicht immer nur bei langer ungenutzter Verbindung, zumindest mein Bauchgefühl.

Mit den Transitions verstehe ich natürlich auch, deshalb dachte ich, das man das irgendwie über die Zeit macht, also den Socket verwirft, sobald 30 sek. nichts mehr gesendet wurde, dann ist ja ein reconnect nicht mehr ganz so schlimm.

[daniel2311]

haha, ich habe das ganze nur an und ausgemacht und schon jede Menge Übertragungsfehler bekommen - und Spurious Retransmission von Verbindungen, die was länger schon zu sind und dann ein Reset bekommen, während schon weiteres auf der Leitung läuft. Aber habe auch noch meine modifizierte Version mit den neuen Sockets am laufen.

[herrmannj]

würde das ja bestätigen

[daniel2311]

Ich glaube aber die sind es nicht.
so, jetzt bin ich natürlich kein TCP-Experte, aber ich werde das mal morgen bei mir in der Firma mit unseren Netzwerkern klären.
Ich habe 300 sek bzw. 298 sek nach dem letzten Senden vom Server ein "Fin, Ack" von Server beobachten können.
https://de.wikipedia.org/wiki/Transmission_Control_Protocol#Verbindungsabbau
Das liest sich so, als ob damit die Verbindung geschlossen werden würde, wohlgemerkt vom Server - wer auch immer das auslöst. Der Ufo bestätigt es flott mit einem Ack.
Jetzt setze ich einen weiteren Befehl ab. Der Server schickt über den ja eigentlich abgeschlossenen Port ein Paket, welches Promt vom Ufo mit einem RST, ACK quittiert wird. Es folgenen Retranmissions, bis wohl auch der Server merkt, so geht es nicht. Dabei hat der Ufo bereits 3x mal ein RST geschickt. Nachdem aber der Server das Reset gemacht hat, wird dann beim nächsten Befehl ein neuer Port. geöffnet.
Nachteil ist. Die LED ist nicht an meinem Computer. Ich muss also mal gucken, wie ich das beobachten kann.
Aber schon mal sehr verdächtiges Verhalten vom Server und nicht vom Ufo.

[herrmannj]

yepp. deswegen dort auch die idee mit close/shutdown. imho sollte dann nicht mehr versucht werden über die Verbindung was zu schicken. Der code zum neuaufbauen der Verbindung ist ja drin. Ich glaub der server (hier wifilight) müsste einfach das fin beachten, dann wäre alles gut.

[daniel2311]

Nee, Perl löst ja das Fin aus und müsste ja eigentlich dann bescheid wissen, dass es mit der Verbindung nicht mehr weiter geht. Scheint das allerdings nicht dem Socket mitzuteilen.
nestat hält den Port auch als Close_Wait bzw. Schliessen_Warten, bin auf einem deutschen System.
Wer es mal ausprobieren möchte:

Code Auswählen Erweitern

C:\Users\Administrator>netstat -nao | find "10.23.11.16"
  TCP    10.23.11.10:58434      10.23.11.16:5577       SCHLIESSEN_WARTEN    5884
müsste unter Linux nicht anders sein - außer das find. das müsste mit einem grep gemacht werden.

Scheinbar gibt es hier auch recht viele Fragen in Perl zu nach kurzer Google-Recherche, aber bisher habe ich noch nichts passendes gefunden.

Das ist mal ein spannender Kommentar zu - quelle: http://stackoverflow.com/questions/15912370/how-do-i-remove-a-close-wait-socket-connection:

CLOSE_WAIT means that the local end of the connection has received a FIN from the other end, but the OS is waiting for the program at the local end to actually close its connection.

The problem is your program running on the local machine is not closing the socket. It is not a TCP tuning issue. A connection can (and quite correctly) stay in CLOSE_WAIT forever while the program holds the connection open.

Once the local program closes the socket, the OS can send the FIN to the remote end which transitions you to LAST_ACK while you wait for the ACK of the FIN. Once that is received, the connection is finished and drops from the connection table (if your end is in CLOSE_WAIT you do not end up in the TIME_WAIT state).