Yes the ESP8266 is a great value and powerful little setup, in case you had not found them there are currently three different projects for making your own milight bridge, they are:
http://www.rflink.nl/blog2/devlist
I have not tried the other two as Chris Mullins has done an excellent job documenting everything and is making releases every few days so it is very active.
Hey Matt,
This is a really great writeup. Would love to incorporate this into the project documentation if that’s okay with you. I’m happy to paste/adapt your post, or you can let me know what you want it to look like if you prefer.
Hi Chris,
Yes your welcome to use it as you wish. I do feel the openhab code is better linked to here so I can update it as I improve the openhab side of things, or if you change the MQTT implementation and a newer firmware needs openhab changes. Also that would mean I get people asking for help here instead of you getting hammered with questions from noobs freeing you up to do more coding 
At the moment I’m looking at learning how to write openhab2 bindings so I can make this easier for others then what is posted above. It may/will end up easier for me to create the binding compared to using rules to parse the MQTT updates for when a physical milight remote is pressed. It would then also be possible to add a feature that would auto find and add all globes automatically for end users. The OEM official bridges and milight bindings do not have that ability so it would really make sense to throw away any official bridge/s if you owned one and move to a setup with esp8266 and gain full individual control over many globes.
Thanks for your hard work on this and I look forward to the next release that can handle high rates of commands being sent and the fixes for windows compiling.
Thanks Matt, makes sense to link back here. Added a link on the wiki:
Thanks again for writing this up!
Just a note that I updated the first post with new updated rules that work better for changing colours as previously 1 out of 5 changes were missed. Changing colours now works perfectly unless you hold and swipe around the colour wheel which overloads the current firmware of the esp8266. Just do a single tap for the colour you want and it works great.
is there instruction how to use milight remote with openhab (to keep a state in sync with openhab)?
This setting found in the espMH control panel allows any changes by the milight remotes to send MQTT updates to Openhab and I can confirm it is already sending the MQTT updates.
mqtt_update_topic_pattern
milight/updates/:device_id/:device_type/:group_id
What still needs to be done is to either write openhab rules to parse the incoming MQTT, OR a new binding can be written which will give more benefits. In my free time I am learning at how bindings are created, probably Christmas time I may actually have enough spare time. I will look at doing a rule for on and off only and post it here so you can see how it is done. Then you can try the remote out.
I think I’m in the same boat here.
I’ve purchased a Milight 8 zone RGB+CCT remote and 1 RGB+CCT bulb.
I can control the bulb with the remote and with the ESP8266 using Version 1.6.0_dev9. But I can not seem to control the bulb via OH2.
I do see the MQTT being published when I use 1) the remote control, 2) logged into the ESP8266, and 3) MQTT updates from an OH2 sitemap for ON|OFF, Brightness, and Temp. But I do not see any MQTT updates from OH2 for the color wheel.
But I can not seem to get the Bulb itself to react to OH2 commands including ON and OFF. I see the update in MQTT, but guessing the rule is not parsing correctly. I’m not sure how to exactly confirm my device ID and other info to ensure my Item file information is correct. I did install the Milight binding as well, and that finds the ESP8266 and reports the Bridge being Online with I think I ID of all zeros, ie, Bridge 000000000000
I’m hoping long term here to be able to with the remote to being able to also update/change the color of my philips and lightify bulbs.
What is your remote I’d and the group number of the globe? If the remote is paired with the globe move the remote and watch mqtt. Post what is published as that will tell u the remote Id and the group of the globe. Enter those into the Control panel of the esp8266 up the very top and see
If u can control the globe? If so then u know the hardware is working, the. We just need to edit the openhab rules to match your remote and globe I’d and group.
One thing to be aware of is the mqtt remote Id needs to be in decimal and in the esp2866 control panel it needs to be in hex! Huge pain they r not consistent. The 8266 control panel has the sniff feature and it will report the id in hex whilst mqtt updates will be
In decimal. Sniff works by capturing any remote movements and displaying a log output. Post some more info of what u see being published and check the openhab logs and post their contents when u move a control. Lastly I will need to see how I have edited the code to match your remote I’d and group number.
In the 8266 Control Panel, I can control the bulb as follows. Think this may mean ID 0?
And when I use the slider on either remote or in the 8266 control panel, I see this information in MQTT
mosquitto_sub -u openhab -P XXXXX -p 1883 -t '#'
{"hue":126}
{"hue":25}
{"saturation":20}
{"color_temp":183}
{"color_temp":270}
{"hue":1}
{"hue":356}
{"hue":349}
{"hue":343}
{"hue":339}
{"hue":335}
{"hue":332}
{"hue":330}
{"hue":328}
{"hue":337}
{"hue":349}
{"hue":352}
{"brightness":232}
{"brightness":219}
{"brightness":196}What I think was strange was that when I first had the 1.5 firmware on there, MQTT reported more info including group info. But the current 1.6.0_dev9 shows only the above.
26804 is your remote Id in decimal. The photo of the esp8266 gave me the hex of 68B4 and I used an online calc here to convert.
http://www.rapidtables.com/convert/number/hex-to-decimal.htm
Your using group 1 so the code for openhab needs to be edited with those details to work, or you can pair two remotes to the globe to test my code unchanged.
0x68b4 the 0x means this is hex aka base 16 number. Drop the 0x as it is not part of the number it is just to indicate it is hex and you have the remotes code.
1.5 of the esp8266 published to mqtt differently make sure u use the same version I posted my rules have been tested to work with in my first post.
I think I only need to change that in first spot for the remote ID, and not the group ID and it appears to be working.
So this:
becomes this
And I also found you can use the Hex value as well. This appears to be working as well
Next is to learn how to using the remote control to update other Philips bulb with a Rule.
Yes u only needed to edit that one line if u only own one globe. The other lines need to be unique if u want to get more globes going with separate controls for each but it sounds like u have the hang of it now.
In attempting to learn here this morning more about OH2 and using Mosquitto, have anyone had any luck at getting the Milight remote control to pass its input into OH2? I see Mosquitto is logging the info when the remote is used, I just haven’t figure out yet how to perhaps configure an item file for an Inbound message from the remote in Mosquitto, and then pass that information over to a rule yet.
After searching and reading, I was trying first with just something like to perhaps get a test switch to turn on and off when using the Milight remote, but no luck so far. I’m really not even sure if the Item should be a Switch or a String.
Item
Switch TestMQTT "Testing" {mqtt=">[mosquitto:milight/commands/0x68B4/rgb_cct/1:command:ON:1],>[mosquitto:milight/commands/0x68B4/rgb_cct/1:command:OFF:0],<[mosquitto:milight/commands/0x68B4/rgb_cct/1:command:MAP(en.map)]"}
and the rule
rule "Test MQTT Received"
when
Item TestMQTT received command
then
sendCommand(TestSwitch, ON)
endI won’t have time until Sunday to have a play. You should only have to modify that same string line and then use a rule to parse all the incoming mqtt messages from the one mqtt topic for that globe. The one rule will need to handle state, brightness, hue etc. the colour will be complex which is why I prefer to spend the time creating a binding.
The MQTT topics should always substitute the hexadecimal value for the device ID. I think v1.5 and earlier sent the decimal value of the remote ID in the JSON blob simply because it felt weird to send a string for something that is an integer. But v1.6 and later don’t send the device ID in the JSON blob, so hopefully that makes things less confusing.
However, the formatting of the device ID in the MQTT topics should be more explicit. Created this issue: https://github.com/sidoh/esp8266_milight_hub/issues/143.
Yes it was the json blob and ALSO from memory sending manual Linux terminal mqtt pub commands that needed decimal to work. Have not tried it recently but I am sure I tried hex first in bash when testing and it failed to work till I used decimal.
Sniffer reports hex
Ui used hex only
Bash pub failed to work with hex
Bash pub worked with dec.
Have not tested since with newer firmwares as I used device ids that were the same in hex and dec for all my globes.
Thanks for the help and input guys.
@matt1 I can definitely wait till you have more time and be great if a binding is ever developed.
Right now, I just still think I have something wrong with my Item’s file as I can’t even get OH2 to show an update in the log when I use the remote. I see information being posted to Mosquitto, but nothing shows up in the logs.
fyi. my mqtt-eventbus.cfg file is empty. I think we do not need to enter anything here?
I currently decided to drop back to the 1.5 firmware as I can see more in mosquitto. So with the 1.5 firmware, when I use the remote, I see things like this.
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":96,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":98,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":100,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","hue":237,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","hue":236,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","hue":232,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","button_id":7,"argument":65,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","button_id":7,"argument":56,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","button_id":7,"argument":51,"state":"ON"}Note, the button_id appears to be the Saturation on the remote. The ESP 8266 Control Panel reports it as
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","saturation":97,"state":"ON"}So I tried various items like this, but I get nothing in the log when trying the remote
Number TestMQTT "Test 1" {mqtt=">[mosquitto:milight/commands/26084/rgb_cct/1:command:*:default]"}
Number TestMQTT2 "Test 2" {mqtt=">[mosquitto:milight/updates/26084/rgb_cct/1:command:*:default]"}
Number TestMQTT3 "Test 3" {mqtt=">[mosquitto:milight/updates/26084/rgb_cct/+:command:*:default]"}
Number TestMQTT4 "Test 4" {mqtt=">[mosquitto:milight/updates/26084/1/rgb_cct/+:command:*:default]"}