client quota exceeded

[jan2346]

Hello Yeelight,

on of my ~ 10 lamps is today reporting “client quota exceeded” to each request.

Checked on firewall, there is only one incoming connection to lamp and one outgoing from lamp to somewhere in internet.

Incoming one is from my raspberry pi, from application where i see “client quota exceeded” response.
I see also all requests app sent there and last hours there is no traffic, except of one request per minute like {“id”:1266, “method”:“get_prop”, “params”:[“power”, “active_mode”, “ct”, “bright”, “nl_br”, “active_bright”]}

At least last 6 hours is nothing but this error returned.

While typing this, i wanted to check FW version. Opened yeelight android app, but realized it’s again asking for login (happens to me randomly each few months). Hence i logged in.
Lamp is on 1.5.9_0184.
I hit update, but it failed (could be because i have phone on other AP?).
But that (login or attempt to update) magically helped the lamp and now it’s responding for 10+ minutes already without any issues.

Is that known issue, that “client quota exceeded” can be returned even if there is only 1 request per minute?
Was login, or attempt to update or something else reason that it started working again (using same existing connection)?

thank you

[dingyichen]

Hello,

It seems this is a bug, client quota is 60 per min, if client send more than 60 commands in a minute, lamp will report “client quota exceeded”.

So you write an application to control the lamp locally from raspberry pi, what’s the last command when the issue happens?

@jan2346

While typing this, i wanted to check FW version. Opened yeelight android app, but realized it’s again asking for login (happens to me randomly each few months). Hence i logged in.

What’s the application version do you use? Please update to latest version, we made some optimization, if you encounter the issue again, please let us know.

Thanks,
Andy

[jan2346]

Hello Andy,

Then only commands i saw on last few pages of log were once per minute:
{“id”:1266, “method”:“get_prop”, “params”:[“power”, “active_mode”, “ct”, “bright”, “nl_br”, “active_bright”]}
where ID was incremented each time.

android app i don’t use normally and as i remember wasn’t even started that day. Its version 3.2.36 connected to Europian cloud.

btw … still, would be nice, if “read-only” commands are not counted into quota.

thank you
best regards
jano

[dingyichen]

Hello,

It seems this is a bug, if the issue happens again, let us know.

@jan2346

btw … still, would be nice, if “read-only” commands are not counted into quota.

Each command you send to the bulb, there’s a response. The response will send to cloud, limit quota was set in case of attack on purpose. Btw, 60 per minute is enough to use.

Thanks,
Andy

[madrian]

I so much I hate the cloud in Yeelight. I have 9 ceiling light in my current home, but because of cloud I am not going to buy any more to my new house. Basically it’s just a toy and cannot be used as a main light.

All I wanted is a to control brightness/color_temp from Home Assistant and after 3 button press I get

'1579119183994':
  alias: Ikea Remote - ColorTemp cold Group 1
  sequence:
    service: light.turn_on
    data_template:
      entity_id: light.yeelight_lights_1
      transition: '1'
      color_temp: "{% if not state_attr('light.yeelight_lights_1', 'color_temp') ==\
        \ None %} {% set n = state_attr('light.yeelight_lights_1', 'color_temp') -\
        \ 25 %}  {% if n > 370 %}\n  370\n{% else %}\n  {{ n }}\n{% endif %} {% else\
        \ %}  153  {% endif %}"

2020-01-15 21:41:43 ERROR (SyncWorker_9) [custom_components.yeelight] Unable to update device 192.168.1.182, yeelight_ceiling1_7c49ebb38056: {'code': -1, 'message': 'client quota exceeded'}

[jan2346]

@yeelight: I propose following feature request: add possibility to configure to disable updates of light in direction to cloud communication for exchange with removing quota limit

@yeelight: Feature request: according to what i read read here have a feeling, that for whatever reason there is cloud communication, even if i locally sent get-request, which is not changing state at all (didn’t verify it yet on firewall). I don’t see any reason to do this. Once removed (or if it’s not the case), please stop counting read-only commands/responses to quota.

@madrian: don’t know home assistant, maybe you use bad plugin, which is doing read-requests for no reason. It can maintain local state - no need to read state from light at all. And there is always workaround, when quota is not applied - music mode. I have never tried that, as i’m was far below quota … until this issue appeared.

[krackker]

@dingyichen I’ve just installed my Yeelight Jiaoyue 480 but it does not connect to my Google Home, it will say linked account to yeelight app but does not have a display to start device selection. Any idea why? Does not connect to Mi Home as well

[jan2346]

any reactions on proposals?

[jan2346]

today similar scenario. Lamps are contacted for status once per minute. They were online for 45days and approx 16hours, when i started to get responses like

{“id”:10641, “error”:{“code”:-1, “message”:“client quota exceeded”}}

16:08:49,620 for first lamp, 16:32:51,132 for 4 more lamps, and 4 seconds later for one more.

So 6 of 15 lamps are not working atm…
Seems over yeelight app they works, but we don’t use this at all. We use only wall switches and motion sensors…

So at 20:07 i tried to restart my local control app, so it created new connection to each lamp … that helped … but unfortunatelly for short time only.

