You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was much overjoyed when I found that somebody had already written a LIFX library for Elixir.
I have noticed some limitations in this library, and just soliciting feedback if you are interested in fixing these or accepting patches that fix them, in no particular order. If I got anything here wrong, or misunderstood something, please let me know.
Broadcast address is hard-coded. Won't work if the default route is the wrong interface - as sometimes happens when you have both ethernet and wifi connections. Ideally this should be a config option.
I think when making requests to the lights (e.g. change colour or state) we use the form of the packet that doesn't give an ACK packet. As this is UDP, packets could go missing for no apparent reason. This is very important for non-interactive applications. Ideally we should ask for an ACK and retry several times if we get no response. If we return this error or not to the calling application isn't a big deal for me at present time.
We seem to poll every light with multiple queries every 5 seconds for current state. For some applications this is excessive (e.g. those that only write changes to lights and don't care about the current state), and it should be possible to fine tune or even disable this polling. This is important, because if you have multiple computers running this library, each sending numerous queries, the wasted network usage is likely to add up.
We do not attempt to detect dead lights. Ideally if we send a request to a light, and it doesn't respond after several attempts and/or we poll the light and it fails to respond, we should remove the light from the list and kill the associated process.
Noticed a bug with light names and state disappearing, this appears to be fixed in git master. Great!
Any comments?
If you want I can split this up into multiple tickets.
Thanks
The text was updated successfully, but these errors were encountered:
I believe I have solved these issues, hopefully without introducing too many additional bugs :-) in my fork. At least it seems to work for me.
Not sure I like the idea of sending so many packets when we first start up. For every light, we send 6 packets without waiting for any response between packets. Might think about how to solve this one next.
Hello,
I was much overjoyed when I found that somebody had already written a LIFX library for Elixir.
I have noticed some limitations in this library, and just soliciting feedback if you are interested in fixing these or accepting patches that fix them, in no particular order. If I got anything here wrong, or misunderstood something, please let me know.
Broadcast address is hard-coded. Won't work if the default route is the wrong interface - as sometimes happens when you have both ethernet and wifi connections. Ideally this should be a config option.
I think when making requests to the lights (e.g. change colour or state) we use the form of the packet that doesn't give an ACK packet. As this is UDP, packets could go missing for no apparent reason. This is very important for non-interactive applications. Ideally we should ask for an ACK and retry several times if we get no response. If we return this error or not to the calling application isn't a big deal for me at present time.
We seem to poll every light with multiple queries every 5 seconds for current state. For some applications this is excessive (e.g. those that only write changes to lights and don't care about the current state), and it should be possible to fine tune or even disable this polling. This is important, because if you have multiple computers running this library, each sending numerous queries, the wasted network usage is likely to add up.
We do not attempt to detect dead lights. Ideally if we send a request to a light, and it doesn't respond after several attempts and/or we poll the light and it fails to respond, we should remove the light from the list and kill the associated process.
Noticed a bug with light names and state disappearing, this appears to be fixed in git master. Great!
Any comments?
If you want I can split this up into multiple tickets.
Thanks
The text was updated successfully, but these errors were encountered: