[32_YeeLight.pm][Devel 32_YeeLightBridge.pm] - Modul für Yeelight Wifi Lampen

Begonnen von thaliondrambor, 14 Dezember 2016, 22:21:55

Vorheriges Thema - Nächstes Thema

bjbrill

Hallo,

das blinken kommt mit meiner Alarmanlage echt toll,
Alarmwarnung Gelb, Volles auslösen dann rot und zur Bestätigung des abschaltens blau.
Ich hab mal kurz über deine tolle Anleitung gelesen, die ich super verständlich finde, großes Lob.
Eine kleine Sache ist mir aufgefallen bei meinem Ubuntu funktioniert:
sudo CPAN install JSON::XS nicht,
bei mir muss das CPAN klein geschrieben sein also so:
sudo cpan install JSON::XS.
Es kann sein das da ein Raspi anders reagiert, wollte es nur erwähnt haben.
Ich wünsche schöne Feiertage und viel Erholung.
Schöne Grüße Björn


Ubuntu-Server, Dect200, Jeelink, Unifi, ESP32, Alexa, Tasmota, zigbee2mqtt, OpenDTU.

thaliondrambor

#31
Zitat von: bjbrill am 23 Dezember 2016, 17:53:24
Eine kleine Sache ist mir aufgefallen bei meinem Ubuntu funktioniert:
sudo CPAN install JSON::XS nicht,
bei mir muss das CPAN klein geschrieben sein also so:
sudo cpan install JSON::XS.

Da hast du recht, ist mir irgendwie durchgerutscht, bei meinem Debian muss es auch klein sein. Ist geändert. Danke.

Auch ein frohes Fest wünsche ich.

Edit: Ich habe es tatsächlich geschafft, dass die Bridge zum Großteil funktioniert. Ich bin wirklich ziemlich stolz auf mich gerade, dass ich das hinbekommen habe :-)

Folgende Änderungen gibt es damit im Devel-Branch:

Zitat von: thaliondrambor am 14 Dezember 2016, 22:21:55
Anleitung für 32_YeeLightBridge.pm

1 - Einrichten in FHEM und Define der Bridge

