Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

various limitations #5

Open
brianmay opened this issue Aug 12, 2018 · 2 comments
Open

various limitations #5

brianmay opened this issue Aug 12, 2018 · 2 comments

Comments

@brianmay
Copy link

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

@brianmay
Copy link
Author

I am working on these issues in my work. master...brianmay:master

Think I have retries working, but this still requires more testing before I commit.

@brianmay
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant