Add manifest key supported_brands

[balloob]

Context

Some products are supported by integrations that are not named after the product that you're using. For example, Roborock vacuums are integrated via the Xiaomi Miio (xiaomi_miio) integration.

This requires the user that they know that this is the same application or Google to search if it is supported. This is a poor experience.

Proposal

Add a new integration manifest key called supported_brands to allow an integration to specify other brands that work with this integration.

Note: this proposal is specifically about brands that have a custom API serving multiple brands. This proposal is not meant to steer users to pair their Hue bulbs via the Zigbee integration. That would be for a follow-up proposal and needs different implementation.

The key would be added to the integration that is in Home Assistant. For example, for Xiaomi Miio, it would look like like this:

{
  "supported_brands": { "roborock": "Roborock" }
}

The key is a domain, like we use for integrations. The value is the title.

How to use the key

• Roborock is listed on website under integrations with an automatically generated stub page that directs user to the integration to use.
• Roborock is listed in Home Assistant when clicking "add integration". When selected, we first show a "redirect text", then user continues to the Xioami Miio config flow
• The logo for this domain can be added to our brands repository.

Constraints

• Each domain can only exist once. So a domain is either an existing integration or referred as a "supported brand" by a single existing integration. (can be validated via hassfest)

[thecode]

I think the general idea is good, but why do we need to add it to the manifest?
I think it would be better to add it to the integration docs (similar to the suggestion above) same as we add the supported platforms.

[balloob]

Because they will be shown in Home Assistant too. And we've been moving more and more things into relying on the manifests as the source of truth.

[bdraco]

I think Tuya and magic home will be interesting in this regard as the number of white labels with these is quite long

https://www.home-assistant.io/integrations/flux_led/

[cgtobi]

So will be Legrand, BTicino and Bubendorf working via the Netatmo API. And probably some more.

[frenck]

I would consider Tuya a very bad example in most cases actually.

As they have multiple protocols, including Zigbee based devices

[tetienne]

The new Overkiz integration will be a good example of such features.
We support a lot of brands and chose the white brand name Overkiz but it's not well Known while Atlantic, Somfy, Hitachi, Thermor, Nexity yes.

[iMicknl]

And for 'Overkiz (by Somfy)' we could rename it back to 'Overkiz', since (by Somfy) is just added to show up in search...

[allenporter]

Makes sense to given the user perspective of integrations. Storing in the manifest sounds right.

The documentation and config flow redirect makes sense as a soft way to show the user what's happening to prevent confusion, otherwise it would be too automatic/confusing.

[bdraco]

If the brand develops multiple devices that use different integrations there could be some overlap. Some of vendors switch between Tuya or other vendors for their chips.

That's a problem we have now though. We can always create two brands for this rare case.

[balloob]

Yeah, and when that happens we'll just drop them from the supported brands and have the integration try to guide users in right direction.

[bdraco]

This is a good proposal. We should implement this.

[iMicknl]

Would it be an idea to take discovery into account (eventually) as well? I can imagine this is out of scope for the initial implementation, but perhaps the archicture / setup could already take this into account.

For a vendor that has a white label platform (e.g. Overkiz / magic_home) it would be good to also implement add these vendor details to the discovery info (dhcp etc.).

[bdraco]

Would it be an idea to take discovery into account (eventually) as well? I can imagine this is out of scope for the initial implementation, but perhaps the archicture / setup could already take this into account.

For a vendor that has a white label platform (e.g. Overkiz / magic_home) it would be good to also implement add these vendor details to the discovery info (dhcp etc.).

For discoverable devices the user is probably more likely to figure out what has been discovered even if the brand doesn't exactly line up, however I am sure there are cases where it's confusing.

Once we have this implemented we could allow the config flow to set the brand via in the context for discovery flows assuming it knows which brand it is.

[balloob]

home-assistant/core#67015

[wills106]

Is there a reason why this isn't supported for custom_componets?

I have created the custom_component solax_modbus
It turns out that the Qcells Q.VOLT HYB-G3-3P Hybrid Inverter is just a rebranded SolaX Gen4 Inverter. So I wanted to use:

  "supported_brands": {
    "qcells_modbus": "Qcells Q.Volt"
  }

In my manifest.json to redirect Qcells owners to the SolaX Modbus Integration.

[Misiu]

Same with Cool (http://www.cool.pl/en/clima/klimatyzatory) and Gree HVAC (https://global.gree.com/), they both work using the Gree integration