Die 32_YeeLightBridge.pm und die 32_YeeLight.pm aus dem Devel-Branch herunterladen (https://github.com/thaliondrambor/32_YeeLight.pm/tree/devel), in euren FHEM-Ordner packen und einlesen mit:
reload 32_YeeLight.pm
reload 32_YeeLightBridge.pm


Die Bridge wird wie folgt definiert:
define [NAME] YeeLightBridge

Hinweis: Beide Dateien (YeeLight und YeeLightBridge) müssen aus dem Devel-Branch geholt werden, ansonsten kann es zu Problemen kommen.
Hinweis: Es kann nur eine Bridge definiert werden.

2 - Funktion der Bridge

Die Bridge hört im Netzwerk auf Multicast-Nachrichten der Lampen. Diese werden gesendet, wenn die Lampen hardware-seitig eingeschaltet werden (Spannung) und im Anschluss in regelmäßigen Abständen. Außerdem ist es mit einer Such-Nachricht möglich, dass aktiv der Multicast angefordert wird, was leider im Modul noch nicht funktioniert.

Über die Multicast-Nachrichten können weitere Informationen bezogen werden, die über einen normalen StatusRequest nicht erhältlich sind. Dies sind:

  • ID - eine einzigartige Identifizierungskennung
  • IP - musste bis jetzt z.B. über den Router gesucht werden
  • FW-VER - die aktuelle Firmware-Version
  • MODEL - das Lampenmodel (z.B. color)
  • support - unterstütze Methoden

Über die ID werden bereits definierte Geräte gesucht. Wird eines gefunden, so werden alle Daten überprüft und aktualisiert. Die Aktualisierung der IP-Adresse kann mit dem Attribut updateIP (dazu mehr später) unterbunden werden.
Wenn kein Gerät unter der ID gefunden wird, dann wird nach der IP-Adresse gesucht. Wird hier ein Gerät gefunden, so werden auch wieder die Daten aktualisiert. Durch das Attribut updateIP wird im Umkehrschluss hierbei nicht die ID geändert.
Wird auch mittels der IP-Adresse kein Gerät gefunden, dann wird ein neues angelegt (wenn autocreate aktiv ist). Der Name lautet dann: YeeLight_[ID] oder YeeLight_[NAME], wenn der Name in der Lampe schonmal mit dem "set name"-Befehl gesetzt wurde.

3 - Set - Steuern der Bridge

Platzhalter

4 - Attribute

Folgende Attribute stehen zur Verfügung:


  • defaultramp
  • updateIP

defaultramp
Das Attribut "defaultramp" hat die selbe Funktion, wie schon bei den Lampen selber, gilt aber für alle Lampen. Dabei gilt folgende Priorität: Wird eine Rampenzeit im Befehl angegeben, so hat diese immer Vorrang. Fehlt diese, so wird die Rampenzeit aus dem Attribut "defaultramp" des Devices genutzt. Wenn auch dieses nicht gesetzt ist, so wird die Rampenzeit aus dem Attribut "defaultramp" der Bridge genutzt. Wenn auch dieses fehlt, dann beträgt die Rampenzeit "0" und es werden alle Befehle sofort ausgeführt. Es gilt also Befehl > Device > Bridge > 0.

updateIP
Mit dem Attribut "updateIP" kann verhindert werden, dass ein von Hand angelegtes Device durch die Bridge eine andere IP oder ID bekommt. Standartmäßig (wenn das Attribut nicht gesetzt ist) ist diese Funktion aktiviert. Dadurch werden die Lampen durch die ID identifiziert und die IP angepasst, wenn sie z.B. durch den DHCP geändert wurde.
Das Attribut kann sowohl in der Bridge, als auch im Device selber gesetzt werden, wobei das Attribut im Device Vorrang hat. "0" bedeutet, dass keine Aktualisierung stattfindet. Bei "1" wird die IP/ID aktualisiert.

Ich hoffe es läuft ohne größere Probleme. Wenn keine über die Feiertage gemeldet werden, dann kommt die Bridge auch in den Master-Branch.

Gruß
thaliondrambor

f-zappa

Zitat von: bjbrill am 23 Dezember 2016, 17:53:24
Eine kleine Sache ist mir aufgefallen bei meinem Ubuntu funktioniert:
sudo CPAN install JSON::XS nicht,
bei mir muss das CPAN klein geschrieben sein also so:
sudo cpan install JSON::XS.
Es kann sein das da ein Raspi anders reagiert, wollte es nur erwähnt haben.

In dem Fall ist die Arie mit dem CPAN aber zum Glück sowieso unnötig. Das Perl-Modul ist bei Ubuntu und  Raspbian als Paket dabei.
# Ubuntu 16.04.1 LTS
libjson-xs-perl/stable,now 2.340-1+b2 armhf [installed]
  module for manipulating JSON-formatted data (C/XS-accelerated)
# Raspbian GNU/Linux 8
libjson-xs-perl/xenial 3.010-2build1 amd64
  module for manipulating JSON-formatted data (C/XS-accelerated)


Gruß, Uli

f-zappa

Zitat von: thaliondrambor am 23 Dezember 2016, 18:41:08
Edit: Ich habe es tatsächlich geschafft, dass die Bridge zum Großteil funktioniert. Ich bin wirklich ziemlich stolz auf mich gerade, dass ich das hinbekommen habe :-)
Herzlichen Glückwunsch! Es ist ja gar nicht mal so viel Code, aber er erschließt sich mir noch nicht auf den ersten Blick.
Ich vermute mal, ich muss zuerst mein YeeLight löschen und dann
define ylb YeeLightBridge
definieren, anschließend werden alle vorhandenen Lichter erkannt und als Device angelegt?

Aber .. jetzt genieß erst mal das Weihnachtsfest! Uns hast du mit dem YeeLight-Modul ja schon ein schönes Geschenk gemacht :-)

