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

[thaliondrambor]

Hallo,

ich habe mich an meinem ersten Modul für FHEM versucht und stelle es euch hier zur Verfügung. Bei Fragen, Anregungen und Problemen einfach melden.

Ein kleiner Dank geht an herrmannj, desen WifiLight-Modul ich als Grundlage nutzen durfte. Am Ende habe ich zwar so gut wie nichts übernommen, aber es hat mir dennoch viel geholfen, den Aufbau von FHEM-Modulen zu verstehen.

Aktuelle Version hier: https://github.com/thaliondrambor/32_YeeLight.pm

Gruß
thaliondrambor


###### Under Construction ######

Anleitung für 32_YeeLight.pm

0 - Vorwort

Mit diesem Modul lassen sich die WLAN-fähigen Lampen der Firma Xiaomi, welche unter dem Namen Yeelight verkauft werden, steuern.
Zum aktuellen Zeitpunkt gibt es folgende Lampen:

• LED Bulb Color Wifi - getestet und voll kompatibel
• LED Bulb White Wifi - kompatibel, aber nur Helligkeit einstellbar
• LED Lightstrip Color Wifi - kompatibel
• LED Desk Lamp - wahrscheinlich kompatibel, aber keine Farbe
• LED Deckenlampe - angekündigt und wahrscheinlich kompatibel

Vorteil der Lampen sind der geringe Preis (im Vergleich zu anderen smarten Lampen) und der wirklich große und gut durchdachte Funktionsumfang. Außerdem gibt es einen Betatest für die Sprachsteuerung mit Alexa.

1 - Einrichten der Lampen

Beim erstmaligen Einrichten der Lampen werden diese in das WLAN eingebunden. Dafür ist ein Smartphone, die Yeelight oder MiHome App und ein Mi-Account nötig. Es gibt beide Apps sowohl für IPhone als auch für Android, wobei die Apps für Android schneller laufen und mehr Funktionsumfang haben.
Die App erkennt neue Lampen und man kann diese durch Auswählen des WLANs und Eingeben des Passwortes in das WLAN integrieren. Es ist empfehlenswert gleich ein Firmware-Update der Lampen durchzuführen. Der aktuelle Stand (22.12.16) der LED Bulb Color Wifi ist die Version 1.4.1_45. Mit dieser ist die Funktionalität mit dem Modul voll gegeben. Erfahrungen mit früheren Versionen sind mir nicht bekannt.
Wichtig: in den Einstellungen der Lampe muss über die App der Developer Mode aktiviert werden, ansonsten ist ein steuern über FHEM nicht möglich.
Hinweis: Durch diese Einstellung wird die Kommunikation der Lampe auf unverschlüsselt umgestellt.

Damit ist die Grundeinrichtung der Lampe beendet.

Sollte das WLAN der Lampe nicht mehr findbar sein, so kann sie zurückgesetzt werden in dem man die Lampe je 5 mal für je 3 Sekunden an- und ausschaltet (5 x Aus - 3sek warten - Ein -3sek warten).

2 - Einrichten in FHEM

Bevor das Modul installiert werden kann, solltet ihr das CPAN-Modul JSON::XS auf eurem System installieren, wenn es nicht bereits vorhanden ist. Dieses wird zwangsweise benötigt. Dies geschiet bei einem Linux-System z.B. durch folgende Eingabe:

Code: [Auswählen]

sudo cpan install JSON::XS
Anschließend muss das Modul auf Github heruntergeladen und in FHEM eingebunden werden.
Die 32_YeeLight.pm gibt es hier: https://github.com/thaliondrambor/32_YeeLight.pm. Diese herunterladen, in euren FHEM-Ordner kopieren und mit

Code: [Auswählen]

reload 32_YeeLight.pm oder durch einen Neustart von FHEM "installieren".

Nun ist das Modul einsatzbereit.

3 - Define - Anlegen der Lampen

Die Lampen werden mit folgendem Befehl angelegt:

Code: [Auswählen]

define [NAME] YeeLight [IP]
z.B.: define SchlafzimmerLicht YeeLight 192.168.0.15
4 - Set - Steuern der Lampen

