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

[Morrino]

Hi,

danke für das Modul.
Spricht etwas dagegen das die Stehlampe nicht mit deinem Modul funktioniert?
Finde die sehr interessant und würde mir sie heute bestellen.

[thaliondrambor]

Hi,

danke für das Modul.
Spricht etwas dagegen das die Stehlampe nicht mit deinem Modul funktioniert?
Finde die sehr interessant und würde mir sie heute bestellen.

Moin,
welche Stehlampe meinst du? Die Schreibtischlampe? Alle Lampen von Xiaomi mit WLAN sollten auch mit dem Modul laufen. Da ich sie nicht selber habe und testen kann, kann es allerdings sein, dass sie nicht alle Funktionen unterstützt.

Es gibt von Xiaomi auch ein SmartHome Gateway, welches dann auch die anderen SmartHome Komponenten steuern kann (Wifi, Bluetooth, ZigBee). Das Gateway kann ähnlich wie die Lampen gesteuert werden, allerdings auf einem anderen Port. Ich habe mir das Gateway bereits bestellt, aber es ist leider momentan über all nicht lieferbar. Eventuell werde ich auch für dieses Gateway ein Modul schreiben.

[f-zappa]

Spricht etwas dagegen das die Stehlampe nicht mit deinem Modul funktioniert?

Meinst du die Nachttischlampe oder die Schreibtischlampe? Die Nachttischlampe würde ich sofort kaufen, wenn sie denn WiFi hätte .. leider wird sie stattdessen über Bluetooth angesprochen, hier wird es wohl nichts mit dem Modul.

Alle anderen Produkte werden über WiFi angesteuert und der Hersteller schreibt, dass diese alle das gleiche Protokoll sprechen:

Yeelight 3rd-party control protocol is a feature designed for developers and fans of IoT. All Yeelight WiFi products that are currently on market (Yeelight LED bulb (White), Yeelight LED bulb (Color)) as well as upcoming WiFi light products will support this protocol. Based on this protocol, users can develop their own applications and programs to discover and control Yeelight WiFi devices by using their favorite platform or language. This control protocol uses a SSDP-like discovering mechanism and JSON encoded controlling command, developers can discover and control their devices dynamically under the same LAN. Attention must be payed to following security issue: all the discover and control messages defined in this protocol are not encrypted, which means Yeelight devices' security is guaranteed by the router's security level, therefore user must be responsible for their devices's security when using this control protocol.

Ich erstell mal eine Übersicht, damit wir wissen, worüber wir reden 

• LED Blub (Color) http://www.yeelight.com/en_US/product/wifi-led-c
  für diese Lampe wurde das Modul entwickelt
• LED Bulb (White) http://www.yeelight.com/en_US/product/wifi-led-w
  sollte auch funktionieren, natürlich ist hier nur die Helligkeit anpassbar (Farbtemperatur fix 4000K)
  Ein Exemplar ist zu mir unterwegs, ich werde berichten
• LED Desk Lamp http://www.yeelight.com/en_US/product/mijia-lamp
  Schreibtischlampe mit anpassbarer Farbtemperatur; ich würde vermute, dass eine Untermenge der Befehle (insbesondere ct, brightness) funktioniert.
• LED Lightstrip (Color) http://www.yeelight.com/en_US/product/pitaya
  sollte eigentlich genau so funktionieren wie die farbige Birne
• Bedside Lamp http://www.yeelight.com/en_US/product/yeelight-ctd
  sehr wahrscheinlich nicht kompatibel, da kein WiFi sondern Bluetooth
• Deckenlampe (angekündigt) http://www.yeelight.com/en_US/blog/47
  spekulativ, entweder warten wir auf eine Übersetzung oder jemand mit chinesischen Sprachkenntnissen schaut sich die Seite mal an
  EDIT: "The world's first Lamp to support both Wi-Fi and Bluetooth" - also möglicherweise kompatibel

[Morrino]

Meinst du die Nachttischlampe oder die Schreibtischlampe? Die Nachttischlampe würde ich sofort kaufen, wenn sie denn WiFi hätte .. leider wird sie stattdessen über Bluetooth angesprochen, hier wird es wohl nichts mit dem Modul.

Ich meinte die Nachttischlampe. Das die nicht mit WLan ist hatte ich übersehen.
Damit fällt sie wohl doch flach.

Sehr sehr schade das gerade die nicht mit WLan ausgestattet ist 

[f-zappa]

Sehr sehr schade das gerade die nicht mit WLan ausgestattet ist 

Ja, ich hatte auch schon fast zwei davon bestellt. Die sehen auf den Bilder total gut aus.

