Neues Modul: 30_MilightBridge / 31_MilightDevice

Begonnen von mattwire, 19 Dezember 2014, 01:39:17

Vorheriges Thema - Nächstes Thema

Stoanze01

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...
Zitat von: Markus M. am 12 September 2016, 22:38:29
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!  :)     

KernSani

zumindest eines kann ich beantworten:
ZitatIst 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, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

Stoanze01

Zitat von: KernSani am 31 März 2017, 23:18:34
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:
Zitatprotocol
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!

KernSani

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, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

moonsorrox

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 i5: FHEM-Server 6.1 :: 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

marwal


moonsorrox

Intel-NUC i5: FHEM-Server 6.1 :: 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

TheDestroyer

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?

Zitat von: Stoanze01 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!?)
...

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

speex

#354
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?

Tom111

#355
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!
FHEM 5.9 auf Raspberry Pi - 3B+ - Stretch-5.10.88+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.67
Fritz!Box 7490 OS 07.29 / 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/S300TH/MiLight-Bridge V

speex

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

Tom111

FHEM 5.9 auf Raspberry Pi - 3B+ - Stretch-5.10.88+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.67
Fritz!Box 7490 OS 07.29 / 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/S300TH/MiLight-Bridge V

fhemler

Zitat von: Tom111 am 14 November 2017, 15:00:11
Und?  :)
Das scheint eh die letzte Version zu sein...
Hab nix neueres gefunden... [emoji848]

Tom111

Dann bitte mal die Version vom 31.01.2016 - 02:25:17 versuchen.
FHEM 5.9 auf Raspberry Pi - 3B+ - Stretch-5.10.88+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.67
Fritz!Box 7490 OS 07.29 / 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/S300TH/MiLight-Bridge V