There’s nothing in the logs. Not even complaints about missing requirements. Nothing.
Stupidest mistake in a long time. Didn’t unzip the package but just removed .zip extension by renaming. 
(Latest test bindings I’ve used used this technic for uploading bindings. Was it so that github doesn’t accept .jar files?)
Edit #1
After some testing all seems to work. Configured everything using .thing file.
What is the function of “sensor status” under bindigns configuration parameters? Is it really a indicator and if so, shouldn’t it be as own channel? Or can you somehow turn the sensor off this way? Seems a bit weird when also dimmer switch has this option.
Okay, I am glad you got it working.
The answer is:
| Name | Type | Description |
|---|---|---|
| on | bool | Turns the sensor on/off. When off, state changes of the sensor are not reflected in the sensor resource. Default is “true” |
You can activate and deactivate a sensor via this configuration. Currently this feature is not working in the provided test version.
Great Work Christoph,
on openHAB 2.4.0 Build #1421 running with openHABian on a PI and after deactivating the Hue Binding in PaperUI and restarting OH with your test-binding in the addon-folder my 5 Hue-Sensors works as expected 
Would be very awesome to have everything that still works in Apple’s HomeKit also works in EclipseSmartHome and/or openHAB!
Regards
Heiko
Of course. As I am no Apple user I am afraid you have to help me in this case. Which features do you mean?
See my earlier post:
Now theres this recent post describing similar behaviour. UIs starting and stopping when you install or remove the hue binding? Anyhow for me the hue binding has worked properly all the time. I’m running Zulu java if it matters. Is this something to dig deeper?
IMHO it is, but I do not think that it is related to the Hue binding itself. It is more or less related to the install / uninstall process of a binding.
1 Like
Uninstalled the Hue binding, cleared cache, unzipped and installed the latest test version 0.10.0 onto Milestone 6 of OpenHAB 2.4.0.
FWIW for now: Nothing happens at all. No clue or indication whatsoever of a new binding (addon) installed.
Note: I’ve got a handful of dimmer switches and 12 motion sensors (still expanding).
Sincerely thanks and appreciation for your contribution! 
Hi Remko,
Sry for my stupid question: I do not quite understand if it is working now or not. Did you get your sensor running with the new binding version?
Sorry my mistake. No it is not working.
Is there a special log file or debug setting that I can turn on? I sincerely want to help out.
Please enable DEBUG logging for the binding:
org.eclipse.smarthome.binding.hue
I’m going to set up a separate DEBUG log file for this binding. Just have to figure out how exactly again…as it has been a long while ago since I’ve done this particular line of work…keep you posted.
But spitting through the various openhab.log(.n) files shows (the recurring WARN):
2018-11-25 02:45:11.743 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.eclipse.smarthome.binding.hue-0.10.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.smarthome.binding.hue [253]
Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:=“optional”
Unresolved requirement: Import-Package: org.eclipse.smarthome.config.discovery.upnpat org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
Either missing dependencies?
Sidenote: I do use the official openhab:2.4.0.M6-amd64-debian docker container with persistent storage on a Ubuntu 18.04 LTS server
I saw this before. The framework sometimes does not install dependencies automatically when you put a binding into your addons folder.
First: You have to install the features esh-io-transport-upnp via Karaf console and then put the .jar file into your addons/ folder.
The correct command is
feature:install esh-io-transport-upnp
You can also install a different binding (e.g. Kodi) which needs this dependency too. This in turn installs the required service automatically.
Ahhh … Will install the Kodi binding . Didn’t install it yet as I was thinkering with the various Hue configurations.
==>> It works! The Kodi binding/missing dependency was the key to solve it. Thank you Christoph!
Hi,
Question to the group. I run a hue motion sensor configured as describe ahead which triggers a shelly 1 via MQTT.
Unfortunately it takes up to 3 sec. till the shelly switch on the lights.
Does someone else have similar setup and encounter the same results?
Would be interesting to understand, as I then could focus on the key area of the problem.
Thanks
Dom
Hi Dominik,
Which polling interval do you use in your setup?
Otherwise:
- The
presencevalue is reported every 5 minutes, and when the motion sensor value changes (from motion to no motion or from no motion to motion);
Hi Christoph,
Good question: How to get known of it?
If you followed my instructions in the initial post you will probably use 5 seconds. You can find the value in this line of code
hueMotionSensorPresence.updateInterval=5000
OK, got it.
Yes exactly 5 sec.
Should I decrease it?
If you want to have faster updates from the sensor, Yes.
1 Like