ESH-INF/thing/things.xml: Refer to bridge of other binding

[davidgraeff]

Discussion: https://community.openhab.org/t/development-is-it-possible-in-a-thing-types-xml-for-a-thing-to-refer-to-bridges-defined-in-some-other-binding/42126

I have declared a thing like this:

<thing-type id="topic">

and I'd like 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>

One way is to just have the same binding ID for all those bindings, but this restriction does not make sense if it really is an extensible parent/child relation.

The bigger picture

• Imagine there is a binding to configure connections (let's say to configure 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 parent binding that configures the connections. The child binding "Homie" would need to use those connections. The "MQTT Binding" would establish a public interface with its bridge specification that child bindings can freely use.

Binding dependencies

Of course this would introduce binding dependencies. This concept does not yet exist.

[kaikreuzer]

Well, I think @SJKA already gave the answer here:

"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."

The bindings do not reflect a certain "product support" but rather a "technology support". Just like we do not have a "Fibaro binding", but only a "Z-Wave binding".

Also note that certain products can potentially be supported through multiple bindings - e.g. an "Osram Lightify bulb" through a "Lightify binding" (using the Osram gateway), the "Hue binding" (using the Philips gateway) and the "Zigbee binding" (communicating directly). So effectively, your case is adding "Homie support through MQTT binding".

I am aware that this isn't ideal from a user point of view - nobody would have the idea to look for Homie support in the MQTT binding documentation. This is something that we should try to figure out on the documentation side, though.

FTR: The Blukii support is the prototype for such a situation (which had already been sketched out here (pretty similar to your diagram) - it comes as an additional bundle for the Bluetooth binding and thus is an integral part of the Bluetooth binding, if the blukii bundle is installed. I am still looking for a good format for the README.md (i.e. its documentation) to make it integratable into the Bluetooth documentation. What is probably specifically helpful is to have that product-to-binding relation formally declared in some add-on meta-data as discussed in #3692.

[ssalonen]

Very good comment with much appreciated references.

I would like to highlight that the blukii example shows how bundle/binding ("bluetooth.blukii") can refer to bridges in some other bundle ("bluetooth").

Interestingly, the bindingId in blukii bundle is set to "bluetooth". So does this mean that this setup works when there is no need to introduce bridges by blukii bundle? Otherwise one could not refer to those in the thing xml.

This is not a huge caveat since usually/often there are not many levels of bridges.

[kaikreuzer]

The important point to understand is that OSGi bundles are just a technical split - whether all code and XMLs for Bluetooth (incl. Blukii) are in a single bundle or they are spread over x bundles is just the same at runtime. This has been designed this way right from the start - so that any binding can be easily extended by more specific features by simply adding those features as separate bundles (while their Things use the same binding id).

[mrbig]

@kaikreuzer I've tried to implement the same solution you shown with blukii (code can be found here )
It works with PaperUI but unfortunately it doesn't when I try to set up the bridge and thing in a .things file.

My things file looks like this:

Bridge modbus:tcp:se4000 [ ... ] {
    inverter-single-phase myinverter [ ... ]
}

The bridge is found and set up correctly, but the inverter wich is handled by the sunspec bundle isn't.

I believe it is caused by GenericThingProvider.xtend: currently things under a bridge should be handled exactly by the same handler that handles the bridge.

Is there a workaround for this? Could this been solved by the blukii package?

[kaikreuzer]

currently things under a bridge should be handled exactly by the same handler that handles the bridge

I don't think this is the case, because in almost all cases, we have different handlers for bridges and for things. I cannot rule out that there is an issue, if those are not in the same bundle, though. What kind of error are you seeing? You might want to create a separate bug report for that.

What definitely works in things files (and that's what I used when testing blukii), is to use a flat list instead of nesting the definitions, i.e. you can do

Bridge bluetooth:bluez:hci0 [ address="12:34:56:78:90:AB", discovery=false ]
Thing bluetooth:beacon:hci0:b1  "BLE Beacon" (bluetooth:bluez:hci0) [ address="68:64:4C:14:FC:C4" ]

i.e. the Thing simply references its bridge instead of being nested in its declaration.

[mrbig]

I don't think this is the case, because in almost all cases, we have different handlers for bridges and for things.

Sorry I was using incorrect wording. It's not the thing/bridge handler, but the lookup of the handler factory that has an issue, and only with the nested syntax.

I could check the flat syntax, and it works for me too. I've opened a separate issue for this (see above)