Gruß, Uli

Morrino

Hi

hast du auch geplant in die Bridge (wenn du damit das Gateway meinst) die anderen Yeelight Lampen mit zu unterstützen?
Bin von der Nachttisch Lampe immer noch sehr angetan. ;)

Übrigens scheint aktuell auch mal wieder die Schreibtisch Lampe lieferbar zu sein:
http://www.gearbest.com/table-lamps/pp_363779.html?wid=21

thaliondrambor

#35
Zitat von: f-zappa am 23 Dezember 2016, 23:23:14
Herzlichen Glückwunsch! Es ist ja gar nicht mal so viel Code, aber er erschließt sich mir noch nicht auf den ersten Blick.
Ich vermute mal, ich muss zuerst mein YeeLight löschen und dann
define ylb YeeLightBridge
definieren, anschließend werden alle vorhandenen Lichter erkannt und als Device angelegt?

Aber .. jetzt genieß erst mal das Weihnachtsfest! Uns hast du mit dem YeeLight-Modul ja schon ein schönes Geschenk gemacht :-)

Gruß, Uli


Nein, das Löschen sollte eigentlich gar nicht nötig sein. Ein Neustart von FHEM sollte reichen (da sich was in der DefFn geändert hat). Anschließend sollte das Modul deine bereits angelegten Lampen automatisch den Multicast-Nachrichten zuordnen können und diese so anpassen, dass sie nun über die eindeutige ID anstatt der IP zugeordnet werden (außer du hast das Attribut "updateIP" auf "0" gesetzt).

Und der Code für die "Bridge" ist wirklich sehr kurz. Es wird nur die Verbindung zur Multicastgruppe aufgebaut und wenn Nachrichten empfangen werden, dann werden sie an das YeeLight-Modul weitergegeben. Dort gibt es dann zwei Funktionen (YeeLightBridge_xxx) die die Auswertung vornehmen. Der Code ist dann noch etwas mehr.

Zitat von: Morrino am 24 Dezember 2016, 10:10:18
Hi

hast du auch geplant in die Bridge (wenn du damit das Gateway meinst) die anderen Yeelight Lampen mit zu unterstützen?
Bin von der Nachttisch Lampe immer noch sehr angetan. ;)

Übrigens scheint aktuell auch mal wieder die Schreibtisch Lampe lieferbar zu sein:
http://www.gearbest.com/table-lamps/pp_363779.html?wid=21

Nein, in diesem Fall ist es leider nicht das (hardware) Gateway von Xiaomi, sondern nur eine Softwarelösung für die WLAN-fähigen Lampen. Somit können diese automatisch angelegt werden und man bekommt noch ein paar mehr Informationen, die es vorher nicht gab (die wichtigste dabei ist die eindeutige ID).

Ich würde gerne auch das Gateway von Xiaomi ausprobieren, aber es ist immer noch kaum wo zu haben...außer man möchte 100€ dafür auf ebay ausgeben.

Edit:
Folgendes hat sich im Devel-Branch geändert:
Zitat von: thaliondrambor am 14 Dezember 2016, 22:21:55
00 - Entwicklung

...
...
...


04 - Set - Steuern der Lampen

blink - Befehl
Mit diesem Befehl kann die Lampe blinken. Werden keine weiteren Parameter angegeben, blinkt die Lampe 3 mal für je 1s (entspricht 1 Hz) in der aktuellen Farbe. Danach geht sie wieder in den vorherigen Zustand zurück. Mit dem ersten Parameter, kann eingestellt werden, wie oft die Lampe blinken soll. Der zweite Parameter gibt den Farbmodus vor. Dabei gibt es die Wahl zwischen "1" (RGB) und "2" (CT). Der dritte Parameter ist dann die Farbe. Entweder in Hex für RGB "000001" - "FFFFFF" oder als Farbtemperatur für CT "1700" - "6500". Der vierte Parameter gibt die Zeit eines Blinkvorganges in Millisekunden an und muss mindestens 100 ms betragen.

