I also have a V6 box. I’ve configured that to work with my ‘First Edition’ bulbs. The MiLight Android app can control my lights with the V6 bridge. However Iif I add the V6 bridge to openhab I can’t select the ‘First Edition’ bulb type and if I select the ibox colour bulb then they don’t work and I get the following error;
Confirmation received for unsend command. Sequence number: 0
@MikeJMajor This is not intended behaviour, it is a bug 
the commit closed about 12 problems and opened this new one. Luckily this is open software and you can fix the issue yourself 
Cheers
@Scotsman Yes the milight binding never supported this mixture of old and new generation. Mostly because it doesn’t work with my V6 bridges and old gen easybulbs.
The strange thing I have now is that the binding using the V6 brindge and configuring my first gen bulbs as Colour iBox bulbs my lamp in zone one works. I can turn it on and off and can shange the colours. The other zones are configured the same but they don’t work.
Is there anywhere I can download a older version of the binding?
There is an open source hub that can be placed into UDP mode and use this binding. It can emulate v5 and v6 iboxes and allows the use of old and new gen globes from the same hub if my understanding is correct. Google Sidoh esp8266 milight hub.
I’ve actually ordered the parts and they are arriving today so hopefully I’ll be up and running over the weekend.
I think I have a go with Matthews unofficial binding that uses mqtt instead of udp
Thanks for the reply.
EDIT: Just noticed. - I’ll be trying your binding. 
Parts arrived. Flashed and connected together.
Binding installed and items created.
All went smoothly but I’m not getting the reliability I was hoping for. I bought a NRF24L01+PA+LNA Wireless Module with Antenna and I don’t think its getting enough power so I’ve orders some without PA+LNA to see how they get on.
I think I have fixed the multi bridge setup:
But I do not own multiple V3 bridges. Would be very helpful if someone could test this.
Cheers, David
My NRF24L01 without pa and lna arrived fitted and bridge working flawlessly.
I have a v6 ibox, and it connect’s fine in openhab2, but when i configure it manual as bridge. All the properties aren’t set.
Example: Bridge milight:bridgeV6:mybridge [ host="192.168.0.17", bridgeid="ACCF23A6C0B9", passwordByte1=0, passwordByte2=0 ]
… host = ADDR , bridgeid = ID … got it working
Do you have a bindings jar we can try.
I tried downloading the addons from the latest snapshot and manually installed that. Openhab now shows the hub as connecting but the controls don’t work.
Hi there,
I’m using OpenHAB2 on a raspi with the Milight binding.
It worked well with the old wifi bridge, but does not with ibox2.
ibox2 was found automatically, I created things all the things (bulbs) and items I need (brightness, color) with PaperUI (and in config file, as an alternativee, to be sure) but when triyng to switch or set the brightness or color, the bulbs just don’t react.
Everything works fine with remote and with the milight app (Android).
I checked the protocol in ibox2 (should be udp, I guess), checked the mac address, tried with different zone… The log tells me, that the commands are sent to the bulbs, so the cnnection to the bridge has been established. But just nothing happens with the bulbs.
Does anyone has any idea what to do or try?
Thank you very much,
Simon
The protocol is quite unstable and since about a year the only source that provided any protocol information went offline. I’m the maintainer of this binding, but to be honest I don’t know how to fix the V6 protocol without any documentation nor reference implementations.
Visit this link and read the info, as there is another way to control the Milight range.
@David_Graeff
Would it make sense to implement support for the REST protocol of the opensource hub into your binding? It is fully open and published and would allow people without MQTT to use the opensource hub. It would be far easier to maintain as all the differences between the globes and the different protocols is handled by the hub presenting you with a single consistent REST API.
Every few months Milight is inventing new remote models and now the ability to create a mesh network between the newer range of flood lights, I only see the complexity increasing so handing it off to an active opensource project is attractive to me.
I would accept PRs for the REST interface yes.
But it might also make sense to implement the MQTT Homie protocol in EspMilightHub, to gain auto discovery without doing much work on the Java/openHAB side.
An MQTT broker is setup with a button click nowadays 
What little I know of Homie it sounds great (thanks for your work on it) and it is something I plan on checking out soon for a sprinkler project I am working on. I doubt it (Homie) would get added to the firmware unless Homie takes off in Home Assistant as the main people working on the firmware are HA users and from past experiences they prefer not to do massive changes like that for Openhab users when other ways to work exist.
I do like the idea of doing it that way.
Homie is more or less the response from openHAB developers. Although we are working to include support into HA, that is a slow process. And yes most IoT projects out there are HA infiltrated supported. I have high hopes that this will change with OH 3, because of easier contribution, easier maintenance and better integrated newcomer help.
Hi @David_Graeff,
I have two bridges. One of them is an old v3 which works correctly with the binding, but the other one is a v6 (detected in inbox as iBox) which doesn’t work.
I control the last one with this:
So maybe this could serve as a reference implementation.
Regards.
I have checked the script and it only sends one command per session.
I mean we can do that as well in theory, at the moment the binding tries to stay “connected” though. So the very first few commands usually work and at some point it starts so swallow commands etc because the session gets unstable.
I believe that’s better than the actual situation.