Osram Lightify

[tomas123]

zur Helligkeit

ich schau mir das morgen noch mal mit wireshark an

ich kann hier im Protokoll in der Bytefolge für Helligkeit 0x05 keinen Fehler erkennen

Code Auswählen Erweitern

2015.02.12 01:25:01 3: Ligthify: sending:1100003100000000F58CD90000261884230500
trotzdem bleibt die Lampe hell

wenn ich exakt den gleichen Befehl in der Shell ausführe wird die Lampe dunkel

Code Auswählen Erweitern

$ echo '1100003100000000F58CD90000261884230500' | xxd -r -p | nc 192.168.1.46 4000 | hexdump -C
00000000  12 00 01 31 00 00 00 00  00 01 00 f5 8c d9 00 00  |...1............|
00000010  26 18 84 00                                       |&...|



im Logfile sind auch z.T. seltsame Antworten:

auf Status 07 kommt hier eine vollständige Antwort

Code Auswählen Erweitern

2015.02.12 01:24:17 3: Ligthify: sending:070000130000000001
2015.02.12 01:24:17 3: Ligthify: received: 8700011300000000000300a2254094c900002618840a010203010203000057a40c26ff36ff47656f72672773205a696d6d65720000cfd70388d90000261884020102030702050000648e0a01ff01ff466c7572206f62656e000000000000008985f58cd90000261884020102030702050001178e0affffffff466c757220756e74656e000000000000

auf 07 kam nur eine kurze Antwort

Code Auswählen Erweitern

2015.02.12 01:25:01 3: Ligthify: sending:0f00003200000000F58CD9000026188401
2015.02.12 01:25:01 3: Ligthify: sending:1100003100000000F58CD90000261884230500
2015.02.12 01:25:01 3: Ligthify: sending:070000130000000001
2015.02.12 01:25:01 3: Ligthify: received: 1200013200000000000100f58cd9000026188400


aber was mich am meisten beeindruckt:

Wie oben beschrieben ist das Osram Gateway manchmal für einige Minuten nicht über Ping erreichbar.
In dieser Zeit werden auch keine Befehle vom netcat angenommen (port 4000 closed)

Code Auswählen Erweitern


$ echo '0f 00 00 32 01 00 00 00 f5 8c d9 00 00 26 18 84 00' | xxd -r -p | nc 192.168.1.46 4000 | hexdump -C
^C


Dagegen funktioniert aber weiterhin die FHEM Steuerung der Osram Lampen.
Da scheint es im TCP/IP Handshake einen entscheidenden Unterschied zu geben.

[justme1968]

anbei noch mal eine aktualisierte version.

- fehlende client liste gesetzt

- die laufende nummer der nachricht wird hoch gezählt

- das ct kommando müsste gehen

- transitiontime sollte setzbar sein

- rgb ist noch nicht drin. da muss ich erst noch umrechnen

vielleicht kommen die kurzen antworten wenn sich der status nicht geändert hat.

das das fhem modul weiter senden kann liegt vielleicht daran das eine einzige verbindung dauernd offen gehalten wird und nur neue verbindungen betroffen sind.

gruss
  andre

[trickser]

Ich habe mir mal das Wireshark Protokoll angeschaut.

Es zeigt einen Fehler in der Kommunikation und Übertragung zwischen dem Gateway und dem FHEM Server.

Code Auswählen Erweitern


Paket 1    0f 00 00 32 00 00 00 00  34 74 c9 00 00 26 18 84   01
Paket 2    11 00 00 31 00 00 00 00  34 74 c9 00 00 26 18 84   1b 05 00 07 00 00 13 00  00 00 00 01
Beide Pakete kommen vom FHEM Server.


Zur Erklärung:
Paket 1 ist ein normales einschalten der Lampen.
Paket 2 soll dagegen die Helligkeit justieren.

Dabei existiert aber zwei Probleme.
1. Ich habe das Einschalten der Lampen nicht beauftragt. Somit wird dieses Paket auch losgeschickt, wenn ich nur die Helligkeit betätige.
Der Fehler fällt einem normalerweise nicht wirklich auf. Doch früher oder später wäre es doch aufgefallen.
Eigenschaften an eine Lampe zu senden geht bei fast allen Eigenschaften, nur die Farbe wird nur übernommen, wenn die Lampe auch an ist.

2. Wird dem eigentlichen Paket für die Helligkeit auch das Paket für den LIGHTIFY_Read() Befehl hinzugefügt. Das versteht das Gateway natürlich nicht und antwortet darauf auch ebenso wenig.
Im Code wird ja in der LIGHTIFY_Write() Funktion am Ende als Schlusslicht ja nochmal ein LIGHTIFY_sendRaw() mit "getDevices" ausgeführt. Diese Bytefolge wird dabei an die Bytefolge für die Helligkeit angeknüpft.


