WOFI Leuchten 2.4G RF (FINAL: funktioniert mit NodeMCU V3 und NRF24L01+PA+LNA)

[Felix_86]

Hallo zusammen,

ich bin dabei in unserem Büro einen Showroom einzurichten. FHEM soll hier zur Steuerung von Licht, Heizung und Rollläden usw. dienen.
(Die Rollläden konnte ich bereits erfolgreich (dank dieses Forums) mit dem Intertechno (IT) Modul einbinden und ansteuern.)

Nun möchte ich auch die Deckenlampen mittels FHEM ansteuern. Es handelt sich um WOFI Leuchten. Davon hängen 3 Stück in den Büros, jeweils mit einer eigenen Fernbedienung (total unpraktikabel).
Eine genaue Bezeichnung habe ich leider nicht, aber es geht in diese Richtung:
https://www.wofi.de/innenleuchten/deckenleuchten/2727/deckenleuchte-milo-1flg

Anbei einige Bilder der Lampe, der Technik darunter, sowie der Fernbedienung samt Innenleben.
Bei der Fernbedienung irritiert mich die Kennzeichnung "2.4G RF". Ich kann mir nicht vorstellen, dass tatsächlich auf dem 2.4 GHz Kanal (WLAN) gesendet wird.


Bei meinen Recherchen bin ich bereits auf folgende Einträge hier im Forum gestoßen:
1. https://forum.fhem.de/index.php?topic=59844.0
2. https://forum.fhem.de/index.php?topic=57378.0
3. https://forum.fhem.de/index.php/topic,18958.msg384743.html#msg384743

Zu 1.)
Hier funktioniert leider der Link im Thread nicht mehr, der mir einen Vergleich der Fernbedienung ermöglichen könnte. Das dort genannte Milight Modul habe ich bereits gesehen. Für die Verwendung ist allerdings eine MilightBridge erforderlich und ich wüsste nicht, wo sich hier im Büro eine entsprechende Bridge / Gateway befinden sollte - außer in der Lampe selbst.
Weiter bin ich auf das Modul WifiLight gestoßen, welches allerdings ebenfalls eine Bridge / Gateway erfordert. Zumindest in unserem Netzwerk befindet sich kein entsprechendes Gerät, das ich per IP in FHEM einbinden könnte.

Zu 2.)
Hier wird von einer Fernbedienung mit 433 MHz geschrieben, ich bin nicht sicher, ob das in meinem Fall passend ist. Zudem bin ich mit RFXTRX völlig unerfahren, würde mich allerdings einarbeiten, wenn es erforderlich ist.

Zu 3.)
Hier wird leider nicht darauf eingegangen, wie herauszufinden ist, welche Protokolle WOFI benutzt und ob diese Kompatibel sind mit Wifilight.

Vielen Dank für Eure Tipps, Hinweise und Unterstützung.

[Beta-User]

Es gibt nicht nur WLAN, das auf 2.4 GHz liegt, sondern ua. eben noch MiLight oder auch Zigbee (Hue, Tradfri und co). Das dürfte also stimmen.

Da die Lampe aus 2014 ist, _könnte_ es tatsächlich ein MiLight-kompatibles Protokoll sein.

Bei MiLight lassen sich die einzelnen Leuchtmittel mit mehreren Fernbedienungen koppeln - eine MiLight-Bridge wäre dann eine Art _zusätzliche_ Fernbedienung - die ist also im Moment (vermutlich) wirklich nicht zu finden (die wird dann über WLAN bedient, eigentlich per Handy-App).

Die einfachste Vorgehensweise um das zu testen ist also die, dass du dir eine MiLight-Bridge zulegst - am universellsten ist ein Selberbau-Gerät auf ESP8266-Basis, die hier unter "Sidoh-Bridge" bekannt ist - die kann nämlich zwei Protokollvarianten, andere Kauf-Bridges nicht. Wenn du Glück hast, werden deine Fernbedienungen von der erkannt und du kannst sie einfach duplizieren und die Bridge dann mit dem WifiLight-Modul ansteuern. Wenn nicht, wird es etwas komplizierter. Details hier: https://forum.fhem.de/index.php/topic,88223.0.html und hier https://forum.fhem.de/index.php/topic,87305.0.html.