Syntax und Beispiele:
set [NAME] blink <COUNT> <MODE> <COLOR> <TIME>
set SchlafzimmerLicht blink -> Lampe blinkt 3 mal in der aktuellen Farbe oder der letzten Farbe, wenn die Lampe aus ist, für insgesamt 3s und geht dann wieder in den Ausgangszustand
set SchlafzimmerLicht blink 5 -> Lampe blinkt 5 mal in der aktuellen Farbe oder der letzten Farbe, wenn die Lampe aus ist, für insgesamt 3s und geht dann wieder in den Ausgangszustand
set SchlafzimmerLicht blink 10 1 FF0000 100 -> Lampe blinkt 4 mal in der Farbe Rot für insgesamt 1s (entspricht 10Hz) und geht dann wieder in den Ausgangszustand
set SchlafzimmerLicht blink 4 2 3500 5000 -> Lampe blinkt 4 mal mit eine Farbtemperatur von 3500 K für insgesamt 20s (entspricht 0,2Hz) und geht dann wieder in den Ausgangszustand


on-for-timer, off-for-timer, intervals
Diese Befehle sind aus der SetExtensions.pm entnommen und werden wie von anderen Modulen bekannt ausgeführt.

Syntax und Beispiele:
set [NAME] on-for-timer [TIME]
set SchlafzimmerLicht on-for-timer 120 -> Lampe ist für 120 Sekunden an (es wird defaultramp genutzt)

set [NAME] off-for-timer [TIME]
set SchlafzimmerLicht off-for-timer 180 -> Lampe ist für 180 Sekunden aus (es wird defaultramp genutzt)

set [NAME] intervals [INTERVAL1] <INTERVAL2> ...
set SchlafzimmerLicht intervals 07:00-08:00 16:30-18:00 -> Lampe wird 07:00 Uhr und 16:30 Uhr eingeschaltet und 08:00 Uhr und 18:00 Uhr ausgeschaltet (es wird defaultramp genutzt)


Anleitung für 32_YeeLightBridge.pm

...
...
...


3 - Set - Steuern der Bridge

Platzhalter

4 - Attribute

Folgende Attribute stehen zur Verfügung:


  • defaultramp
  • updateIP
  • timeout
  • keepAlive

...
...
...


timeout
Mit dem Attribut "timeout" kann eingestellt werden, nach wie vielen Sekunden ohne Antwort auf einen gesendeten Befehl, die Verbindung als "disconnected" gilt. Der Timeout beträgt ohne das Attribut 3 Sekunden. Das Attribut kann sowohl in der Bridge, als auch im Device selber angelegt werden, wobei das Attribut im Device Vorrang hat. Ist der Timeout auf "0" gestellt, so werden fehlende Rückmeldungen die Lampe nie auf "disconnected" setzen. Die Nachricht, welche nicht innerhalb des Timeouts beantwortet wurde, wird in der ErrorQueue gespeichert. Hat die Lampe den Status "disconnected" so können keine Befehle an die Lampe gesendet werden, außer "reopen".

keepAlive
Wenn keine Befehle an die Lampe gesendet werden, kann es sehr lange dauern, bis erkannt wird, dass die Lampe nicht mehr erreichbar ist. Deswegen kann mit dem Attribut "keepAlive" ein regelmäßiges Signal an die Lampe gesendet werden. Der minimale Zeitabstand für zwei keepAlive beträgt 60 Sekunden. Das Attribut kann sowohl in der Bridge, als auch im Device selber angelegt werden, wobei das Attribut im Device Vorrang hat. Ist das Attribut nicht gesetzt, so wird kein regelmäßiges Signal gesendet (entspricht keepAlive = 0). Zum Erkennen von gestörten Verbindungen, wird dabei das Attribut "timeout" genutzt. Sollte dieses auf "0" gestellt sein, so kann auch mit "keepAlive" keine Störung erkannt werden.
Das gesendete Signal ist ein StatusRequest, so dass so auch eine regelmäßige Statusabfrage möglich ist. Wobei die Readings der Lampen im Normalfall sowie so aktuell sind.