Als Beweis für die Theorie habe ich mal den letzten sendRaw ausgeklammert und die Helligkeitsregelung funktionierte.
Das gleiche scheint auch bei dem An / Aus Befehl zu passieren, das System vom Gateway ist aber bei dem Befehl aber viel stabiler.

Ich habe das mal mit dem kleinen netten, freien Tool namens PacketSender (http://packetsender.com) mal ausgetestet. Und habe einfach mal aus Spaß ein TCP Paket mit dem HexCode an das Gateway gesendet:

Code Auswählen Erweitern

0f 00 00 32 14 00 00 00 40 94 c9 00 00 26 18 84 01 [b]07 00 00 13 10 00 00 00 01[/b]
Zur Erklärung. 

Code Auswählen Erweitern

0f 00 00 32 14 00 00 00 40 94 c9 00 00 26 18 84 01 ist zum einschalten der Lampen und

Code Auswählen Erweitern

07 00 00 13 10 00 00 00 01 ist der Code, damit das Gateway dir die Lampeninformationen übermittelt.
Eigentlich sollten sie nicht hintereinander stehen, ich habe es aber mal ausgetestet. Es funktionierte und die Lampe sprang an.


Das gleiche mit der Helligkeit getestet.

Code Auswählen Erweitern

11 00 00 31 6f 00 00 00 34 74 c9 00 00 26 18 84 20 00 00 07 00 00 13 10 00 00 00 01
Diesmal dagegen gab es keine Reaktion. Weder in der Antwort noch im visuellen.


Ich denke das der Fehler im syswrite() liegt. Da ich persönlich keine Probleme im Code erkennen kann.

[justme1968]

ich verstehe nicht ganz was du mit fehler meinst.

das fhem modul sendet zur zeit vor dem dim befehl noch explizit noch ein einschalten (und danach noch eine status abfrage).

das ist nichts anderes als wenn ich von hand zuerst ein schalte und dann die helligkeit ändere.

beides kannst du auf netzwerk ebene nicht unterscheiden. da gibt es keine pakete sondern nur bytefolgen. das ist ja auch der grund warum am anfang einer nachricht die länge steht. damit du weisst wann eine nachricht zu ende ist und die nächste anfängt.

es kann natürlich sein das das gateway probleme hat wenn nachrichten zu schnell kommen. das wäre aber dann tatsächlich ein bug auf deren seite und wir müssen uns einen workaround überlegen.

oder man darf ein kommando erst senden wenn das vorherige bestätigt wurde.

bitte bau mal nach dem syswrite in sendRaw ein

Code Auswählen Erweitern

select(undef,undef,undef,0.5);ein und schau ob es dann geht. du kannst auch mit 1 statt 0.5 probieren.

wenn das funktioniert baue ich ein das das nächste kommando erst dann gesendet wird wenn das vorherige bestätigt wurde.

gruss
  andre

[tomas123]

vielleicht stimmt das timing nicht

das Gateway wird mit zwei anfragen überflutet und muss noch seine Antwort los werden

verbessert sich das Timing, wenn  man jede Antwort ins Log zu schreibt?

[justme1968]

das select oben baut eine kurze verzögerung ein. das wäre der test zum timing.

gruss
  andre

[trickser]

Und das Select war Lösung. Ich würde aber wirklich auf die Antwort warten statt nur eine Zeit abzuwarten.

[justme1968]

ich bin schon am einbauen.

gruss
  andre

[trickser]

Ich würde den für dich mal die letzten beiden veränderbaren Werte:
Farbtemperatur &
Farbe
einbauen. Würde aber wissen (falls du es weißt) welche Variablen ich dafür abgreifen muss. Für Helligkeit gibt es ja auch bri und pct.

[justme1968]

die farbtemperatur ist in der version oben schon drin:

Code Auswählen Erweitern

set <device> ct 3000
die farbe habe ich hier auch schon fertig.

gruss
  andre

[justme1968]

versuch mal die angehängte version.

- es gibt jetzt eine send queue. eine neue nachricht wird erst dann abgeschickt wenn die vorherige bestätigt wurde
- das setzten der farbe müsste jetzt auch  gehen (colorpicker, hue slider, set rgb)

was noch fehlt:
- rausfinden welcher lampen typ (rgb/rgbw/w) es tatsächlich ist
- reachable auswerten
- alles was mit gruppen zu tun hat

gruss
  andre

[trickser]

Ich werde die Version gleich testen.

was noch fehlt:
- rausfinden welcher lampen typ (rgb/rgbw/w) es tatsächlich ist
- reachable auswerten
- alles was mit gruppen zu tun hat

Ich habe die Informationen zu (fast) all den Problemen. Als ich das Protokoll letztens analysiert hatte habe ich mich genügend damit auseinandergesetzt.

1. der Lampentyp ist bei der Nennungsnummer der Lampe im dritten Byte kodiert.
Ich habe zwei Weiße Lampen und 1 RGB (w) Lampe.
Weiße Lampen haben die Kennung       ?? ?? D9 ...
RGB(w) Lampen haben die Kennung     ?? ?? C9 ...


Reachable ist herauszufinden wie es Tomas schon erwähnte mit dem letzten Byte = 01
ODER
sobald die short Adresse

Code Auswählen Erweitern

normale LED
short |HW Adresse             ??          ??    ??   Off Hel Temp R  G  B     Name-String
CF D7 03 88 D9 00 00 26 18 84 02 01 02 03 07 02 05 00 00 2D 8E 0A FF FF FF FF 46 6C 75 72 20 6F 62 65 6E 00 00 00 00 00 00 00
(Zitat)
FF FF steht. Dieses FF erscheint nach einiger Zeit, oder wenn man die Lampe von Hand mal angetrickert hat. Zum Beispiel An / aus oder Helligkeit ... und danach die Namenabfrage.



Gruppen ist auch schönes Thema. Gruppen werden als neue Steuereinheit definiert. Ich kann somit einfach die Gruppe ausschalten und alle Lampen in dieser Gruppe gehen aus. Gleiche bei Helligkeit, Farbe und Farbtemperatur.

Gruppennamen bekommt mit dem Befehl:

Code Auswählen Erweitern

06 00 00 1e 01 00 00 00
als Antwort kommt:

Code Auswählen Erweitern


00000000  3f 00 01 1e 10 00 00 00  00 03 00 01 00 41 6c 6c  |?............All|
00000010  65 20 4c 61 6d 70 65 6e  00 00 00 00 00 02 00 48  |e Lampen.......H|
00000020  61 6E 73 65 27 73 20 47  72 75 70 70 65 00 00 03  |anse's Gruppe...|
00000030  00 4e 61 63 68 74 6c 69  63 68 74 00 00 00 00 00  |.Nachtlicht.....|
00000040  00                                                |.|

Formatiert ist das:
3F 00 01 1E 01 00 00 00 00 03 00                                    - wahrscheinlich 3 Gruppen
01 00 41 6C 6C 65 20 4C 61 6D 70 65 6E 00 00 00 00 00   - Name
02 00 48 61 6E 73 65 27 73 20 47 72 75 70 70 65 00 00    - Zahl der Gruppe
03 00 4E 61 63 68 74 6C 69 63 68 74 00 00 00 00 00 00

Wie ich nun die Lampen aus den Gruppen auslesen, ist noch eine Frage mit der ich mich gleich mal beschäftigen werde. In meinem letzten Wireshark Protokoll hatte ich was ähnliches gefunden.

[trickser]

In der neuen Version gibt es anscheinend einige Fehler. Ich bekomme zumal die Fehlermeldungen:

Code Auswählen Erweitern

2015.02.12 19:36:01 1: Ligthify: Autocreate: An error occurred while creating device for id '3474C90000261884': HUEDevice3474C90000261884 already defined, delete it first

Zu anderen gibt es einen Fehler bei deinem Code das dass hier irgendwie passiert:

Code Auswählen Erweitern

2015.02.12 19:33:01 3: Ligthify: sending:070000130000000001
2015.02.12 19:33:01 3: Ligthify: sending:070000130000000001
2015.02.12 19:33:02 3: Ligthify: sending:070000130000000001

Als Antwort kam nur eine Anfrage zurück.
Gleiche als man die Anfrage für ein/aus stellen wollte:

Code Auswählen Erweitern

Ligthify: sending:0f000032000000004094C9000026188401
Ligthify: sending:070000130000000001

Antwort kam nur für Gruppe.
Antwort für ein/aus dagegen kam nie an.

Ich habe den Code selbst analysiert und mir ist kein Fehler aufgefallen, sondern dein Code sieht sehr stabil und solide aus. Aber scheint trotzdem nicht zu laufen.
(Die Statusabfrage wird anscheinend alle paar Millisekunden rausgehauen)

Im Prinzip. Es läuft zurzeit nichts. Weder schafft die Webseite es die Lampen ein und auszuschalten noch den Status der Lampen zu erkennen.

EDIT:
Die alte Version dagegen funktioniert hervorragend. Ich habe sie nochmal eingeladen und die Fehlermeldung

Code Auswählen Erweitern

Ligthify: Autocreate: An error occurred while creating device for id ...
Existiert nicht.

[justme1968]

zeig mal bitte ein list auf das lightify device.

[trickser]

Code Auswählen Erweitern

Internals:
   CONNECTS   1
   DEF        192.168.1.78
   FD         4
   Host       192.168.1.78
   LAST_CONNECT 2015-02-12 19:54:39
   NAME       Ligthify
   NR         31
   NTFY_ORDER 50-Ligthify
   STATE      Connected
   TYPE       LIGHTIFY
Attributes:

Ich sehe hierdraus erstmal keine Probleme. Das List wurde erstellt mit dem alten Skript, da ich ja mein Haus noch bedienen will .