By defining a programmatic way to set state or configuration changes to different software blocks, we can then implement a more user-friendly GUI for changing settings. At the moment most blocks can only be controlled by editing YAML files, which is both unfamiliar to many users, is easy to introduce syntax errors into, and which can't validate configuration input.
Previously, Joannes proposed using the /set/ topic prefix for configuring devices or software blocks (see here). I am going to document an example of how this syntax could be used, in order to get further feedback and potentially allow an experimental implementation.
In the original Ontology proposal, Joannes uses the convention /set/devices/<device_type>/<device_identifier> for addressing commands to device types or individual devices. I propose to use /set/blocks/<block name>/<attribute> for the topics when configuring blocks.
Blocks could post the current settings to the same MQTT topic on start up, allowing GUIs to display the current configuration before it is edited.
Say we want to set the agile_region setting for the dynamic2mqtt block. This might be done by posting to /set/blocks/dynamic2mqtt/agile_region.
There is no way of returning feedback if a user tries to post an invalid value as a setting- in a RESTful API it could respond with an 4XX range error code, the asynchronous nature of MQTT doesn't allow the same kind of immediate feedback. One solution could be defining a standard topic for Blocks to give feedback to UI components.
Having a less direct response means that validation will have to be done on the "client side", as well as within the block itself.
A basic webapp to trigger post to a given MQTT topic was prototyped here.