The "new" Milight IBox and milight binding

Thank You very much. This actually helped. My router worked in 2.4 and 5 at the same time, so i switched off just 5 and Ibox maneged to connect. But still i have an issue with Milight 4W RGB+CCT bulb, cant connect or sync it to the zone, no respond at all. Should I move ibox close to the celling in order to force it, or is there any other solution ? Regards. I hope this will work too…

Is anyone using the whitemode on the rgbLed type? I have the v3 bridge and the command is sent (according to the logs) but nothing happens. The color thing works for general control and color, but I cannot get the bulb to go white with a whitemode thing linked to a switch. Any suggestions will be appreciated! thanks

Use the colour slider to reduce saturation to 0. Whitemode will be activated automatically.

Cheers David

1 Like

Thanks David

But should this not work programmatically? I.e through the whitemode thing linked to a switch? Just asking as it’s in the readme but doesn’t seem to work. For now I’m using the HSB type to turn the saturation down. And thanks for all the hard work keeping the binding up to date, awesome job!!

There is no whitemode channel anymore, the readme needs to be fixed :slight_smile:

Hi, I’m trying out openhab for the first time as a way of controlling my limitlessled bulbs via an iBox2.
I’m on Windows 10 64 bit and have tried Milight binding with both Stable Version 2.1.0 and Snapshot Version 2.2.0.
In both cases I get the following error:

