Introduction
The goal for this topic is to agree on the changes required in the framework in order to support dynamic changes to some of the channel type characteristics. An examples are: value to text mappings (options) and format string, which are provided as part of the channel type definition, either in xml or through a channel type provider programatically. Also, we can think of extending it to other channel type parameters, i.e. min/max/step values and read-only attribute, although I don’t have a real life use case for them today.
Current design seems to assume that channel types are to be available when thing becomes online and they should not change during its lifetime. For example, Paper UI is designed around this assumption and is able to refresh channel changes dynamically, but not channel types.
In some circumstances it is needed to at least update the definition of channels types, based on the information received in the runtime from a remote device under binding supervision. One example is Loxone binding, which can receive from the Miniserver an update with a new definition of labels for lighting controllers, while the device remains connected and operating all the time. It is a change in the device configuration that we need to reflect in the openHAB.
Before we jump to the design of what needs to be done, I’d like to agree on the assumptions for the changes. Here is how I see this situation.
End user use cases
I think that there is basically one requirement that affects what end user will see:
- User should see the dynamic changes to the available channel type options and format immediately as they happen on the remote device (thing). They should become visible in the UIs and rest API, providing that the user has not provided custom configuration of these parameters through configuration files. There should be no interruption to the thing operation, for example thing should not go offline and online again for these changes to be visible.
@Kai, for now I would like to review and agree on the assumptions, the use cases and set of parameters that we should be allowing for dynamic modifications, so that we are on the same page wrt requirements for the change.
Thank you
Pawel