One more comment about the query load of the HomePilot.
At this moment, I can deal with the whole magic just using two HTTP requests.
There is no need to query the current positions of rollershutters and thermostats with http://<HomePilotIP>/devices/<individualDID>.
You can get any actuator status, actual value, setpoint etc. using stateExtension="/v4/devices" and parsing through the cache allover again with a scheme like stateTransformation="JSONPATH:$.devices[?(@.did==<myDID>)].statusesMap.Position".
This exhaustive list just does not contain pure sensor devices (like remote switches, UWS, door and window sensors, sun sensors or the like). As mentioned quite early (way before my time 
) in this thread, they can be found in stateExtension="/v4/devices?devtype=Sensor", parsing goes very similar in a stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].readings.contact_state" scheme.
With this, you can do all the cyclic reading with only two HTTP requests, and no more individual DID addresses.
This (temporarily) fixed the issue with the delay setting - currently, HP counts the pure number of channels, multiplies with the delay and extends the polling period if it’s too short. It does not check if they all have the same stateExtension and will be cached. No way known yet to circumvent this, but seems like the HomePilot can bear two requests without any delay. See ongoing discussion in this thread.
The individual DID addresses are still and only required for issuing commands. But in contrast to periodical readings, commands issued from time to time normally do not have the risk of driving the HomePilot into a denial-of-service 