Osram Lightify

Begonnen von Laffer72, 27 Oktober 2014, 12:53:12

Vorheriges Thema - Nächstes Thema

justme1968

ich hab es mal so eingebaut. deine falsch erkannte lampe ist damit auch behoben.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Damian

#121
Falls jemand eine Anregung für eine FB für RGBW-Stripes braucht (hier FS20 S8 mit Osram RGB LIGHTIFY FLEX RGBW):

define di_led DOIF ([FS20_000600] eq "on")
  (set HUEDevice1 pct 100)
DOELSEIF ([FS20_000600] eq "off")
  (set HUEDevice1 pct 0)
DOELSEIF ([FS20_000600] eq "dimup")
  (set HUEDevice1 pct {([HUEDevice1:pct]+10)})
DOELSEIF ([FS20_000600] eq "dimdown")
  (set HUEDevice1 pct {([HUEDevice1:pct]-10)})

DOELSEIF ([FS20_000601] eq "on")
(set HUEDevice1 hue 63535)
DOELSEIF ([FS20_000601] eq "off")
  (set HUEDevice1 hue 0)
DOELSEIF ([FS20_000601] eq "dimup")
  (set HUEDevice1 hue {([HUEDevice1:hue]+2000)})
DOELSEIF ([FS20_000601] eq "dimdown")
  (set HUEDevice1 hue {([HUEDevice1:hue]-2000)})

DOELSEIF ([FS20_000602] eq "on")
(set HUEDevice1 sat 254)
DOELSEIF ([FS20_000602] eq "off")
  (set HUEDevice1 sat 0)
DOELSEIF ([FS20_000602] eq "dimup")
  (set HUEDevice1 sat {([HUEDevice1:sat]+10)})
DOELSEIF ([FS20_000602] eq "dimdown")
  (set HUEDevice1 sat {([HUEDevice1:sat]-10)})

DOELSEIF ([FS20_000603] eq "on")
(set HUEDevice1 ct 330)
DOELSEIF ([FS20_000603] eq "off")
  (set HUEDevice1 ct 200)
DOELSEIF ([FS20_000603] eq "dimup")
  (set HUEDevice1 ct {([HUEDevice1:ct:d]+10)})
DOELSEIF ([FS20_000603] eq "dimdown")
  (set HUEDevice1 ct {([HUEDevice1:ct:d]-10)})

attr di_led do always



Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

tomas123

In der fhem.cfg steht als Fehlermeldung "unknown attribute pollDevices".
Offensichtlich wurde das Attribut automatisch von Modul 30_LIGHTIFY.pm angelegt.
Ist das ein Problem?

attr global motd Error messages while initializing FHEM:\
configfile: Lightify: unknown attribute pollDevices. Type 'attr Lightify ?' for a detailed list.
...
attr Lightify pollDevices 1


der Befehl
list Lightify
Internals:
   CONNECTS   1
   DEF        192.168.1.46
   FD         4
...
Attributes:
   pollDevices 1

zeigt das Attribut an

Log
2015.02.15 22:41:47.626 3: Lightify: unknown attribute pollDevices. Type 'attr Lightify ?' for a detailed list.
2015.02.15 22:41:50.301 1: configfile: Lightify: unknown attribute pollDevices. Type 'attr Lightify ?' for a detailed list.
2015.02.15 22:41:57.896 2: Error messages while initializing FHEM: configfile: Lightify: unknown attribute pollDevices. Type 'attr Lightify ?' for a detailed list.

justme1968

ja ich weiß das es die meldung gibt.

erst mal ignorieren.

das attribut muss gesetzt werden. auch wenn es im modul nicht vorgesehen ist.

gruß
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

tomas123

Zitat von: justme1968 am 13 Februar 2015, 12:49:44
ich habe das modul im aktuellen stand mit zwei kleinen erweiterungen eben eingecheckt: http://forum.fhem.de/index.php/topic,33736.0.html.

gruss
  andre

mein feedback nach einer Woche mit drei Lampen am Osram Gateway: rock stable  :)

Goodie_One

Hi,

kurz zu meinem Systemaufbau:
- FHEM-Server auf Synology NAS
- CUL und einige FS20-Geräte
- Lightify mit drei RGBW Lampen und einem RGBW-Strip

Habe den Gateway (als LICHT_SZ) im fhem.cfg eingebunden, bekomme dann im log folgende Meldung:

2015.02.27 16:47:37 1: LICHT_SZ: Autocreate: An error occurred while creating device for id '1234567890123456': Cannot load module HUEDevice


Liegt das am JSON? Warum benötigt das Lightify was von HUE?

Greets, One

justme1968

weil (wie auch in der commandref steht) die einzelnen lampen jeweils ein HUEDevice sind:
ZitatThe actual LIGHTIFY lights are defined as HUEDevice devices. sind.

wenn du ins log schaust wirst du ziemlich sicher sehen das es am fehlenden json perl modul liegt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Goodie_One

Hi Andre,

danke für die Antwort - jep offensichtlich ...

Und ja, wenn ich das Log nochmals genauer studiere steht dann 4 mal da, dass ich kein json.perl Modul habe. Ok, werde mal die entsprechende Anleitung (ist ja im wiki zu finden) durcharbeiten.

Und wenn es dann funkt auch kurz berichten.

Greets,
One

Goodie_One

Hi,

nur kurz, funkt gut. Lediglich der Color-Picker geht auf dem Firefox im Android nicht. Ansonsten coole Sache das. Kann/soll ich irgendwelche Log-Auszüge posten, die nützlich für die weitere Verfeinerung des Moduls dienen?

Greets,
One

justme1968

vielleicht kann noch mal jemand versuchen mitzuschneiden ob man erkennen kann ob eine leuchte im rgb oder im weiss mode ist.

also bei einer rgbw leuche jeweils farben und weisstöne über die app einstellen und die nachrichten aus dem fhem log mit verbose 5 posten.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

tomas123

Wenn ich in der lightify smartphone app etwas einstelle, dann loggt doch FHEM nichts, solange ich in FHEM keinen Parameter verändere.
Soll ich manuell die entsprechenden Statusmeldungen "07 00 00 13 10 00 00 00 01" triggern ?

PS: hier hat jemand Anfang Dezember in python Modul für Osram Lightify angefangen
https://github.com/mikma/python-lightify
# Commands
# 13 all light status (returns list of light address, light status, light name)
# 1e group list (returns list of group id, and group name)
# 26 group status (returns group id, group name, and list of light addresses)
# 31 set group luminance
# 32 set group onoff
# 33 set group temp
# 36 set group colour
# 68 light status (returns light address and light status (?))

justme1968

ich dachte das gateway meldet auch wenn über die app geschaltet wird.

da fällt mir ein das noch die gruppen fehlen.

die 0x68 nachricht wäre zur status abfrage vermutlich besser als die 0x13 die ich zur zeit verwende.

weißt du mehr darüber?
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

tomas123

#132
Zitat von: justme1968 am 03 März 2015, 21:57:19
die 0x68 nachricht wäre zur status abfrage vermutlich besser als die 0x13 die ich zur zeit verwende.
weißt du mehr darüber?

ich habe mich mal durch den Python Code durchgearbeitet:
COMMAND_LIGHT_STATUS = 0x68

class Lightify:
    def update_light_status(self, light):
        data = self.build_light_status(light)
        self.send(data)
        data = self.recv()
        return

    def build_light_status(self, light):
        return light.build_command(COMMAND_LIGHT_STATUS, "")

class Light(Luminary):
    def build_command(self, command, data):
        return self.__conn.build_light_command(command, self, data)

class Lightify:
    def build_light_command(self, command, light, data):
        length = 6 + 8 + len(data)
        return self.build_basic_command(0x00, command, struct.pack("<Q", light.addr()), data)

    def build_basic_command(self, flag, command, group_or_light, data):
        length = 14 + len(data)
        return struct.pack("<H6B", length, flag, command, 0, 0, 0x7, self.next_seq()) + group_or_light + data


demnach ergibt sich für die Lampe 12 97 bc d9 00 00 26 18 84 folgender Code zur 0x68 Statusabfrage:
     
   pack("<H6B", length, flag, command, 0, 0, 0x7, self.next_seq()) + group_or_light + data
   0E 00 00 68 00 00 07 12 97 bc d9 00 00 26 18 84


und siehe da, es geht:
$ echo '0E 00 00 68 00 00 07 12 97 bc d9 00 00 26 18 84' | xxd -r -p | nc 192.168.1.46 4000 | hexdump -C
00000000  1b 00 01 68 00 00 07 12  00 01 00 97 bc d9 00 00  |...h............|
00000010  26 18 84 00 02 00 23 58  14 ff 07 01 ff           |&.....#X.....|


ich habe mal an der RGB Lampe herumgespielt und es ergibt sich wieder das übliche Schema für die Antwort:

1b 00 01 68 00 00 07 12 00 01 00 97 bc d9 00 00 26 18 84 00 02 00 23 58 14 ff 07 01 ff

