Probleme mit milight UDP Befehlen seit Update auf 9.9.5

2712
Beiträge: 1317
Registriert: Fr 12. Aug 2016, 07:20
Wohnort: Österreich

Do 17. Dez 2020, 16:37

Ja, klar Cat5e hätte gereicht, aber ich musste eh neu bestellen, und der Preisunterschied ist mittlerweile maginal. :lol:
LMAir&2 Extender, 3 X RM3mini, Harmony Elite & 3 X Companion, Deconz Zigbee Gateway, piVCCU, Node-Red (für Anbindung Harmony, Homematic, Broadlink, Dreamscreen, Zigbee), ettliche Aktoren, 8 Alexas, Fritzbox 7590, 7490, 7560, 2 X 4040, 1 X 450 :D
Micha K.
Beiträge: 12
Registriert: So 15. Jul 2018, 18:04

So 20. Dez 2020, 19:26

Hallo in die Runde,

einen IP Konflikt habe ich nicht. Ich hatte Fritzbox und Repeater als Mesh Netzwerk eingerichtet und hatte damit, bis zum letzten AirStudio Update auch nie Probleme. Auch habe ich keine Sende oder Empfangsprobleme und hatte generell an der Position der einzelnen Komponenten nichts verändert.

Ich habe dennoch alle erwähnten Ratschläge ausprobiert. Ich habe das Meshnetzwerk aufgelöst, Fritzbox und Repeater verschiedene SSID's gegeben und auch den Repeater ganz aus dem Netzwerk genommen und alle Geräte direkt mit der Fritzbox verbunden.