Es gibt von Xiaomi auch ein SmartHome Gateway, welches dann auch die anderen SmartHome Komponenten steuern kann (Wifi, Bluetooth, ZigBee).

Wo ich Bluetooth lese: ob damit auch diese Nachttischlampen anzusteuern gehen?

[thaliondrambor]

Ja, mit dem Gateway sollten alle steuerbar sein. Nicht nur die Lampen. Es gibt ja zum Beispiel auch Lufterfrischer und und und...

Gesendet von meinem SM-G930F mit Tapatalk

[Morrino]

Es gibt von Xiaomi auch ein SmartHome Gateway, welches dann auch die anderen SmartHome Komponenten steuern kann (Wifi, Bluetooth, ZigBee). Das Gateway kann ähnlich wie die Lampen gesteuert werden, allerdings auf einem anderen Port. Ich habe mir das Gateway bereits bestellt, aber es ist leider momentan über all nicht lieferbar. Eventuell werde ich auch für dieses Gateway ein Modul schreiben.

Das wäre natürlich sehr interessant.
Find die Xiaomi Artikel allgemein eine interessante Alternative zu HUE und Co.
Aber auch Bewegungssensor etc...

[f-zappa]

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 habe das gerade noch einmal gecheckt .. mit der Eve-App tritt das Problem nicht auf, mit der Home-App von Apple aber reproduzierbar. Der Unterschied zwischen beiden ist im Log leicht zu erkennen: Eve setzt zuerst Hue und dann Saturation. Home macht das umgekehrt. Die Logs selbst schenk ich mir jetzt mal, weil ich inzwischen die Ursache kenne. Ich habe nämlich entdeckt: Wenn ich den Hue-Wert manuell über den Befehl setze ("set yl hue 0"), wird die Saturation ebenfalls auf 100 hochgedreht (also auch ganz ohne HomeKit-Beteilitung).
Und das sollte diese Zeile ja eigentlich verhindern:

Code Auswählen Erweitern

                $sCmd->{'params'}->[1]  = $hash->{READINGS}{saturation}{VAL} + 0;# saturation

Nur, dass das Reading in den Anfangstagen des Moduls von "saturation" in "sat" umbenannt wurde.
Bei mir gibt's die alten Readings aber immer noch als Karteileichen, weil ich zu faul zum Löschen oder Neudefinieren war. Und bei "saturation" steht halt noch eine 100 drin :8
Also, dieses Problemchen kann mit einem "7x" behoben werden.
Für die Akten, mein homebridgeMapping sieht inzwischen so aus:

Code Auswählen Erweitern

clear
Hue=hue::hue,minValue=0,maxValue=359,minStep=1
Brightness=bright::bright,minValue=0,maxValue=100,minStep=1
Saturation=sat::sat,minValue=0,maxValue=100,minStep=1

[f-zappa]

Mist, und schon knallt es an einer anderen Stelle 
Ich habe eine LightScene, die gleichzeitig ct und bright setzt. Das bringt FHEM reproduzierbar zum Absturz. Reihenfolge ist egal.

Code Auswählen Erweitern