Folgende Befehle stehen zur Auswahl:

• on
• off
• toggle
• bright
• hsv
• hue
• sat
• rgb
• dimup
• dimdown
• color
• ct
• start_cf
• stop_cf
• scene
• name
• default
• reopen
• statusrequest

on - Befehl
Mit diesem Befehl kann die Lampe eingeschaltet werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.
Die Farbwerte und Helligkeit, die die Lampe nach dem Einschaltbefehl hat, hängt vom gespeicherten default-value ab. Standartmäßig ist dieser Weiß mit 6500K Farbtemperatur und 100% Helligkeit. Diesen Wert kann man über die App oder FHEM mittels dem Befehl "default" ändern. Nur über die App kann man auch einstellen, dass jedesmal wenn die Lampe ausgeschaltet wird, der Zustand vor dem Ausschalten als default gespeichert wird.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] on <RAMP>
set SchlafzimmerLicht on -> Lampe wird sofort eingeschaltet oder wird heller innerhalb <defaultramp> ms
set SchlafzimmerLicht on 0 -> Lampe wird sofort eingeschaltet, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht on 5000 -> Lampe wird heller innerhalb von 5s

off - Befehl
Mit diesem Befehl kann die Lampe ausgeschaltet werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] off <RAMP>
set SchlafzimmerLicht off -> Lampe wird sofort ausgeschaltet oder wird dunkler innerhalb <defaultramp> ms
set SchlafzimmerLicht off 0 -> Lampe wird sofort ausgeschaltet, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht on 5000 -> Lampe wird dunkler innerhalb von 5s
off - Befehl
Mit diesem Befehl kann die Lampe ausgeschaltet werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] off <RAMP>
set SchlafzimmerLicht off -> Lampe wird sofort ausgeschaltet oder wird dunkler innerhalb <defaultramp> ms
set SchlafzimmerLicht off 0 -> Lampe wird sofort ausgeschaltet, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht off 5000 -> Lampe wird dunkler innerhalb von 5s
toggle - Befehl
Mit diesem Befehl kann der Zustand der Lampe gewechselt werden (entspricht on/off-Befehl). Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] toggle <RAMP>
set SchlafzimmerLicht toggle -> Lampe wird sofort an/ausgeschaltet oder wird heller/dunkler innerhalb <defaultramp> ms
set SchlafzimmerLicht toggle 0 -> Lampe wird sofort an-/ausgeschaltet, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht toggle 5000 -> Lampe wird heller/dunkler innerhalb von 5s
bright - Befehl
Mit diesem Befehl kann die Helligkeit der Lampe von 0-100% geändert werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet. Eine Helligkeit von 0% führt den off-Befehl aus.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] bright [BRIGHT] <RAMP>
set SchlafzimmerLicht bright 50 -> Helligkeit der Lampe wird sofort auf 50% gestellt oder wird heller/dunkler bis 50% innerhalb <defaultramp> ms
set SchlafzimmerLicht bright 0 -> Helligkeit der Lampe wird sofort auf 50% gestellt, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht bright 5000 -> Helligkeit der Lampe wird heller/dunkler bis 50% innerhalb von 5s
hsv - Befehl
Mit diesem Befehl kann die Farbe der Lampe im HSV-Farbraum eingestellt werden. Dabei ist der Hellwert (value) immer 100%, der Farbwert (hue) kann von 0-359 und die Sättigung (saturation) von 0-100 eingestellt werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] hsv [HUE] [SAT] <RAMP>
set SchlafzimmerLicht hsv 120 100 -> die Farbe der Lampe wird sofort auf Grün gestellt oder ändert sich zu Grün innerhalb <defaultramp> ms
set SchlafzimmerLicht hsv 180 100 0 -> die Farbe der Lampe wird sofort auf Cyan gestellt, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht hsv 20 75 5000 -> die Farbe der Lampe ändert sich zu einem Braunton innerhalb von 5s
hue - Befehl
Mit diesem Befehl kann der Farbwert (hue) der Lampe im HSV-Farbraum von 0-359 eingestellt werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] hue [HUE] <RAMP>
set SchlafzimmerLicht hue 320 -> der Farbwert der Lampe wird sofort auf 320 gestellt oder ändert sich zu 320 innerhalb <defaultramp> ms
set SchlafzimmerLicht hue 45 0 -> der Farbwert der Lampe wird sofort auf 45 gestellt, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht hue 160 5000 -> der Farbewert der Lampe ändert sich zu 160 innerhalb von 5s
sat - Befehl
Mit diesem Befehl kann die Sättigung (sat) der Lampe im HSV-Farbraum von 0-100 eingestellt werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] sat [SAT] <RAMP>
set SchlafzimmerLicht sat 50 -> die Sättigung der Lampe wird sofort auf 50 gestellt oder ändert sich zu 320 innerhalb <defaultramp> ms
set SchlafzimmerLicht sat 20 0 -> die Sättigung der Lampe wird sofort auf 20 gestellt, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht sat 100 5000 -> die Sättigung der Lampe ändert sich zu 100 innerhalb von 5s
rgb - Befehl
Mit diesem Befehl kann die Farbe der Lampe im RGB-Farbraum eingestellt werden. Der RGB-Wert kann dabei als Hex-Wert ("000000" - "FFFFFF") oder einzeln für Rot, Gelb und Grün (0 - 255) angegeben werden. Als optionaler Parameter kann eine Rampenzeit (in Millisekunden, mindestens 30ms oder 0) angegeben werden, welche die Lampe vom Ist-Zustand innerhalb der Zeit zum Soll-Zustand überführt. Ohne Angabe des Parameters wird die Zeit aus dem Attribut defaultramp genommen. Ist dieses auch nicht gesetzt, wird die Zeit 0 angenommen und sofort geschaltet.
Bei einem RGB-Wert von "000000" bzw "0 0 0" wird die Lampe ausgeschaltet.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] rgb [RRGGBB] <RAMP> oder set [NAME] rgb [RED] [GREEN] [BLUE] <RAMP>
set SchlafzimmerLicht rgb 00FF00 oder set SchlafzimmerLicht rgb 0 255 0  -> die Farbe der Lampe wird sofort auf Grün gestellt oder ändert sich zu Grün innerhalb <defaultramp> ms
set SchlafzimmerLicht rgb 00FFFF 0 oder set SchlafzimmerLicht rgb 0 255 255 -> die Farbe der Lampe wird sofort auf Cyan gestellt, auch mit gesetzem Attribut <defaultramp>
set SchlafzimmerLicht rgb D86C36 5000 oder set SchlafzimmerLicht rgb 216 108 54 5000 ->die Farbe der Lampe ändert sich zu einem Braunton innerhalb von 5s
### TODO ###
dimup
dimdown
color
ct
start_cf
stop_cf
scene
name
default
reopen
statusrequest

5 - Readings

Momentan spiegeln die Readings nur den Zustand der Lampen wieder. Diese ergeben sich aus den entsprechenden Set-Befehlen (oder durch das Steuern über die App).
Wenn das Reading "color_mode" auf "HSV" steht, dann entsprechen die Werte von "hue", "saturation" und "bright" dem aktuellen Zustand der Lampe. Die Readings "ct" und "rgb", "rgb_red", "rgb_green", "rgb_blue" entsprechend dem Zustand, den die Lampe hatte, als der entsprechende Farbmodus zuletzt an war. Das gilt auch, wenn "color_mode" auf "RGB" bzw "ct" steht.

6 - Attribute

Folgende Attribute stehen zur Verfügung:

• defaultramp

defaultramp - Attribut

Mit diesem Attribut kann die Dauer der "Änderungsrampe" in Millisekunden angegeben werden. Dieser Wert ist immer dann wirksam, wenn kein anderer Wert im Befehl angegeben wird. Die Mindestdauer beträgt 30ms.
Hinweis: Wenn das Attribut "defaultramp" gesetzt ist und ein Befehl trotzdem sofort ausgeführt werden soll, dann muss als Rampendauer 0 im Befehl angegeben werden.

7 - Sonstiges

Es gibt zwei versteckte Befehle, welche nur genutzt werden sollten, wenn man weiß, wie die API der Lampen funktioniert. Diese sind nicht per Dropdown-Menü verfügbar, sondern müssen über die Kommandozeile eingegeben werden.
Diese lauten:

• raw
• flush

raw - Befehl
Mit diesem Befehl kann ein Kommando direkt an die Lampe geschickt werden ohne das er vorher vom Modul verarbeitet wird (ausser das Anhängen von "\r\n"). Genauere Infos über die gültigen Kommandos gibt es hier: www.yeelight.com/download/Yeelight_Inter-Operation_Spec.pdf

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] raw [COMMAND]
set SchlafzimmerLicht raw {"id":1,"method":"set_power","params":["off","smooth",3000]} -> entspricht set SchlafzimmerLicht off 3000
flush - Befehl

Gesendete, empfangene und fehlerhafte Kommandos werden in Warteschlangen gespeichert (SendQueue, AnsQueue, ErrQueue). Anschließend werden sie verarbeitet und, wenn sie erfolgreich abgearbeitet wurden, gelöscht. Die Warteschlangen kann man sich z.B. über folgenden Befehl ansehen:

Code: [Auswählen]

list [NAME]Ein Leeren der Listen ist über den Befehl "flush" möglich. Dabei werden die gelöschten Befehle ab einem Verbose-Level von 4 in den Log geschrieben. Beim Löschen der Gerätedefinition und Herunterfahren von FHEM wird der Befehl automatisch ausgeführt.

Syntax und Beispiele:

Code: [Auswählen]

set [NAME] flush
set SchlafzimmerLicht flush

00 - Entwicklung

Unter https://github.com/thaliondrambor/32_YeeLight.pm/tree/devel gibt es einen wenig getesteten Entwicklungsstand. Wenn beim Testen geholfen wird, freue ich mich sehr.

Folgende Änderungen gibt es im Devel-Branch:

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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

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. Da sich relevanter Code im Define-Teil geändert hat, bitte einen Neustart von FHEM durchführen mit:

Code: [Auswählen]

shutdown restart
Die Bridge wird wie folgt definiert:

Code: [Auswählen]

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
• timeout
• keepAlive

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.

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.

[f-zappa]

n'Abend,
das Timing könnte besser nicht sein. Gestern kam meine (erste) Lampe an - heute Abend habe ich dann selbst ein bisschen herumprobiert. Als ich im Forum noch mal deinen anderen Thread gesucht habe, habe ich dann gesehen, dass du das passende Modul schon veröffentlicht hast. Danke!

Allerdings ist das hier dann leider auch schon der erste Bugreport ... schon die Definition

Code: [Auswählen]

define blabla YeeLight x.x.x.x
lässt FHEM crashen; im Log findet man dann

Code: [Auswählen]

2016.12.14 23:33:06 1: PERL WARNING: Prototype mismatch: sub main::to_json ($@) vs ($) at /usr/share/perl/5.20/Exporter.pm line 66.
2016.12.14 23:33:06 1: PERL WARNING: Prototype mismatch: sub main::from_json ($@) vs ($) at /usr/share/perl/5.20/Exporter.pm line 66.
Undefined subroutine &main::is_ipv4 called at ./FHEM/32_YeeLight.pm line 58.
Es juckt mich zwar in den Fingern, da noch selbst genauer nachzusehen, aber dann ist die Nacht wahrscheinlich schnell vorbei. Da morgen die Arbeit ruft, will ich also mal vernünftig sein. Das Feedback wollte ich trotzdem schon mal geben, vielleicht hast du ja schon eine Idee, woran das liegt.

Nebenbei: Ich finde, die Lampe macht von der Verarbeitung her einen guten Eindruck und gibt ein sehr schönes Licht. Die hatte definitiv ein FHEM-Modul verdient :-)

Gruß, Uli

[thaliondrambor]

Guten Morgen,

als ich deinen Post eben las, wusste ich sofort, wo der Fehler liegt. Ich hatte ehrlich gesagt ein anderes Verhalten erwartet,da es bei mir so funktioniert. Ich habe das Problem behoben. Es kann allerdings sein, dass das CPAN-Modul Data::Validate::IP noch installiert werden muss.

Der fehlerfreie Version hängt oben am ersten Post. Mehr heute Abend, denn ich muss auch arbeiten :-)

Gruß
thaliondrambor

Edit: Ich habe eine Möglichkeit gefunden die IP-Adresse mit dem Standartmodul Socket zu überprüfen. Ist nun implementiert.
Die Warnungen kommen meiner Meinung nach aus dem JSON::XS Modul. Ich weiß noch nicht so recht, wie ich die wegbekommen soll. Meiner Meinung nach rufe ich die "decode_json"-Funktion richtig auf, aber im JSON::XS Modul selber wird eine Funktion aus der Exporter.pm "falsch" aufgerufen. Wobei falsch ja relativ ist. Es gibt ja nur ein prototyp mismatch. Es funktioniert ja trotzdem alles.

Edit2: Ich habe ein Repository auf Github angelegt. Dort ist dann der aktuelle Stand und ein Entwicklungsstand zu finden.
https://github.com/thaliondrambor/32_YeeLight.pm

[f-zappa]

Super, damit funktioniert es :-) Und damit wird die YeeLight auch sofort wesentlich brauchbarer, denn sie reagiert sofort auf einen Umschaltvorgang. Die YeeLight-App geht ja den Umweg über eine chinesische
Cloud, und je später der Abend wird, um so zäher reagiert die Lampe (wenn 1.3 Mrd. Chinesen aufwachen und ihre Smartphones zücken, geht offenbar die große Firewall in die Knie).

Wirst du eigentlich (analog wie in WifiLight) auch einen Parameter "defaultramp" einbauen? Fänd ich super.
Bei "set rgb" fände ich die übliche Hex-Notation (#RRGGBB) einfacher und lesbarer, kann man Dich überzeugen, das noch zu ändern?

Im devel-Zweig geht es ja schon gut voran, vor allem den "colortemperature" Modus finde ich wichtig (sollte man den nicht "ct" abkürzen?)

Ich werd am Wochenende mal versuchen, die YeeLight in LightScene und HomeBridge einzubauen (ohne irgendwelche Anpassungen taucht die Lampe in HomeKit bereits auf und lässt sich zumindestens an und aus schalten). Übrigens ist auch noch eine weiße Lampe zu mir unterwegs. Ich bin mal gespannt, wie die sich dann mit dem Modul verhält.

Gruß, Uli

[justme1968]

für homebridge und auch den colorpicker wäre es gut wenn das rgb kommando (zumindest optional) auch RRGGBB als hex verstehen würde. auch (zusätzliche) getrennte kommandos für hue und saturation wären gut für den colorpicker und widgetOverride.

vielleicht magst du dir auch mal die kommandos und readings die hue und lightify verwenden anschauen. je kompatibler und ähnlicher die module untereinander sind um so einfacher wird es für die frontends neue gerate einzubinden.

auch farbige lampen icons über die beiden Color_devStateIcon routinen aus Color.pm lassen sich dann einfacher verwenden.

gruss
  andre

[thaliondrambor]

Huhu, also Attribute sind definitiv vorgesehen, aber mit denen habe ich mich noch gar nicht beschäftigt. Deswegen gibt es noch keine.

Ich möchte erstmal alle Grundfunktionen der Lampe umsetzen. Danach mache ich mich an die Funktionen, die die Lampe nicht hat, aber FHEM dann realisiert.

Die RGB Notation in Hex werde ich umsetzen. Das geht schnell. Da ich bis jetzt noch keine anderen steuerbaren Lampen hatte, weiß ich gar nicht so genau, was die anderen Module so können :-)
Aber ich werde versuchen das Modul möglichst nah an die anderen zu bauen.

Gesendet von meinem SM-G930F mit Tapatalk

[Alexk30]

Super das du dieses Modul umgesetzt hast. Meine beiden Yeelight RGB´s wurde einwandfrei erkannt und funktionieren bestens. Ich freue mich auf deine Erweiterungen (colorpicker etc.) Vielleicht hast du ja auch später die Möglichkeit die Lightscence aus der APP einzubauen.