Leider alles ohne Erfolg. :(

Ich habe dann den Ursprungszustand wieder hergestellt, also Fritzbox und Repeater als ein Mesh Netz, wobei die Milight Box mit der Fritzbox und der Air mit dem Repeater verbunden ist.

Ich habe dann habe ein Downgrade auf AirStudio 9.3.4 und Firmware 8.7 aufgespielt. Und siehe da... Keinerlei Probleme mehr bei den UDP Befehlen. :D

Dann ist mir aber aufgefallen, dass ich in der SW 9.3.4 meinen Bresser Thermometern noch keinen Kanal zuordnen konnte. Also habe ich SW 9.8 und Firmware 9.6 installiert. Auch hier keine Probleme mit den UDP Befehlen. Die Milight Box hat jedes mal reagiert.

Was aber nicht mehr funktioniert hat, waren alle angelernten Befehle - sei es IR oder Funkbefehle. Alle Trust und Intertechno Schalter haben normal funktioniert, nur beim Auslösen der angelernten Befehle ist der Air in eine circa 1 minütige "Schockstarre" gefallen (rote LED leuchtet dauerhaft und AirStudio meldet eine abgebrochenen Verbindung zum LM).

Ich habe dann die fehlenden IR und Funk Befehle wieder neu angelernt und alles ausgiebig getestet. Es gab anfangs einige Probleme mit der Cloudverbindung, aber nachdem ich alle Geräte neu gestartet und auch auf dem Handy die Cloudverbindung einmal gelöscht hatte, lief wieder alles ohne Probleme.

Da mir die Sache aber keine Ruhe gelassen hat, habe ich noch etwas recherchiert und bin darauf gestoßen, dass zwar meine Fritzbox Version keine Paketmitschnitte machen kann, wohl aber bei meinem Fritz Repeater die Funktion Paketmitschnitt funktioniert.

Ich habe mich daher entschlossen, noch mal einen Versuch mit der aktuellen Software des AirStudio zu wagen. Ich habe das Update natürlich gemacht, ohne etwas an der sonstigen Konfiguration zu ändern!

Und was soll ich sagen... :cry: nach dem Update auf SW 9.9.5 und die aktuellste Firmware traten wieder die selben Probleme mit der Milight Box auf, wie bei Eröffnung dieses Thread's. Außerdem waren auch wieder alle angelernten IR und Funk Befehle weg... :roll:

Ich habe dann einen Paketmitschnitt nach folgendem Schema gemacht: Insgesamt 50 Schaltvorgänge die UDP Befehle an die Milight Box senden, immer im Wechsel EIN und AUS (also bei Erfolg, wenn EIN nicht funktioniert hat, dann solange bis es funktioniert hat), zu einer Gruppe von LED Streifen (bei mir im System "Dekolicht) - hier das Ergebnis mit der aktuellsten Software:

20 Versuche aus der App - davon 6 erfolgreiche Schaltvorgänge
20 Versuche aus AirStudio direkt - davon 5 erfolgreiche Schaltvorgänge (zwei davon aber erst nach einem Doppelklick im Airstudio)
10 Versuche über Alexa - kein einziger erfolgreich

Daraufhin habe ich, natürlich auch OHNE irgend etwas an der sonstigen Konfiguration zu ändern - wieder zu SW 9.8 und FW 9.6 gedowngradet und wieder einen Paketmitschnitt, nach dem selben Schema, erstellt:

20 Versuche aus der App - alle erfolgreich
20 Versuche aus AirStudio direkt - alle erfolgreich
10 Versuche über Alexa - alle erfolgreich

Die Wireshark Auswertung der beiden Mitschnitte hänge ich als Screenshot an. Mir als Laie ist dabei nur aufgefallen, dass bei der neuen Softwareversion (links), meist nur 62 Byte übertragen werden - und nur ab und an 64 Byte - letztere waren (glaube ich zumindest) auch die wenigen erfolgreichen Schaltvorgänge.

Ich sende die beiden Mitschnittdateien auch gern nochmal an den Support, wenn das gewünscht ist?

Mein Fazit ist, dass mit der neuen Software Version wohl doch irgend etwas mit den UDP Befehlen nicht mehr so funktioniert, wie in den bisherigen Versionen und ich auf jeden Fall und so lange wie möglich bei der alten Version bleibe.

Allerdings mache ich mir auch etwas Sorgen, denn irgendwann werde ich upgraden müssen und sollte das Problem bis dahin nicht behoben sein, sind meine LED Streifen (das sind in Summe 14 Stück an 7 Controllern, plus zwei LED Deckenleuchten) nicht mehr über den LM steuerbar. :roll:

Außerdem ist mir bei dem Wechsel zwischen den Versionen noch folgendes aufgefallen, was bei dem ein oder anderen User bestimmt für Probleme sorgt:

- die Pausenzeiten in meinen angelegten Szenen waren fehlerhaft. Alle Kurzzeitpausen waren plötzlich 30.000 Sekunden lang und alle Langzeitpausen waren 6 Std. lang.
- die Kanäle bei meinen 6 Bresser Thermometern waren völlig durcheinander gewürfelt
- alle gelernten Befehle - egal ob Funk oder Infrarot - waren gelöscht bzw. fehlerhaft. (hatte ich bereits oben erwähnt)
- ich musste die betroffenen Befehle auch in meinen Szenen löschen und wieder neu einfügen, ein reines Neuanlernen der Befehle hat nicht geholfen
- ebenso musste ich die alten Befehle in der Alexa App löschen und Alexa wieder neu suchen lassen

Ich danke allen für Ihre Mühen und Ratschläge und hoffe, dass mir das JB Media Team bei meinem Problem helfen kann.

Euch allen ein frohes Fest
Dateianhänge
Screen2.jpg
Screen2.jpg (482.14 KiB) 8451 mal betrachtet
2712
Beiträge: 1317
Registriert: Fr 12. Aug 2016, 07:20
Wohnort: Österreich

Mo 21. Dez 2020, 09:51

Eine Idee hätte ich noch, da es mir gerade selbst wieder aufgefallen ist. Setze mal, wenn möglich deinen Funkkanal auf 1 (Router und Repeater). Ich hatte am Wochenende meine ersten 2 Repeater zum Router verkabelt. Einer davon ist eine Fritzbox 7490, die sich dann unbemerkt wieder auf "Autokanal" gestellt hatte (und dann Kanal 11 benutzte), und schon hatte ich massive Probleme mit meinem Extender. Erst hatte er sich gar nicht verbunden, auch nicht nach Restart, dann nach platt machen schon, aber selbst AirStudio (alles in der neuesten Version) zeigte unter Wlan die SSID nicht an und zuckte permanent. Ich habe auf beide LMAir alle 10 Minuten einen Ping laufen, kommt keine Antwort nach 3 Versuchen, führe ich via einer Tasmota Steckdose einen Restart aus (Ausschalten, nach 20 Sekunden wieder einschalten), Email an mich falls das stattfindet.
Andere Funknetze auf Kanal 11 wurden nicht angezeigt. Nach Festlegen auf Kanal 1 war alles wieder sauber, und auch der Extender zeigte wieder die SSID und den Kanal an. Das habe ich mehrere Male ausprobiert. Kanal 11 scheint entweder der LMAir nicht zu mögen, oder AVM hat hier einen Bug. Auch mit Kanal 6 hatte ich schon Probleme....Meine Repeater und die 7590 haben alle die neueste FW.

@JBMedia, vielleicht könnt Ihr das mal checken, wenn Ihr Zeit habt.
LMAir&2 Extender, 3 X RM3mini, Harmony Elite & 3 X Companion, Deconz Zigbee Gateway, piVCCU, Node-Red (für Anbindung Harmony, Homematic, Broadlink, Dreamscreen, Zigbee), ettliche Aktoren, 8 Alexas, Fritzbox 7590, 7490, 7560, 2 X 4040, 1 X 450 :D
Benutzeravatar
jbmedia
Administrator
Beiträge: 4446
Registriert: Mi 17. Feb 2016, 13:42

Mo 21. Dez 2020, 15:19

An den Paketmitschnitten erkennt man schön, dass alle UDP Befehle mit beiden airStudio Versionen einwandfrei verschickt wurden. Woher der Unterschied in der Längenangabe genau kommt, müsste man sich im Detail anschauen. Dies kann z.B. die Länge einer Checksumme des TCP Protokolls o.ä. sein. Entscheidend ist die UDP Payload, also die beiden Data Bytes sowie die zugehörige Längenangabe von 2. Diese Daten werden vom Empfänger verarbeitet sind bei allen Paketen korrekt.

Es muss also eine tiefere Ursache geben, warum es in einem Fall nicht sauber läuft. Wir werden probieren, ob wir den Effekt reproduzieren können.
Wir wünschen viel Spaß mit den Produkten und einen erfolgreichen Tag! Ihr jbmedia Team :)

Benutzeravatar
freebsd-man
Beiträge: 155
Registriert: Do 29. Okt 2020, 18:03

Mo 21. Dez 2020, 22:44

Was ich bei den ge-capture-ten Paketen sehe, ist ein Unterschied in der Frame-Header-Länge und nicht in der Länge des Frame-Payload (UDP).
Der Frame mit 62 Byte hat kein QoS im Frame-Header und deshalb 2 Byte weniger. (Siehe 802.11 optionales QoS-Control)

Und dann fällt mir noch ein, das Ethernet-Frames mit weniger als 64 Byte von den meisten Geräten als Runt-Frames interpretiert werden.
Das sind dann Pakete, die auf Grund ihrer zu kleinen Länge als defekt verworfen werden.

Denke da liegt das Problem.
Entweder QoS-Control nutzen oder den Payload verlängern (padding).
Dann sollte alles wieder klappen.
--
Yours freebsd-man
DerSchatz
Beiträge: 61
Registriert: Sa 14. Okt 2017, 08:50
Wohnort: Wedel

Di 22. Dez 2020, 12:19

Hallo,

auch ich habe identische Probleme mit dem Schalten meiner MiLights.
Ich schalte vier MiLights mit einer "alten" MiLight-Bridge per UDP, was definitiv bis 9.8.3 völlig problemlos funktioniert hat.
Nach Installation der 9.9 Version wurden die MiLights in den Szenen nur noch selten geschaltet, auch im AirStudio wurde erst nach mehrmaligem Betätigen der TEST-Funktion irgendwann ein Schaltvorgang ausgeführt. Daraufhin bin ich wieder zurück auf die 9.8.3, wo alles fehlerfrei funktionierte. Dies habe ich bei jeder neuen Programmversion danach wieder ausprobiert und bin jeweils wieder zurück.
Irgendwann hatte ich dann auch die "selbstveränderten" Pausenzeiten, die ich dann korrigiert habe. Um nun nicht wieder zurück zu wechseln, habe ich in den Szenen dann die MiLight-Befehle in jeder zweiten Zeile wiederholt, sende also mindesten 8x den gleichen Befehl. Dies bringt jetzt zwar das gewünschte Ergebnis, ist aber letztlich nur ein Workaround, so dass ich mich über eine echte Problemlösung freuen würde. Zwischen den Up- und Downgrades habe ich natürlich nichts an meinen WLAN-Einstellungen verändert.

Beste Grüße!
Benutzeravatar
jbmedia
Administrator
Beiträge: 4446
Registriert: Mi 17. Feb 2016, 13:42

Di 22. Dez 2020, 12:44

freebsd-man hat geschrieben:
Mo 21. Dez 2020, 22:44
Entweder QoS-Control nutzen oder den Payload verlängern (padding).
Dann sollte alles wieder klappen.
Das ist ein sehr interessanter Aspekt! QoS kann man in der Fritz!Box unter Internet > Filter > Priorisierung für jedes Gerät individuell aktivieren. Bei priorisierte Anwendungen > Neue Regel den Light-Manager hinzufügen und bei Netzwerkanwendung alle wählen.

Sollte es dann immer noch nicht klappen, die UDP Daten bitte mit 00 00 auffüllen. Am besten in beiden Fällen mit Wireshark prüfen, ob die Änderungen erfolgreich durchgeführt wurden.

Die Frage wäre, warum die Fritz!Box von sich aus manche UDP Pakete mit QoS flagged und andere nicht. Dies kann wohl nur AVM beantworten.
Wir wünschen viel Spaß mit den Produkten und einen erfolgreichen Tag! Ihr jbmedia Team :)