Ich habe festgestellt, dass damit erstmal fast alle Funktionen der API für die Lampen umgesetzt sind. Es fehlen nur noch zwei:

Das erste sind Cron-Jobs (cron_add, cron_get, cron_del) mit denen man nach einer bestimmten Zeit (Timer) etwas ausführen kann. Allerdings ist der einzige mögliche Befehl momentan nur das Ausschalten. Deswegen habe ich mich dafür entschieden, dass ganze lieber über die SetExtensions.pm mit "on-for-timer", "off-for-timer" und "intervals zu erledigen.

Die zweite fehlende Funktion ist der Musik-Modus. Momentan ist die Lampe ein TCP-Server mit welchem sich FHEM verbindet und so die Befehle sendet. Diese Verbindung hat allerdings zwei Einschränkungen. Erstens sind so nur maximal 4 Verbindungen zulässig (eine davon baut FHEM auf, ich habe keine Idee, wieso dort noch drei andere dazu kommen sollten). Zweitens kann man so maximal 60 Befehle pro Minute an die Lampe senden. Auch hier denke ich, dass das im Normalfall kein Problem sein sollte. Während des Testens und Programmierens ist es mir zweimal passiert, dass die Lampe keine Befehle mehr entgegengenommen hat, aber da habe ich auch echt viel geschickt.
Man kann diese Beschränkungen umgehen, in dem man den Musik-Modus einschaltet. Dazu muss man erstmal die normale TCP-Verbinung aufbauen, dazu einen TCP-Server und dann der Lampe mitteilen, dass sie sich mit dem TCP-Server verbinden soll. Über diese neue Verbindung gibt es dann keine Beschränkungen mehr.
Auch wenn ich grundsätzlich der Meinung bin, dass es besser ist, keine Beschränkung zu haben als nur 60 Befehle pro Minute, ist das erstmal recht weit unten auf meiner Prioritätenliste. Dafür müsste ich mich erstmal damit beschäftigen, wie ich in FHEM ein TCP-Server aufbaue, der non-blocking ist.
Solltet ihr öfter mal an die 60-Befehle-Grenze kommen, so teilt mir dies bitte mit.

Neben dem Fertigstellen der Anleitung, steht auf meinem Plan, dass ich die unterschiedlichen Modele (RGB, W, LED-Stripe) mit ihren jeweiligen unterstützten Funktionen hinzufüge.

cc13

Hallo Thaliondrambor,

wow, kann ich da nur sagen. Nachdem nun mein Urlaub begonnen hat, habe ich mich wieder mit meiner YeeLight beschäftigt und sehe, was du in der Zwischenzeit geschaffen hast. Respekt und mein Dank.

Ich habe das Modul installiert und konnte es sofort in Betrieb nehmen. Ein paar Anmerkungen dazu:

ZitatHinweis: Wenn das Attribut "defaultramp" gesetzt ist und ein Befehl trotzdem sofort ausgeführt werden soll, dann muss als Rampendauer 0 im Befehl angegeben werden.

Ic habe "defaultramp" auf 5000 stehen und das funktioniert auch. Nun habe ich ab und an den Bedarf, die Lampe ohne Verzögerung ein/auszuschalten und habe das mit


set WohnzimmerLicht on 0


bzw.


set Wohnzimmerlicht off 0


probiert. Der 0-Wert greift allerdings nicht und die Lampe wird weiterhin mit Verzögerung ein/ausgeschaltet. Mach ich da beim Befehl etwas falsch?

Das nächste was ich mich frage, es gibt ein Abfall-Modul, welches auch von GitHub kommt und wie folgt installiert wird:


update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt


Dabei hat man die Möglichkeit, direkt über die Update-Funktion von fhem die neuesten Modulversionen installieren zu lassen. Kannst du das auch so umsetzen?

Und das nächste und vorerst letzte, hier im Thread ist von einer Nachttischlampe die Rede, welche allerdings über Bluetooth angesprochen wird. Der Raspi 3 hat ein solches Modul eingebaut, kann das evtl. dafür verwendet werden, um die Lampe anzusprechen?

Grüße,
cc13

thaliondrambor

#37
Zitat von: cc13 am 26 Dezember 2016, 18:13:08
Ic habe "defaultramp" auf 5000 stehen und das funktioniert auch. Nun habe ich ab und an den Bedarf, die Lampe ohne Verzögerung ein/auszuschalten und habe das mit


set WohnzimmerLicht on 0


bzw.


set Wohnzimmerlicht off 0


probiert. Der 0-Wert greift allerdings nicht und die Lampe wird weiterhin mit Verzögerung ein/ausgeschaltet. Mach ich da beim Befehl etwas falsch?

So sollte es tatsächlich funktionieren, aber da haben sich gleich zwei Fehler in den Code geschlichen. Ist nun im Devel-Branch behoben.

Zitat von: cc13 am 26 Dezember 2016, 18:13:08
Das nächste was ich mich frage, es gibt ein Abfall-Modul, welches auch von GitHub kommt und wie folgt installiert wird:


update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt


Dabei hat man die Möglichkeit, direkt über die Update-Funktion von fhem die neuesten Modulversionen installieren zu lassen. Kannst du das auch so umsetzen?

Ich würde eher dazu tendieren, das Modul in das offizielle Repository aufzunehmen, aber ich habe mich erstens noch garnicht damit beschäftigt, was ich dafür tun muss und zweitens würde ich das Modul gerne noch länger testen, bevor es dann die FHEM-Installation von irgendwelchen Leuten zerschießt.

Zitat von: cc13 am 26 Dezember 2016, 18:13:08
Und das nächste und vorerst letzte, hier im Thread ist von einer Nachttischlampe die Rede, welche allerdings über Bluetooth angesprochen wird. Der Raspi 3 hat ein solches Modul eingebaut, kann das evtl. dafür verwendet werden, um die Lampe anzusprechen?

Grüße,
cc13

Ein kurzer Besuch auf Google ergab, dass es auch eine API für die Bluetooth-Lampen gibt. Die heißt Yeelight Blue Message Interface. Es würde mich schon reizen, dass auch in das Modul zu integrieren, allerdings habe ich keine passenden Lampen. Es gibt dafür auch bereits Umsetzungen mit python und node-js. Eventuell kann man da was einfaches integrieren, was darauf zugreift.

Für mich ist eher das Gateway http://xiaomi-mi.com/mi-smart-home/xiaomi-mi-gateway-2/ als nächstes interessant. Damit kann man auch die Taster und Sensoren von Xiaomi mit einbinden, welche auch günstig sind.

Edit:
Ich habe einen Merge vom Devel- mit dem Master-Branch durchgeführt.

cc13

Zitat
So sollte es tatsächlich funktionieren, aber da haben sich gleich zwei Fehler in den Code geschlichen. Ist nun im Devel-Branch behoben.

Neue Version eingespielt und es funktioniert wie vorgesehen. Danke!

Das Gateway sehe ich nirgends zum kauf, zumindest nicht bei den mir bekannten Versendern. Interessant ist das schon, ich bleibe dran.

Morrino

Zitat von: thaliondrambor am 26 Dezember 2016, 19:25:32

Für mich ist eher das Gateway http://xiaomi-mi.com/mi-smart-home/xiaomi-mi-gateway-2/ als nächstes interessant. Damit kann man auch die Taster und Sensoren von Xiaomi mit einbinden, welche auch günstig sind.


Anscheinend wird hier auch schon am Gateway gearbeitet:
https://forum.fhem.de/index.php/topic,63212.msg544594.html#msg544594

thaliondrambor

Zitat von: Morrino am 27 Dezember 2016, 16:02:04
Anscheinend wird hier auch schon am Gateway gearbeitet:
https://forum.fhem.de/index.php/topic,63212.msg544594.html#msg544594

Danke für den Hinweis. Ich werde mich dort mal mit einklinken.


Könnt ihr bitte mal die aktuelle 32_YeeLightBridge.pm aus dem Master-Branch einspielen und für mich was testen?
Theoretisch sollte es funktionieren, dass eine Such-Nachricht rausgeschickt wird und die Lampen antworten. Bei mir funktioniert es nur leider nicht.
Ich habe im Yeelight-Forum nachgefragt und dort sagte man mir, dass es eventuell an Routern mit OpenWrt liegen kann. Diese verhindern durch das igmp snooping, dass die Nachrichten richtig bei den Lampen ankommen. Ich habe neben zwei FritzBoxen auch noch zwei Router für Freifunk, welche auf OpenWrt laufen. Auch wenn durch diese eigentlich kein Datenverkehr laufen sollte, so habe ich sie testweise mal beide außer Betrieb genommen. Leider gab es keine Besserung.

Also bitte mal folgendes testen. Verbose in der Bridge auf 4 stellen und dann einmal den Befehl "search" ohne weitere Parameter ausführen. Dann sollte im Log stehen:
YeeBridge: Search with M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1982
MAN: "ssdp:discover"
ST: wifi_bulb


Wenn bei euch im Anschluss die Lampen im Log mit einer "NOTIFY"-Message antworten, dann funktioniert es bei euch. Wenn ihr euch nicht sicher seit, dann einfach mal den Log ab dem "Search" posten.
Danke.

cc13

Hi,

ich habe versucht, die Bridge mit


reload 32_YeelightBridge.pm


zu installieren, nachdem ich sie vorher in den FHEM-Ordner gelegt habt. Folgende Meldung bekam ich:


Can't locate IO/Socket/Multicast.pm in @INC (you may need to install the IO::Socket::Multicast module) (@INC contains: fhem.p/lib fhem.p/FHEM/lib ./FHEM/lib ./lib ./FHEM ./ /usr/local/FHEM/share/fhem/FHEM/lib . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl) at ./FHEM/32_YeeLightBridge.pm line 22.
BEGIN failed--compilation aborted at ./FHEM/32_YeeLightBridge.pm line 22.

thaliondrambor

Dann musst du noch das CPAN-Modul IO::Socket::Multicast auf deinem System installieren. Das sollte mit "sudo cpan install IO::Socket::Multicast" gehen.

Ich glaube ich weiß, wieso das Senden der Suchanfrage nicht geht. Nur eine Lösung habe ich noch nicht. Ich werde mir was überlegen. Die periodischen Multicasts werden ja schon erkannt.

cc13

Hier mein Logauszug dazu:


2016.12.28 16:57:48 4: YeeBridge: Search with M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1982
MAN: "ssdp:discover"
ST: wifi_bulb

2016.12.28 16:57:48 4: received multicast message on 239.255.255.250:1982:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1982
MAN: "ssdp:discover"
ST: wifi_bulb

thaliondrambor

#44
Danke. Das hatte ich vermutet.
Das Problem ist, dass ich momentan nur einen Socket für die Multicast-Adresse aufbaue. Für die Suchnachricht müsste ich noch einen weiteren UDP-Socket aufbauen. Da ich das aber gerne auch non-blocking machen möchte, müsste ich einen zweiten FD im Modul hinterlegen. Nur keine Ahnung wie das geht :-) Alternativ müsste immer erst der Multicast geschlossen werden, dann die Suchnachricht über einen neuen Socket und im Anschluss wieder den Multicast aufbauen.

Es geht bestimmt auch mit zwei Sockets, ich weiß eben nur nicht wie. Das finde ich schon noch raus. Habe aber keinen PC dabei. Erst morgen Abend wieder.

Edit: Die neueste Version im Devel-Branch unterstützt nun auch das aktive Suchen nach Lampen über die Bridge. Außerdem kann man nun bis zu 10 Szenen in Attributen anlegen und abspielen lassen (userScene0 - userScene9). Mehr dazu morgen. Es ist doch schon recht spät.