The "new" Milight IBox and milight binding

Tertius_Hyman · October 5, 2017, 4:48pm

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

Ramasouto · October 13, 2017, 3:21am

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.

Rob_Reid · October 14, 2017, 12:33am

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

Ramasouto · October 20, 2017, 3:43am

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!

Best,

Ramiro

David_Graeff · October 20, 2017, 9:31pm

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

Tertius_Hyman · November 6, 2017, 7:26pm

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 )

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

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

Bridge milight:bridgeV6:00000000F82A [ ADDR="10.0.0.208", 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.

matt1 · November 7, 2017, 12:04am

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.

Snocksman · November 7, 2017, 7:42pm

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 ?

Ramasouto · November 11, 2017, 11:58pm

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

Best,

Ramiro

stolly82 · December 17, 2017, 7:28pm

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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98
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 192.168.20.98

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”:“192.168.20.98”,“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”:“192.168.20.98”,“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”:“192.168.20.98”,“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”:“192.168.20.98”,“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”:“192.168.20.98”,“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”:“192.168.20.98”,“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?

Thanks

Jan

Erich_Weber · December 21, 2017, 5:22pm

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

stolly82 · December 21, 2017, 7:26pm

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.

Jan

Erich_Weber · December 21, 2017, 8:46pm

Hi Jan,

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

Greets, Erich

Erich_Weber · December 22, 2017, 11:43pm

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…

Greets,
Erich

Dsn90 · December 28, 2017, 11:43am

Hi everybody,

first thanks for the great work with this binding, its amazing.

The only thing that i cant get to run is the disco mode. I read about the issues with the whitemode or the nightmode
but is there also a problem with the discomode?

Each time i send an number to my animation mode item, the only reaction from my bulbs is to reduce the brightness.

Hope anyone could help me, thanks for your answers!

Foxejoe · December 31, 2017, 11:22am

Hi Ramasouto,
I have the same problem after update at 2.3.0 … I tried to reload the 2.0 binding but whitemode doesn’t work.
I read the ESP8266 bridge but I don’t understand how can the whitemode be solved.
Can you share your solution?
Thanks
Lorenzo

stolly82 · January 1, 2018, 9:38pm

Hey,

now I have the same issue!

[nal.protocol.MilightV6SessionManager] - Bridge reports an invalid command: xx

It´s with stable 2.2.0 and 2.3.0.

furax54 · January 14, 2018, 3:17pm

I open an issue for the log flood : https://github.com/openhab/openhab2-addons/issues/3046

Licht77 · January 21, 2018, 12:33pm

There is a fix in github…

Moriarty · January 22, 2018, 5:59am

Where?