[Felix_86]

@ Beta-User
Vielen Dank für die ausführlichen Informationen. Das macht mir erstmal Hoffnung, die WOFI Leuchten steuern zu können.

Bei der Suche hier im Forum nach der Sidoh Bridge finde ich zahlreiche Beiträge und Antworten (unter anderem von dir ), die auf das Github Projekt esp8266_milight_hub oder umgebaute Bridges (z.B. SONOFF) mit der Sidoh Firmware verweisen. Einen Bauanleitung oder Komponentenliste für ein Selberbau-Gerät auf ESP8266-Basis konnte ich nicht finden (evtl. in den Tiefen des Forums übersehen  ).

Wäre eines der folgenden Angebote, das was ich brauche:
https://forum.fhem.de/index.php/topic,83019.msg752311.html#msg752311
https://www.ebay.de/itm/NodeMCU-V3-1-Arduino-ESP8266-ESP-12-E-Lua-CH340-WiFI-WLan-IoT-Lolin-Mini-Micro/252718027546?hash=item3ad72b131a:g:nRoAAOSwYwJaD2tX

Für mich zum Verständnis:
Dies sind dann Steckkarten / Zusatzboards für die GPIO des Raspberry?

Besten Dank im Voraus.

[Beta-User]

Das Ding ist dann schlicht ein unabhängiges Gerät, das ins WLAN eingehängt wird und bringt für erste Tests auch eine eigene Web-Oberfläche mit, mit der man ohne FHEM erst mal die Funktionsfähigkeit testen kann. Funktioniert das, kann man WifiLight, (Milight..., nicht empfohlen), MQTT oder HTTPMOD nutzen, um die Bridge anzusteuern und damit im Prinzip beliebig viele Bulbs bzw. Gruppen von Bulbs schalten.

Die Selberbau-Bridge ist im Prinzip ein ESP8266 (fast egal, welche konkrete Bauform, es muß nur SPI verfügbar sein) und ein nRF24L+-Modul. Chris Mullins hat die original-Verkabelung mit einer NodeMCU (wie der von dir verlinkten) in seinem Blog dargestellt: https://blog.christophermullins.com/2017/02/11/milight-wifi-gateway-emulator-on-an-esp8266/

Hier im Forum wird in der Regel ein MySensors-Gateway genutzt. Dafür gibt es Platinen (oder Fertiggeräte wie das verlinkte), die einen Wemos D1 Mini nutzen (ist etwas kleiner) und ein "kleines" nRF-Modul. Ich selbst habe einen Wemos D1-Klon mit einem "großen" nRF-Modul (geshieldet, "2300m"), verkabelt wie hier https://www.mysensors.org/build/connect_radio (ESP8266-Abschnitt) dargestellt und mit einem Kondensator (Details bei MySensors.org). Bei den nRF-Modulen gibt es viele Fakes, von daher schwankt die Reichweite teilweise erheblich bei den "kleinen" Modulen.

Nimmt man die MySensors-Verkabelung, muß man nur darauf achten, dass ein PIN in der Konfiguration des Web-Interfaces dann (einmalig) umgestellt werden muß (siehe bereits verlinkte Beiträge oder den "eigentlich wollte ich nur..."-Thread).

Hoffe, das ist nun etwas klarer...

[Felix_86]

Hallo Beta-User und all die anderen,

ich bin nun ein Stück weiter:
In den vergangenen 3 Wochen habe ich mir ein ESP8266 und ein nRF24L+-Modul zugelegt, beides nach Anleitung von Chris Mullins verkabelt, mittels "NODEMCU Firmware Programmer" auf Version 1.7.1 geflasht, ins WLAN gebracht, über das Webinterface auf Version 1.8.0 aktualisiert. Das hat soweit geklappt.

