Sending too many (maybe > 60 - 90/ second) lighting updates too quickly has the possibility of frying hardware. It would be a good idea to add rate limiting to 60 - 90 Hz.

This may be done using a third party package, but I would rather avoid adding another dependency if it can be avoided. Another possible strategy would be an update queue, similar to that in RGB.NET where when a user sends an update, it is added to a queue, and the queue itself is responsible for rate limiting.

Any solution to this would need to allow for easy modularity, so future device support would be quick and easy to implement.