Henryk PlötzOkay, I've created some github projects and pushed my source so far. This is only what I have now, but I intend to make it usable.
First up: https://github.com/henryk/milight-reverse-engineering simply contains all the little tools and some of the notes I developed while doing the actual reverse engineering. I don't believe that it's useful to anyone, but you never know. This is totally undocumented and unsupported, and in some cases has commented-out functionality from different phases of the process. YMMV.
Then there's my currently most stable code in https://github.com/henryk/openbeacon-ng/tree/openmili (in firmware/nRF51/pca10031-openmili). This is actually the openbeacon-ng project by my friend Milosch Meriac, but it does have a build system for the nRF51 that is not as full-on retarded as the official Nordic SDK, and also allows for easier code sharing. At some point this should somehow move into the actual project described next.
Finally, there's the OpenMili project: https://github.com/henryk/openmili. This is supposed to be the actual project that people want to use. I have a grand mental plan, but there's only the Arduino proof-of-concept code in there as of now.
The idea is to have proper layers of abstraction and build upon them, allowing mix-and-match as needed. Some of the comments on this http://hackaday.io project indicated that they were/are working along similiar lines, but do have a real PL1167 (or compatible). So the middle layer will be a virtual PL1167 abstraction, that can either shell out to a real PL1167 (I may need help here, since I don't have one to test on) or an emulation on a Nordic chip. As I've said before I want support for both the nRF51[48]22 and nRF24L01(+) chips on the layer below that. Above that would be a thin shell for Mi-Light 2.4GHz frames so that a simple serial protocol will allow to make useful use of the hardware from a host application. Then the first primary goal is to have a host application that fully replaces a Mi-Light Wi-Fi gateway, possibly with slightly better timing, and, most importantly, configurable IDs. (First idea: open multiple UDP ports, each port will send with a different ID; Second idea: also open TCP ports for reliable communication.)
Then, far off in the future I see the possibility of a more advanced firmware implementation with vastly improved timing and features: interleaving multiple commands to different bulbs when sending, maybe performing color animations autonomously, receiving and reporting commands sent by other remotes when idle.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I have the new RGB+CCT bulbs, for which there is currently no WiFi box at all.
I hope I can use this to make something work, to eventually tie in with Amazon Echo.
the RGB+CCT downlights are very good. They mix white with the RGB to give saturation control. They are finally almost comparable to Hue (apart from the 1 way protocol & addressing of bulbs). Hue makes all its colours (and white) out of mixing lime+orange+blue, I think.
I think they only mix half of the white LEDs in with the colour though, since overall maximum brightness in 'colour' mode even when saturated with white, is quite a bit dimmer than any of the warm to cool whites on their own at full brightness.
Anyway they are great. These are the FUT068 RGB+CCT downlights. A million million times better than the GU10 RGB+W.
I am assuming that the remote control might actually send out the commands of two separate controllers at the same time (RGB, and WW/CW) but we'll see. I'll try to sniff the remote's commands once I have the Pi & radio set up as per https://www.raspberrypi.org/magpi/pi-mi-light/
The standard RGB+W remote does not work at all with these RGB+CCT bulbs, but it might simply be that the bulbs are set to only link with a given range of remote/gateway IDs that are reserved for RGB+CCT remotes. Either that, or the whole protocol is different, in which case I'll fail miserably :-)
Are you sure? yes | no
I'm very eager to leverage this project to control my "Mi Light" RGB bulbs rather than the useless IR-controlled bulbs I had before.
Unfortunately I'm having quite a bit of difficulty even getting the Arduino sketch from Github to compile. I've spent a few hours trying to understand the project and find some (any) community discussion with others who've gotten it to work.
If I follow it correctly, the project is aiming to substitute the Wifi controller, but not (yet) bypass this and control the bulbs directly using RF (eg via 24L01). For now I would be happy using my Arduino as a substitute for the original remote control. I'd love to hear from anyone who's got an Arduino controller working.
There haven't been a lot of updates to the code or the project blogs lately, has it been suspended?
Are you sure? yes | no
I was researching the MiLight hardware and ARduino connectivity and came across this:
http://souliss.net/media/diy-your-philips-hue-led-bulb/
Are you sure? yes | no
hi henryk,
Very interesting work! Are there any updates? Is your receiver working reliable. I'be meanwhile put some of the modified wifi boxes transmitters to a raspi. But your solution looks much better as I have many LED milights...
Are there any details re the Hardware you use? I would like to build up your solution based on a raspi. I would need some hints how to build up a transmitter extension. Programming should be fine - however I'm weak on the HW side...
Cheers.
Are you sure? yes | no
Hi Henryk, I'm impressed by your work. I just started to adapt your github code to Raspberry Pi however my dev skill may be insufficient. So can I get your help for adapting the Arduino Code on the RPi ? The goal is to integrate it to Domoticz by emulating multiple remotes with only one emitter and without the original wireless bridge.
Best regards,
Are you sure? yes | no
Excellent work so far on this project. Any idea if it would be possible to unlimit the light to just RGB or W? Have you investigated the actual bulb controllers/firmware?
Are you sure? yes | no
No, I haven't.
Are you sure? yes | no
The protocol just doesn't support it, it's either RGB or W. I guess you could write new firmware for the controllers though, or replace the controllers altogether. I have a few lights on the way, so I might check that out if I end up feeling too limited by the Milight protocol.
The microcontroller is an STM8003 which is kind of weird in that there are VERY cheap development boards and USB programmers on ebay, but i can't find much support for them around the hacking community.
Are you sure? yes | no