Some INFO from Daikin
Sending commands
Users should be mindful of the impact of sending rapid commands to heat pumps, especially those involving the start or stop of the compressor (e.g.onOffMode). To maintain reliability and durability, itās advisable to avoid initiating compressor start and stop operations more frequently than once every 10 minutes.
Itās essential to consider that the startup behaviour of the compressor consumes more energy than during steady-state operation.
Be aware that the focus of the Daikin Onecta Cloud API is mainly on home comfort control. The API is not suitable for reactive control algorithms, like PV solar optimisation, due to the rate limitation. For reactive applications, the Daikin HomeHub provides you with a local interface.
Rate limitation
A rate limitation is applied to every application that is created through this developer portal. All applications will have the following default rate limit:
rate limit per day: 200
rate limit per minute: 20
This rate limit configuration allows you to send a maximum of 200 requests per 24 hour window to the ONECTA Cloud API. Furthermore, per minute, a maximum of 20 requests can be sent. This rate limitation gives you the possibility to query the state of your devices periodically while keeping the flexibility to perform sufficient actions on your devices.
For example, if your application would fetch the state of your devices every 10 minutes, this would take up 144 API requests over a window of 24 hours. Note that you can request the state from all devices with only one API request. You then still have 56 requests that you can use for other actions such as changing the operation mode or room temperature setpoint during this window. However, you canāt perform these actions too quickly after each other because you only have a budget of 20 requests per minute.
The API rate limit algorithm is implemented using a sliding window policy, which dynamically tracks and manages the number of requests made within specific time intervals.
In a sliding window approach, time is divided into consecutive intervals, often referred to as windows. Unlike a fixed window where the limit resets at regular intervals, the sliding window maintains a moving time frame that continuously shifts forward.
For example, if we consider the rate limit of 20 requests per minute, the sliding window constantly tracks the requests made within the last minute. Each time an API call is made, only those requests are taken into account to calculate the remaining budget. This dynamic shifting ensures that the rate limit is calculated over a rolling time period rather than a fixed reset point.