#Do we want an entity for the remaining
tall valley
Now that you ask the question like this... In my recently merged Tado rate limit, I got the explicit request to do that only on exceptions and in the diagnostics
deep plank
Yep, I don't exactly recall the reasoning
tall valley
Not relevant for each update cycle
deep plank
and in your case, was it a counter or from the headers?
tall valley
Headers
deep plank
because here it seems more like a device property rather than a side effect so to say
tall valley
Debatable, depending on your need for data I suppose
tall valley
because here it seems more like a device property rather than a side effect so t...
True
deep plank
yea, hence I threw it in here as I wasn't completely sure
tall valley
I'd say it's fine. Interesting what others think 😀
thick matrix
How would the user be able to use that information? They would need to know how action calls relate to write requests. Without that information I don't think we should add it.
thick matrix
And I don't think we want users to have to care about that either.
tall valley
Would exposing the limit in the diagnostics be an option?
deep plank
I believe it already is now
deep plank
How would the user be able to use that information? They would need to know how ...
At this point I am wondering how they present that in their app or to their users
signal cape
My main reason for adding it was visibility when troubleshooting automations that stop changing the mode after the daily limit is reached. It gives a 429 error (noted in documentation under troubleshooting).Since it is already a disabled-by-default diagnostic sensor, and also available through diagnostics, I saw that as a reasonable middle ground.
It can also provide useful graph/history insights, for example to spot unexpected spikes in write usage caused by an automation
signal cape
At this point I am wondering how they present that in their app or to their user...
The app they (duco) provide is primarily intended for installers of the product. The Connectivity Board seems to be mainly aimed at users who want to integrate the system into their home automation setup.
deep plank
In that case I think we should handle 429 well
signal cape
Currently a 429 is treated as a generic DucoError, the coordinator raises UpdateFailed and entities go unavailable until the next poll. Improving this in the library and integration is planned for a follow-up PR.
I'm thinking about proper DucoRateLimitError handling, ServiceValidationError on write actions, and a warning log
bitter nymph
Better to focus on getting that done then 👍