Starte ich nun das Sniffing im MiLight Hub und drücke anschließend eine Taste auf der oben gezeigten Fernbedienung sehe ich im Bereich "Traffic sniffed (sent and received)" Einträge zu "cct packet received". Ich gehe daher davon aus, dass die Komponenten funktionieren und die Firmware korrekt geflasht wurde und alles lauffähig ist.

Nun entspricht das von der Fernbedienung empfangene Paket nicht dem Beispiel von Chris Mullins im Bezug auf die Bezeichner HIER.

Code: [Auswählen]

cct packet received (7 bytes):
Request type : 5A
Device ID   : 4307
b1      : 81
b2      : D2
b3      : 00
Sequence Num. : D2
Die Device ID lässt sich anhand des Bezeichners gut herausfinden. Trage ich diese im MiLight Hub ein, stelle den Remote Type auf CCT um, passiert aber nichts.

Im Bereich "Traffic sniffed (sent and received)" sehe ich nun auch die gesendeten Pakete, allerdings haben diese einen anderen Aufbau (Zuordnung von Werten zu den Bezeichnern).

Code: [Auswählen]

cct packet received (7 bytes):
Request type : 5A
Device ID   : 4307
b1      : 01
b2      : 0B
b3      : 02
Sequence Num. : B9
Nach meinen Tests und Prüfungen ergibt sich für mich folgende Zuordnung:

cct packet received (7 bytes)	jedes bisher gesendete und empfangene Paket hat 7 byte
Request type	jedes bisher gesendete und empfangene Paket hat den Type 5A
Device ID	jedes bisher empfangene Paket hat die ID 4307; wenn ich diese ID im Hub eintrage, enthalten alle gesendeten Pakete ebenfalls diese ID
b1	jedes bisher gesendete Paket scheint hier die Group zu enthalten. Je nach dem welche Group ich in MiLight Hub einstelle (1-4 oder all) wird dieser Paramter bei einem gesendeten Paket hier angegeben (01-04 oder 00). jedes bisher empfangene Paket enthält hier allerdings eine Nummer zwischen 80 und 85. Der Wert ist abhängig davon, welche Taste ich drücke (Zuordnung siehe unten)
b2	jedes bisher gesendete Paket schickt hier immer einen anderen Wert, je nach dem welche Einstellungen ich im MiLight Hub bei Farbtemperatur, Helligkeit und Status (an/aus) auswähle / anklicke. Status an ist immer 08, Status aus ist immer 0B. jedes bisher empfangene Paket enthält hier eine fortlaufende HEX-Nummer. Wenn ich mehrmals die gleiche Taste an der Fernbedienung drücke ist das gut zu sehen (.....E8,E9,EA,EB,EC,EE,EF.....)(identisch zu Sequence Num)
b3	jedes bisher gesendete Paket enthält hier eine fortlaufende HEX-Nummer. Wenn ich mehrmals die gleiche Taste im MiLight Hub drücke ist das gut zu sehen (.....71,72,73,74,75,76,77.....) jedes bisher empfangene Paket enthält hier 00, egal welche Taste an der Fernbedienung gedrückt wird
Sequence Num	jedes bisher gesendete Paket enthält hier eine fortlaufende HEX-Nummer, allerdings nicht in 1er Schritten, sondern in 2er Schritten (...47,49,4B,4D.........). Eine Zurodnung zu einem anderen Wert ist hier nicht möglich. jedes bisher empfangene Paket enthält hier eine fortlaufende HEX-Nummer. Wenn ich mehrmals die gleiche Taste an der Fernbedienung drücke ist das gut zu sehen (.....E8,E9,EA,EB,EC,EE,EF.....) (identisch zu b2)

Je nach dem, welche Taste der Fernbedienung ich drücke, ergibt sich für b1 folgender Wert:

Fernbedienung	-->>	cct Packet Value
Taste heller	-->>	b1 = 81
Taste dunkler	-->>	b1 = 80
Taste Licht ein	-->>	b1 = 83
Taste Licht aus	-->>	b1 = 82
Taste warmweiß	-->>	b1 = 84
Taste kaltweiß	-->>	b1 = 85

Zusammenfassung:
- die Fernbedienung sendet bei b1 immer die Taste, die gedrückt wurde
- die Fernbedienung sendet bei b2 immer eine fortlaufende HEX-Nummer
- die Fernbedienung sendet bei b3 immer 00
- der MiLight Hub sendet bei b1 immer die Group, die eingestellt ist
- der MiLight Hub sendet bei b2 immer den Ziel-Schaltzustand (so würde ich das mal interpretieren)
- der MiLight Hub sendet bei b3 immer eine fortlaufende HEX-Nummer (in 2er Schritten)



Habe ich nun eine Change MiLight Hub und die WOFI Lampen zusammen zu bringen?

Kann ich mittels curl oder raw_commands die zu sendenden Parameter für b1,b2,b3 selbst definieren? Wenn ja, wie?
Die Beschreibung der REST endpoints mit "POST /raw_commands/:device_type" habe ich bereits gesehen, allerdings wird nicht beschrieben, welcher Wert im Paket an welche Stelle gehört.

Vielen Dank für's Lesen und hilfreiche Infos.

[Beta-User]

Wow, das liest sich doch schon mal gut, die HW ist damit definitiv funktionsfähig, kann allenfalls noch ein Reichweitenthema sein...

Hast du beide Protokoll-Varianten (V5 und V6) mal ausprobiert? (Da gab es zumindest früher eine Möglichkeit, das umzustellen).

Ansonsten wäre mein Tipp, das ggf. direkt auf Chris' Blog zu fragen bzw. auch vorab da mal zu stöbern. Vielleicht findest du dort den "springenden Punkt". Oder in der Projektbeschreibung zu openmili, da war der Aufbau des V5-Protokolls beschrieben.

[Felix_86]

Besten Dank für deine Rückmeldung, Beta-User.

Ich bin nun die seitenweisen Informationen in Chris' Blog durchgegangen und dabei auf zwei hilfreiche Einträge gestoßen, in denen Chris die Verwendung von curl zum Senden von raw_commands empfiehlt.

In diesem Beitrag baut Chris das curl-Kommando nach meinem Verständnis wie folgt zusammen.

Empfangenes Paket von Josh:

Code: [Auswählen]

cct packet received (4 bytes):
Request type : 5A
Device ID : 2621
b1 : 02
b2 : 0D
b3 : 1D
Sequence Num. : D4
curl-Kommando von Chris:

Code: [Auswählen]

curl -vvv -X PUT -d '{"packet":"5A 26 21 02 0D 1D D4","num_repeats":50}' milight-hub.local/raw_commands/cct
Das heißt für mich:
curl Paket-Stelle 1 = Request type
curl Paket-Stelle 2 = Device ID Teil 1
curl Paket-Stelle 3 = Device ID Teil 2
curl Paket-Stelle 4 = b1
curl Paket-Stelle 5 = b2
curl Paket-Stelle 6 = b3
curl Paket-Stelle 7 = Sequence Num

Übernehme ich diesen Aufbau nun auf ein von mir empfangenes Paket:

Code: [Auswählen]

cct packet received (7 bytes):
Request type  : 5A
Device ID     : 4307
b1            : 82
b2            : 40
b3            : 00
Sequence Num. : 40
Ergibt sich daraus folgendes curl-Kommando:

Code: [Auswählen]

curl -vvv -X PUT -d '{"packet":"5A 43 07 82 40 00 40","num_repeats":50}' 10.10.20.106/raw_commands/cct
Setze ich das curl-Kommando über einen Raspberry ab, ist die HTTP Response zwar 200 OK, aber der Milight Hub snifft für seine eigenen gesendeten Pakete nur 0 (null).

