Unfortunately I can’t find the time to debug and fix the issues described in this ticket at the current time. As soon as I can find the time I will do so if nobody finds a fix by then.
The problem described by kjell seems to be network related. Also, keeping the state of the light seems to be an issue with the lightify itself, as the app fails to keep state as well. I’ve noticed there are some sort of profiles that you can save, but they are available in the app itself, and they won’t work without the app.
Current python-lightify version is 1.0.3.
Where’s the latest version developed/committed? I only found version 1.0.2 in Github.
Andreas Neumeier seems to be packing / maintaining this at the following location:
Yeah, I forked the latest 1.0.4 and made a minor change so that light names now support utf-8. It works for me, I don’t know how well with others.
You fix works ok?
I was thinking how about just truncating self.next-seq() to ubyte? Maybe the field is there for differentiating different requests? If it cannot be truncated, what’s the point of having only one byte as counter?
I put % 256 to mine. Lets see how that works.
It’s been stable for a while now. There are still a bunch of other things that need fixed that I say I’ll get to every Sunday but haven’t gotten to it yet… Sounds like your fix maybe better, want to post a gist it might be useful for some other people watching the thread?
Not much code:
file : /usr/local/lib/python3.4/dist-packages/lightify/init.py
line 232 self.next_seq()
change to : self.next_seq() % 256
line 244 self.next_seq()
change to : self.next_seq() % 256
line 260 self.next_seq()
change to : self.next_seq() % 256
line 272 self.next_seq()
change to : self.next_seq() % 256
There’s three bytes before this counter : 0,0,7
Maybe they are just part of the counter?
But if there is many phones connecting to same lightify hub, are the counters synchronized? I don’t think so? Sounds too complicated. So my bet is it’s just something to keep different requests in some kind of order. Maybe there was some kind of rare error and with this counter it’s now 256x more rare?
So in all honesty as far as understanding the protocol goes I stopped when I found a suitable python lib, my original research / protocol understanding was based off the following two items:
http://forum.iobroker.net/viewtopic.php?t=897 (In German) and https://github.com/timoly/houmio-driver-osram-lightify
This may yield something of use when looking at counters and what they are used for. The first seems like there’s some fairly detailed information which I was originally just calling in a shell script using netcat.
Maybe changing next_seq() directly is better -> change just one row
def next_seq(self):
self.__seq = ( self.__seq + 1 ) % 256
return self.__seq
@MindrustUK I’ll take a look on your links and do some testing
You’re right 
Seems to me people have missed the fact that Lightify has a REST API.
https://eu.lightify-api.org/lightify/api/
The problem I bumped into with the rest API was you need an internet connection, while this isn’t a huge problem there are times when peoples internet will drop out and then you can’t turn your lights off conveniently. The other issue was the following, which I could see going wrong fairly quickly:
“When developing Your App, please ensure that polling is used sparingly in order to minimize unnecessary network traffic, i. e. ensure that (i) Your App only polls in case of active use of Your App, (ii) polling is discontinued after maximum fifteen (15) minutes if the active use has been stopped and (iii) Your App does not poll more than once every three (3) seconds on average per gateway.”
I’m sure logic could be added to keep these conditions happy but again, I found someone who’d done most of the work already so just used their lib.
This lightify REST api is using Osram cloud?
No thanks.
My goal is to close internet access of Osram hub and only open that when want to update something.
Was not aware that the API used the cloud…that’s messed up…
Oh well, doubt i’ll be getting any more osram stuff anyway…
Hello guys,
I’ve reported the issue https://github.com/home-assistant/home-assistant/issues/3089 for Osram Lightify and @ktpx pointed me out this thread. Thanks @ktpx
I was able to experience the same issue however after implementing the fix provided by @MindrustUK at https://gist.github.com/MindrustUK/3af79d035dbbd26b4cc5f08b8d99a8e9 it been working without the same tracebacks.
Sometimes I have an issue that the frontend HASS switch does not work on the first try, but when I try the second it works fine (with the colors as well).
@MindrustUK, what you think to open a PR to lightify to address this issue to be included on the 0.28 version? Thank you @MindrustUK for the good work.
@MarkoMarjamaa I had the same issue about trying to find the 1.0.3 version. It seems to be that the git has the tag 1.0.3 but the file is still 1.0.2 which creates a little bit of confusion.
I created a PR to make it cohesive at https://github.com/aneumeier/python-lightify/pull/4, but I think it will not be necessary if we come with a better fix and get it committed on lightify upstream.
What do you guys think?
1 Like
I suspect the front end issue, where you have to switch twice occasionally, might not be an issue with hass. I sometimes get the same behaviour in the lightify app, leading me to think it’s an issue with the gateway or otherwise internal to lightify. There was a firmware update recently for the gateway, let’s see if its still an issue…
The range problem fix should be pushed upstream, it’s such a minor fix anyway, and saves us the work of having to copy over the working file, after every hass release …
I think the double switch thing is as a result of the re-connect introduced by bsdwave although I’ve not had a chance to test / prove that. It’s fairly high on my list as it’s winding me up whenever I used my lights.
I’m hoping I may get a chance either this weekend or next to look into a few more issues in the code, i.e. the lights going to full brightness on turning a group on. I’ll post back when I get a chance to sort a few of these things.
@ktpx yes I’ve updated my firmware yesterday night. let’s see how it goes.
@MindrustUK thank you. It would be awesome if you could look into it and please let me know if you need any help than we could make a PR to get into 0.28.
@MarkoMarjamaa just for your information, aneumeir merged today the PR https://github.com/aneumeier/python-lightify/pull/4 so now we should be good with 1.0.3 version on his upstream repo.
Thanks guys!
1 Like
Hello guys,
Just to let you all know that I had NO issues after running the @MindrustUK’s code https://gist.github.com/MindrustUK/3af79d035dbbd26b4cc5f08b8d99a8e9
@MindrustUK whenever you have some time, I think it is ready a for PR seems to be pretty stable to me.
Thank you!
~mmello
I finally had a bit of time this weekend to look at the Osram code again, after the changes made by various people adding things like transitioning and introducing other incidental undesirable behavior (light states not being maintained during toggling etc). I think I’ve fixed most of these in a way that transitions should work from on or off state. Brightness should persist across states.The multiple toggle to turn a light on should also HOPEFULLY be fixed. This is based off the code in Home-assistant rather that what’s hosted in my git repo. If this tests well I’ll commit it up along with the dependent lib. I take it the reset sequence counter from my previous gist is still going ok for everyone? Feedback welcome.
New osramlightify.py component here: https://gist.github.com/MindrustUK/ea063506d76273fd0ded56e8e17550d4
2 Likes