ergibt entsprechend des allgemeinen Antwort-Schemas
1b 00                              Anzahl der Bytes des Paketes minus 2
      01                           01 Antwort vom Gateway (00 Kommando zum Gateway)
         68                        Befehlsname (hier 0x68 = LED Status)
            00                     fortlaufender Counter um die Antwort des Gateways zuordnen zu können
               00 07 12            unknown
                        00         00=ok // 15=Error (als Antwort)
                           01      Anzahl der folgenden Info-Zeilen (=Anzahl der Lampen, hier = 1)
                              00   unknown
97 bc d9 00 00 26 18 84            Adresse der Lampe
00                                 00=Lampe erreichbar / 01 = Lampe nicht erreichbar und Stopmarker der Antwort
   02                              unknown
      00                           00=off / 01=on
         23                        Helligkeit in Prozent
            58 14                  Farbtemperatur 0x1458= 5208 Kelvin
                  ff 07 01         RGB
                           ff      unknown


leider gibt es keine neuen Erkenntnisse, da die Antwort auf 0x68 noch knapper ist, als die Antwort auf die Statusanfrage aller Lampen 0x13
(es fehlt u.a. die Zigbee 16 Bit short adress)
$ echo '07 00 00 13 10 00 00 00 01' | xxd -r -p | nc 192.168.1.46 4000 | hexdump -s 11 -e '"%8.8_ax " 18/1 "%02.2x " "|on:"1/1 "%02.2x " "|H:"1/1 "%02.2x " "|T:"2/1 "%02.2x ""|RGB:"3/1 "%02.2x " " |"' -e '42/1 "%_p" "\n"'
...
00000089 2d 8f 97 bc d9 00 00 26 18 84 0a 01 02 03 03 02 00 00|on:00 |H:23 |T:58 14|RGB:ff 07 01 |-......&...........#X.....WoZi............


der einzige Unterschied:

0x13 fragt nur das Gateway ab. Die Antwort erfolgt sofort. Dabei werden auch Lampen gemeldet, die man gerade vom Stromnetz getrennt hat, weil es immer einige Zeit dauert, bis das Gateway eine tote Lampe bemerkt.

0x68 fragt die Lampe direkt ab (über das Gateway  :) ).
Die Antwort verzögert sich um etwa 1 Sekunde. Dafür werden stromlose Lampen sofort erkannt.

Beispiel für Lampe nicht erreichbar (Stopmarker 01)
$ echo '0E 00 00 68 00 00 07 12 97 bc d9 00 00 26 18 84' | xxd -r -p | nc 192.168.1.46 4000 | hexdump -C
00000000  12 00 01 68 00 00 07 12  00 01 00 97 bc d9 00 00  |...h............|
00000010  26 18 84 01                                       |&...|


fragt man eine nicht am Gateway registrierte Lampe an, wird nicht mal mehr die Adresse zurückgemeldet:
$ echo '0E 00 00 68 00 00 07 12 97 bc ef 00 00 26 18 84' | xxd -r -p | nc 192.168.1.46 4000 | hexdump -C
00000000  07 00 01 68 00 00 07 12  15                       |...h.....|

tomas123

#133
Zitat von: justme1968 am 03 März 2015, 09:29:10
vielleicht kann noch mal jemand versuchen mitzuschneiden ob man erkennen kann ob eine leuchte im rgb oder im weiss mode ist.

das weiß leider nicht mal die lightify app selber

(http://www.iphone-ticker.de/wp-content/uploads/2014/09/lightify-app-700.gif)

Im mittleren Bild ist eine RGB Lampe dargestellt (rechts eine weiße Lampe mit regelbarer Farbtemp, veraltete App).

mittl. Screenshot zeigt: Farbtemperatur 2700K (rötl. weiß) und RGB=Grün (bei Helligkeit = 100%)
Welche Farbe die Lampe tatsächlich hat, hängt davon ab, ob man zuletzt am Schieber Farbtemperatur (Lampe weiß) oder RGB (Lampe grün) gezuppelt hat.
Die App kann das nicht darstellen. Der grüne Kreis oben links kann lügen...

Ich habe auch in den Statusabfragen 0x13 und 0x68 kein Byte gefunden, dass den Modus White / RGB anzeigt.

tomas123

Zitat von: justme1968 am 03 März 2015, 21:57:19
ich dachte das gateway meldet auch wenn über die app geschaltet wird.

Na ja, da Antwort erfolgt doch an die IpAdresse:Port von der das Paket losgeschickt wurde.
FHEM muss schon explizit eine eigene Statusanfrage senden um eine Antwort zu erhalten