Code: [Auswählen]

pi@raspi1:~/Desktop $ curl -vvv -X PUT -d '{"packet":"5A 43 07 82 40 00 40","num_repeats":50}' 10.10.20.106/raw_commands/cct
* Hostname was NOT found in DNS cache
*   Trying 10.10.20.106...
* Connected to 10.10.20.106 (10.10.20.106) port 80 (#0)
> PUT /raw_commands/cct HTTP/1.1
> User-Agent: curl/7.38.0
> Host: 10.10.20.106
> Accept: */*
> Content-Length: 50
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 50 out of 50 bytes
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Content-Length: 4
< Connection: close
<
* Closing connection 0
true
pi@raspi1:~/Desktop $


Code: [Auswählen]

cct packet received (7 bytes):
Request type  : 00
Device ID     : 0000
b1            : 00
b2            : 00
b3            : 00
Sequence Num. : 00

Wo liegt nun das Problem, dass die im curl-Kommando gesetzten Paketinhalte nicht so vom Milight Hub gesendet bzw. empfangen werden?
Ich habe es bereits mit verschiedenen Paketinhalten versucht, ohne Erfolg. Der Parameter "num_repeats" hat gar keine Auswirkung, es werden immer 10 Pakete im Milight Hub Sniff angezeigt, obwohl im curl-Kommando 50 steht.
Zum Test wurden die curl-Kommandos von einem Mac und einem CentOS abgesetzt, um die curl-Version auszuschließen, allerdings mit gleichem Ergebnis.

Weiterhin vielen Dank.

[Beta-User]

Sorry, aber mit den RAW-Themen bin ich auch etwas überfragt, brauchte ich bisher nicht.

Nur um sicherzugehen: Du hast einen Kondensator dran an dem nRF? Sonst könnte einfach auch die Sendeleistung bescheiden sein...

[Felix_86]

Zunächst schade

Nur um sicherzugehen: Du hast einen Kondensator dran an dem nRF? Sonst könnte einfach auch die Sendeleistung bescheiden sein...

Ich habe keinen Kondensator zwischen nodeMCU und nRF24L+ verbaut. Laut der Anleitung von Chris ist davon auch keine Rede und wurde in der Shopping List auch nicht genannt.

Meine Shopping List umfasst:

NodeMCU V3 ESP8266 ESP-12 E Lua CH340 WiFI WLan IoT 32 Bit microUSB Arduino
https://www.ebay.de/itm/NodeMCU-V3-ESP8266-ESP-12-E-Lua-CH340-WiFI-WLan-IoT-32-Bit-microUSB-Arduino/323317052895?hash=item4b4732b5df:g:auwAAOSwmmxW6dqn

NRF24L01+PA+LNA SMA Antenna Wireless Transceiver Communication Module 2.4G 1100m
https://www.ebay.de/itm/NRF24L01-PA-LNA-SMA-Antenna-Wireless-Transceiver-Communication-Module-2-4G-1100m/323374672377?hash=item4b4aa1e9f9:g:~bIAAOSwmmxW5jCR

40 Stück Dupont Draht Kabel Linie Buchse auf Buchse Jumper Wire Arduino
https://www.ebay.de/itm/40-Stuck-Dupont-Draht-Kabel-Linie-Buchse-auf-Buchse-Jumper-Wire-Arduino/323325742051?hash=item4b47b74be3:g:FNUAAOSwzVxZbeX4

[Beta-User]

Dann solltest du die shopping-List erweitern .

Da du vermutlich "auch noch" das pa+lna-Teil verwendest, ist das umso wichtiger.

...mit einem "großen" nRF-Modul (geshieldet, "2300m"), verkabelt wie hier https://www.mysensors.org/build/connect_radio (ESP8266-Abschnitt) dargestellt und mit einem Kondensator (Details bei MySensors.org). ..

Sorry, hätte ich evtl. noch deutlicher ausdrücken müssen, dass das essentiell ist .

[Felix_86]

Sorry, das verstehe ich nun nicht. Bin ich blind oder liegt es an der Hitze?

Weder Chris noch mysensors.org beschreiben für die Verkabelung von NRF24L01+ & ESP8266 die Verwendung eines Kondensators.
Die NodeMCU kommt direkt mit 3V an zwei entsprechenden PINs. Da sehe ich keine Notwendigkeit für die Verwendung eines Kondensators zur Regulierung von 5V auf 3V.

Weiter schaltet mysensors.org eine Verbindung zwischen NodeMCU Pin D2 zum NRF24L01+ Pin CE. Tue ich dies mit der MiLight Firmware funktioniert gar nichts mehr.
Setze ich die Verbindung, wie bei Chris beschrieben, von NodeMCU Pin D0 zum NRF24L01+ Pin CE funktioniert es wieder.
Alle anderen genannten Verbindungen von Chris und mysensors.org sind identisch.

[Beta-User]

Vielleicht muß man nur wissen, nach was man sucht:
https://www.mysensors.org/build/connect_radio#connecting-a-decoupling-capacitor

Es geht also um einen Cap zwischen 3.3V und GND direkt am nRF-Modul zur Entstörung und Verbesserung der Versorgungsspannung; 4.7u sind die empfohlene Startgröße, 47u erfahrungsgemäß aber auch ok (gerade bei den "großen", ich nehme grundsätzlich eher die größeren bzw. Adaptermodule, wo mehrere drauf sind).

Edit: Hier ist auch noch was dazu zu finden: https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo ("Note! Power Problems:")

[Felix_86]

Ha ha, so langsam fällt die Sau 

Ich habe zwar vorgestern ein NRF24L01+ Breakout Modul in meine Shopping List aufgenommen und bestellt, das heute noch nicht eingetroffen ist, dennoch hat mir der Umstand, dass beim curl-Kommando nur 0 (null) geschickt wird (HIER), keine Ruhe gelassen, da ich mir nicht vorstellen konnte, dass eine zu geringe 3 Volt Spannung anliegt und dieses Verhalten verursacht. Immerhin ist das Empfangen von Signalen der Fernbedienung jederzeit zuverlässig möglich.

Ich habe also weitere Recherchen zu curl angestellt und dabei folgendes in Erfahrung gebracht:
- unter Verwendung der Option "-X POST" wird standardmäßig "application/x-www-form-urlencoded" verwendet. Dies sehe ich auch in der HTTP Response HIER
- bei  "application/x-www-form-urlencoded" ist zur Übergabe von Parametern folgende Syntax (zwingend) erforderlich: -d "param1=value1&param2=value2" HIER
- die Beispiele von Chris in seinem Blog und auch im Github bei sidoh nutzen allerdings die "geschweifte-Klammer-Syntax": -d {"packet": "01 02 03 04 05 06 07 08 09", "num_repeats": 10} HIER und HIER
- um aber die "geschweifte-Klammer-Syntax" zu verwenden, darf man nicht "application/x-www-form-urlencoded" verwenden, sondern es muss "application/json" sein. Dies setze ich mit: -H "Content-Type: application/json" HIER


Baue ich mir nun mit den neuen Erkenntnissen ein curl-Kommando zusammen

Code: [Auswählen]

curl -vvv -X PUT -H "Content-Type: application/json" -d '{"packet":"5A 43 07 82 82 00 82","num_repeats":5}' 10.10.20.106/raw_commands/cct
und setze dieses ab

Code: [Auswählen]

pi@raspi1:~/Desktop $ curl -vvv -X PUT -H "Content-Type: application/json" -d '{"packet":"5A 43 07 82 82 00 82","num_repeats":5}' 10.10.20.106/raw_commands/cct
* Hostname was NOT found in DNS cache
*   Trying 10.10.20.106...
* Connected to 10.10.20.106 (10.10.20.106) port 80 (#0)
> PUT /raw_commands/cct HTTP/1.1
> User-Agent: curl/7.38.0
> Host: 10.10.20.106
> Accept: */*
> Content-Type: application/json
> Content-Length: 49
>
* upload completely sent off: 49 out of 49 bytes
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Content-Length: 4
< Connection: close
<
* Closing connection 0
true
pi@raspi1:~/Desktop $
wird der umgestellte Content-Type mit "application/json" angezeigt und die HTTP Response ist weiterhin 200 OK. Nun snifft der Milight Hub auch das Paket, so wie es mittels curl-Kommando gebaut und abgeschickt wurde

Code: [Auswählen]

cct packet received (7 bytes):
Request type  : 5A
Device ID     : 4307
b1            : 82
b2            : 82
b3            : 00
Sequence Num. : 82
und die WOFI Lampe schaltet sich aus 

Somit kann ich mittels NodeMCU V3 und NRF24L01+PA+LNA (aktuell auch OHNE NRF24L01+ Breakout Modul) die WOFI Lampen schalten.

Nun geht es an die Einbindung in FHEM......
Vielleicht noch ein kurzer Tipp von dir: Ich vermute, ich muss auf HTTPMOD zurück greifen, damit ich die angepassten curl-Kommandos abschicken kann. Sehe ich das richtig oder habe ich eine Chance mit WifiLight oder Milight (nicht empfohlen)?

Vielen Dank, Beta-User

[Beta-User]

RAW geht mit Milight oder Wifilight nach meiner Kenntnis nicht (habe auch nicht aktiv gesucht), also wenn, dann HTTPMOD oder MQTT.

Hattest du eigentlich beim Anlegen der Bulb in der Web-Oberfläche ein "0x" vorangestellt? Eingeben kann man auch ohne, aber es funktioniert nur mit der HEX-Kennung. Vielleicht hilft das und du bist bereits weiter als gedacht...

Jedenfalls schön, dass das mit Milight/openmili an sich geht.

Bin jetzt erst mal weg *grins*

[Felix_86]

Wird eine Device Id ohne führende 0x im Web-Oberfläche in das Feld eingegeben, erscheint eine rote Fehlermeldung, dass 0x erforderlich ist. Somit konnte ich die Device Id gar nicht direkt, also ohne 0x, eingeben. Das habe ich schon richtig gemacht, sollte man auch HIER erkennen können:

Die Device ID lässt sich anhand des Bezeichners gut herausfinden. Trage ich diese im MiLight Hub ein, stelle den Remote Type auf CCT um, passiert aber nichts.

Im Bereich "Traffic sniffed (sent and received)" sehe ich nun auch die gesendeten Pakete, allerdings haben diese einen anderen Aufbau (Zuordnung von Werten zu den Bezeichnern).

cct packet received (7 bytes):
Request type : 5A
Device ID   : 4307
b1      : 01
b2      : 0B
b3      : 02
Sequence Num. : B9

[Beta-User]

Ok, sorry, war mal wieder nur um sicherzugehen.

Ich habe die Bridge schon eine Weile (damals noch unter Milight) im Einsatz, und meine mich zu erinnern, dass da früher keine "Syntax"-Prüfung drin war; über den Punkt war ich nämlich ganz am Anfang selbst gestolpert.

Und du hast recht, es hätte aus deinen Angaben abgelesen werden können. Hin und wieder übersehen wir alle halt die eine oder andere Kleinigkeit .

[Beta-User]

Hallo Felix_K,

wollte nur kurz die Info loswerden, dass meine Milights jetzt alle mit dem sidoh-Hub auf MQTT2 laufen - damit kommen auch Infos von den Fernbedienungen in FHEM an, ohne dass man irgendeinen externen Broker oä. installieren muß.

Da du (bisher) nur raw-Infos tauschst, ist das evtl. nicht so interessant, aber ich gehe davon aus, dass auf dem Weg auch recht einfach RAW-Anweisungen an die Bridge geschickt werden können.

Gruß, Beta-User