search

sidoh / esp8266_milight_hub

Replacement for a Milight/LimitlessLED hub hosted on an ESP8266
MIT License
940 stars 220 forks source link

Support Philips Hue API #49

Open fireboy1919 opened 7 years ago

fireboy1919 commented 7 years ago

It occurred to me that while it is nice to emulate the UDP protocol supported by Milight, it might even better to emulate the protocol supported by something else - noteably, Phillips Hue or LiFX.

Obviously, that would require storing group state information on the Controller, but it would make the project much, much easier to integrate with other systems.

The other nice thing is that at least some of the work is already done, and only needs porting - Controlling a bridge from a shield in Arduino code: https://gist.github.com/jamesabruce/8bc9faf3c06e30c3f6fc

Emulating everything: https://github.com/bwssytems/ha-bridge

Obviously, this might be a big undertaking. But it might be worth it.

sidoh commented 7 years ago

It's come up a few times before (although I think mostly as comments on my blog post). I like the idea, but you're right, it seems like a lot of effort.

The reason I'm hesitant (but not opposed) to pursuing this:

  1. People who use this project are probably pretty savvy, and are likely using a system that has pretty good support for Milight devices. HomeAssistant, OpenHAB, and SmartThings all have pretty stable integrations with Milight.
  2. For anything that does work with Hue but not with one of the above platforms, the bridge you're referencing in your second link would make it pretty easy to glue this project together with a Hue emulator. Obviously that's exactly the intention behind it :). It's less holistic, but probably only slightly more work on the part of an end user.

I could be wrong, but this makes me feel like it's quite a bit of effort for relatively little added value.

sidoh commented 7 years ago

I meant to end that with a question -- how well does this resonate with you?

fireboy1919 commented 7 years ago

Good point. Actually, I think that writing a connector to this as-is is less than a day's work.

Had I not had issues with HubAction (as I imagine pretty much everyone does), it'd have been four hours, probably. In contrast, writing a new hub would be considerably time consuming.

What I really wanted was a better mechanism to do discovery of this device than the UDP one put forward by the Milight app, and supporting hue would be one way of doing that.

However, I think there might be a better way.

g-rom-info commented 7 years ago

Hi, First of all, I thank you so much for your amazing program ! I'm very impressed ! Althought I acknoledge that most of home automation solutions supports Milight protocol. Hue Bridge emulation will be very interesting because some products like Logitech Harmony can not use Milight protocol... Best regards,

MichaelDanCurtis commented 7 years ago

Honestly, I am not sure the ESP could handle that efficiently, I would like to see a clean way to run ha-bridge and mi light hub together.. maybe MQTT would work.... I need to look into that.

sidoh commented 7 years ago

There are a few projects out there which emulate the Hue API on the ESP8266, so shouldn't be hard to tell. I'm a little skeptical myself, but parts of it probably aren't bad.

MQTT is already supported. :)

MichaelDanCurtis commented 7 years ago

Yeah, HA-bridge supports MQTT as well... the difficulty will be converting HUE color data into MQTT messages as I would not call the ha-bridge exactly user-friendly just yet. HUE's format is .... complex to say the least [{"device":{"state":{"on":true,"bri":254,"hue":4444,"sat":254,"effect":"none","ct":0,"alert":"none","colormode":"hs","reachable":true,"xy":[0.0,0.0]},"type":"Extended color light","name":"Hue Lamp 1","modelid":"LCT001","uniqueid":"00:17:88:01:00:d4:12:08-0a","swversion":"65003148"},"huedeviceid":"1","hueaddress":"192.168.0.118:8000","huename":"HueEmul"},{"device":{"state":{"on":true,"bri":254,"hue":23536,"sat":144,"effect":"none","ct":201,"alert":"none","colormode":"hs","reachable":true,"xy":[0.346,0.3568]},"type":"Extended color light","name":"Hue Lamp 2","modelid":"LCT001","uniqueid":"00:17:88:01:00:d4:12:08-0b","swversion":"65003148"},"huedeviceid":"2","hueaddress":"192.168.0.118:8000","huename":"HueEmul"},{"device":{"state":{"on":true,"bri":254,"hue":65136,"sat":254,"effect":"none","ct":201,"alert":"none","colormode":"hs","reachable":true,"xy":[0.346,0.3568]},"type":"Extended color light","name":"Hue Lamp 3","modelid":"LCT001","uniqueid":"00:17:88:01:00:d4:12:08-0c","swversion":"65003148"},"huedeviceid":"3","hueaddress":"192.168.0.118:8000","huename":"HueEmul"}]

