Currently there are some problems with associating units. For example a device introduces a list of power switches and power consumption sensors. Two of these belong together but because they are differentiated by their unit type it is almost impossible to resolve this association using the registry. And because both types are duplicated for the device, the bound to host flag cannot be used to resolve the association either.
We identified 3 possible solutions:
Implementing new unit types when a new combination is needed. This does not seem right because the number of unit types could explode and names for these combinations sound wrong (e.g. ConsumptionPowerSwitch).
Implement optional services for a unit. This would also lead to other changes, e.g. the colorable light could be a light with optional brightness and color services. The problem with this is that interfaces are not rigid anymore or could throw exceptions if you try to use an optional service. This seem tedious to handle.
Associate units via their configurations. This is done on device class level where each unit template config can be associated to another by its id. A consistency handler should then resolve the associations into dal unit ids and add them to the according dal unit config.
We decided to use the last approach because it does not entail the same disadvantages and is an extension rather than a re-implementation. So the following things have to be done:
Extend the types for unit template configs and unit configs by list of associated ids
Implement a consistency handler as explained above
Configure associations for existing device classes
Currently there are some problems with associating units. For example a device introduces a list of power switches and power consumption sensors. Two of these belong together but because they are differentiated by their unit type it is almost impossible to resolve this association using the registry. And because both types are duplicated for the device, the bound to host flag cannot be used to resolve the association either.
We identified 3 possible solutions:
We decided to use the last approach because it does not entail the same disadvantages and is an extension rather than a re-implementation. So the following things have to be done: