Hi David
Have the same problem, but I’m using Openhabian, do you know how I can change to your version? I’ve used PaperUI for addons install and I’m not able to find the .jar locations ( read somewhere that is not just a copy paste thing??)
Regards,
Atle
Hi hageatle, there is no difference on Openhabian. Just uninstall the release version of the plugin in paper ui and then copy the jar file to /usr/share/openhab2/addons. Also check that the owner of the file is set to “openhab” and the group is set to “openhabian” and then the addon should install automatically. (You can also simply fix the file rights using openhabian-config)
After that the plugin should install automatically.
Ok, thanx for your reply 
Just to be sure, is it normal for the addons folder to be empty, I’m used to OH 1 and there you could just copy the jar to the folder and there was also all the other bindings…??
Hate to mess this up again 
regards
Atle
Yes the folder should be empty. The addons from the repository are stored in a different folder in OH2.
Thank you so much, solved it!! 
best regards
Atle
Just for information: running without problems!
This worked for me too. Nice work! I’m running openhab apt based, 2.3.0-SNAPSHOT, Build #1198. V2 Bridge version 1711151408.
For your version i also had to install org.eclipse.jdt.annotation and org.eclipse.smarthome.config.discovery.upnp, but I think this just has to do with my not being on Openhabian.
Regardless, the bundle solves this problem for me with no noticeable delay.
Does anybody know if the fix will be incorporated in the official Binding?
I sometimes have the same problem if I switch my group (10 lamps) on/off in a fast succession. This isn’t much of a problem in real life though. However the reason I ended up reading this thread was that the state of the lamps gets updated to only two of them, ie. when I switch the lamps ON outside Openhab (Hue app for example) only two of the lamps will be updated to the ON state on Openhab. I know they were working in the beginning few days ago when I installed the binding, so something is definitely not right here.
V1 bridge here with version 01041302.
…and on the next day all my lights are updating normally again without touching OH in any way, so who knows what’s going on. Maybe all but two of the lights were at 0% brightness, see below.
Found a possible new bug: when brightness is set to 0 outside OH, light will be shown as swithed OFF even though it stays dimly lit.
Hue_Lightstrip_Color changed from 45,60,5 to 45,60,0 (brightness was decreased to min level (0) through Paper UI, light switches off completely)
Hue_Lightstrip_Color changed from 45,60,0 to 45,60,5 (brightness was increased, light switches on)
Hue_Lightstrip_Color changed from 45,60,5 to 45,60,0 (brightness was decreased to min level (0) through Android app all4hue, light stays dimly lit and is reported as OFF on OH)
If the lights are already OFF and are switched ON to their min level by Hue motion sensor the same thing happens -> they are not reported as ON. I didn’t create an issue of this yet - could someone check and confirm if they have the same behavior? Note that it is not possible to set the brightness below 1% using the official Hue app (at least on Android).
Sorry for spamming the thread, original issue remains.
I’am currently testing my code changes here: https://github.com/TheNetStriker/smarthome/commit/faf3ee1f0335e5cbff0ea585bca0f55b1578e032
The lamps do not switch as fast as before, but they always switch without exceptions. The binding should now automatically choose the right delay for the amount of commands that are being sent.
If you want to test my changes I’ve just uploaded the modified addon to my Dropbox: https://www.dropbox.com/s/v9q37dmxo6q4kqh/org.eclipse.smarthome.binding.hue-0.10.0-SNAPSHOT.jar?dl=0