21:06 one lamp started with client quota exceeded
21:18 next one
21:20 another
in the end again same 6 lamps had issue again…

@yeelight: isn’t it kind of overflow in some internal counter etc? Would it help, if i firewall lamps from internet? (i don’t need your app unless for pairing and setting lan control and default settings … would be great if all that could be done without internet/app)

so i powercycled 8 lamps and will see…

overall i’m pretty disappointed … i have 15 ceiling maps and
… many of them lamps are just loosing wifi over longer period and wont reconnect unless powercycled
… some are not capable to reconnect to wifi, if i powercycle AP. Have to powercycle lamps
… and this quota stuff in addition to that …

and just bought arwen … hoping that one will work … not yet connected to local control.

[Amber_Sun]

Hi Jan,
Sorry for hear that, I think the device is receiving too many commands in a short period of time. There is a limit of 60 commands per minute on the device in LAN mode.

You can slow down the rate at which the client sends commands, or try to disconnect the connection and reconnect the client Quota Exceeded. Or control the lights over UDP channels.

BR, Amber

[jan2346]

point is it’s receiving only 1 get-cmd per minute over LAN … over cloud i have no idea (but i don’t use mobile apps to control lamps … i use it only for initial setup).

and still it’s stupid i cannot even issue GET cmd … that should not count to quota, as GET is not forwarded to cloud hopefully.

Btw .i think everyone would be happier, if quota to protect cloud just prevent it to send it to cloud and keep LAN working as normal …

[jan2346]

next time it happens i’ll do a logging of all traffic over wifi and will try instead to remove internet connect from lamp to see if that helped … to have a proff. Hoping it’ll be again in few years and not tomorow

[dingyichen]

@jan2346

point is it’s receiving only 1 get-cmd per minute over LAN … over cloud i have no idea (but i don’t use mobile apps to control lamps … i use it only for initial setup).

and still it’s stupid i cannot even issue GET cmd … that should not count to quota, as GET is not forwarded to cloud hopefully.

Yes, you are right, I think this is a bug. Seems it is not easy for us to reproduce, so do you have Wechat or other instant message application, I will loop firmware engineer to help if the issue happens again.

[jan2346]

i don’t use any IM, but it should not be a problem to create an account on some web-based one.

See last sections i wrote - problem is probably 32bit overflow of uptime information in lamp…

I’m here, as i have quota issue again… happened today on multiple lamps at nearly same time
first lamp (stairs, motion controlled, hence most often used): 2022-04-21 16:12:56,347 in CEST timezone.
next 5 lamps all within 3 second: 2022-04-21 16:42:57,834 (+3 seconds)

i restarted my app, hence local connection (1 to each lamp) was reconnected around 2022-04-21 19:50:57,741

Problem appeared again around 2022-04-21 20:39:33,720 and persists…
over yeelight app i can control them.

around 21:35 trying to firewall one lamp from internet, keeping only LAN connection…
also enabling logging of all packets going to IP of lamp…

well 7 minutes later no good news, still quota problem reported. Lamp tried to send 180 packets to internet durign that time. Locally there were only 5-7 packets sent to lamp per minute, among them only 1 data push per minute.

21:46 i firewalled existing connection between my local app and lamp. A minute later app did new connection instead. Already for first message, quota error was returned back…

21:49 powercycling that single lamp (still firewalled from internet)

21:50 … LAN control works again as normal
21:55 … still works, can do multiple commands per minute, no problem.

chcked 3 lamps in yeelight app … all having uptime 1199hrs, 14 minutes atm, and using 1.5.9_0189. Model yeelink.light.ceiling1

that uptime is suspicious … as 1199hrs is just little above 2^32 milliseconds!
as problem was 5hrs and about 15 minutes ago … that gives me around 1194hrs… that is 4298400000 millis which is quite close to 2^32 … just 1hour difference … taking into account, that internal clock could not be precise enough … i would stay problem is because of overflow of uptime millis somehow…

please check that

[jan2346]

any feedback?

[jan2346]

any news?

[dingyichen]

Thank you for your reply, the cause of this problem seems to be the clock overflow, restarting the device can last for a month or so. At present, there are some problems in Xiaomi Cloud that cause the products of this platform to be unable to update the version. After the cloud problem is fixed, we will give you a whitelist version to solve this problem. Thank you for your understanding and support.

[liufei1]

Hi, this one is confirmed as a bug. The lamp/bulb’s quota refilling timer failed to arm after 2^32 milliseconds. The fix is simple. Yet we are facing problems releasing a new version, even one for beta testing, due to some technical issue with the IoT could service. For now, please power cycle the bulb/lamp from time to time, to avoid this timer-overflow issue.

We are still working to push the fix of the cloud service issue, but this will take a very long time due to some somehow ‘technical’ reasons… Will let you know in case of any progress.

[jan2346]

today next 3 lamps off on same issue.

[roygeraets]

Hi Liufei1,

Hitting the same problem here with three monob bulbs.
Bulbs error: “client quota exceeded”.

Only after a reboot of the bulb the quota is set back to 0.

Can you give me an estimate when the new firmware will be pushed?

MI ID: 6376330791

Kind Regards,

Roy