Milight V4 Bridge Stabilität

Begonnen von Benutzer, 26 September 2015, 11:38:46

Vorheriges Thema - Nächstes Thema

Benutzer

Grüß euch!

Wie sind eure Erfahrungen punkto Stabilität der Milight Bridge V4?

Meine ist extrem instabil.....verliert ständig nach einer gewissen Zeit den Link......

Die Bridge wurde mittels Android Milight App 2.0 ins bestehende WLAN (Fritzbox7390+Repeater 1750E mit WPA2 CCMP Verschlüsselung) eingebunden. Das funktionierte auf Anhieb.

Einbindung in FHEM mittels Milight Bridge und Milight Device war ebenfalls kein Problem.

Bridge bekommt auch von der FB immer die selbe IP. Die Lampensteuerung funktioniert nach Stromreset der Bridge für einige Schaltvorgänge problemlos (FHEM), nach einigen Minuten wird's dann unzuverlässig. Nach erneutem Reset funktioniert es dann wieder eine kurze Zeit. In FHEM wird die Bridge dann immer wieder mit STATE "unreachable", bzw. "error" angezeigt.

Manchmal werden die Befehle auch extrem zeitverzögert verarbeitet, was mich aber mangels Rückkanal doch sehr wundert.

Im Internet findet man Leute die z.B. mit einem Arduino die Bridge pingen, und bei keiner Antwort automatisiert aus/einschalten -> aber das kanns ja nicht sein, oder?

Wie sind eure Erfahrungen mit dem Teil? Habt ihr Firmware Updates gemacht? Falls ja, woher habt ihr die Firmware?

Bin kurz davor das Teil wieder zurück zu schicken.

Wäre für Hilfestellungen bzw. Tipps sehr dankbar.

Achja: FHEM läuft in der aktuellsten Version mit allen Updates via Lan angebunden auf einem Raspberry Pi.

Beste Grüße,

Thomas
aktuelles FHEM auf Raspberry Pi B

Markus M.

Wenn die Befehle zeitverzögert bearbeitet werden, kann es auch sein dass mit deinem FHEM was nicht stimmt.

Ich hatte allerdings selbst eine Bridge, die ständig die Verbindung verloren hat.
Ich habe sie dann ausgetauscht, der Ersatz hat das Problem nicht mehr.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

Benutzer

Zitat von: Markus M. am 26 September 2015, 11:48:20
Wenn die Befehle zeitverzögert bearbeitet werden, kann es auch sein dass mit deinem FHEM was nicht stimmt.

Ich hatte allerdings selbst eine Bridge, die ständig die Verbindung verloren hat.
Ich habe sie dann ausgetauscht, der Ersatz hat das Problem nicht mehr.

Das FHEM Problem schließe ich aus, da das Verhalten mit der Android App ohne FHEM genau so ist. Werde die Bridge dann wohl tauschen lassen.

Thomas
aktuelles FHEM auf Raspberry Pi B

herrmannj

Hi

yepp, die bridge haben tlw große Streuungen in der Zuverlässigkeit. tauschen ist ein guter Plan. Gibt auch mittlerweile user die den tx aus der bridge ausbauen und direkt an den gpio pins des pi laufen lassen. Das wifi board der bridge ist scheinbar.... suboptimal ;)

Alternativ müsste mMn auch ein usb seriel Wandler (vielleicht über einen arduino) gehen.

Das wäre insgesamt in meinen Augen ein geiles Projekt wenn man noch einen rx an den arduino schweißt - dann könnte man die remotes auch auswerten und an fhem zurückgeben sowie mit intelligenter sw im arduino auch RF Kollisionen erkennen.

Mir fehlt aber Zeit das umzusetzen.

vg
joerg

henryk

Moin,

Zitat von: herrmannj am 26 September 2015, 12:26:20
Das wäre insgesamt in meinen Augen ein geiles Projekt wenn man noch einen rx an den arduino schweißt - dann könnte man die remotes auch auswerten und an fhem zurückgeben sowie mit intelligenter sw im arduino auch RF Kollisionen erkennen.

Das wird so einfach leider nichts. Die WLAN-Milight-Verbindung in der Bridge ist eine serielle Schnittstelle mit nur einer Richtung, da kommt nichts zurück. Die WLAN-Komponente ist auch maximal dumm gehalten und sendet einfach nur die Daten die sie über WLAN bekommt auf dem UART raus. Alle Intelligenz liegt in der anderen Platine.

Was man aber machen kann, ist, das Milight-2.4GHz-Protokoll selber zu implementieren. Ich hab das zu diesem Zwecke reverse engineered: https://hackaday.io/project/5888-reverse-engineering-the-milight-on-air-protocol
Die 2.4GHz-Funkkomponente die man dann noch braucht wäre der PL1167 (oder LT8900, wozu ersterer kompatibel sein soll), was einige Leute erfolgreich benutzen. Ich hab' auch was gebastelt was sowohl empfangen als auch senden mit einem Nordic nRF24L01+ kann, in proof-of-concept-Qualität (tut im Prinzip, aber das Interface zum Host ist nicht zuverlässig, und ich habe grade keine Zeit für diese Baustelle). Eigentlich will ich damit nämlich beliebig viele Remote-IDs haben, um mehr als 4 Lampengruppen anzusteuern.

Zur Zeit benutze ich aber tatsächlich noch die Milight-Bridge. (Hatte bisher 2 oder 3 Ausfälle in ebensovielen Monaten, wo die Bridge wie vom Ursprungsposter beschrieben nicht mehr antwortet und einen power cycle braucht. Einen Rückkanal auf der Ebene gibt's übrigens, was ja schon durch den unreachable-state indiziert wird: Das FHEM-Modul prüft die Verbindung zur Bridge und ändert entsprechend den State. Kommandos werden dann gequeued und abgegeben wenn die Bridge wieder da ist, daher die verzögerte Ausführung.

--
Henryk Plötz
Grüße aus Berlin

herrmannj

Hi Henryk,

ebenfalls interessanter Ansatz.

Der Angang über den Arduino würde auch die Möglichkeit eröffnen die hlqueue im Arduino arbeiten zu lassen, das wäre gut machbar und würde das timing aus fhem ziehen. Deine Interpretation des Protokolls ist doch für RGB eigentlich schon komplett.

Den rx halte ich für eine Nebenbaustelle. Für listen before talk oder für die remotes kann man, muss man aber nicht. Die beschriebenen Chips scheinen ja sowieso Transceiver zu sein.

Brauchst Du support von der fhem modulseite ? Die host com wackelt im arduino oder in fhem ? Welchen mc hast Du dran ?

vg
joerg



Benutzer

Abgesehen davon, dass ich die Bridge tausche hätte ich gerne gewusst ob jemand die Bridge ins Wlan seiner Fritzbox integriert hat, und welche WPA2 Verschlüsselung aktiv ist. Auf der Limitlessled Seite gibt es eine Bridgev4 Anleitung in welcher steht, dass die Bridge NUR unter WPA2 AES stabil läuft. Ich habe in meiner Fritte WPA2 CCMP eingestellt (AES gibt es dort gar nicht), welches aber laut Wikipedia AES zum Verschlüsseln verwendet.

Gruß,

Thomas
aktuelles FHEM auf Raspberry Pi B

Jumbo

Es ist ein bekanntes Problem. Das Netz ist voll damit. Einziger Lösungsansatz bis jetzt ist die Bridge an einen Raspberry pi zu löten.
Hatte ich auch hier mal gepostet. Bei mir funktioniert es seitdem perfekt, nicht einmal die connection verloren.


Benutzer

Zitat von: Jumbo am 28 September 2015, 15:23:22
Es ist ein bekanntes Problem. Das Netz ist voll damit. Einziger Lösungsansatz bis jetzt ist die Bridge an einen Raspberry pi zu löten.
Hatte ich auch hier mal gepostet. Bei mir funktioniert es seitdem perfekt, nicht einmal die connection verloren.

Statusupdate für die Nachwelt:
Problem gelöst durch Tausch. Kein Löten notwendig (in meinem Fall, obwohl ich gerne löte). Die neue Bridge ist stabil und schnell. Ist seit Wochen kein einziges Mal ausgefallen. Ist aber definitiv eine andere Firmware (V1.0.04a-JCY-1) mit WebGUI. Alles Gut! Offensichtlich gibt es hier sehr kreative "Streuungen" bei den Bridges. Macht jetzt endlich Spaß das Zeugs  ;D
aktuelles FHEM auf Raspberry Pi B

thsm

Hi zusammen,

ich ergreife einfach mal den Thread, da ich ähnliches Problem habe.
Also ich besitze auch die MilightBridge v4 und bekomme sie nur mit State unreachable in Fhem eingebunden.
Mit der IOS App klappt aber alles reibungslos.
Kann es sein, dass das Problem ist, das ich FHEM auf einem Windowsrechner betreibe und hier Strawberry portable benutze ?
Ich habe ja gelesen, dass ansich zusätzliche Pakete erforderlich sind, die ich wahrscheinlich nicht in Strawberry portable habe. Oder könnte die Ursache für den State auch eine andere sein ?

Viele Grüße
Thorsten

tobi73

Hallo zusammen,

habe bei mir ein ähnliches verhalten wie thsm beobachtet.
Zwei Milight Bridges im Einsatz, beiden funktionieren mit meiner Smartphone App (Wifi Light Bulb unter Windows Phone) einwandfrei. Unter FHEM ist eine der beiden Bridges extrem unstabil – geht oft in den "unreachable" Status und reagiert dann auch nicht mehr auf Befehle. Die andere funktioniert tadellos.
Scheint also tatsächlich auch an der Bridge zu liegen (eine funktioniert ja, die andere nicht)  aber nicht nur. Steuerung mit der Smartphone App funktioniert bei beiden immer - auch wenn in FHEM ,,unreachable" angezeigt wird.
Scheint also dass die Smartphone App irgendwas anders macht als FHEM. Zeit hatte ich jetzt noch nicht mich genauer mit dem Code zu beschäftigen oder die App zu rev-enngineeren... Hab nur gesehen dass in  MilightDevice jeder Befehl immer 2x sendet ...
Hat jemand ähnliche Beobachtungen gemacht? Vielleicht kann sich der Autor das nochmals ansehen und hat irgendeine Idee?

gruß Tobi

Markus M.

Habt ihr mal versucht zwischen UDP und TCP für Verbindung und Pings zu wechseln?
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

tobi73

yep, hat aber leider nicht geholfen  :(

SmartT

Nabend zusammen,

ich greife den Thread hier einfach noch einmal auf, da mich interessiert ob jemand dieses Problem gelöst hat. Ich habe ebenfalls eine MilightBridge v4, die über easybulb und Fernbedienung absolut zuverlässig funktioniert. Bei der Einbindung in FHEM über Win 10 und Strawberry-Perl (wie bei den beiden Beiträgen oben, aber nicht Strawberry-portable; alles 64-bit) funktioniert die Steuerung über die Weboberfläche für ca. 10 Sekunden tadellos (Farben ändern, an-/ausschalten), dann wechselt der Status zu "unreachable" bzw. "error".

Hier mein Log: (Hoffe das passt so, bin seit 10 Minuten das erstmal in einem Forum angemeldet - bin für alle Tipps offen!  ;D)

2017.02.09 23:54:35 1: starting in console mode
2017.02.09 23:54:35 1: Including fhem.cfg
2017.02.09 23:54:35 3: telnetPort: port 7072 opened
2017.02.09 23:54:36 3: WEB: port 8083 opened
2017.02.09 23:54:36 3: WEBphone: port 8084 opened
2017.02.09 23:54:36 3: WEBtablet: port 8085 opened
2017.02.09 23:54:36 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 134, <$fh> line 43.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 359, <$fh> line 43.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 390, <$fh> line 43.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 411, <$fh> line 43.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 456, <$fh> line 43.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 487, <$fh> line 43.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 514, <$fh> line 43.
Smartmatch is experimental at ./FHEM/31_MilightDevice.pm line 721, <$fh> line 43.
2017.02.09 23:54:38 3: Wohnzimmer_Define: I/O device is MilightBridge
2017.02.09 23:54:38 1: Including ./log/fhem.save
2017.02.09 23:54:38 3: initialUsbCheck return value: This command is not yet supported on windows
2017.02.09 23:54:38 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2017.02.09 23:54:38 0: Featurelevel: 5.7
2017.02.09 23:54:38 0: Server started with 11 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os MSWin32, user HomeServer, pid 9116)
2017.02.09 23:54:50 1: PERL WARNING: Use of uninitialized value $args[2] in pattern match (m//) at ./FHEM/31_MilightDevice.pm line 278.
2017.02.09 23:55:20 1: PERL WARNING: Terminating on signal SIGHUP(1)

Danke im Voraus!