UDP vs TCP update rates


I’ve written some software to control my Yeelight lamp. I want to be able to update it at least 20Hz (higher, if possible), as I’m controlling it via a virtual synthesiser. This appears to be possible using UDP, but after a certain number of messages I receive the “client quota exceeded” error. So, I wrote some further code to use the “set_music” command setting, and have the commands sent using TCP. Using TCP the update rate seems very unreliable. I’ve found I can only get it to update accurately at around 4Hz. Is this normal, or am I doing something wrong?

Can we get a way to disable cloud updates so that we can use UDP without the “client quota exceeded” error? That would be my ideal solution to this, as that is simple to use and is performing well. An option via the app would be great, or perhaps a command that temporarily suppresses this would be good.

The limit is up to 60 times per minute, you will receive “client quota exceeded” if the number is bigger than 60.

If the lamp change to music mode(command set_music), there is no command quota and no property change reported.

The set_music command is to enable the music mode, once received the command, the bulb will act as a TCP client to connect to the server specified in the parameter and from then on, the server can send any commands to the bulb. The music-to-light transformation part should be done by music server (normally use FFT).

Yes, I understand all of this. I am already using the command “set_music”, and then my software becomes a TCP server for sending further lighting commands. My issue is that I cannot update this as often as I can for the UDP mode (with UDP, I can update the colour of the bulb reliably at around every 50ms, but over TCP that value is more like every 250ms - any lower than this and the bulb does not update correctly via TCP). I’m unsure if this is an issue of my software, or of the hardware/bulb’s TCP client.

So in what kind of scenario could you send the command at around every 50ms?

How about merge some kind of command into a flow command within music mode?

I’m trying to get the lamp to follow/represent a control signal that is somewhat random, so the flow commands don’t really work for me, unfortunately. I’m making a plug-in, for some music creation software, that will allow users to set up lights to react to their songs.

Using UDP I can do this, and it looks great, but after a few seconds I reach the message limit. If the TCP/set_music mode could be updated more often, then this would look great for me too.

I see we did actually update to use UDP for Razer chroma, but I am not sure if the device you have supported the feature.

For more information please refer to: https://github.com/Yeelight/Yeelight-Chroma-Connector

Thanks for your response. I’ve had a quick look at it, but it seems as though it requires Windows. I will have a better look when I have time. I’m currently developing my plug-in on macOS, and am hoping to have this plugin availble on Linux, maxOS, and Windows (as well as support a wide range of Yeelight devices), so ideally either:

a) I’m doing something wrong in my code, and should be able to update the TCP/set_music mode more often, or
b) This would have to be fixed in the firmware for these devices - either by adding a mode to disable cloud updates and limits to UDP, or making the TCP update rate higher.

You need to focus on this file: Yeelight_Inter_Operation_Spec_UDP_R2_en.pdf, this’s protocol-related.

1 Like

Thank you - I will have a look through this. I think the lamp I have does not support this (or at least, not yet). I have ordered some other Yeelight products that I’m still waiting to be delivered, so hopefully they will support it if my current lamp doesn’t.

Thanks again for your help. I’ve managed to set up a UDP session using the “udp_sess_new” method, and am able to update it more frequently and reliably than when using the TCP server method. :grinning:

1 Like