But ultimately, the problem is that the limitlessled hubs kind of suck, and they need to be better.
There’s a better way! Throw away your hub! You shouldn’t be limited to only four groups per hub anyway. This way, you have one hub that controls everything rather than only groups of four.
Try my approach: make a better hub for less than $10 out of parts you get from Amazon, and use my integration.
The integration:
It works pretty much perfectly for me, but I don’t know if it’s going to work for everyone. I’m not sure how varied hubs are between them. I also don’t know how difficult it will be to use. Give it a shot!
More than 4 bulbs per zone is certainly a bonus! Definitely looks like a bit of work to get it set up but it seems like you’ve had a lot of success afterwards. I think I’m at a point where I’ve got mine setup and running perfectly and hopefully can sustain this for a while but I’ll definitely give your method another look when/if anything decides to poop out on me. Thanks for the info!
First, this is pretty awesome… if for no other reason than to be able to use it as a Node-red entry point… (not something I have worked on just yet but I do plan too) i.e. MiThings -> Node.red websocket -> device / UDP / whatever
On that note, I am having a problem and hoping you can give me a clue…
I have:
Installed the fireboy1919 : MiLight Controller DHT
Installed all of the smartapps
Published only the fireboy1919 : MiLight Manager
config’d the various things (as a note, the group ID is decimal but the device id is in hex … so I had to convert it in the app)
Now everything SEEMS to be working, but nothing happens
The log seems to send it correctly, but not lights…
…any advice on the logging that would help? (the live logging is … well not very informative)
At the moment, the backend doesn’t return anything meaningful so that you know that it works. Hopefully we can work that in soon.
I switched from hex to numbers because the design is meant to completely replace the need for the “group” concept. Each group is just a virtual hub instead. That’s why there’s a “pair” button for each light.
As to you problem - are able to actually get to the milight esp8266 hub and issue commands?
Try going directly to the milight hub on port 80 via a web server. Does that work? And if so, can you get it to turn lights on and off from there?
Oh yeah, that makes really good sense, due to the design of the milight system, exposing the device ID as a “group ID” just makes far more sense… I simpley didn’t consider the ramifications of being able to spoof multiple Device IDs … thats pretty freaking sweet.
Well… maybe,
I got the ESP to run … pretty well, the web service is … odd… slow… and sometimes just a whole lot of “NOPE” but usually it works ok.
I can also HTTP to it , but I have not formed a good curl message that works it seems…
This returns an “Invalid JSON” http://192.168.1.9/gateways/0xa229/rgbw/0
and this returns … nothing… so if its formed correctly it may very well be the ESP curl --data-binary '{"command":"set_white"}' -X PUT http://192.168.1.9/gateways/0xa229/rgbw/0
I could be wrong, but I think it requires all caps in the hex gateway code (so 0xFFFF rather than 0xffff). That said, there’s also the actual interface you can use from a browser that makes service calls itself.
Have you tried that?
You could also try unpairing via the smartthings device handler (select a created light and hit the unpair button within three seconds of turning on a light). That should work regardless of the state of the lights if the controller is working.
The curl statement is supposed to return just “true”, btw.
Happy to take suggestions on the web service. I tried to make it RESTful, and I think it’s reasonably close to being decent RESTful design.
The request returning “invalid json” is because you need to send a JSON body (sending a GET request results in an empty/null body). It probably can respond to GET, but bodies in a GET request are weird. The officially supported verb is PUT.
it shouldn’t matter if the device ID is capitalized. You can try curl with the ‘-vvv’ flag to get more info. fireboy1919 is right, it should return “true”:
$ curl --data-binary '{"command":"set_white"}' -X PUT "http://milight-hub/gateways/0xa229/rgbw/0"
true%
Hi, Thank you for sharing wonderful works with the community. Unfortunately, I am having a bit of trouble getting it working and seeking some guidance and help. (I have 2 MR16 bulbs and 1 LED RGBW controller for testing)
First of all, when I try to install SmartApp: “milight-light.groovy” via Repo, it doesn’t get installed and I get error: “1 skipped due to errors” (“milight manager” installed & published / “mithings” installed / Device handler “MiLight Controller” installed & published)
Secondly, I have tried to go around this problem by installing from Code. With ST App, tried to “add new light”. I cannot figure out what to put down for the “Code” (Optional: will be autoassigned). It doesnt allow me to add light without filling in the Code. (Added lights with some random numbers)
Lastly, I can control the lights with Milight App. However, It appears I cannot get any responses from LimitlessLED Wifi Bridge V6 Light commands. Not sure it would be relevant, but I can access Web Admin in Browser and “TCP,38899,lights.cloudsy.com” as cloud server setting.
Any help/suggestions would be greatly appreciated. Thank you.
For everyone with MiLight, EasyBuld, LimitlessLED this works so well.
£20 and I had the bits to make 2 hubs. OK that doesnt include case and PSU but I have enought spare cables and old iphone chargers!
The first hub took 30 minutes to be up and running, the second 15 minutes. Paired with a test light and controlling it perfectly.
The smartthings integration took about an hour, I used the Github repo update to manage it but found I had to manually add one of the sets of code.
Added the smartapp on the ipad. Needed to go back an change the group for the lights as I had some lights on groups 2, 3 and 4.
Then low and behold… it works!
Next added devices to Alexa and 10 minutes later I have all the lights working under voice control and part of smartthings.
Pretty awesome.
One problem, and it is mentioned in the GitHub readme… colour wheel not working.
you need to modify the code in MlightLight line 161 with formula above from bucky and the colour wheel works.
However the only problem I now have is to reset the light back to white when using alexa.
However, a few hours of playtime and I have milights back in my good book, working with smartthings and voice controlled in Alexa… pretty cool and thanks to Sidoh and Fireboy1919 for some brilliant work and lowering the cost of my smart lights by a few hundred quid less than Philips Hue.
Thanks for that. I didn’t think of a button.
Will try it later.
I’ve now got 5 sets/rooms of Mi-Light working on smartthings. Gonna invest in setting up other rooms now.
All working well with alexa too.
Now everything works, I can start back using smartthings again.
UPDATE: got it all working now. Thanks for the tip with the button tile and core.
Im greatful to everyone involved. Just made a third controller and had it running in under 30 minutes. Costs less than 20 pounds to make the pair - though I havent put them in a case yet. The third is just because it was using the V2 NodeMCU rather than V3, so it is smaller.
Seriously folks who are looking at MiLight, this option is a no brainer and it works seamlessly with Smartthings.
What this does is make smartthings know the switch is on.
That keeps alexa in sync with the on and off commands so you don’t need to turn the light on again before turning it off.
EDIT: I’ve also found it works with the old (4 year+) white only lights which were oftern found as controllers to drive strip lights. See the issues page on GITHUB for info.