Autor Thema: Neues Modul: 30_MilightBridge / 31_MilightDevice  (Gelesen 49779 mal)

Offline Stoanze01

  • New Member
  • *
  • Beiträge: 21
  • schau ma moi, dann sen´g ma scho!
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #345 am: 31 März 2017, 23:08:06 »
Servus zusammen, muss mich hier nun auch mal mit einbringen! :D

Betreibe seit einigen Monaten mehrere Milights mit GU10 Fassung, an bestehenden Lampen welche über den Unterputz-Schalter bedient werden. Wenn meine MilightBridge über einen längeren Zeitraum von ca. 1ner Std. keine Befehle übermittelt, bekomme ich im Log auch die Meldungen
2017.03.31 12:41:15.116 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 12:57:26.355 1: Timeout for MilightBridge_DoPing reached, terminated process 23786
2017.03.31 12:57:26.355 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:05:06.510 1: Timeout for MilightBridge_DoPing reached, terminated process 24248
2017.03.31 13:05:06.511 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:09:58.579 1: Timeout for MilightBridge_DoPing reached, terminated process 24566
2017.03.31 13:09:58.579 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:54:06.873 1: Timeout for MilightBridge_DoPing reached, terminated process 27218
2017.03.31 13:54:06.874 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:55:23.661 1: Timeout for MilightBridge_DoPing reached, terminated process 27280
2017.03.31 13:55:23.662 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:57:31.879 1: Timeout for MilightBridge_DoPing reached, terminated process 27395
2017.03.31 13:57:31.880 3: BlockingCall for MyMilightBridge1 was aborted
über die hier ja schon seit geraumer Zeit heiß diskutiert wird. Schluss folglich, der vorangehenden Diskusion, schaltet die Bridge ja anscheinend in eine art Ruhe-, Ecomodus und Logt fröhlich vor sich hin! (Echt kacke!)
Kann ich irgendwie verhindern das diese in den Ruhe-, Ecomodus geht? Den der Logeintrag müllt einfach nur den Log zu! (habe schon überlegt ein notify zu senden wenn die Bridge den status unreachable meldet, um diese am 'leben' zu halten) (evtl. schon jemand einen solchen Workaround versucht!?)

Zudem ist mir aber auch folgendes Aufgefallen:
Wenn ich die Milight vom Strom nehme (Wandschalter drücken) und wieder Strom gebe, geht die Milight in den letzten Zustand, wie bereits von Markus M. erwähnt...
Gar nicht, es wird immer der letzte Zustand geschaltet und du weisst zwischendrin nicht, wann du die Lampe steuern kannst.

Wenn ich nun aber die Lampe vom Strom nehme, die Bridge längere Zeit keine Befehle sendet und sich quasi abschaltet und ich dann die Lampe wieder mit Strom versorge geht diese gedimt, in einer Farbe an die nicht der des letzten Zustandes entspricht!?!  ???
Hat, oder kann zufällig jemand das gleiche Verhalten bestätigen/beobachten??
Mich würde nun interessieren mit welchem Parameter oder Vorgehensweise ich diesen Zustand festlegen kann. Also in welchen Zustand die Miligth geht wenn die Bridge einen Timeout hat und ich die Lampe wieder mit Strom versorge! Weiß wäre nice  8), da ich meist beim betreten der Wohnung erstmal ein "normales" Licht (weiß) benötige, erst im laufe des Abends möchte ich eine bestimmte Licht-Atmosphäre schaffen, was ich dann auch ganz einfach mit FHEM realisieren kann!  ;D     

Bsp.: Yeelight, habe ich eine im Einsatz, (leider nur mit einer E27 Fassung erhältlich) welche ich beim einrichten über die App auf weiß eingestellt habe, bevor ich dieser dann den Internetzugang unterbunden habe. (Musste dies so nachkonfigurieren da ich natürlich bei der ersten Implementierung die Lampe nicht auf weiß eingestellt hatte)   ::)
Dann geht diese beim einschalten (Stromkreis geschlossen) auch immer in weiß an!  :)
Wenn die Yeelight sich an der Fritzbox anmeldet, wird mit einem notify der connect Befehl gesendet damit ich diese auch gleich wieder aus FHEM heraus steuern kann. Klappt super!

Ist es möglich die Devices der Bridge auf Erreichbarkeit zu prüfen? (Um bei Erreichbarkeit gleich einen 'set hsv' Befehl auszulösen?)

Und da ich ja gerade schon hier bin:
Die Bridge kommuniziert über das UDP Protokoll das keine Quittung liefert, jedoch kann man auch auf TCP umstellen. Welche Vor-, Nachteile hat es auf TCP umzustellen? Bekommt man über TCP eine Quittung ob die Nachricht gesendet oder sogar angekommen ist!? Der 'Device specific help' konnte ich leider keine Vor-, oder Nachteile des TCP Protokolls entnehmen. 


Bin schon jetzt gespannt auf eure Antworten!  :)     
FHEM auf RaspberryPi3; Funk-, & IR-Modul, HarmonyHub, Yeelight RGBW, Milights, FritzBox, Xiaomi Flora Monitor, MAX!-Cube mit  Thermostaten & Fensterkontakten, Amazon-DashBtn

Offline KernSani

  • Hero Member
  • *****
  • Beiträge: 1440
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #346 am: 31 März 2017, 23:18:34 »
zumindest eines kann ich beantworten:
Zitat
Ist es möglich die Devices der Bridge auf Erreichbarkeit zu prüfen? (Um bei Erreichbarkeit gleich einen 'set hsv' Befehl auszulösen?)

Und da ich ja gerade schon hier bin:
Die Bridge kommuniziert über das UDP Protokoll das keine Quittung liefert, jedoch kann man auch auf TCP umstellen. Welche Vor-, Nachteile hat es auf TCP umzustellen? Bekommt man über TCP eine Quittung ob die Nachricht gesendet oder sogar angekommen ist!? Der 'Device specific help' konnte ich leider keine Vor-, oder Nachteile des TCP Protokolls entnehmen. 
FHEM kommuniziert mit der Bridge über UDP/TCP, die Bridge selbst funkt aber an die Birnen. Die Birnen nehmen stumpf entgegen (sofer sie können - sprich Strom haben). Ein Rückmeldung ist nicht möglich
RasPi: RFXTRX, HM, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline Stoanze01

  • New Member
  • *
  • Beiträge: 21
  • schau ma moi, dann sen´g ma scho!
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #347 am: 31 März 2017, 23:56:38 »
zumindest eines kann ich beantworten:FHEM kommuniziert mit der Bridge über UDP/TCP, die Bridge selbst funkt aber an die Birnen. Die Birnen nehmen stumpf entgegen (sofer sie können - sprich Strom haben). Ein Rückmeldung ist nicht möglich

Ach kacke, somit kann man wirklich auf keine Weiße prüfen ob ein Device gerade verfügbar ist oder nicht!  :-\

@KernSani
Die Bridge kann man aber entweder über UDP oder TCP kommunizieren lassen, liegt zwar beides im OSI-Layer4, sind aber dennoch unterschiedliche Protokolle....

UDP sendet die Daten, ohne sich um den Verbleib zu kümmern und bietet lediglich eine Checksummen-Funktion, und deren Prüfung beim Empfänger. Es wird allerdings bei fehlerhaften Checksummen nichts unternommen - dies bleibt der Applikation überlassen.
TCP stellt sicher, dass der Client die Daten korrekt erhalten hat, und dass sie in der richtigen Reihenfolge ankommen. Dabei geht jedoch einiges an Bandbreite verloren, wodurch die Übertragung verlangsamt wird.

siehe Hier https://glossar.hs-augsburg.de/Unterschiede_zwischen_TCP/UDP
Ausführlichere Beschreibung der Unterschiede https://www.computerbase.de/forum/showthread.php?t=61320

Im Modul 'MilightBridge' unter 'Device specific help' ist zu lesen:
Zitat
protocol
Default: udp. Change to tcp if you have enabled tcp mode on your bridge.

Aber vielen Dank für die Info mit der Funk-Kommunikation zwischen Bridge und Device, wusste ich nicht!
FHEM auf RaspberryPi3; Funk-, & IR-Modul, HarmonyHub, Yeelight RGBW, Milights, FritzBox, Xiaomi Flora Monitor, MAX!-Cube mit  Thermostaten & Fensterkontakten, Amazon-DashBtn

