LW12/Wifilight - unregelmäßiges Übertragunsproblem

[Pythonf]

Mein LW12 in Kombination mit Wifilight will ab und an die Befehle per FHEM nicht akzeptieren. Interessanter Weiße war der LW12 eingeschaltet und um exakt 0:00Uhr hat er sich ausgeschaltet. Hier das Logfile bei der übertragung eines Befehls, welcher nicht angenommen wird:

Code Auswählen Erweitern

2014.11.14 00:01:06 3: LED_Fabian set HSV 0, 100, 0 with ramp: 0, flags:
2014.11.14 00:01:06 4: LED_Fabian hsv transition without ramp routed to direct settings, hsv 0, 100, 0
2014.11.14 00:01:06 4: LED_Fabian high level cmd queue add hsv/ctrl 0, 100, 0, ctrl , targetTime 1415919666.83202, qlen 1
2014.11.14 00:01:06 5: LED_Fabian high level cmd queue exec dropper delay: -0.00209593772888184
2014.11.14 00:01:06 4: LED_Fabian high level cmd queue exec hsv 0, 100, 0, delay 50, hl qlen 1, ll qlen 0, lock 0

Das Problem ist unregelmäßig, ob es immer um 0:00Uhr ausgeht konnte ich noch nicht beobachten.
Eine Reproduktion erwies sich bislang als unmöglich. Der LW12 ist in einem Netzwerk, dass durch zwei Router mit der selben SSID, dem selben Password, dem selben Kanal und im selben Netzwerk sind. DHCP läuft über die Fritzbox, feste IP-Adresse ist zugewiesen. Die Kontrolle per App ist noch möglich.

Zusatz: seit 0:06Uhr Funktioniert die Steuerung über FHEM wieder. Dies ist allerdings nicht die Regel, teilweise dauert der Ausfall einige Stunden.

Grüße
Fabian

[herrmannj]

Hi Fabian,

Du hattest, glaub ich, schon mal stress damit. (?)

Im log selber sehe ich nix, da fehlt aber auch noch was (das send). Auf Stabilität lege ich Wert deswegen würde ich das auch gern lösen - ich kann aber die Ursache so nicht sehen.

Du sagst das er um 0:00 ausgegangen ist, der Befehl den ich sehe ist aber (um 1:06) auch ein "aus". Wenn der lw12 auch für fhem aus ist (laut reading!) wird aus "aus" nicht gesendet. Das wäre ok. Bei der Sache mit den beiden routern bin ich etwas skeptisch, ob das dazu beiträgt weiß ich nicht.

Kommst Du mit wireshark klar ? Weil da müsste man jetzt eigentlich rein. Der lw12 wird per TCP angesprochen. In wireshark sieht man ob die Übertragung so ins Netz geht wie sie ins OS geht, und anhand des ACK vom LW12 auch ob der LW12 den Befehl erhält und bestätigt.

Sollte der Befehl (sprich byte Kette) nicht ankommen würde das OS den wiederholt raus schicken."Eigentlich" ist da alles sicher.

Alternativ könnte es ein fehler des, sprich im, LW12 sein. Ob hard- oder firmware bzw ob es einen work around gibt läßt sich erst entscheiden wenn die Ursache klar ist bzw ob das überhaupt irgendwie mit fhem zu tun hat.

vg
jörg

[Pythonf]

Wireshark kenn ich, und werde ich auch versuchen, damit die genauen Daten zu loggen, aber hier ist vorerst nochmal ein vollständigeres Logfile:

Code Auswählen Erweitern

