So now we have launched the LIFX Developer Zone we would love to hear what you think. So be honest and harsh, but polite. We are looking for as much feedback as possible on the HTTP API Documentation, the LAN Protocol Documentation and this forum itself.
Lack of how the onboarding works in your LAN Protocol doc is a major problem. Weāre still locked into owning an Android or a recent iPhone just to start using your bulbs.
So itās really hard to use these SDKs to bring your bulbs to other platforms.
1 Like
I havenāt taken a look at the docs yet - but I just wanted to tell you guys that open-sourcing the low level protocol is awesome!
I was having a hard time deciding between going with Hues or with LIFX bulbs - and this pushed me to go with LIFX.
I hope the Developer Zone stays alive and supported!
1 Like
@dotMorten Iāve forwarded your request on.
@AngelicLiar Glad to have you on board. When you get around to reading it please feel free to post any questions you might have.
One question that occurs to me - is it possible to create/save/activate/edit Scenes via the HTTP API?
Alternatively, if (for example) I had three bulbs and wanted to set one to green, one to red and one to blue, is it possible to do this with a single PUT command, so that all the bulbs change at once? Or would I need to make three sequential PUTs and see the bulbs change one at a time?
1 Like
Iāll be totally honest. This feels like a huge betrayal and really makes me worry about LIFX as a platform. The iOS and Android SDKs on github werenāt always kept up to date, but still, were reasonably maintained and documented. It allowed a very quick on-boarding process for new developers. On iOS, it was as simple as adding āpod āLIFXKitāā to your podfile and with a few lines of code, youāre already controlling lights. Now we have to re-implement things like bulb discovery and deal with constructing lower-level messages/payloads? Is this just a matter of budget cuts at LIFX, or is there a rationale behind this? Why move the discussion from github to a custom site?
@lightbow I understand how you feel, and it your situation that too would be my first reaction.
Please note that we are not retracting the SDKs. They still remain available, and they are still open source. So their documentation is also still available. Additionally because they are open source anybody can pick them up and run with it. If somebody did choose to do this we will provide support in these forums as tracking the Github every SDK that someone has made with our documentation is difficult.
These same reasons mean that there is no need to re-implement anything that the SDK already does. Simply keep using the SDK as you would normally, and when things need fixes simply fork and patch the SDK.
In reality this decision was because we donāt have enough time to produce SDKs for all the requested languages while still adding features to the existing SDKs. Instead releasing the documentation allows anyone to add features to the existing SDKs and even create their own, making a better ecosystem for everyone.
To quote from the blog post:
We recognize there may be value in providing a light-weight wrapper around the protocol and API as reference implementations. The hot topic of debate is which language should we do this in to start with. Weād love to hear your opinion at LIFX Developer Zone!
2 Likes
Personally, Iām not so worried about the lack of SDKs. I actually would much prefer the LAN documentation over the old SDKs. I found them (at least the Ruby one; I didnāt take quite as close a look at the iOS and Android ones) to be rather baroque and have usage pitfalls. So Iām just as happy writing my own.
However, I do find it a little puzzling, in that it seems that LIFX needs to maintain these libraries anyway, for their own use in the first-party apps. Although I realize that cleaning up code for public consumption takes some effort, it seems like it would be worth it, because then bug fixes could flow upstream from the community into the first-party apps.
Ideally, it would be wonderful to see the first-party apps themselves open-sourced, but I donāt know how likely that is to happen.
What Iām personally more disappointed by is the incompleteness of the docs (e. g. things like onboarding) and the lateness of their arrival. As an engineer, I am sympathetic, because I know what itās like to have limited resources and customers that are demanding the moon. However, the main reason I picked LIFX over Philips Hue is because I thought LIFX would be more open, and more amenable to the hacker/maker culture. And LIFX probably is slightly more open, but still Iām a bit disappointed.
By Bob Morris, who is a political journalist and is not and never has been an employee of LIFX.
My apologies; I never meant to imply that he was. I just thought this article captured the ābuzzā that had been around LIFX a couple years ago (perhaps I even read it back in the day), but I posted the link as I ran across it, without thinking too deeply about it. I didnāt mean to imply LIFX had ever made any promises about open source.
On the other hand, LIFX did make promises about open standards:
And to be clear, open standards are a much more important priority to me than open source. As I originally stated in my reply to @lightbow, I can always write my own code if I have the spec.
Iāve worked at startups before, so I understand how limited your resources are. So, one constructive suggestion would be to start with MagicMonkeyās protocol docs, and then you can just correct the things that are out of date or incorrect. That should be less resource-intensive than writing docs from scratch for one message at a time.
Hope that clarifies things!