Nochmals vielen Dank für deine Mühe und vorallem Zeit.

Gruß Alex

[thaliondrambor]

N'Abend,

ich habe mal ein bisschen weitergebastelt. Ich habe den Code etwas optimiert, wovon ihr nicht so viel merken solltet. Es wurden aber auch ein paar Funktionen hinzugefügt:

Code: [Auswählen]

RGB nimmt nun auch Hex-Werte (RRGGBB)
Hue und Saturation können auch einzeln gesetzt werden
Attribut defaultramp wurde hinzugefügt (Standartzeit falls nicht anders im Befehl angegeben)
Den aktuellen Stand findet ihr im Devel-Branch von Github: https://github.com/thaliondrambor/32_YeeLight.pm/tree/devel

Übrigens ist auch noch eine weiße Lampe zu mir unterwegs. Ich bin mal gespannt, wie die sich dann mit dem Modul verhält.

Ich sehe bei mir keinen Anwendungsfall, wo sich die weißen Lampen lohnen für gerade mal 1-2€ weniger. Sie funktionieren aber grundsätzlich genauso, wie die farbigen Lampen. Ich muss dann nur einen Typ hinzufügen und die Funktionen deaktivieren, die die weiße Lampe nicht kann.

Es gibt übrigens gerade von Xiaomi einen Betatest für die Steuerung der Lampen mit IFTTT und mit Echo. Das soll wohl bereits gut laufen. Wann es das für die Allgemeinheit gibt, weiß ich nicht.


Es gibt eine Funktion, die ich gerne implementieren möchte, bei welcher ich aber nicht genau weiß, wie am besten.
Momentan kann man an die Lampe Befehle senden auch wenn sie aus ist. Die Lampe quittiert das auch mit einem "ok", aber die Werte werden nicht übernommen. Man kann also die Lampe nicht auf z.B. Blau stellen, wenn sie aus ist, und beim einschalten ist sie dann tatsächlich blau. Das ist natürlich unschön.

Mir fallen drei Möglichkeiten dazu ein:
1. Die Lampe wird automatisch eingeschaltet, wenn sie aus ist und einen Befehl erhält.
2. Es können keine Befehle gesendet werden, wenn sie aus ist (on, toggle, statusrequest usw. gehen natürlich immer).
3. Der Befehl wird in FHEM gespeichert und beim nächsten Einschalten ausgeführt.

Ich tendiere grundsätzlich zu 1. bin aber am Überlegen, ob man nicht alle drei implementieren und per Attribut das gewünschte Verhalten auswählen sollte. Auch dann würde ich 1. als Default nehmen.

Wie ist eure Meinung dazu?

Gruß
thaliondrambor

[Alexk30]

1. soll bedeuten, wenn ich der Lampe den Befehl "Blau 50" gebe schaltet sie sich so ein?

Gruß Alex

[thaliondrambor]

Genau. Momentan passiert gar nichts. Also nicht mal eine Fehlermeldung.

[f-zappa]

Möglichkeit 1 halte ich auch für die intuitive. Umgekehrt fände ich dann auch logisch, den Helligkeitswert 0 zu erlauben und die Lampe dadurch auszuschalten.

Bei den Hex-Werten ist mir noch ein Mini-Fehlerchen aufgefallen .. momentan nimmt er die führenden Nullen weg (Blau wird z.B "FF" statt "0000FF"). Aber im Set-Befehl akzeptiert er das umgekehrt nicht, das ist natürlich schlecht für Automatisierungen. Vielleicht lieber

Code: [Auswählen]

       my $hexrgb              = sprintf("%06X",$rgb);
Ebenfalls für Automatisierungen wie z.B. abspeichern von Ist-Werten fände ich gut, wenn Readings und Set-Befehle konsistent wären. "set ct 2900" für die Farbtemperatur ist prima, aber dazu passend sollte in colormode dann auch "ct" stehen und auch das Reading für die Farbtemperatur sollte so heißen. Analog natürlich für alle anderen Werte.

