search

sidoh / esp8266_milight_hub

Replacement for a Milight/LimitlessLED hub hosted on an ESP8266
MIT License
944 stars 220 forks source link

SYS-T1 Wired Milight Protocol Reverse Engineering #636

Closed Lightning1984 closed 4 years ago

Lightning1984 commented 4 years ago

Hi Everyone,

I bought 6 pcs of the Milight SYS-RD1 RGB+CCT LEDs for my terace. For those not familiar with this type of LEDs, they use a single wire data bus along with +/- 24V DC supply. To link them to the MiLight Wifi world and be able to controll them a so called "host controler" (SYS-T1 or SYS-PT1) is required, see below schema. image

I already managed to controll the LEDs using the ESP8266 Milight Hub and the SYS-T1 controller over the Air. As a further step I though it would be nice to controll the LEDs directly from i.e. the ESP8266 completely avoiding the Milight 2.4GHz wifi link. Also this would allow to individually group the LEDs together by connecting them to indiviudal pins of the microcontroller (proper driver circuitry is required of course).

I assumed that the encoding on the data line should be pretty straight forward given that it only controls RGB+Brightness+ColourTemp.

Unfortunately this is not the case, every data burst seems to be completely different to the previous one. The Host controller sends a periodic update to the LEDs about every 6 seconds even without any change in color or brightness. image

The encoding appears to me to be some sort of Manchester or BiPhase encoding. image

Maybe someone with more reverse engineering experience is able to find out the secrets of this protocol.

Attached is the captured data of a few periodic update bursts using the Saleae Logic Pro. The file is in the version 2 format, the software can be downloaded from https://ideas.saleae.com/f/changelog/. The logic levels on the data line are 0 and +24V so be carefull when experimenting yourself since this is beyond the maximum input rating of most logic analyzers.

regards Rupert

SYS-RD-Periodic-Data.zip

sidoh commented 4 years ago

If every packet is different, it might be the case that they're using the same "encryption" scheme used in all of the newer 2.4 GHz protocols. You can see the code here:

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MiLight/V2RFEncoding.cpp#L48

I have a writeup here:

https://blog.christophermullins.com/2017/03/18/reverse-engineering-the-new-milightlimitlessled-2-4-ghz-protocol/

mabau commented 2 years ago

@Lightning1984 I'm thinking about buying those outdoor led spots as well, and would like to address them directly without the detour of the controller. Did you make any progress decoding the protocol?

Lightning1984 commented 2 years ago

Hi, unfortunately not. I dropped the project since I didn't want to invest the time. I'm still using the leds though and I can really recommend them, the build quality is really good. I installed them in a raised WPC floor by cutting away the bottom part of the black plastic holder that comes with the LED and milling a stepped hole into the planks using a router and a template that perfectly fits this first section. Until now I'm using the esp8266 based bridge which just works fine and living with the compromise of unnecessarily going via the wireless interface for now. There is one downside though, if you cut the power to the controller the leds all come on in a faint dim blue color and need to be turned off. Since there are not many power cuts where I live that's not a huge issue. Regards

mabau commented 2 years ago

Thanks for your detailed answer! I'll probably buy them then, since I haven't found any alternative for wired ESP32-controllable outdoor color LEDs.