2016.12.20 22:50:58 3: YeeLight e2.yl1 - set e2.yl1 bright 20
2016.12.20 22:50:58 5: e2.yl1 SendQueue: added {"params":[20,"smooth",5000],"id":2,"method":"set_bright"} with id:2
2016.12.20 22:50:58 5: SW: {"params":[20,"smooth",5000],"id":2,"method":"set_bright"}
2016.12.20 22:50:58 4: e2.yl1 is sending: {"params":[20,"smooth",5000],"id":2,"method":"set_bright"}
2016.12.20 22:50:58 3: YeeLight e2.yl1 - set e2.yl1 ct 3100
2016.12.20 22:50:58 5: e2.yl1 SendQueue: added {"method":"set_ct_abx","params":[3100,"smooth",5000],"id":3} with id:3
2016.12.20 22:50:58 5: SW: {"method":"set_ct_abx","params":[3100,"smooth",5000],"id":3}
2016.12.20 22:50:58 4: e2.yl1 is sending: {"method":"set_ct_abx","params":[3100,"smooth",5000],"id":3}
2016.12.20 22:50:58 4: reading from e2.yl1: {"id":2, "result":["ok"]}
2016.12.20 22:50:58 5: e2.yl1 AnswerQueue: added {"id":2, "result":["ok"]}
2016.12.20 22:50:58 3: e2.yl1 success sending 2: {"params":[20,"smooth",5000],"id":2,"method":"set_bright"}
2016.12.20 22:50:58 5: e2.yl1 SendQueue: deleted {"params":[20,"smooth",5000],"id":2,"method":"set_bright"}
2016.12.20 22:50:58 5: e2.yl1 AnswerQueue: deleted {"id":2, "result":["ok"]}
2016.12.20 22:50:58 4: reading from e2.yl1:
{"method":"props","params":{"bright":20}}
{"id":3, "result":["ok"]
2016.12.20 22:50:58 5: e2.yl1 AnswerQueue: added
{"method":"props","params":{"bright":20}}
{"id":3, "result":["ok"]
garbage after JSON object, at character offset 44 (before "{"id":3, "result":["...") at ./FHEM/32_YeeLight.pm line 739.


EDIT: Bei so einem Konstrukt bleibt alles gut:

Code Auswählen Erweitern

set e2.yl1 ct 2900 ; sleep 1 ; set e2.yl1 bright 100
Da verwurstelt sich wohl irgendwas in den Queues, die genau das verhindern sollten ...

[thaliondrambor]

Eigentlich ist das Problem ganz einfach. Bei

Code Auswählen Erweitern

{"id":3, "result":["ok"] fehlt ein "}" am Ende.

Wenn die Befehle zu "schnell" abgesendet werden, dann kommen manchmal die Antworten so schnell, dass quasi zwei in einem Receive stehen. Das habe ich versucht hier aufzutrennen:

Code Auswählen Erweitern

sub
YeeLight_Read
{
my ($hash) = @_;
my $name = $hash->{NAME};

my $buf = DevIo_SimpleRead($hash);
return undef if(!defined($buf));

my $read;
my $search = "}";
my $offset = 0;
my $result = index($buf, $search, $offset);

while ($result != -1)
{
my $sResult = index($buf, "}}", $offset);
$result++ if ($result == $sResult);
$result++;
$read = substr($buf,$offset,$result);
Log3 $name, 4, "reading from $name: $read";

Add_AnsQue($hash,$read);
$offset = $result + 1;
$result = index($buf, $search, $offset);
}

return undef;
}

Anscheinend war das nicht erfolgreich...
Mit den Regex und Zeichenketten auseinanderfriemeln habe ich es ehrlich gesagt nicht so^^
Die richtige JSON-Antwort kann blöderweise mit "} oder }} oder ]} enden. Das macht es irgendwie nicht gerade einfach. Ich denke, ich muss das wahrscheinlich verschachtelter machen. Oder jemand hat eine andere Idee.

In deinem Fall werde ich wohl hinten ausversehen die "}" abgeschnitten haben...Und das führt beim Decodieren des JSON-Codes zum Absturz. Es hat also eigentlich nichts mit den Queues an sich zu tun. Das Problem kommt erst beim Umwandeln der Antworten um sie dann auszuwerten.

Aber dafür ist jetzt keine Zeit mehr.

Ich habe übrigens gestern auch schon nach einer Evaluierung für JSON-Code geschaut, um solche Fehler abzufangen, damit nicht das ganze FHEM abstürzt. Leider habe ich noch nichts gefunden. Es gibt ein CPAN-Modul dafür, aber das müsste man natürlich extra noch nachinstallieren.

Gute Nacht.

[bjbrill]

Hallo,
erst mal riesen Dank für das Modul für das Yeelight.
Ich bekomme leider keine Verbindung hin, Fhem & Lampensoftware sind aktuell. Die Lampe kann mit der App auch gesteuert werden.
Leider steht im Fhem immer nur disconnected im Webinterface.
Ich hab zu Testzwecken erst ein mal nur dein Befehl übernommen und natürlich die IP der Lampe angepasst.
Im Standard Log steht vollendendes:

Code Auswählen Erweitern

2016.12.21 16:04:52 1: PERL WARNING: Prototype mismatch: sub main::to_json ($@) vs ($) at /usr/share/perl/5.18/Exporter.pm line 66, <$fh> line 2286.
2016.12.21 16:04:52 1: PERL WARNING: Prototype mismatch: sub main::from_json ($@) vs ($) at /usr/share/perl/5.18/Exporter.pm line 66, <$fh> line 2286.
2016.12.21 16:04:52 3: YeeLight SchlafzimmerLicht defined at 192.168.178.35:55443
2016.12.21 16:04:52 3: Opening SchlafzimmerLicht device 192.168.178.35:55443
2016.12.21 16:04:52 3: Can't connect to 192.168.178.35:55443: Connection refused
2016.12.21 16:04:52 2: Attempt to write to disconnected device.
2016.12.21 16:04:52 1: PERL WARNING: Use of uninitialized value $ret in concatenation (.) or string at ./FHEM/32_YeeLight.pm line 602, <$fh> line 2286.
2016.12.21 16:04:52 1: PERL WARNING: Use of uninitialized value $ret in pattern match (m//) at ./FHEM/32_YeeLight.pm line 603, <$fh> line 2286.
2016.12.21 16:04:52 1: PERL WARNING: Use of uninitialized value $ret in concatenation (.) or string at ./FHEM/32_YeeLight.pm line 603, <$fh> line 2286.

Ich hoffe ihr könnt daraus etwas lesen, ich bin zwar gut im Foren durchstöbern aber so gut kenne ich mich leider nicht aus.
Schöne Grüße aus Niedersachsen bjbrill

[thaliondrambor]

Guten Abend,

@bjbrill
Ich vermute, dass du den Developer Mode in der Lampe noch nicht aktiviert hast. Dann läuft die Kommunikation nur verschlüsselt und das kann die API und damit FHEM nicht.
Zum Aktivieren des Developer Mode musst du in der Yeelight-App (nicht MiHome) die Lampe auswählen, dann oben rechts mit den drei Punkten die Einstellungen öffnen, dort auf "Developer Mode" und dann den Schalter hinter Developer Mode antippen.

Gruß

thaliondrambor

[bjbrill]

So einfach kann es sein, 

Ich hab den Development über die App eingeschaltet und schon bekomme ich auch eine Verbindung.

Herzlichen Dank für die Super schnelle Antwort, dann kann das getüftel jetzt ja los gehen 

[thaliondrambor]

So, ich stelle euch dann mal wieder meine abendliche Arbeit zur Verfügung.

Als erstes habe ich das Problem mit den zu vielen bzw. schnellen Antworten behoben. Das war gar nicht so einfach, aber jetzt sollte das Modul diese richtig auseinander nehmen. Ich habe es mit drei Befehlen auf einmal versenden versucht und es hat mit der aktuellen Version immer geklappt.

Außerdem gibt es nun eine Überprüfung der gesendeten und der empfangenen Befehle, ob sie tatsächlich dem JSON-Format entsprechen. Sollte dies nicht der Fall sein, werden sie in einer ErrorQueue abgespeichert, die man dann z.B. über "list [NAME]" einsehen kann. Es wird vorher auch noch ein recht einfach gehaltener Versuch unternommen, die Zeichenkette zu reparieren (auf eckige Klammern am Ende und Anfang schauen und eventuell hinzufügen).
Also selbst fehlerhafte Zeichenketten sollten FHEM jetzt nicht mehr zum Absturz bringen.


Außerdem habe ich zwei neue Kommandos hinzugefügt, die allerdings nicht in der Auswahlliste erscheinen, da sie nur für Sonderfälle gedacht sind und voraussetzen, dass man sich mit der API und dem Modul auseinander gesetzt hat.

Mit "raw" kann man eigenen Code an die Lampen senden. Wenn dieser der Yeelight-API entspricht, wird er auch ausgeführt. Z.B.:

Code Auswählen Erweitern

set [NAME] raw {"id":1,"method":"set_power","params":["off","smooth",3000]}
Dies entspricht:

Code Auswählen Erweitern

set [NAME] off 3000
Wenn der Befehl nicht richtig ist, wird er trotzdem an die Lampe gesendet. Sollte er nicht dem JSON-Format entsprechen, dann landet er in der ErrorQueue. Auch die Antwort der Lampe, landet dort, wenn der Befehl nicht passt.

Mit "flush" können die Inhalte der drei Queues gelöscht werden. Die gelöschten Inhalte werden ab verbose "4" im Log gespeichert vor dem Löschen. Beim Löschen der Devices und beim Runterfahren von FHEM wird auch ein "flush" durchgeführt. Der Befehl sieht wie folgt aus:

Code Auswählen Erweitern

set [NAME] flush

Ich hoffe es läuft jetzt alles so weit und alle schön fleißig testen. Die neue Version gibt es gleich auf Github.

(Die erste Hälfte der Bridge funktioniert schon, so dass bald auch mit autocreate und einer eindeutigen Identifizierung über die ID, unabhängig der IP-Adresse, gerechnet werden kann.)

Gruß

thaliondrambor

[thaliondrambor]

Guten Abend,

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.
Geplant: Parameter für Farbe, Anzahl, Dauer (Frequenz)

Syntax und Beispiele:

Code Auswählen Erweitern

set [NAME] blink
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

Außerdem habe ich einen Großteil der Anleitung im ersten Post geschrieben.

Gruß
thaliondrambor