Micha K.
Beiträge: 12
Registriert: So 15. Jul 2018, 18:04

Di 22. Dez 2020, 12:55

jbmedia hat geschrieben:
Di 22. Dez 2020, 12:44
freebsd-man hat geschrieben:
Mo 21. Dez 2020, 22:44
Entweder QoS-Control nutzen oder den Payload verlängern (padding).
Dann sollte alles wieder klappen.
Das ist ein sehr interessanter Aspekt! QoS kann man in der Fritz!Box unter Internet > Filter > Priorisierung für jedes Gerät individuell aktivieren. Bei priorisierte Anwendungen > Neue Regel den Light-Manager hinzufügen und bei Netzwerkanwendung alle wählen.

Sollte es dann immer noch nicht klappen, die UDP Daten bitte mit 00 00 auffüllen. Am besten in beiden Fällen mit Wireshark prüfen, ob die Änderungen erfolgreich durchgeführt wurden.

Die Frage wäre, warum die Fritz!Box von sich aus manche UDP Pakete mit QoS flagged und andere nicht. Dies kann wohl nur AVM beantworten.
@derSchatz schön das ich mit dem Problem nicht alleine bin. :roll:

@jbmedia das kann ich gern irgendwann im neuen Jahr mal probieren, aktuell fehlt mir dafür aber die Zeit. Da ich mir mit einem Up- und Downgrade immer das halbe AirStudio zerschieße, sind das locker 3 bis 4 Stunden, damit alles wieder läuft. :|

Ich verstehe dennoch nicht, warum die Fritzbox ein und den selben Befehl anders behandelt, nur weil er aus zwei verschiedenen Soft- bzw. Firmwares des Lightmanagers kommt?? Das kann doch dann nicht an der Fritzbox liegen, sondern muss an dem Sender (LMAir) liegen - oder sehe ich das falsch?? :?

Soll ich euch noch einmal die kompletten Paketmitschnitte per Mail zukommen lassen?

@freebsd-man Danke für deinen Lösungsansatz :)
Antworten