Extend XML ThingType definition

[J-N-K]

At the moment it is only allowed to either use a config-description-ref or a config-description. It would be very useful to combine both.

Usecase:

The OneWire binding defines a lot of thing-types that all have two parameters which are identical. This is perfect for config-description-ref. Some thing-types have additional parameters. With the proposed change one could write

<config-description-ref uri="thing-type:onewire:basethingconfig" />
<config-description>
    <parameter name="id1" type="text">
        <context>network_address</context>
        <label>Temperature sensor ID</label>
        <description>Sensor ID of the DS18B20 sensor in format: xx.xxxxxxxxxxxx</description>
        <required>true</required>
    </parameter>
    <parameter name="lightsensor" type="boolean">
        <label>Ambient light</label>
        <description>Ambient light connected</description>
        <default>false</default>
        <required>false</required>
    </parameter>
    <parameter name="temperaturesensor" type="text">
        <label>Temperature Sensor</label>
        <options>
            <option value="DS2438">internal (DS2438)</option>
            <option value="DS18B20">external (DS18B20)</option>
        </options>
        <default>DS2438</default>
        <limitToOptions>true</limitToOptions>
        <required>false</required>
    </parameter>
</config-description>

instead of repeating the parameter defintion that are already part of the referenced config-description.

[davidgraeff]

I also would like that for the MQTT binding, CoAP binding and the HTTP binding would benefit as well. I guess every more "generic" binding is benefiting.

[maggu2810]

I moved from XML to programmatic thing types, channel, configuration etc. for a while. It allows to use the same constants in the definition and its usage and it allows inheritance and reuse of every part. Perhaps you can give it a try what needs to be changed to allow both and we could check if there are some blockers. But I assume there will be a request sooner or later why we don't allow multiple configuration descriptor references that are merged etc.

[hakan42]

I moved from XML to programmatic thing types, channel, configuration etc. for a while.

@maggu2810 , could you give me a pointer where I can read how you do the programmatic access? I have bindings (senseBox, already in master, and luftinfo, still in planning) which could benefit from extensible channels as well.

[maggu2810]

@hakan42 I cannot point you to a location that contains code at the moment as it is done for proprietary bindings. But perhaps I can post some parts of code if I am back to work next week (need to check).

[J-N-K]

I had a quick look and it is not so easy. The current implementation of getConfigDescriptionObjects in AbstractDescriptionTypeConverter checks if there is a config-description-ref and if so, returns with that URI and an empty set of parameters. If there is no config-description-ref, the config-description is parsed, and the thing-type UID is returned as URI with the parsed parameters.

So either two (or more) URIs need to be returned (the provided one(s) and a second one for the attached parameter set) and merged later (i have not found out where the URI is resolved to parameters yet) or we need to merge it there. I have no idea yet, if the URI-content is already available at that time.