Development; Is it possible in a thing-types.xml for a thing to refer to bridges defined in some other binding?

Add-ons Bindings
,
1

Hello,

I’m asking myself if it is possible within a binding in the ESH-INF/thing/things.xml file to refer to things/bridges of other bindings. An example:

I have declared a thing like this:

<thing-type id="topic">

and I want this thing to be a child of a bridge of another binding:

<thing-type id="topic">
	<supported-bridge-type-refs>
            <bridge-type-ref id="otherBinding.someBridge" />
	</supported-bridge-type-refs>
</thing-type>

Does this work?

The bigger picture is this: Imagine there is a binding to configure connections (let’s say to Mqtt brokers). And another binding to configure things with channels that react to incoming data on a connection or provide the means for the user to send data to the connection (for instance to realize Mqtt topic messages). The following picture visualize this, concentrate on the box called “MQTT Binding” and “Homie”:

The “MQTT Binding” would be the first binding that configures the connections. The second binding “Homie” would need to use those connections and this is where my question pops in. Am I allowed to refer to other bindings bridges in the thing-description xml file?

Cheers, David

2

Doesn’t look like it: https://github.com/eclipse/smarthome/blob/447b2d6e90f4714d4dee8e127173b5209292508f/bundles/core/org.eclipse.smarthome.core.thing.xml/src/main/java/org/eclipse/smarthome/core/thing/xml/internal/ThingTypeConverter.java#L69 It always prefixes it with the current binding id.

3

Is this a valid use case and should ESH be extended to allow this scenario?

A nasty workaround would be to introduce a local bridge thing (in this example within “Homie”). Those local bridges are auto discovered and mapped to the other bindings (“Mqtt Binding”) bridges.

4

This is very interesting!

I have been discussing about similar thing with Attila Nagy. The use case is very similar to one you described, we have modbus binding having the connection things (either serial connection or tcp connection), and then some other binding providing specialized things representing actual device specific implementations.

The benefit would be that the connection things are implemented only once. Developers could focus on implementing device specific functionality in the other binding…

Best,
Sami

5

Shouldn’t the connection be made on item level? An item is already able to be bound to more than one binding/thing. If you plug the things together, each thing has to know too much about the other thing for my taste.

Sorry if i missed the point, i do not have much knowledge on openHAB internals yet.

6

There already exist several such cases, e.g. zigbee, zwave, bluetooth, knx (planned)… So far, such cases were always considered to be one “binding”, i.e. they were all using the same binding ID, even if there are several different bundles which add additional, specialized thing types. I would consider doing the same for MQTT.

Otherwise, if you still think it would make sense, then I would very much prefer having this discussion as an issue directly in the Eclipse SmartHome project.

7

I feel like I’m spamming the issue board already :smiley: I think a forum for enhancement discussions is not so bad after all. But yeah, I can open an issue.

8

@David_Graeff please paste the issue here as well – I would like to continue the discussion and find out the best solution.

I think there are quite many differences between the protocols (e.g. discovery and higher level device/data definitions in zigbee, zwave, bluetooth) and I’m not sure whether same approach works for all (no discovery, arbitrary data)…

EDIT: found it: https://github.com/eclipse/smarthome/issues/5301

9

In this case it clearly targets Mqtt related bindings, no different protocols etc. I can imagine it would be quite difficult to use this approach for different protocols.