Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Esp8266 support, reason for group limitation? #3

Open
bugs181 opened this issue Jul 5, 2015 · 4 comments
Open

Esp8266 support, reason for group limitation? #3

bugs181 opened this issue Jul 5, 2015 · 4 comments

Comments

@bugs181
Copy link

bugs181 commented Jul 5, 2015

I've read some of your project logs on hackaday.io and have been waiting for over a year for someone to shed some light on the protocol. I noticed that you've mentioned the nRF51 several times and seem to lean towards that SoC. I know this project is in extremely early stages but I'd like to ask that you not leave out us esp8266 folks.

I haven't had much time to study the reason behind the 4 group limitation but could you shed some light on that as well? How do multiple bridges work at the moment? Do multiple remotes paired to multiple bridges work? If so, couldn't you simulate multiple bridges using some sort of unique ID per group?

Thanks for any info. Looking to get started on this. I have a nuand bladeRF that I've been meaning to break out again and this project could just be my excuse to do so.

Edit; Forgot to mention, great work so far! Looks very promising.

@VincentGijsen
Copy link

Well, I too have read the blog, If I recall correctly, this is due the remote having a limited number of physical buttons. The only way (due to the hardcoded protocol within the bulbs, is to utilise different preamble addressed.
This address is normally hardcoded within the remote and bridge. The awesome software build by henryk is that you can change this preamble.

I guess for the lesser programmer, the easiest way to control more than 4 distinct groups is to run multiple instances of the host-program, using different port+address param. Or modify his code slightly to add an additional byte to address the 'sending bridge', this minor fix will yield 254x4 distint groups, however this will obviously break compatibility with the existing apps ;)

@bugs181
Copy link
Author

bugs181 commented Jan 26, 2016

Hey there, sorry I haven't responded before now. For some reason I didn't receive a notification. Thanks for the information on the preamble. I also don't mind breaking existing app compatibility, as my automation needs are met with the homebridge project. My next goal is to create some sort of MiLight/LimitlessLED bridge that can control more than 4 groups of lights. I have PLENTY of devices that can act as the MiLight bridge, so I don't see the need on spending money for individual MiLight bridges.

RasperryPi, Onion Omega, Various versions of Esp8266, About 30 Pogoplugs. So as you see, I don't really want to invest in just another MiLight bridge when I'm sure I can adapt one of those devices to do what I need. MiLight/Limitless are nice because of the price, especially compared to Phillips Hue, however this bridge thing is really putting a damper on my plan.

@csowada
Copy link

csowada commented Mar 29, 2016

I created an example for esp8266 with four wlan gateway in one (I use different UDP ports) device. So I keep the gateway compatible with original gateway software.
https://github.com/csowada/openmili

@bugs181
Copy link
Author

bugs181 commented Apr 5, 2016

@csowada Wow! Great work! For some reason I don't get Github notifications and I just happen to check back on this thread due to coincidence.. I'll check your repo out as soon as I'm able to!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants