Fastest setColor rate

[ArquintL]

Hi

I'm currently also trying to get a strobe effect and for that I tried different rates.
Changing the color every 0.2 sec looks good, but it's still a bit slow for me.
If I try a higher rate (e.g. 0.1 sec), then the bulb doesn't react at all or does get only a few commands.
Is there a way to get the best rate (maybe depending on the WiFi network) or is there a way to improve this rate?

Thank you for any inputs

Linard

[nsforge]

At the moment, it's not possible to send messages faster than every 200ms using the public SDKs, so this limits the rate at which you can change colours. We hope to address this in the future through a combination of firmware and SDK updates.

[kuzmycz]

I am not sure you want to have transactions firing that frequently. It would be better to combine a set of actions into a single payload.

Regards,
Mark

Sent from my iPhone

On 22 Apr 2014, at 3:21 pm, Nick Forge notifications@github.com wrote:

At the moment, it's not possible to send messages faster than every 200ms using the public SDKs, so this limits the rate at which you can change colours. We hope to address this in the future through a combination of firmware and SDK updates.

—
Reply to this email directly or view it on GitHub.

[lightbow]

Here's a YouTube video of LIFXtend, which seems to get past the rate limiting: https://www.youtube.com/watch?v=KG5uusKWo9I

[daz]

That tool doesn't use this API I don't think, It was released a fair while ago

On 22 May 2014, at 6:56, Lightbow notifications@github.com wrote:

Here's a YouTube video of LIFXtend, which seems to get past the rate limiting: https://www.youtube.com/watch?v=KG5uusKWo9I

—
Reply to this email directly or view it on GitHub.

[lightbow]

@nsforge can you be more specific about the throttling? Is the 0.2sec limit per-bulb or overall? Are there separate limits/guidance on single-bulb commands vs. group commands? Does the SDK handle all the throttling you expect, or should developers be doing any throttling themselves. I don't mind, since I have to do it for Philips hue (0.1s rest time after every light command, 0.7s rest time after every group command, all on a per-bridge basis)

[loefberg]

Assuming that LFXKit works like lifx-sdk-android (I'm pretty sure it does), all outgoing messages are added to a queue. Every 200ms a message is taken from the queue and sent. So if you send messages faster than that all that is going to happen is that the queue builds up. I'm setting this limit to 20ms but that does lead to some lost messages. I'm guessing that you could probably get away with 50ms with no ill effects. Try changing LFXUDPMessageSendRateLimitInterval in LFXSDKConstants.m.

[loefberg]

I forgot to mention that you get one queue per gateway. So one queue for all lights, mostly. And group messages are only one message no matter how many lights in the group, so that will be substantially faster.

[lightbow]

Thanks. I'll play with that constant, though it would be great if there were a more official way to make things go faster (or at least detect when commands fail, or some way to calibrate). Or, maybe if there were a way to queue up several commands on the bulb itself and execute them with a higher degree of reliability and lower latency. Maybe we'll get something once they roll out the scheduling/timer feature.

[alexfgreen]

any update here? Was this addressed?