2014.11.15 17:21:14 3: LED_Fabian RGB LW12 dim 100 1
2014.11.15 17:21:14 3: LED_Fabian set HSV 120, 100, 100 with ramp: 1, flags:
2014.11.15 17:21:14 3: LED_Fabian low level cmd queue send ERROR 5600ff00aa, qlen 1 (trying to reconnect)
2014.11.15 17:21:15 1: LED_Fabian low level cmd queue send ERROR 5600ff00aa, qlen 1 (reconnect giving up)
2014.11.15 17:21:15 3: LED_Fabian set HSV 120, 0, 100 with ramp: 0, flags:
2014.11.15 17:21:16 3: LED_Fabian low level cmd queue send ERROR 56ffffffaa, qlen 2 (trying to reconnect)
2014.11.15 17:21:17 1: LED_Fabian low level cmd queue send ERROR 56ffffffaa, qlen 2 (reconnect giving up)
2014.11.15 17:21:53 5: LED_Fabian prepare start hsv transition (is actual) hsv 120, 0, 100, 1416068513.65615
2014.11.15 17:21:53 4: LED_Fabian current HSV 120, 0, 100
2014.11.15 17:21:53 3: LED_Fabian set HSV 100, 100, 100 with ramp: 0, flags:
2014.11.15 17:21:53 4: LED_Fabian hsv transition without ramp routed to direct settings, hsv 100, 100, 100
2014.11.15 17:21:53 4: LED_Fabian high level cmd queue add hsv/ctrl 100, 100, 100, ctrl , targetTime 1416068513.65615, qlen 1
2014.11.15 17:21:53 5: LED_Fabian high level cmd queue exec dropper delay: -0.00429487228393555
2014.11.15 17:21:53 4: LED_Fabian high level cmd queue exec hsv 100, 100, 100, delay 50, hl qlen 1, ll qlen 0, lock 0
2014.11.15 17:21:53 4: LED_Fabian RGB LW12 set h:100, s:100, v:100
2014.11.15 17:21:53 5: LED_Fabian low level cmd queue add 5654ff00aa, qlen 1
2014.11.15 17:21:53 5: LED_Fabian low level cmd queue qlen 1, send 5654ff00aa
2014.11.15 17:21:53 3: LED_Fabian low level cmd queue send ERROR 5654ff00aa, qlen 1 (trying to reconnect)
2014.11.15 17:21:54 1: LED_Fabian low level cmd queue send ERROR 5654ff00aa, qlen 1 (reconnect giving up)
2014.11.15 17:21:54 5: LED_Fabian low level cmd queue add 00, qlen 2
2014.11.15 17:21:54 4: LED_Fabian high level cmd queue ask next 1416068514.74364
2014.11.15 17:21:54 5: LED_Fabian | LED_Fabian unlock queue 0

Ich habe jetzt versucht, das ganze mit Wireshark zu capturen. Aber ich konnte nur Kommunikation zwischen der IP meines Rechners und der des FHEM-Hosts mitschneiden (Wireshark per TightVNC läuft auf dem FHEM-Host)
Gruß
Fabian

[herrmannj]

Hi Fabian,

ja, vergiss auch - brauchst Du nicht mehr weiter machen (es sei denn zum üben. Den funk von 2 anderen Teilnehmern mitzuschneiden ist nicht ganz einfach und hängt auch von der Netzwerkkarte ab. Nicht alle Karten unterstützen den dafür notwendigen Modus. Ist aber trotzdem eine gute Übung und wenn man es kann wertvolles Know how  ).

Dein letzter Post war ja auch noch frisch (ich hatte wohl Gehirnfrost  ), da gings ja darum das die beiden Module (..light  /  ..led) beide das gleiche Verhalten zeigen. Dein log bestätigt auch ganz klar das es ein Netzwerkproblem ist.

Hier:

Code Auswählen Erweitern

2014.11.15 17:21:14 3: LED_Fabian low level cmd queue send ERROR 5600ff00aa, qlen 1 (trying to reconnect)
kann der Befehl nicht zugestellt werden. Das WifilLight Modul erkennt das beim LW12 und versucht es ein zweites mal den Befehl zum LW12 zu bringen.

Code Auswählen Erweitern

2014.11.15 17:21:15 1: LED_Fabian low level cmd queue send ERROR 5600ff00aa, qlen 1 (reconnect giving up)
Geht auch nicht, also gibt das Modul auf. In diesem Moment könntest Du ihn vom fhem host aus nicht mal anpingen, von das aus ist er nicht im Netzwerk erreichbar.