Bitte nicht falsch verstehen, wenn ich immer wieder was zu "motzen" habe - ich finde es klasse, wie rasant du das entwickelst 

[CoolTux]

Möglichkeit 1 halte ich auch für die intuitive. Umgekehrt fände ich dann auch logisch, den Helligkeitswert 0 zu erlauben und die Lampe dadurch auszuschalten.

So weit ich weiß verhält sich Hue auch so. Wäre also logisch.

Ebenfalls für Automatisierungen wie z.B. abspeichern von Ist-Werten fände ich gut, wenn Readings und Set-Befehle konsistent wären. "set ct 2900" für die Farbtemperatur ist prima, aber dazu passend sollte in colormode dann auch "ct" stehen und auch das Reading für die Farbtemperatur sollte so heißen. Analog natürlich für alle anderen Werte.

Bitte nicht falsch verstehen, wenn ich immer wieder was zu "motzen" habe - ich finde es klasse, wie rasant du das entwickelst 

Generell sollten Setnamen und Readingsnamen gleich lauten, dann fügt nämlich FHEM bei der Set Auswahl im Frontend automatisch den aktuellen Readingswert ein.


Und zum Schluss ein Danke für Deine Arbeit und weiterhin viel Erfolg und Spaß mit Deinem Modul.


Grüße

[thaliondrambor]

So,

habe ein paar kleinere Korrekturen vorgenommen.
Außerdem habe ich die ReadFn gefunden und verstanden :-) Nun werden die Statusänderungen, welche die Lampen verschicken, ausgelesen und die Readings werden gesetzt. Nicht nur, dass das Last vom Modul nimmt, da nicht ständig StatusRequests durchgeführt werden müssen. Jetzt sieht man in FHEM auch die Änderungen, wenn man z.B. mit dem Handy schaltet.

Die Lampen schalten sich jetzt bei den Befehlen ein, wo es nötig ist. Außerdem schaltet eine Helligkeit von 0 die Lampen aus.

Die Readings und Set-Befehle wurden aneinandern angepasst. Deswegen wäre es wohl sinnvoll, die Readings mal zu löschen, damit da nicht zig ungenutzte rumschwiren.

Es gibt auch noch ein paar neue Funktionen. Es kann der Lampe ein Namen gegeben werden (also direkt in der Lampe gespeichert). Der Default-Status der Lampe kann gespeichert werden (Farbe und Helligkeit die sie nach Spannungswiederkehr hat). Es kann eine Farbfolge gestartet werden (genaueres folgt in der Hilfe). Außerdem habe ich drei Szenen aus der App eingefügt (sunrise, sunset, happy_birthday), welche über "scene" gestartet werden können.

Da das ganze mittlerweile recht umfangreich ist, werde ich mich mal auch an eine Hilfe/Funktionsbeschreibung machen.

Bitte nicht falsch verstehen, wenn ich immer wieder was zu "motzen" habe - ich finde es klasse, wie rasant du das entwickelst 

Motz ruhig weiter. Deswegen habe ich es ja unter anderem schon jetzt zur Verfügung gestellt. Erstens dachte ich, dass es bestimmt auch schon jetzt Leute gibt, die mit dem kleinen Funktionsumfang was anfangen können. Aber vor allem wollte ich natürlich Feedback und Fehler finde. Ich alleine mit meinen paar Lampen, wovon ich beim Programmieren immer nur mit einer spiele, finde nunmal nicht alle Fehler und/oder Eventualitäten.

Aktueller Stand wie üblich auf Github und ich lade Sie auch mal wieder oben im ersten Post hoch.

Edit 19.12.:
Anstatt an einer Anleitung habe ich mich heute mit einem aufgetretenem Problem befasst. Da die Antworten der Lampen zu schnell bzw. nicht in genau definierten Reihenfolgen ankommen, hat das Modul Fehler ausgeworfen. Also habe ich zwei Warteschlangen erstellt, je eine für die gesendeten Befehle und eine für die erhaltenen Nachrichten. So können diese ausgewertet werden, ob es Benachrichtigungen von der Lampe sind oder ob sie Antworten auf die Befehle sind, und entsprechend verarbeitet und die Warteschlangen geleert werden. Das hat echt eine Menge Zeit gebraucht, bis es funktioniert.

Zusätzlich gibt es jetzt noch einen "reopen"-Befehl, falls die Lampe mal offline ist.
Feedback darüber, wie die Lampen bei euch laufen, ist gern gesehen.

[f-zappa]

Moin,

ich habe nach dem schlechten Tatort noch die neue Modulversion mit Spannung installiert und direkt mal ein paar ColorFlows probiert 

Eine Kleinigkeit ist direkt aufgefallen: Für "Action" werden die Werte 1, 2, 3 gefordert, laut Inter-Operation Specification sollten es 0, 1, 2 sein.

Code: [Auswählen]

return "$name start_cf: action ($args[1) must be 1, 2 or 3." if ($args[1] < 1) || ($args[1] > 3);
Dabei ist an der "0" gerade spannend, dass man eine kurze Animation abspielen kann und die Lampe danach wieder zum Ausgangszustand zurückgeht. Damit sind z.B. schöne diskrete Benachrichtigungen möglich (z.B. Waschmaschine ist fertig -> zwei mal blau blinken)

Code: [Auswählen]

set yl start_cf 3 0 500,1,255,100,500,1,1,1
In Homekit habe ich die YeeLight teilweise erfolgreich eingebunden. An/Aus und Helligkeit verhalten sich wie erwartet, aber in den meisten Fällen wird bei einer geänderten Farbe die Saturation auf 100 gestellt (gefühlt jedes dritte bis vierte Mal funktioniert es wie gewollt). Ich habe gemutmaßt, dass hier die Set-Befehle für Hue und Saturation gegenseitig "wettlaufen" und versucht, das durch Delays provisorisch weg zu bekommen. Allerdings ohne Erfolg.

Code: [Auswählen]

attr yl homebridgeMapping clear  On=power,valueOn=on,valueOff=off,cmdOn=on,cmdOff=off Hue=hue::hue,delay=100 Brightness=bright::bright Saturation=sat::sat,delay=300Das habe ich aber bereits heute Nachmittag mit der vorherigen Modulversion ausprobiert, möglicherweise verhält es sich jetzt schon wieder anders. Ich kann's gerade leider nicht ausprobieren.

So .. gute Nacht allerseits!

[thaliondrambor]

Eine Kleinigkeit ist direkt aufgefallen: Für "Action" werden die Werte 1, 2, 3 gefordert, laut Inter-Operation Specification sollten es 0, 1, 2 sein.

Danke. Habe ich gleich behoben und die Kontrolle der Parameter für die colorflows noch etwas erweitert. Mehr ist Heute aber nicht drin.

Mich würde interessieren, ob die Saturation in Verbindung mit de Homekit jetzt funktioniert. Wenn nicht wäre ein Log mit verbose 5 ganz interessant. Da sieht man dann genau, wann welcher Befehl gesendet wird, wann die Antwort und die Benachrichtigung kommt und wann was in die Warteschlangen geschrieben, bearbeitet und gelöscht wird.
Ich hoffe einfach mal, dass es auch so geht.^^

Edit: Ich habe eben deinen Code fürs blaue Blinken ausprobiert:

Code: [Auswählen]

set yl start_cf 3 0 500,1,255,100,500,1,1,1
Leider ist mir da was unschönes aufgefallen. Wenn die Lampe aus ist, z.B. Tags über, bleibt sie nach dem Befehl an, da für Sie anscheinend der vorherige Status der Status ist, der unter default gespeichert ist. Das ist natürlich blöd.

Mit dem

Code: [Auswählen]

set yl start_cf 3 2 500,1,255,100,500,1,1,1würde sie zwar aus gehen, aber eben immer, auch wenn Sie vorher an war.

Eventuell überschreibe ich die Action "0" mit dem Modul, so dass die Lampe am Ende wieder ausgeht, wenn sie vorher aus war.

Edit2: Es waren dann doch quasi nur zwei Zeilen Code. Da konnte ich nicht widerstehen. Aber nun Gute Nacht ^^