Thanks for the comments:

1. Instead of throttling commands i suggest that the controller should 'serialize and throttle commands'

Depends a bit how you define the semantics here (or what exactly you mean by serialization). Throttling to me implies serialization, certainly if there's only one physical connection to a device. But it doesn't necessarily imply synchronicity. Also it's not something I'd definitely impose on all implementations.

The main drive at the moment is to pull some common functionality into the controller framework. The current API for commands is quite generic so it allows implementers to add multiple features behind the API – synchronous (blocking the sensor thread) vs. asynchronous (i.e. KNX bus listener), connection management (one vs multiple connections), caching of read device states (not transmitting read request to device) which all amount to 'throttling' the request load to devices to some degree, using different ways.

I intend to keep the original generic API so that it is still available for that one corner case implementation where what we provide through framework implementations is not suitable and basically leaves the full breadth of implementation possibilities open for extension to address implementations we are not able to foresee.

At the same time we are all struggling with the default model of the protocol API which often translates to the worst case implementation which is passive devices (we need to poll) and a 'write-through' of every polling request. Either we end up with simplistic protocol implementations that are noisy, too chatty and not optimized for the devices or we all start building the features mentioned above independently (synchronous/asynchronous semantics, connection management and caching).

So providing framework implementations for those features and making the available for protocol implementers based on how they fit into their protocol designs is the goal of the next revision of the command API.

2. I suggest that read commands can be synchronous (blocking) or asynchronous (non-blocking).

Yes, and this is already the case but the burden is left for the implementer to handle and that can be too difficult of an expectation so providing guidance on how to handle from the framework side make sense (keeping to the point above that the more 'powerful' mechanism is still kept in place for those who want to handle special cases).

3. I would encourage breaking apart the architecture using rest or webservice api's where possible or appropriate. I can see scenarios where it is difficult to cover everyones need but integrators might want to use parts of the application. Possible candidates for such REST apis would be the panels and the devices of a controller.

Will try to keep in mind, in practice keeping REST API for everything is some implementation overhead so for the time being going by use cases as they come up – and for that reason if there's a specific use case then do bring it up, otherwise it may go unaddressed.

In the meantime we first need to build an appropriate object model in the controller for elements, including panels and devices, that is currently completely missing. Once such an object model is in place, translating that into a REST API is comparatively minor task.

Please let us know of your further comments and ideas.