sharph
Cannot connect to bulbs after update to firmware 1.2beta
Today I was invited to be a beta tester for the new firmware version 1.2 on my bulbs. Since the update I cannot communicate with them via python. The official Ruby API still works.
I get the following traceback:
lifx.get_lights()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.2/dist-packages/lifx/lifx.py", line 117, in get_lights
network.sendpacket(p)
File "/usr/local/lib/python3.2/dist-packages/lifx/network.py", line 54, in sendpacket
connect()
File "/usr/local/lib/python3.2/dist-packages/lifx/network.py", line 44, in connect
tcpsock.connect(addr)
socket.error: [Errno 111] Connection refused
Is there a way to force a UDP socket connection via this API? I'm curious if only TCP has issues. I'm still waiting for the beta invite/response, but thanks for the warning.
That's a bummer! I'm of the opinion that UDP over Wifi isn't very reliable. It's fine for streaming media where the occasional dropped packet means a blip in the stream that will probably go unnoticed. But for control messages? There's a reason I chose TCP in my implementation.
I'd tell you a joke about UDP, but you probably wouldn't get it.
If this is the direction LIFX is going in, I'll see what I can do about moving the code to UDP (it shouldn't be very hard) if no one else wants to take a shot.
Ugh, this is probably going to break the reliability of state information of the bulb objects. Definitely nothing to build a REST interface out of.
Ah, I got your UDP joke. Or maybe it was someone else's that just finally made it to me.
At any rate, I wasn't stating that you should change the whole implementation, just for test; but I would imagine it wouldn't be a fun exercise even for that. They say they UDP as a fall-back mode, but I couldn't tell you what the threshold is, nor if they actually implemented it.
Perhaps it's some other issue, like the message API was changed and now that port is closed? Just another though.
I suppose I shouldn't change things up too much prematurely. I'm at a bit of a loss though. I'll check out the Ruby libs to see how LIFX is doing it.
From a brief review, it seems LIFX expects all data to flow via UDP; Have written to them regarding this, and to get more information.
Considered doing a partial rewrite of the Python lib to support/use UDP, but I'm personally more inclined to rewrite into QT5 (due to the nature of my interests).
If/when I hear back from LIFX, I will come back with (hopefully) more details. If any of you hear from them on this topic, do share :)
EDIT: LIFX confirmed via email that TCP is no longer used as of FW v1.3 :(
@GNious You should do a rewrite for UDP if you're feeling up to it! I'd totally merge it. Are Python and QT mutually exclusive?
@sharph - They aren't mutually exclusive per se, just that the project I'm messing with is in QML, so QT is native, where-as using your LIFX-Python lib, I had to use a shim :)
The version of LIFX-Python, that I have, doesn't match yours 100%, so if I do figure out early support for UDP in this lib, merging might be a bit of a mess.
Biggest issue I can see is that using UDP would be asynchronous - Currently, with TCP, you send a request, and wait for a reply. With UDP, would have to send request(s), and then be ready for replies (or no reply!) at any point. That would require having a separate thread always listening for packages from the bulb(s), and then updating the status in the lib. (from talks with LIFX: Apps updating status on a bulb results in broadcasted status packages, to keep concurrent apps in sync with the status of the bulb(s)) I have very little experience with threads in Python (or python in general), so this is non-trivial for me :)
Note: The project I'm working on is a LIFX app for Jolla phones. Previously, I assisted @luwes on his LIFX-Menu app (https://github.com/luwes/LIFX-Menu), that uses your lib.
Uki, I think I have an early+ugly version using UDP running, without a separate thread for receiving replies. Am still testing stuff, notably it runs seemingly OK in command-line, but fails when I use it with the LIFX-Menu app for OSX.
Will update my fork of the project, and see about making a pull request NOTE: The Pull-request should no be accepted blindly - there will be ugly code, lots of old code commented out, and likely breakage :)
GGuys, any idea if this is still working with the latest firmware? Not in the mood of re-writing all my scripts that i borrowed from you peeps :P
@veeectorm - sorry, didn't see your question :( The last version of lifx-python I messed with (see my clone) handles latest firmware, except for a few hiccups - biggest headache you're likely to encounter is that it doesn't read status-updates automagically, so you may have to poll for status every so often.
Got it. Ill update my code based on yours then.
I hope i dont lose all my work hehehehe.
Thanks a lot!
Sent from my iPad
On Oct 23, 2014, at 10:38 AM, GNious [email protected] wrote:
@veeectorm - sorry, didn't see your question :( The last version of lifx-python I messed with (see my clone) handles latest firmware, except for a few hiccups - biggest headache you're likely to encounter is that it doesn't read status-updates automagically, so you may have to poll for status every so often.
— Reply to this email directly or view it on GitHub.
Well, sorry to bump something kinda old, but last firmware finally broke it completely. Ill double check everything once i get a chance. Thankfully i only updated one bulb instead of all of them.
On the other hand, the new firmware is ridiculously fast, id say instantaneous while controlling bulbs. Pretty impressive.