Hi @Andre0512 - from your blog it seems that one of Haier's big concerns is the high polling rate of API calls (10 seconds) and the impact on their server running costs.
Perhaps during your discussion, you should suggest them to implement a server push model (e.g. based on SSE). As device's status probably only change on a time frame of many minutes, such a solution would drop the bandwidth hugely.
You might cite Philips Hue / Signify whose API is open and published. They are changing from an older API v1 which is polling based to a much newer API v2 which is event driven. The latter is hugely more performant in terms of user experience (state updates are immediate) and also hugely more performant in terms of bandwidth (state updates sent on the scale of tens of minutes vs. polling in the scale of seconds).
Just for info, I wrote the Hue API v2 integration into openHAB, so I have a good understanding how this works. I can provide you with links to the Hue API v2 description and architecture if it helps.
Hi @Andre0512 - from your blog it seems that one of Haier's big concerns is the high polling rate of API calls (10 seconds) and the impact on their server running costs.
Perhaps during your discussion, you should suggest them to implement a server push model (e.g. based on SSE). As device's status probably only change on a time frame of many minutes, such a solution would drop the bandwidth hugely.
You might cite Philips Hue / Signify whose API is open and published. They are changing from an older API v1 which is polling based to a much newer API v2 which is event driven. The latter is hugely more performant in terms of user experience (state updates are immediate) and also hugely more performant in terms of bandwidth (state updates sent on the scale of tens of minutes vs. polling in the scale of seconds).
Just for info, I wrote the Hue API v2 integration into openHAB, so I have a good understanding how this works. I can provide you with links to the Hue API v2 description and architecture if it helps.