Das wiederholt sich dann ja mehrfach, der LW12 bleibt aber für den gesamten Rechner unsichtbar. Warum jetzt die app draufkommt kann ich Dir nicht sagen. Vermutung wäre das die app vielleicht im gleichen WLAN hängt wie der LW12 - der fhem host aber an der anderen Box. Oder irgendwie sowas. Routing ?

Ich erlaube mir nochmal Deine WLAN config hier reinzustellen, in der Hoffnung das vielleicht ein Netzwerk Spezialist drauf schaut und etwas dazu beitragen kann:

Ich habe bei mir zuhause zwei wlan netzte mit selber ssid, selbem kanal selbem passwort und selbem Netzwerk.

vg
jörg

[Pythonf]

Was das ganze für mich besonders unerklärlich macht ist, dass die IP Adresse zentral von meiner Fritzbox vergeben wird und ich auf die Weboberfläche des LW12 per Browser, als auch auf die Steuerung per App zugreifen kann. Fakt ist, der LW12 ist im Netzwerk, er hat die richtige IP-Adresse und er lässt sich aus beiden Wlan-Netzwerken per App steuern. Aber weder per Wifilight noch per Wifiled über FHEM steuern.
Bei deaktivierung des Repeaterwlans, welches näher an den LW12 ist, als dass der Fritzbox wollen die LW12, obwohl das Fritzboxwlan gut erreichbar ist, und auch schon erreicht wurde sich nicht in dieses einloggen (Dies wurde über einen Zeintraum von ca. 5min getestet). Mein FHEM läuft auf einem Cubietruck, welcher ebenfalls per Wlan in mein Netzwerk integriert ist.
Bei reaktivierung des Repeaterwlans sind die LW12 sehr schnell wieder per App zu erreichen, interessanterweiße funktioniert auch die Steuerung per FHEM wieder. Die LEDs befinden sich im Repeater-Wlan, der Cubietruck im Fritz Wlan.
Grüße
Fabian

[herrmannj]

das log ist in der Beziehung eindeutig und das Verhalten beider Module kongruent dazu.

Das die IP (per DHCP) von der einen fritz box kommt hat vermutlich nichts zu sagen, da passiert ja auf Netzlevel noch viel mehr. Beispiel (nicht passend aber analog): eine fritz box hat ja auch Einstellungen welche die Kommunikation von WLAN Teilnehmer untereinander regeln (unabhängig davon das die auch die IP bekommen).

Entweder das ist systemisch durch die beiden Netze oder der LW12 setzt halt irgendwelche Protokollbestandteile nicht korrekt welche für das roaming notwendig sind. Ich muss da aber passen, vielleicht finden wir hier noch einen Spezialisten zu dem Thema, es gibt ja echt massig know how hier im Forum.

Ich wüsste nicht ob (welche) Änderungen auf dem Cubietruck da was drehen könnten, ich denke das muss auf Netzwerk Level passieren.

vg
jörg

[herrmannj]

auf die Weboberfläche des LW12 per Browser, als auch auf die Steuerung per App zugreifen kann.... und er lässt sich aus beiden Wlan-Netzwerken per App steuern

Sicher ? Probier doch mal (im Fehlerfall) den lw12 vom Cubietruck aus zu pingen. Oder / Und das webif von das aus zu erreichen. Der Cubietruck ist vtml headless (?) aber Du kannst ja ein wget nehmen.

vg
jörg

[Pythonf]

Der Zugriff vom PC auf das LW12 Webinterface funktioniert und auch der VNC Zugriff auf den Cubietruck funktioniert zu diesem Zeitpunkt! Beim nächsten Ausfall werde ich das mit dem Ping über den CT versuchen. Vielen Dank hier schonmal für deine Unterstützung!

Grüße
Fabian

[flavourflo]

Hallo Pythonf,

ich habe leider das gleiche Problem 

Mein FHEM-Log besagt manchmal (bin noch auf keine Regelmäßigkeit gekommen) folgendes:
2017.09.25 18:54:04 3: LED_Strip low level cmd queue send ERROR 56ff0000aa, qlen 1 (reconnect giving up)

In diesem Moment kann der LW12 dann nicht erreicht oder angesteuert werden.

Konntest du das Problem darmals lösen?

LG
Florian