Last time I checked, the API only worked through the osram cloud and not directly with the bridge, so if your internet connection goes down, your lights stop working and there’s also a slight delay which is annoying when you’re trying to combine motion sensors with lights.
Has the API changed to allow local mode?
Nope, it has not. And there is the reason 
There is no reason, and yes that is exactly the reason. I don’t like the idea to send this through the cloud based API. The second reason is that I like to reverse engineer protocols. Unfortunately it is time consuming.
If you like to have a cloud API based implementation, I guess there’s a meaning for that, I just don’t like the idea
I got the new implementation already. It is much more reliable right now, before I only owned one bulb and everything worked fine until you have more than one. I just want to make sure color and stuff is working nicely again before I put a new version online. I also talked to @Kai and we definitely want to get a Lightify integration version into openHab 2.1.
That’s a bummer. I was hoping you were going to say otherwise because using a published API would be the way to go. I dug through their sample code and found the following in appconfig.yaml
PRODUCTION-EU : "https://eu.lightify-api.org/lightify/services"
PRODUCTION-US : "https://us.lightify-api.org/lightify/services"
UAT : "https://192.168.0.100:8443"
DEVELOPMENT : "http://localhost:8080/lightify/services"
Both UAT and DEVELOPMENT are local network addresses, but I think that’s in there for testing over at OSRAM. I did NOT confirm this by changing the address to the IP of my bridge.
Btw here is the LUA based dissector for Wireshark, hope it helps you a bit. Feel free to extend it and send in pull request: https://github.com/noctarius/lightify-binary-protocol/blob/master/osram-lightify.lua
Hi Noctarius, amazing! Downloaded, copied to addons and wham! the osram gateway was instantly found in the inbox! Thank you so much for this awesome binding.
Noctarius, thanks for all the hard work. I was wondering if you have updated the code in github yet. I have quite of few of the OSRAM lights and would like to try it out. I’ll be glad to help with any network captures for any device you don’t have access to if you’ll post the code or the JAR. Thanks.
Hi Noctarius,
After i used this binding for 2 weeks, i noticed that it makes the openhab sluggish and unresponsive. For example, turning on/off light switches sometimes takes several seconds to react or they dont react at all. I tried it twice on a fresh OH2 install from the image file. And both of the times i had the same after a few days (or maybe even few hours).
Have you noticed the same behavior or is this all a local issue i have with my setup?
Thanks.
Emre
Hey Emre,
No unfortunately I have the same behavior and it became worse with the last gateway update. Yesterday I had a few minutes to deactivate the auto-status-update polling and it seems to work, which would most possibly mean, that I overload the gateway with just a few requests every 5 seconds. I hope to get some better picture tonight, when I need to use it again to switch on / off lights.
I’ll probably go ahead and let it be deactivated for now until I have a better solution (when it actually works tonight). I’ll keep you updated.
PS: to all, sorry for being so unresponsive at the moment, been traveling most of the time and that means, not at home, no chance to work on the binding 
Thanks noctarius. I’ve been trying to work on my problem as well. It may be related to what you’re experiencing, but on a more immediate time-span. I’ll have it working for a while, and then it becomes slower and slower, and then non-responsive. Last weekend, I thought it was running fine with 2 RGBW recessed lights, and decided to add 2 TW and then it stopped working. I’ve since removed the two TW lights and can’t get it to behave again.
Anyways, I’ve been silently working away at it, but haven’t been able to devote more than 30 minutes here and there to tracking down the problem. Once I discover any clues, I’ll post them.
Great, I just pushed the current status of my code to github, feel free to build your own version (I’ll also update the dropbox download).
The current version does not do the updates but seems responsive / stable for the last few days. It is a PITA to test since, as you said, it takes a while to make it completely unresponsive. I’d be happy to get some more feedback
Tried again with own build from your Github repo and it is partly working. Seems that I have a special situation since I switch on/off mains power of the bulb. There, the status change is not recognized in the binding while in the Lightify app it takes around 10s for detecting that mains power / bulb is switched on. So: Is there a way to adjust the status refresh rate in the binding to get my situation covered?
When drop in the latest vesion from dropbox I get following error:
2017-07-01 17:20:29.591 [ERROR] [org.apache.felix.fileinstall ] - Failed to install artifact: /usr/share/openhab2/addons/org.openhab.binding.lightify-2.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: A bundle is already installed with the name "org.openhab.binding.lightify" and version "2.1.0.201706181942" at location: file:/usr/share/openhab2/addons/org.openhab.binding.lightify-2.1.0-SNAPSHOT.jar
at org.eclipse.osgi.storage.Storage.install(Storage.java:496)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.BundleContextImpl.installBundle(BundleContextImpl.java:146)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:1036)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:952)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:871)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:485)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312)[4:org.apache.felix.fileinstall:3.5.6]
I have latest snapshot build
For some reason it seems not to override the old file. Shutdown openhab, remove the old JAR first, start openhab, wait until it all booted and copy the new file to the position.
Thank, works now
Sometimes the integration seems to have lost connection to the gateway and it takes a while to reconnect, does anyone else have this issue? In that case I’d go and reduce the timeout for connection disconnects.
I installed the binding, everything was discovered fine. (Surface light TW + Some lightify plugs )
I use the things from PaperUI with the items defined in an *.items file. (I also tested with an item generated from PaperUI, same behaviour)
Switch ljPro "Arbeitszimmer LJ pro" <printer> {channel="lightify:powersocket:017ba969:598FA300AA3EB07C:ps#power"}
But only the Surface Light is switchable. Whenever i try to switch one of the plugs via openhab, i get the following messages:
2017-07-27 10:49:59.157 [INFO ] [nding.lightify.handler.DeviceHandler] - Command: OFF, lightify:powersocket:017ba969:EF610B0000261884:ps#power
2017-07-27 10:49:59.160 [DEBUG] [nding.lightify.handler.DeviceHandler] - Retrieving zone: EF610B0000261884=null
2017-07-27 10:49:59.162 [INFO ] [nding.lightify.handler.DeviceHandler] - Switch state: null
2017-07-27 10:49:59.164 [INFO ] [nding.lightify.handler.DeviceHandler] - Command-Type: class org.eclipse.smarthome.core.library.types.OnOffType
2017-07-27 10:53:02.353 [INFO ] [nding.lightify.handler.DeviceHandler] - Command: ON, lightify:powersocket:017ba969:598FA300AA3EB07C:ps#power
2017-07-27 10:53:02.356 [DEBUG] [nding.lightify.handler.DeviceHandler] - Retrieving zone: 598FA300AA3EB07C=null
2017-07-27 10:53:02.357 [INFO ] [nding.lightify.handler.DeviceHandler] - Switch state: null
2017-07-27 10:53:02.359 [INFO ] [nding.lightify.handler.DeviceHandler] - Command-Type: class org.eclipse.smarthome.core.library.types.OnOffType
Switching via the lightify app works.
The reason i switched from using the hue bridge (for these stuff) was a strange behaviour of the Surface light with the normal switch (doesn’t want to turn on, need to switch on/off several times). And off course the state being offline in hue bridge.
Am i missing something? Are the plugs not supported? If not, can i help?
Thanks for any help.
Is anybody using Lightify Plugs successfully with the lightify binding or am i the single user?
I have a plug connected and it works, however (I’m honest) I use as part of a group. Have you tried the other binding? I’m currently in India so I don’t have the chance to test it, but in general I’m happy to merge the efforts.