The command quota limit seems problematic to me because the application program and the Yeelight bulb do not share the same view of commands per minute.
A simple real life example:
A child (or the child in all of us) wants to play with the light by sliding controls around. My program might need to switch to music mode to avoid the quota. Unfortunately, my interface program (MIP) has no reliable way to know when to switch to music mode because MIP doesn’t know the state of Yeelight’s command quota. MIP could just always go into music mode but has lost the ability to query the bulb so MIP needs to track the bulbs state itself which comes with problems. It is unclear to me how to properly handle a user triggering high command rates.
One minute seems a very long time for it to be a resource management issue which prompts me to ask: Why do we have this limit?
Assuming that the limit is required, have you any suggestions on how to handle the messaging for someone who is sliding a control around? MIP can certainly debounce with delayed updates but even then, MIP doesn’t know when the Bulb started counting nor it’s current count. To be completely reliable MIP would need to limit updates to 1 per second which would be far too slow to be, well… fun.