Im sorry with disabled i ment it is commented out. 
Okay i will give it a try, but to do this i need to âreenableâ the code for the motion sensor again and can try to pair it?
Or can i do it with currently released build and have a look at the logs?
Thanks for your help
No, you donât need to change anything. Just pair it, do a âlog:set TRACE org.openhab.binding.osramlightifyâ, wave, then set it back to INFO or DEBUG at least (trace logs all the polling).
Note: if the gateway sends any sort of motion event messages the connector thread will probably die (after logging⊠somethingâŠ) and youâll have to restart openHAB. If not then maybe thereâs some indication of events in the responses to the LIST_PAIRED poll responses. Either way itâs the trace logs that are needed in the first instance.
From what I figured out, the gateway doesnât send any packets for any of the motion events. My guess is, thatâs all handled internally of the gateway and you can only configure the behavior for motion event -> lights on/off. Thatâs very unfortunate since I wanted to set up specific rules based on the motion sensor but I couldnât make it to work.
Binding version: 2.2.0.201710152309 | OSRAM Lightify Binding
Channels âpowerâ and âdimmerâ are not showing up on Thing configuration page of light bulb. Only channels âcolorâ, âtemperatureâ and âabsTemperatureâ are displayed (see screenshot below).
When I open Thing configuration page of my light bulb, in the right lower corner "ERROR: 404 - Not Found " is shown for a few seconds. But I can link items to the missing channels and use the items without any problems:
Switch light_power "Licht Flur: Power" <light> {channel="osramlightify:rgbw:84-18-26-00-00-C9:power"}
Dimmer light_dimmer "Licht Flur: Dimmer" <light> {channel="osramlightify:rgbw:84-18-26-00-00-C9:dimmer"}
Maybe its just an issue with the configuration page.
Thanks for this nice plugin!
Thatâs correct. If you have an RGBW device you have a color channel which supports dimmers and switches so separate channels arenât required. Those channels come into their own for tunable and plain switchable devices though.
That said, the device handler cares more about the type of a command rather than the channel it was sent to and nothing stops you having a text configuration that sends commands in via bogus âchannelsâ.
Question for those of you who are using LightifyâŠ
I noticed that the gateway requires you to set up a cloud account. Can you use the OH + Lightify Binding without the cloud?
Not a big fan of all my requests being sent to the cloud.
Thanks,
Squid
If i recall correctly, you canât use the gateway without setting up the account. The binding just provides access to the gateway after it is set up. But i may be wrong.
I believe the answer is yes although I havenât tested it yet although I certainly intend to. I have to agree, when lights/heating is on and when the pattern is broken is not the sort of data that should be streamed in real time to any external party if youâre someone willing and able to spend money on smarts.
Some things wonât work without work without external access - firmware updates for one, possibly pairing - so youâd want it reasonably easy to switch. However the binding currently uses the LAN protocol exclusively so anything it can do it should be able to do if the internet is down. The link back to OSRAM (actually a third party OSRAM partners with, I believe) runs over QUIC so thereâs not much chance of using that.
Thanks to all the people who put a lot of effort into all of this.
I am using your plugin @mjagdis and for the most time it works 
but from time to time the gateway just dies 
and i honestly donât know why. If and when this happens i find in the log the following entry.
2017-11-25 06:23:53.258 [WARN ] [mlightify.internal.LightifyConnector] - Error
org.openhab.binding.osramlightify.internal.exceptions.LightifyException: status = RESET_REQUIRED response to Packet type = GROUPCAST, Command = GET_GATEWAY_FIRMWARE_VERSION, Seq number = 0, Status = RESET_REQUIRED
at org.openhab.binding.osramlightify.internal.messages.LightifyBaseMessage.handleResponse(LightifyBaseMessage.java:235)[251:org.openhab.binding.osramlightify:2.2.0.201710152309]
at org.openhab.binding.osramlightify.internal.messages.LightifyGatewayFirmwareMessage.handleResponse(LightifyGatewayFirmwareMessage.java:66)[251:org.openhab.binding.osramlightify:2.2.0.201710152309]
at org.openhab.binding.osramlightify.internal.LightifyConnector.run(LightifyConnector.java:299)[251:org.openhab.binding.osramlightify:2.2.0.201710152309]
2017-11-25 06:23:53.284 [ERROR] [mlightify.internal.LightifyConnector] - Connector died:
java.lang.NullPointerException
at org.openhab.binding.osramlightify.internal.LightifyConnector.run(LightifyConnector.java:312)[251:org.openhab.binding.osramlightify:2.2.0.201710152309]
if anyone could tell me what i could do to avoid this i would be very happy
Sorry, I have a fix for that. I just hadnât pushed it yet because I was waiting to see how reliable it was. Unfortunately no sooner had I fixed it than my gateway stopped doing it. Anyway RESET_REQUIRED turns out to be more of a LIST_PAIRED_DEVICES_REQUIRED. It seems a LIST_PAIRED triggers some sort of resync at the upper protocol level. Donât know why. But an 0x16 RESET_REQUIRED status actually means, âdonât send me that, I want to see you do a LIST_PAIRED next.â
As far as I am aware the only remaining problem is that if your wifi AP goes away for âtoo longâ the Lightify gateway decides the network is permanently gone and clears its wifi config. My AP is set to reboot every monday at 5am and something like 50% of the time me gateway needs to be told about my network all over again. Thatâs one for OSRAM to sort out though
Iâve pushed. Just keep an eye on the PR for the build completing.
I got a motion sensor at a decent price on friday so thereâll be some support for them soon. They do show up as paired and it is possible to tell how much battery they have (I think), whether they are enabled (reflecting the âpowerâ button state in the Lightify app) and whether they are currently triggering activities. By which I mean there is a flag in the device state we see that says if the sensor has triggered an associated activity. This is NOT the same as detecting motion. You have to have an activity defined for the flag to change. It remains to be seen what happens if there is more than one activity or if the device associated with the activity is powered down. Still. Better than nothing, right?
Effects will be along soon. I got a bit sidetracked working out how to do realistic looking fire/flame/candle flickers. I just need to finish that off and then do the ocean ripples. And, yes, they will be heavily parameterized so you too can waste your life
Can you tell us where to find the updated JAR. Is the one showing the Eclipse Market? The one there says last updatd 9/18?
Yes. The marketplace entry points to the Travis built jar belonging to the pull request https://github.com/openhab/openhab2-addons/pull/2486 so once that has completed (and it has) the jar is up to date with all changes.
Iâm stilling the occasional Error on an OH2 start with the latest binding. Does anyone else see similar?
2017-12-08 16:09:52.581 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.osramlightify.handler.LightifyDeviceHandler@66c97eba': null
java.lang.NullPointerException: null
at org.openhab.binding.osramlightify.handler.LightifyBridgeHandler.sendMessage(LightifyBridgeHandler.java:109) [15:org.openhab.binding.osramlightify:2.2.0.201711271952]
at org.openhab.binding.osramlightify.handler.LightifyDeviceHandler.initialize(LightifyDeviceHandler.java:98) [15:org.openhab.binding.osramlightify:2.2.0.201711271952]
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source) ~[?:?]
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) [111:org.eclipse.smarthome.core:0.10.0.201712081218]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [111:org.eclipse.smarthome.core:0.10.0.201712081218]
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) [?:?]
2017-12-08 16:09:52.653 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while initializing handler of thing 'osramlightify:rgbw:84-18-26-00-00-04-EA-17': null
java.lang.NullPointerException: null
at org.openhab.binding.osramlightify.handler.LightifyBridgeHandler.sendMessage(LightifyBridgeHandler.java:109) [15:org.openhab.binding.osramlightify:2.2.0.201711271952]
at org.openhab.binding.osramlightify.handler.LightifyDeviceHandler.initialize(LightifyDeviceHandler.java:98) [15:org.openhab.binding.osramlightify:2.2.0.201711271952]
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source) ~[?:?]
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) [111:org.eclipse.smarthome.core:0.10.0.201712081218]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [111:org.eclipse.smarthome.core:0.10.0.201712081218]
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) [?:?]Thatâs a thing add passing a freshly newâd ListPairedDevices to the bridge handler which then tries, and fails, to pass it to the connector. But the connector shouldnât be null - it is allocated in the bridge handlerâs initialize and only cleared in the dispose. Possibly there is some other error further back in the log that might shed more light but it looks like thereâs a race between device start and bridge start.
Hmmm⊠what HW, openHAB version and how many bindings, bridges and devices do you have?
Never mind. Iâve fixed it. I think. I fixed something anyway
The colour temperature percentage range (0-100%) of my tunable white ist exactly the opposite as if this light is connected to my hue bridge.
osramlightifgy binding => [1=âwarmâ,50=âneutralâ,100=âcoldâ]
hue binding => [100=âwarmâ,50=âneutralâ,1=âcoldâ]
Itâs just a minor issue, but maybe this may be adjusted simply as well.
Itâs not just the difference in mapping definition, but also the dynamic icons work the other way round. This looks a bit strange and may confuse new users of the binding. (A yellow bulb if i select cold. ;))
(@mjagdis, i know there is no right or wrong, itâs a matter of definition, but it would be nice to share one definition with openHAB.)
The Yeelight binding is also opposite then hue binding.
The LIFX binding agrees with Hue and since those are both ESH rather than openHAB I guess we should go with that. Actually Iâve already changed it but if anyone feels a strong preference for having 100% be the highest temperature instead of the lowest I could be persuaded to make it a config option.