Okay, 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.

