What’s the real reason for quota? I don’t see any benefit atm, only problems with it.
And music mode … opening firewalls in other direction…
Local control will cause internal state change and the changes need to be sent to our cloud in order to make other client in sync. The quota is to avoid too many messages being sent to cloud.
Hello,
If it’s to protect cloud, then i see following bug:
- why do i get “client quota exceeded” for “get_prop” request? I believe, that one is not producing notification to cloud and hence should be always responding.
- i’m getting “client quota exceeded” after less then 50 cmds modifying state. Is perhaps also “get_prop” and other read commands calculated into quota? I would expect it’s not, as it’s not generating request to cloud.
And i have following ideas:
A) light should avoid to send too much to cloud, instead of preventing executing already received commands.
Reason: Best user experience is, when user can contol the light state. Delayed display of current state can be accepted, important it, when i select scene etc, that it’s set. Similar when i hit wall switch connected over local control, i want to control the lamp. Etc.
Note: even if some state is prevented to be send to cloud, if there was no other state change, it mus be later send anyway, to get synced.
Other idea:
B) would it be possible to disable quota for time, when light is not having connection to cloud?
C) What about making it possible to configure light (same to be user after power cycle) in way, that it disables sync to cloud and disables quota? Basically it’s simillar to music mode, with few differences
- connection is still done in direction to light
- works without need to enable it explicitly
Advantages out of this: - no need to open firewalls for lights
- allows multiple clients (compared to music mode) - e.g. useful for fault tolerancy
- easy to determine what is connectivity issue compared to music mode (other direction of connection).
- much easier to work with, as don’t need to maintain two connections and use one as kind healthcheck for another, as no need to enable special (music) mode.
Disadvantage (actually not at all compared to music mode):
- no cloud … but, who does need cloud, if using local control to integrate with own controllers etc?
Note to explain advantage: TCP connection can break down in way, that party, which is not trying to send data, will not detect it immediately, but after long time. If such party is light, then it’s unlucky situation as light doens’t normally have need to send data. Local controller will detect connection issue very fast (on next attempt to send data - hence as soon as it wants to contorl the light) for “music” connection, and to safely recover, it must restart music mode to force light to reconnect in such cases.
thank you
best regards
jan
- Why “get_prop” cause quota consumed? The granularity is not small enough because we just want to make the logic in the bulb simple enough and easier to understand. User doesn’t need to think “oh, this command will cause quota decrease or that command won’t …”.
- Why don’t do delay sending? Internally we already delayed state reporting for some small time. But per most user’s feedback, delay display of the current state is not acceptable. You can’t just predict other user’s needs just from your own feelings.
- Having no connection to the cloud? Most people just want to use local control and meantime control their lights through Alexa/Google.
- Make quota configurable? Yes, we can do that of course. But here we need to ask: why would someone need to send 60 commands to a bulb? We have published the API for over 2 years and we didn’t get any complaint about the quota, so we assume this mechanism is not too bad for most use cases. Introduce any option will cause confusion to users that don’t need that option, so we must be very careful.
- Regarding TCP connection break issue, I didn’t quite understand your point. TCP_KEEPALIVE is enabled on the bulb and it can detect peer lost.
I think instead of listing the disadvantage of our local control mechanism, you’d better explain what do you want to implement and why do you think 60 commands per minute is not enough for you. But please remember, we are making devices and APIs for majority users, sometimes we need to do compromises.
Hello,
i see your points, thank you. You can close the topic.
I hope in real life i wouldn’t need 60 cmds/second.
I hit quota limit many times, while dimming testing my controller. Simply turn on, and select scene by multiple wall switch hits and then finetune with long press. During long press, brightness is adjusted multiple times per second. For simplicity, i was fetching the state before each adjustment.
So with this, i hit quota quite fast, e.g. while showing my wife how it works 
(or stucks, if someone plays with light too much)
For me control over mobile phone is quite uncomfortable. Not only i have find it, have clean and free hands, but also would need to start app, or find homescreen with many many light controls. Instead wallswitch is on well known location, at entrance to room, can be hit with elbow or similar, and even grand mother knows how to use it. I have wall switches connected to ESP8266 boards, which communicate with rPI. rPi contains all logic and is communucating with light of all brands and other stuff.
Only remote controls we use are in sleeping room. However not original ones, as there i didn’t find a way, how to turn on night light directly. With API it’s possible using workaround: by turning lamp on with “smooth” effect over a 500ms or similar, immediately followed by command to reduce brightness.
As i remember home assistant, openhab and other home automation solutions are often having web & mobile apps to control all. I think they would be prefered in installation where are either not only lights or not only single brands is used. Hence again local control would be used, instead of cloud.
(i personally don’t use it … don’t need any app).
For alexa/google …well, even if used, they are just sources of events, which are processes by home automation system, in my case rPI. … then local control -> no cloud needed.
Overall my personal experience with cloud (of few brands including yours) is not good. Usually it works, but delay is sometimes quite noticable and from time to time, it’s over second or two, which is not acceptable.
(and i have good internet connection, working remotely over RDP majority of the time)
Hence i’m avoiding clouds and internet in general and trying to have all locally.
Hence local controller, firewalled lights, idea of no quotas if no cloud access etc.
thank you
best regards
jan
Now I see why you want to remove the quota! As a consumer electronic manufacture, we have to make products based on the marketing needs. Personally I don’t like cloud either and I even think WiFi for lighting products is anti-technique, but we have to listen to most customers’ voices so we can survive.
Thanks for your understanding and thanks for choosing Yeelight products.