Add-on store not showing subbindings

[lsiepel]

This might be a severe issue in 5.1.0. All subbindings are not shown in the store. Screenshots from 5.1.0 stable on windows. They can be installed from a configuration file, so it seems pure UI related.

A added screenshots and would expect many more hits for these search terms. They are also not shown in the list itself without search. I assume it might be related to the . in the binding id or something similar, as only 1 is shown

For bluetooth

For MQTT

For Modbus:

After some more checks i doubt it is UI related.

The endpoint http://localhost:8080/rest/addons?serviceId=karaf
shows a large json, and checking the content it only shows 1 occurence of sunspec and that is here: So the endpoint does not seem to provide the proper json for the subbindings?!

{
        "uid": "binding-modbus",
        "id": "modbus",
        "label": "Lambda Heat Pump Binding",
        "version": "5.1.0",
        "compatible": true,
        "contentType": "application/vnd.openhab.feature;type\u003dkaraf",
        "link": "https://www.openhab.org/addons/bindings/modbus/",
        "author": "openHAB",
        "verifiedAuthor": true,
        "installed": false,
        "type": "binding",
        "description": "Lambda heat pump binding via Modbus TCP/IP.",
        "configDescriptionURI": "",
        "keywords": "",
        "countries": [],
        "connection": "local",
        "properties": {},
        "loggerPackages": [
            "org.openhab.binding.modbus",
            "org.openhab.binding.modbus.e3dc",
            "org.openhab.binding.modbus.foxinverter",
            "org.openhab.binding.modbus.helioseasycontrols",
            "org.openhab.binding.modbus.kermi",
            "org.openhab.binding.modbus.lambda",
            "org.openhab.binding.modbus.sbc",
            "org.openhab.binding.modbus.stiebeleltron",
            "org.openhab.binding.modbus.studer",
            "org.openhab.binding.modbus.sungrow",
            "org.openhab.binding.modbus.sunspec"
        ]
    }

[lsiepel]

Also strange that binding-modbus is listed as Lambda Heat Pump Binding

[holgerfriedrich]

I don't have a 5.0 system at hand, but in 4.3 is was similar:

[jsjames]

I just checked the old UI (pre vue3) and get similar results (with a 5.0.3 openhab server). As @lsiepel noted, I believe the UI is generating the search results from the endpoint /rest/addons/serviceId=karaf correctly, as the returned data from the endpoint might not include all the bindings/sub-bindings. Has an issue be filed on core for this?

[lsiepel]

Finally got back to my pc. I can confirm this is an issue that should probably be transferred to core. It has been like this for some time. Not sure how long.

It looks like all bindings from https://github.com/openhab/openhab-addons/blob/main/features/openhab-addons/src/main/resources/footer.xml are aggregated. Causing them not to show up in the addon store.

A second problem is that the modbus binding does some weird mixup with lambda, might be related, might not, needs more investigating.

@kaikreuzer can you move this to core ?

[lsiepel]

Feel a bit stupid as this has been the behaviour since atleast 3.0.0 Now that homeassistent and homie got split from mqtt it was more noticable. Anyway, i think this needs a solution. As we now have about 30 bindings that are not visible when searching the store.

Probably because they are all encapsulated as one feature. I wonder if there is some way to detect these subbindings and add placeholders / virtual entries in the store that link to the parent feature.
Or if we might split them all into seperate features like other bindings.
@ccutrer you did some work on this, so i tag you as you might be able to share some of your experiences when splitting these ?

[ccutrer]

I've never expected sub-bindings to show up separately in the addon store. Separate entries in the store is one of the several benefits of splitting a subbinding into its own binding.

I was hoping to split the espmilighthub binding from MQTT during winter break, since it's a simpler binding than Home Assistant and Homie without dynamic thing types, for others to use as a template for further splits. Unfortunately I'm dealing with multiple home and electronics emergencies here, so I may not get any more hobby time.

[kaikreuzer]

I agree with @ccutrer - there actually is no official concept of a "sub-binding" - the vocabulary used is "binding extension", i.e. one existing binding is extended by supporting additional thing types. Our documentation also processes it this way: The extensions are listed as part of a binding, see e.g. https://www.openhab.org/addons/bindings/bluetooth/

[lsiepel]

Ah, so it’s a binding extension after all.
Still, around 30 extensions are not listed. The openHAB.org website does show them separately. Apart from this inconsistency, it may also lead to users being unaware that their device already has a ready-to-use integration just a click away.

These extensions are primarily technology-centric (e.g. MQTT, Modbus). Brands that rely on these technologies typically don’t promote the underlying protocol in the same way they do HomeKit or Matter. As a result, users tend to search from a brand perspective rather than a technology perspective.

I would like to explore possible solutions. My main goal would be to have all bindings that are currently known as extension shown in the store.

[kaikreuzer]

Yes, I agree that the current concepts make it hard to find out that support for a certain device exists - it would indeed be nice to address this. I don't have a good suggestion/idea myself right now, but I am open for anything that might be discussed.

[lsiepel]

@ccutrer you are splitting some, but not all. Do you have a clear definition or criteria to decide the ones to split?

[ccutrer]

I think the eventual goal is to split or merge all. By merge, I mean that for example BlueZ and BlueGiga might just become part of the base Bluetooth binding, and all the manufacturer specific extensions become their own binding. But I haven't touched Bluetooth or ModBus yet because I don't use those bindings.

EDIT: so my not completely clear separation point is manufacturer (or higher level "convention" like Homie and Home Assistant in MQTT land) is not installed by default, but the base bridge and any generic things are in the main binding. I'm not sure where BlueZ and BlueGiga fit in that example. For Bluetooth, I'm also keeping the (not in the main distribution) ESPHome binding in mind, because it can provide a Bluetooth bridge functionality as well.

[rkoshak]

I agree that listing sub-bindings as a separate entry here isn't what's was originally expected. But I also would have expected the search to be a little more comprehensive and this may point at a wider problem.

For example, if I search for "milight" I would have expected the MQTT binding to be in the results. If I search for Govee I'd have expected the Bluetooth binding to be in the results. Instead, I get the Mi Light binding only (i.e. the standalone binding, not the MQTT sub-binding) and the Govee search only returns the stand alone Govee WiFi binding.

With the current behavior, it's impossible to discover what might be supported by which add-ons through the Add-on store. One must go to the online docs and to a generic search (not the add-on search from the addons page).

And that brings in a discrepancy which might be the root cause of this issue. If I search for "milight" on the online docs addon search, the epsmilighthub binding does come up come up and is't shown as its own binding but the MQTT binding does not come up at all. Same for "Govee", the Govee sub-binding does come up but the parent Bluetooth binding does not.

And reading the readmes for these sub-bindings in the docs does not make it clear what binding they are extensions of so it's not clear what add-on needs to be installed.

For the end user's perspective, the search results in the Add-on store and in the online docs should be consistent. And if we plan on keeping the concept of sub-bindings at all we, need a better way to make it more clear what needs to be installed to get them after doing a search. A bonus would be if when searching for a sub-binding, the main binding comes up (instead?, in addition?).