My NRF24L01 without pa and lna arrived fitted and bridge working flawlessly.
1 Like
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.
Hi,
is it only the overhead of opening a session what concerns you, @David_Graeff?
If so, I think the overhead of trying to keep it alive will typically be higher. Or did I get something wrong here?
Anyway, if the v6 bridge would work, many people would be happy. 
Regards,
Simon
I assume you know about this, right?
I don’t know if it helps.
Simon
Yes exactly. The limitlessled website is not existing anymore though and there is no official information. You can find those pieces on different web-pages but none has archived yet to keep a session alive for longer. They are all establishing a new session for each command as far as I have seen.
Do I get you right, that the session handling is the only issue with your current version of the bindung? What’s the benefit about trying to keep the session alive?
Opening the session for every command sounds acceptable as typically therw won’t be that much commands per given timeframe.
Is there anything I can help with?
Simon
Yup, if you can do a bit of Java programming, you could try that scenario out. Establish a new session for each command and see if that is more reliable.
The session is used to determine if the bridge is still online. We can of course also just poll via the discover package (most solutions out there do it like this).
New here and to Opensource projects after recently retiring. So please guidance as needed if I am out of bounds. My ultimate goal is to build a binding for Pioneer SC-LX501. Planned steps on the way were to get a few things setup and then move on to determining how the bindings are built. My immediate next step is to install eclipse and find the documentation on building bindings. I am also expecting an ESP8266 and assorted goodies in the mail tomorrow to play with SimonFlei binding as well. However, if it helps - I am getting this in the logs
==> /var/log/openhab2/openhab.log <==
2019-02-22 15:38:38.323 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.milight.internal.handler.MilightV6RGBCWWWHandler@13fe0d13’: null
java.lang.NullPointerException: null
at org.openhab.binding.milight.internal.handler.AbstractLedV6Handler.sendRepeatableCat(AbstractLedV6Handler.java:212) ~[?:?]
at org.openhab.binding.milight.internal.handler.AbstractLedV6Handler.setBrightness(AbstractLedV6Handler.java:96) ~[?:?]
at org.openhab.binding.milight.internal.handler.AbstractLedHandler.handleCommand(AbstractLedHandler.java:139) ~[?:?]
at org.openhab.binding.milight.internal.handler.AbstractLedV6Handler.handleCommand(AbstractLedV6Handler.java:202) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at com.sun.proxy.$Proxy125.handleCommand(Unknown Source) [208:org.openhab.binding.milight:2.4.0]
at org.eclipse.smarthome.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:75) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
at org.eclipse.smarthome.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:49) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [102:org.eclipse.smarthome.core:0.10.0.oh240]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Looks like a serious bug. Unfortunately I do not have time to fix that in the very near future, as I’m busy with another openHab part. Because you are a new user, I cannot expect you to fill a bug report, can I?
Cheers, David