Milight: setting color not always results in the same color?

I am trying to get a number of milight bulbs running, so far with some success …

Current problem:

  • 1xiBox
  • a few RGB+CCT spots
  • org.openhab.binding.milight-2.5.0-SNAPSHOT.jar


Dimmer bathA "Bathroom all"		{channel="milight:rgbwwLed:14fb9196:ledbrightness"}
Color bathA_color "Bathroom all color"		{channel="milight:rgbwwLed:14fb9196:ledcolor"}
Dimmer bathA_temp "Bathroom all temp"		{channel="milight:rgbwwLed:14fb9196:ledtemperature"}
Dimmer bathA_saturation "Bathroom all sat"		{channel="milight:rgbwwLed:14fb9196:ledsaturation"}

I am trying to use them setting bathA_color, e.g. like this:

var HSBType color = HSBType.fromRGB(255,255,255); 
sendCommand( bathA_color, color );

e.g. trying to switch from off state to white at full white which results in (events log):

2019-06-26 18:43:29.621 [ome.event.ItemCommandEvent] - Item 'bathA_color' received command 0,0,100
2019-06-26 18:43:29.622 [nt.ItemStatePredictedEvent] - bathA_color predicted to become 0,0,100
2019-06-26 18:43:29.628 [vent.ItemStateChangedEvent] - bathA_color changed from 0,0,0 to 0,0,100
2019-06-26 18:43:29.629 [vent.ItemStateChangedEvent] - bathA changed from 0 to 100

Looks good so far. However, if I have a look at my bulbs, they have some red component. Not always, possibly depending on what they had before(?).

So, what am I missing? Isn’t setting the color overriding all previous settings? And if not, what would I use then in order to set an arbitrary color just without knowing in what state the bulbs have been before?

Even worse, it seems, that sometimes the above sendcommand() does not switch on the lights. The sequence

var HSBType color = HSBType.fromRGB(255,255,255); 
sendCommand( bathA_color, color );
# lights do *NOT* switch on, though log says color 0,0,100 is set
# some time passes by ... until user clicks a button
sendCommand( bahA, 0 );
# some time passes by ... until user clicks another button
sendCommand( bathA_color, color );
# lights are finally on!

Welcome to Openhab!

Sorry if this post seems to not answer your question but I would encourage you to setup the opensource hub for Milight globes, it then gives you the ability to use both bindings among other advantages. I have 23 globes running great on this hub and binding combination and it is rock solid.


In some way it does actually answer my question, at least if EspMilightHub does not suffer from the same problems as the “normal” milight binding. However, as it includes hardware (which is already on it’s way - that will take a while) it is not really a drop-in replacement :slight_smile:

However, one bridge being it unlimitted or not will not cover my entire house, either.

Other +/- radical solutions I thought of were running one of the CLI milight clients via ExecBinding.

On the other hand obviously people are successfully using the milight binding, thus, the problems I face are most probably due to some misunderstanding from my side.

Ok, I am currently testing iobroker. Seems that milight support is more matching my expectations …

Since you seem to have the needed skill level, are you interested in looking as to why the current binding does not work compared to the milight app and also iobroker? I don’t own a ibox or any OEM bridge for that matter so I can not do this and you can read the history of the current situation in this thread…

If someone sniffs and documents their findings correctly it will greatly assist someone that can code to improve the situation. I would prefer to look at how the app communicates as further bridges are more likely to continue in the same direction as the app.

As mentioned I have flawless operation using the open source bridge and the binding that I wrote so I am not keen to purchase hardware to look at something when I feel the opensource hub is far superior and more likely to still be working in 20 years time as the full code is opensource.

You will be surprised as you can make a bridge as powerful as a wifi router at going through walls and distance. I have a single hub doing my whole large house currently but will be installing at least two for redundancy reasons not coverage. As with all wifi, metal in your walls does block and create dead spots so moving the bridge around can find a better spot.

For getting good range see this post. Ordering in the parts does take time.

First: I totally agree that it is great to have a free and open controller reducing the vendor dependency. I appreciate your efforts in creating EspMilightHub. The limitation to 4 (or 8) groups per controller is an annoyance your project did overcome.

Once I get my ordered hardware and find some time to set it up I am willing to try things out and see if your binding/controller does work as expected in my case - no need to fix things as long that there is no proof that they are broken. I guess, spending time to find out why the “classic” milight binding is not working as I’d expect is not very interesting(?). I have worked around the problem at the moment using iobroker (and it’s OpenHAB adapter).

Of course, I am willing to do some sniffing be it via this Java thingy or with Wireshark if there are functions you wish to be tried out and logged.


You will be surprised as you can make a bridge as powerful as a wifi router at going through walls and distance.

In fact, I am using 3 wifi access points in order to cover the area :slight_smile:
I am not expecting that the EspMilightHub will cover the entire area with one device only.