Exception in thread "SessionThread" java.lang.IllegalArgumentException: Port out of range:-1
       at Source)
       at org.openhab.binding.milight.internal.protocol.MilightV6SessionManager.send_search_for_broadcast(
        at org.openhab.binding.milight.internal.protocol.MilightV6SessionManager.session_handshake_process(
       at Source)

This error appears multiple time in my console when I start openhab and when I do a Search for things.

Any advice would be appreciated.

Does anyone have a reliable link or experience themselves on the different Milight options?

I have a lot of GU10 bulbs, marked as 4W (bought most about 2 years ago). As far as the web goes their brightness seems they are about 250lm (but then some say 400+ lumens…?). Some listing also say 5W for some GU10 models…

I see the newer 4W GU10 RGB+CCT bulbs are 250->280lm, but now I’m hesitant to buy them as I cannot get a definitive answer as to the brightness compared to my existing bulbs. I cannot go for a weaker bulb as I don’t want to add more to get the same lighting. Can anyone share some personal experience on the different options (GU10 4W RGBWW, GU10 4W CCT, 5W RGBWW, and the newer 4W RGB CCT) regarding their brightness? thanks!!

And sorry if this is off topic, just thought we all have these bulbs in common :wink:

Hi, I am experiencing exactly the same issue… everything worked fine with Version 2.0 but upgrading to 2.2 caused this issue with the Port being out of range… any ideas?
I have now manually installed org.openhab.binding.milight_2.1.0.ref-rc9 and the issue has stopped and everything is working normally.

Thanks for that, I did the same with rc11 and am going now too.

David, first of all, thanks for the amazing Job, I am too happy integrating my MiLights with your binding that I cannot begin to explain. I am experiencing the consequences of the Whitemode change. With bulbs supporting saturation, I have no problem pulling saturation down to 0 as you suggested to enable white mode. Do you have any suggestion with RGBW ones that do not support Saturation?

Thanks a lot in advance for your answer and infinite thanks for the work in the binding!



You mean the very old rgbw ones? I would suggest to replace them with newer models. Basically nobody has the old ones anymore so functionality can’t be really tested. And they had a lot of limitations as well.

Cheers David

Hi everyone

Though I’d share something I recently got working…

I have three MiLight V3 bridges (the older square ones) all-together supporting about 10 zones in my house. I’ve invested quite a lot into MiLights and must say they work almost as good as my Hue bulbs, but at a fraction of the cost. So recently I ran across an ESP8266 enabled bridge (link) that replaces the MiLight’s ones. This a fantastic prospect as the normal bridges has a limited range whereas the RF chip for this project comes with an external antenna which I’ve had working throughout my house! It also means you only have to look after one “bridge”.

So for those interested, after you got the hardware and connected everything together (really simple to do), you configure as many virtual gateways as you want. The project includes a “sniffer” mode which you can use to identify your existing gateway’s IDs, i.e. the ID to which bulbs subscribe when you initially linked them up. Using this sniffer it relatively easy to create the virtual gateways and means that your existing bulbs remain exactly as-is, no reconfiguration needed!

The only caveat is to ensure that you configure the OH2 MiLight binding with the correct thing type. I used to use the rgbLed, but with the virtual gateway I simulate a V6 bridge and for this I use the V6 Milight binding’s channel and the rgbwLed thing. This combination works like a charm.

Here’s an example of the gateway configuration:

And for OH’s MiLight binding (note the IPs are the same, i.e. only one physical device now :slight_smile:)

Bridge milight:bridgeV6:000000005E4D [ADDR="", ID="000000005E4D", CUSTOM_PORT=3389] {
        Thing   rgbwLed          1
        Thing   rgbwLed          2
        Thing   rgbwLed          3
        Thing   rgbwLed          4

Bridge milight:bridgeV6:000000007B89 [ ADDR="", ID="000000007B89" , CUSTOM_PORT=3390] {   
        Thing   rgbwLed          1
        Thing   rgbwLed          2
        Thing   rgbwLed          3
        Thing   rgbwLed          4

Bridge milight:bridgeV6:00000000F82A [ ADDR="", ID="00000000F82A" , CUSTOM_PORT=3391] {
        Thing   rgbwLed          1
        Thing   rgbwLed          2
        Thing   rgbwLed          3
        Thing   rgbwLed          4

The remainder of OH’s configuration is as per usual.

There’s another post on the forum explaining how to use MQTT to achieve something similar, but in my case I wanted all my lights represented by a single “color” item and not discrete controls. If you want to have a look see here.


Thanks for posting, I have linked back here to this post from mine. Great to have more options to choose from.

Doing some testing to see which way works the way I want for my setup. It would be possible to link the two lots of code so that the milight remotes update the UPD controlled items.

Not sure if this is what you meant, but if you want to group the lights controls together just use this in your sitemap file:

Text label="Milight hallway globe" icon="light" 
Switch 		item=Milight_ID1_G1_State
Slider 		item=Milight_ID1_G1_Brightness
Slider 		item=Milight_ID1_G1_CTemp
Colorpicker 	item=Milight_ID1_G1_Hue

You then get a menu to click on to see the controls.

Hi !

I´m new to openhab2 and i´m trying to use the milight binding with my ibox2 Bridge. I installed openHABian on a Raspberry Pi and switched to the unstable release tree in the config tool. Then i restarted the raspi and installed the milight binding (binding-milight - 2.2.0.SNAPSHOT).
When I try to add the IBox2 as a new “thing” it starts an automatic search, but does not find my ibox2. Then I added the ibox manually by entering its IP- and MAC-Address. After that it shows me the ibox2 as Online. Now I tried to add my Milight Controllers FUT036 (CCT only) & FUT028 (4 Channel RGBW) without success. Is it possible, that these Controllers are not supported by the Binding ?

Got it, yes, they might be the old ones (I got them a few months ago though, but that does not mean they cannot be old).

In any case, I found a workaround I’d like to share in case it helps anyone.

I am using the ESP8266 homebuilt bridge. This bridge supports different type of commands (UDP, MQTT, etc.) So, I created a shell script that triggers the white mode and then I installed the COMMAND binding and created a switch that calls the script. It is working very well :slight_smile:



Dear Guys,

usually I´m able to find any issues by my self, but in MiLight Binding it looks like I have an issue which I can´t find out by my self.

The MiLight binding was working almost perfect for a few weeks now but after updating to the latest 2.2.0 version I got a issue, cause the binding is spamming full the logs.

The binding is still working with my bridge and LED´s but I get this Logs all 2-3 sec. in my log:

20:16:16.940 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:16.951 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:18.759 [INFO ] [smarthome.event.ItemStateChangedEvent] - Wohnzimmer_Heizung_SET_TEMPERATURE changed from 22 to 6
20:16:18.769 [INFO ] [smarthome.event.ItemStateChangedEvent] - Wohnzimmer_Heizung_ACTUALHUMIDITY changed from 31 to 31.25
20:16:18.863 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:19.392 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_W changed from 253 to 265
20:16:19.409 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_counts changed from 128461508 to 128461510
20:16:19.424 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_K changed from 85641.0000 to 85641.0078
20:16:21.092 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:21.950 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:21.958 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:26.998 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:27.006 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:29.406 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_W changed from 265 to 274
20:16:29.439 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_counts changed from 128461510 to 128461512
20:16:32.005 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:32.015 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:37.015 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:37.027 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:39.416 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_W changed from 274 to 270
20:16:39.427 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_counts changed from 128461512 to 128461514
20:16:41.092 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:41.103 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:42.026 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:42.037 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:47.037 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:47.048 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:49.406 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_W changed from 270 to 259
20:16:49.417 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_counts changed from 128461514 to 128461516
20:16:49.436 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_K changed from 85641.0078 to 85641.0156
20:16:51.404 [INFO ] [smarthome.event.ItemStateChangedEvent] - Miete_Kueche_Heizung_ACTUALTEMP changed from 12.5 to 12.4000000000000003552713678800500929355621337890625
20:16:52.048 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:52.058 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:57.058 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:16:57.067 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:16:59.411 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_W changed from 259 to 261
20:16:59.432 [INFO ] [smarthome.event.ItemStateChangedEvent] - Stromzaeler_counts changed from 128461516 to 128461518
20:17:01.103 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:17:01.111 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:17:02.067 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge
20:17:02.076 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
20:17:07.075 [DEBUG] [.milight.internal.protocol.QueuedSend] - Sent packet 'D0 00 00 00 02 7D 00 ’ to bridge

First I thought it´s from the Keep Alive interval but after changing this to a higher period the log comes still all 2-3 sec.

When I change log:set TRACE smarthome.event I get the info that the Thing updates the timestamp if I note it right.

2017-12-17 20:40:30.403 [me.event.ThingUpdatedEvent] - Received event of type ‘ThingUpdatedEvent’ under the topic ‘smarthome/things/milight:bridgeV6:MiLight/updated’ with payload: ‘[{“label”:“iBox/iBox2”,“configuration”:{“REFRESH_IN_SEC”:20,“REPEAT”:2,“WAIT_BETWEEN_COMMANDS”:100,“ID”:“F0FE6B62CA3A”,“PASSWORD_BYTE_1”:0,“ADDR”:“”,“PASSWORD_BYTE_2”:0},“properties”:{“sessionid”:“7D 00”,“sessionid_last_refresh”:“1513539625599”},“UID”:“milight:bridgeV6:MiLight”,“thingTypeUID”:“milight:bridgeV6”,“channels”:[]},{“label”:“iBox/iBox2”,“configuration”:{“REFRESH_IN_SEC”:20,“REPEAT”:2,“WAIT_BETWEEN_COMMANDS”:100,“ID”:“F0FE6B62CA3A”,“PASSWORD_BYTE_1”:0,“ADDR”:“”,“PASSWORD_BYTE_2”:0},“properties”:{“sessionid”:“7D 00”,“sessionid_last_refresh”:“1513539620474”},“UID”:“milight:bridgeV6:MiLight”,“thingTypeUID”:“milight:bridgeV6”,“channels”:[]}]’
2017-12-17 20:40:30.510 [me.event.ThingUpdatedEvent] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
2017-12-17 20:40:34.241 [me.event.ThingUpdatedEvent] - Received event of type ‘ThingUpdatedEvent’ under the topic ‘smarthome/things/milight:bridgeV6:MiLight/updated’ with payload: ‘[{“label”:“iBox/iBox2”,“configuration”:{“REFRESH_IN_SEC”:20,“REPEAT”:2,“WAIT_BETWEEN_COMMANDS”:100,“ID”:“F0FE6B62CA3A”,“PASSWORD_BYTE_1”:0,“ADDR”:“”,“PASSWORD_BYTE_2”:0},“properties”:{“sessionid”:“7D 00”,“sessionid_last_refresh”:“1513539630520”},“UID”:“milight:bridgeV6:MiLight”,“thingTypeUID”:“milight:bridgeV6”,“channels”:[]},{“label”:“iBox/iBox2”,“configuration”:{“REFRESH_IN_SEC”:20,“REPEAT”:2,“WAIT_BETWEEN_COMMANDS”:100,“ID”:“F0FE6B62CA3A”,“PASSWORD_BYTE_1”:0,“ADDR”:“”,“PASSWORD_BYTE_2”:0},“properties”:{“sessionid”:“7D 00”,“sessionid_last_refresh”:“1513539625599”},“UID”:“milight:bridgeV6:MiLight”,“thingTypeUID”:“milight:bridgeV6”,“channels”:[]}]’
2017-12-17 20:40:34.367 [me.event.ThingUpdatedEvent] - Thing ‘milight:bridgeV6:MiLight’ has been updated.
2017-12-17 20:40:35.409 [me.event.ThingUpdatedEvent] - Received event of type ‘ThingUpdatedEvent’ under the topic ‘smarthome/things/milight:bridgeV6:MiLight/updated’ with payload: ‘[{“label”:“iBox/iBox2”,“configuration”:{“REFRESH_IN_SEC”:20,“REPEAT”:2,“WAIT_BETWEEN_COMMANDS”:100,“ID”:“F0FE6B62CA3A”,“PASSWORD_BYTE_1”:0,“ADDR”:“”,“PASSWORD_BYTE_2”:0},“properties”:{“sessionid”:“7D 00”,“sessionid_last_refresh”:“1513539634266”},“UID”:“milight:bridgeV6:MiLight”,“thingTypeUID”:“milight:bridgeV6”,“channels”:[]},{“label”:“iBox/iBox2”,“configuration”:{“REFRESH_IN_SEC”:20,“REPEAT”:2,“WAIT_BETWEEN_COMMANDS”:100,“ID”:“F0FE6B62CA3A”,“PASSWORD_BYTE_1”:0,“ADDR”:“”,“PASSWORD_BYTE_2”:0},“properties”:{“sessionid”:“7D 00”,“sessionid_last_refresh”:“1513539630520”},“UID”:“milight:bridgeV6:MiLight”,“thingTypeUID”:“milight:bridgeV6”,“channels”:[]}]’

Has somebody an idea, what it can be and how to fix that?



I have the same problem after update to 2.2.0. Has anyone a hint for this issue?
Thanks, Erich

Hey Erich,

today I installed 2.3.0 and there the interval period is working again, so you can change the interval to 300 sec.

Then you get this message only all 300 sec and not all 2 sec.

Not perfect but much better.


Hi Jan,

thanks for your quick respone. Now I’ve installed 2.3.0 too and it’s ok (message all 300s).

Greets, Erich

Unfortunatey there is the next issue. If I set the interval period to a greater value (e.g. 200), then I can’t control the lights anymore. In the logs I get the following entries:

2017-12-23 00:25:46.587 [INFO ] [nal.protocol.MilightV6SessionManager] - Bridge reports an invalid command: 10
2017-12-23 00:25:46.674 [INFO ] [nal.protocol.MilightV6SessionManager] - Bridge reports an invalid command: 11
2017-12-23 00:25:47.939 [INFO ] [nal.protocol.MilightV6SessionManager] - Bridge reports an invalid command: 12

There is no problem (and no error messages), if I set the period to a smaller vallue (e.g. 60). However, I have again every 60 seconds the update-log-messages. Very strange…