Offline KernSani

  • Hero Member
  • *****
  • Beiträge: 1440
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #348 am: 01 April 2017, 08:10:33 »
Mir ist schon klar, dass es einen Unterschied zwischen UDP und TCP gibt ;-) Ich hatte übrigens prototypisch mal eine bridge gebaut, die direkt über USB angesprochen wird: https://forum.fhem.de/index.php/topic,68515.msg599838.html#msg599838
RasPi: RFXTRX, HM, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 2730
  • Online
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #349 am: 25 Juni 2017, 12:40:39 »
Meine Frage hier ohne das ich jetzt den gesamten Thread durchforsten muss, kann ich mit dem Modul diesen Controller ansteuern, weiß das hier zufällig jemand.
XCSOURCE Magic UFO-WiFi LED-Controller DC12-24 V, LD382
Intel-NUC i3: FHEM-Server 5.8 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline marwal

  • Newbie
  • Beiträge: 2
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #350 am: 26 Juni 2017, 07:12:23 »
Das funktioniert mit dem Modul WifiLight:

https://wiki.fhem.de/wiki/WifiLight


Beste Grüße
FHEM 5.8 | RPi3MB - Jessie | DS415+ | RaspberryMatic
CUL433 | CUL868 | HM-CFG-USB-2 | nanoCUL433
Yamaha-RX679 | MC-WX030 | Sonos-Play1 | Sonos-Play5
IN6012HD | div. HM | div. HM-IP | HUE | MiLight

Offline moonsorrox

  • Hero Member
  • *****
  • Beiträge: 2730
  • Online
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #351 am: 26 Juni 2017, 11:44:47 »
Danke...  ;)
Intel-NUC i3: FHEM-Server 5.8 :: Perl v5.18.2

Homematic: HM-USB-CFG2,HM-CFG-LAN Adapter, HM-LC-BL1-FM, HM-LC-Sw1PBU-FM, HM-LC-Sw1-PI-2, HM-WDS10-TH-O, HM-CC-TC, HM-LC-SW2-FM

Offline TheDestroyer

  • New Member
  • *
  • Beiträge: 9
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #352 am: 29 Juni 2017, 17:07:24 »
Servus zusammen, ich schließe mich Stoanze01 an, habe das selbe Problem, mein Log ist richtig zugemüllt mit der MilightBridge.

Ich schalte die Bridge nie aus, sie läuft die ganze zeit durch.
Gibt es vielleicht die Möglichkeit das man den log von der MilightBridge abstellt?

Servus zusammen, muss mich hier nun auch mal mit einbringen! :D

Betreibe seit einigen Monaten mehrere Milights mit GU10 Fassung, an bestehenden Lampen welche über den Unterputz-Schalter bedient werden. Wenn meine MilightBridge über einen längeren Zeitraum von ca. 1ner Std. keine Befehle übermittelt, bekomme ich im Log auch die Meldungen
2017.03.31 12:41:15.116 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 12:57:26.355 1: Timeout for MilightBridge_DoPing reached, terminated process 23786
2017.03.31 12:57:26.355 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:05:06.510 1: Timeout for MilightBridge_DoPing reached, terminated process 24248
2017.03.31 13:05:06.511 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:09:58.579 1: Timeout for MilightBridge_DoPing reached, terminated process 24566
2017.03.31 13:09:58.579 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:54:06.873 1: Timeout for MilightBridge_DoPing reached, terminated process 27218
2017.03.31 13:54:06.874 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:55:23.661 1: Timeout for MilightBridge_DoPing reached, terminated process 27280
2017.03.31 13:55:23.662 3: BlockingCall for MyMilightBridge1 was aborted
2017.03.31 13:57:31.879 1: Timeout for MilightBridge_DoPing reached, terminated process 27395
2017.03.31 13:57:31.880 3: BlockingCall for MyMilightBridge1 was aborted
über die hier ja schon seit geraumer Zeit heiß diskutiert wird. Schluss folglich, der vorangehenden Diskusion, schaltet die Bridge ja anscheinend in eine art Ruhe-, Ecomodus und Logt fröhlich vor sich hin! (Echt kacke!)
Kann ich irgendwie verhindern das diese in den Ruhe-, Ecomodus geht? Den der Logeintrag müllt einfach nur den Log zu! (habe schon überlegt ein notify zu senden wenn die Bridge den status unreachable meldet, um diese am 'leben' zu halten) (evtl. schon jemand einen solchen Workaround versucht!?)
...

Offline Beta-User

  • Hero Member
  • *****
  • Beiträge: 2084
  • Wo ist das Handbuch hin?!?
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #353 am: 29 Juni 2017, 17:30:49 »
Es ist nicht nur so, dass das log zugemüllt wird, sondern nach meiner Erfahrung wird FHEM tatsächlich immer für eine Denkpause blockiert.

Besser also: anderes Modul nehmen (wifilight); diese Empfehlung ist aber ohne Gewähr, dass das besser ist (wird aber aktiver betreut).

Oder: Bridge(s) gegen eine Eigenbau-Bridge tauschen (so hab' ich das gelöst).

Gruß, Beta-User
stretch@HP-T5740 | ConfigDB | VCCU | MySensors seriell (2.2.0-beta, RS485+nRF24) | DS18B20@MySensors | Milight@ESP-GW | SIGNALduino | MapleCUN
Bitte beachten: https://forum.fhem.de/index.php/topic,71806.0.html
Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline speex

  • Full Member
  • ***
  • Beiträge: 125
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #354 am: 09 November 2017, 18:16:54 »
Stets wenn die "Blocking timeout" Meldungen ins Log wandern gehen die Lampen nicht mehr.

Lässt sich das nicht unterbinden hat keiner eine Idee oder ist keiner Betroffen?
« Letzte Änderung: 09 November 2017, 19:56:12 von speex »

Offline Tom111

  • Full Member
  • ***
  • Beiträge: 430
  • Das Ziel ist das Ziel :D
    • Tom hat gar keine Homepage!
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #355 am: 09 November 2017, 18:31:47 »
Tja, manchen Leuten kümmern nun mal nicht die Probleme anderer!
Ich habe die Version "30_MilightBridge.pm" vom 24.06.2016 09:07:17 und dann das Modul exclude_from_update gesetzt, warum weiß ich nicht mehr so genau.
Aber ich habe keinerlei Probleme mit dem Modul, alles funktioniert tadellos!

Also, die, die Probleme mit dem Modul haben, einfach mal die Version vom 24.06.2016 ausprobieren!
« Letzte Änderung: 09 November 2017, 18:34:52 von Tom111 »
FHEM 5.8 auf Raspberry Pi - 2B - Wheezy-4.9.50+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.66
Fritz!Box 7490 OS 06.92 / Fritz!Dect200 / Fritz!Powerline 546E
FS20ST-4/ FS20 DI-5/ FS20LS/ FS20 PIRI-2-KU/ FS20 TFK/ FS20S4A/ FS20 SU-3/ FS20 S20-3
HMS100TF/ FHT80TF-2/ ASH2200/ MiLight-Bridge V4

Offline speex

  • Full Member
  • ***
  • Beiträge: 125
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #356 am: 09 November 2017, 20:03:05 »
Danke für den Tipp, das werd ich probieren.

Eine vielleicht etwas abenteuerliche Brechstangen Methode wäre auch einfach die Milight Bridge an eine funktsteckdose zu hängen und per notify aus/an zu  schalten.  :o

Offline Tom111

  • Full Member
  • ***
  • Beiträge: 430
  • Das Ziel ist das Ziel :D
    • Tom hat gar keine Homepage!
Antw:Neues Modul: 30_MilightBridge / 31_MilightDevice
« Antwort #357 am: 14 November 2017, 15:00:11 »
Danke für den Tipp, das werd ich probieren.
Und?  :)
FHEM 5.8 auf Raspberry Pi - 2B - Wheezy-4.9.50+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.66
Fritz!Box 7490 OS 06.92 / Fritz!Dect200 / Fritz!Powerline 546E
FS20ST-4/ FS20 DI-5/ FS20LS/ FS20 PIRI-2-KU/ FS20 TFK/ FS20S4A/ FS20 SU-3/ FS20 S20-3
HMS100TF/ FHT80TF-2/ ASH2200/ MiLight-Bridge V4