WTF

[khmann]

2017-09-25

Q: I don't see the code? A: Correct. I'm still waiting for some legacy products to test and they're on a boat. I've made some pretty aggressive radio optimizations and I want to make sure I have the resources to support them.

Q: This looks like bullshit? A: No more than can be said about any futlight.com product. But hey, you keep buying them!

Q: WTF? A: Right. I really have been able to get some significant performance improvements, for other Nordic coders the light bulb will come on ;)

There are currently two components: the optimized radio interface and the back-end (currently python) stateful controller; it works on my mac and openwrt.

The goal is to push as much intelligence into the nRF24LU1+ as possible, moving to another nRF (BBC:Microbit?) as a future repeater/sensor node if interest persists. I'd prefer to tie to other controllers as much as possible and only support the radio interface.

-kh

[RvonMallesch]

Hi there,

I'm very impressed by Halloween demonstration video - very cool! Do you have an estimate of when your code will be ready to be shared? What are the advantages of your project over sidoh's Milight project?

Regards,

Richard

[starkillerOG]

@khmann looks verry intresting, would be nice to use for high throughput as ambilight. On which hardware will this project run, will it be able to run on something cheap like an ESP8266? Will this project support UDP interface, if so could it by any change support one of the 4 UPD protecols used by Hyperion (personal preffrence is the AtmoOrb protecol)? (it would then be really easy to use as ambilight).

[khmann]

USB code is up now, POC python scripts to follow shortly. Advantages of this implementation are that RF communications are co-processed by a USB dongle enabling anything with a USB interface to speak Mi.Light directly via python. I already have so many PCs and OpenWRT routers around I just wanted to plug in USB dongles rather than add yet another controller platform.

"Light" controllers like ESP generally don't have USB and so the traditional SPI interface is a better fit. I got some tweaks in sidoh/esp8266_milight_hub to make it work a little better (refactor the syncword), but that's not a platform I really work with so I didn't go very far (a lot of low-level changes could be made).

Hopefully all of the existing nRF milight implementations can take some ideas (hint: REUSE_TX_PL with a timer interrupt, frequency-hopping is a waste of time!) as I really am getting 20x as many packets in the air as traditional implementations.

For halloween, I used 6 dongles, one for each frequency my 2015-era 9W RGBW bulbs support, but for normal "around the house" use a single dongle is sufficient. For that display all the bulbs are actually listening to the same ID, I rely on randomness in the bulb's hopping to make it look interesting.

I'm sure I'll delve more into the network interface in the future, but right now my focus is on providing scenes based on time of day and input from real milight remotes. Think f.lux for the kitchen strip lights and some basic scenes that can easily activate with stock controllers.

[RvonMallesch]

Very cool!. I am hoping to do scenes just light you :-)

[RvonMallesch]

I have 75+ RGB+CCT bulbs. It strikes me for optimal performance I should be running 3 radios on a Raspberry PI (one for each channel). Does that sound reasonable or supportable by your code? I bought a crazy radio yesterday, Maybe I should buy 2 more?

[khmann]

The crazyradio is excellent hardware, though in theory the $5 makerfocus (and other) amplified SPI modules should be equally capable. You can get two on an RPI natively, with simple measures you can get more.

The crazyradio itself should be capable to drive a second SPI radio without too much bother, and I plan to work on that in the future.

Many of the bulbs now support multiple frequency "classes" - it's part of the "automatic signal repeating - extend the range infinite" feature. So if you were OCD about it, you might need at least 6 radios to hit all the frequencies. I'm not sure if published an analysis of the SPI radio interface channel selection on an FUT015 yet, it's on my list...

I don't have my dev hardware handy, but I'll post a macro example soon. Be aware, I've not done anything with RGB-CCT yet, the "encryption" function still needs to be implemented.

Another note, while the nRF24lu1+ is technically USB2, it's "hi-speed" (11mbps) and not "full speed" (480mbps). For optimal performance of multiple radios you really want a USB hub with MTT (multiple transaction translators)

[fab33]

Any news about this project ?

[starkillerOG]

@khmann are you still working on this project?