MichaelDanCurtis commented 7 years ago

Wow, ya know what... I have just had a dunning-Kruger moment. In looking into it further and understanding the HUE api.... your right, it fits pretty nicely on an esp.

https://github.com/probonopd/ESP8266HueEmulator

Hell he is even running the neo pixels library.... so ... yeah, thats pretty cool.

sidoh commented 7 years ago

Yeah, this is one of the ones I came across. I could be wrong, but it looks like it's only intended to control a neopixel strip. I think making something that emulates an arbitrary number of devices would be trickier and would require some fairly heavy persistence. All totally doable, but I think it's questionable whether the added complexity is worth the slightly better ease of integration.

g-rom-info commented 7 years ago

Instead of emulate dynamically, why not set a static number of bulbs ? The original Hue Bridge supports 50 bulbs. I think you can emulate a hue bridge with a static number of bulbs (48 bulbs) and statically assign these bulbs to the first 12 UDP gateways ? I don't know the level of the difficulty in order to implement this on your code...

WoodsterDK commented 7 years ago

An option could be this project, he plans to add milight support. It is supposed to make the milight appear as a hue bulb. https://github.com/mariusmotea/diyHue

sidoh commented 7 years ago

@g-rom-info, I think it'd be important to be able to customize device id/group bound to virtual Hue bulbs. I could definitely be wrong, but I don't think there's a good way to not drastically increase the complexity of state being tracked.

@WoodsterDK, you may already be aware, but there are quite a few hue emulators out there. I think this is the one I run into most often. Wouldn't be hard to make it work with this project. HomeAssistant also has one baked in. This is the main reason I'm hesitant to bake in native support.

WoodsterDK commented 7 years ago

Actually hadn't see the support for milight in HA-bridge. I don't think native support makes sense either.

mariusmotea commented 7 years ago

Hi,

I create a Hue Bridge emulator that works with ESP8266 RGBW Bulbs (named Color Dream), Neopixel strips and custom ESP8266 Hue sensors. Now i try to extend support for MiLights using this project because the procedure to flash this bulbs is complicated and some inexperienced persons may damage them. My ESP8266 sketches contain conversions formulas from xy, ct and hue color mode to RGB/W so if will be possible to implement them also to this project it will be great.

sidoh commented 7 years ago

Nice!

The HTTP/MQTT APIs will accept RGB in the JSON blob. There's also a field called color_temp that accepts color temperature as measured in mireds. I'm not exactly sure what you mean by "ct," but I'm guessing it's just color temperature measured in kelvins? Mireds are a super simple conversion from that, just 1_000_000/T.

No support for xy right now. Could add it, but would probably prefer to have stuff use RGB or Hue/Sat if possible.

mariusmotea commented 7 years ago

Hi! I receive first milight bulb, which is cct model, added support for it in my bridge emulator and when i control the color temp from Philips Hue application i receive opposite result, max warm white is max could white and could white is warm white. It this a bug in the hub or Philips reverse mireds in their application? Also if i will create a PR to add support for hue xy color mode it will be accepted?

sidoh commented 7 years ago

It's quite possible they're reversed. I doubt this would be a bug in Philips hue. Note that mireds are inversely correlated with color temperature -- lower values have a higher color temp.

Sure, there's certainly no harm in supporting it if it'd be useful.

WoodsterDK commented 7 years ago

Now it is being mentioned, then I think I saw this in Home Assistant too using the mqtt_json platform... the temperature slider gives an inversed color.

tbrasser commented 7 years ago

@WoodsterDK this should've been fixed (in HomeAssistant and the underlying library) quite recently.

WoodsterDK commented 7 years ago

Super, will try to update. Thanks for the info.