LimitlessLED support
Opened this issue · 11 comments
Existing code:
Docs:
I just got a kit; and given the other examples it shouldn't be too tricky to add.
@theojulienne - Any objections to me extracting out the core of your driver into a node-limitlessled? gembly/LimitlessGEM kind of thing, but I haven't actually got that working properly (I have gotten yours happy).
That'd let the two projects share a well tested component and focus just on the integration/UI/wiring bits...
@CloCkWeRX, absolutely!
The latest is actually here: https://github.com/ninjablocks/ninja-limitlessLED
This has support for the new RGB+W lights with direct brightness setting, multiple gateways, etc, and so is refactored and a bit nicer. It could probably be pulled out into a node-limitlessled quite easily.
i think that would be a great idea!
Part 1 is done - splitting out a library from ninja-limitlessLED - https://github.com/CloCkWeRX/node-limitlessLED
@gembly - you might be interested in the above, because it's very similar to https://github.com/gembly/LimitlessGEM ; but has a few more bells and whistles.
@theojulienne I refactored it a tiny bit to avoid looking for things; so hub is just a dumb hash rather than a settings object. I dunno if you want a PR with refactoring for the ninja driver.
I'll take your advice on if methods like write() should be part of the API - clearly useful, but somewhat ninjablocks specific at the moment.
I guess the big problems to solve now are autodiscovery; and a thing system lightglobe driver.
Re autodiscovery, the hub reckons it supports being found over UDP.
After resetting the wifi bridge, the ip address is 10.10.100.254 and the admin UDP port is 48899
if the wifi bridge has already been connected to your lan via dhcp, you can use the direct ip if known, or just use the broadcast address 10.1.1.255 on your subnet and use the Admin UDP port number 48899.
The ADMIN commands allow you to scan and find wifi bridges and set wifi lan SSIS/PW setups direct via your app.
Send the string via UDP, and wait for the UDP response of "+ok"
That might be enough to re-introduce the 'hub' object into the API, as it would mean a bunch less setup stuff around!
excellent. ok, let's try to figure out how to do discovery. we need two things: finding the gateways on the network, and find the bulbs on each gateways.
i understand that these gateways never return anything on port 8899, but we need to figure out a way around that. keep in mind that i don't have one of these gateways, so i'm speaking from theory, not experience.
my understanding from http://www.limitlessled.com/dev/ is that the hub also listens on port 48899 and accepts the hayes command set. perhaps it is possible to send one of the I0 to I9 commands and see if you get back a response that looks like an AT response. if that works, try sending a broadcast packet and see what responses you get back.
the harder part is finding out about the bulbs. i suspect that their applications are able to do discovery somehow. what i suggest is this: first, delete the app and then download it again (to get rid of whatever cache it might have); second, turn on port mirroring on your access point and start tcpdump to capture traffic to/from the hub; third, launch the app, capture the traffic, and then analyze it to see how it figures out how many bulbs are on the hub.
if this doesn't yield success, we'll need to talk to the firmware guys to fix it. there are many ways they could do this. we'd have to figure out the simplest and suggest it to them...
@CloCkWeRX - any luck?
I got bogged down, I discovered that the router I have goes out of its way to ruin multicast.
Will take another look today.
thanks!
@CloCkWeRX - any motion/interest? just checking, thanks!
My hub died sadly, New one on order
On Sunday, November 9, 2014, Marshall T. Rose notifications@github.com
wrote:
@CloCkWeRX https://github.com/CloCkWeRX - any motion/interest? just
checking, thanks!—
Reply to this email directly or view it on GitHub
#238 (comment)
.
ouch!