Allow multiple instances of a single add-on, with distinguishing names

Feature Requests
1

Right now, hassio only allows installing an add-on from a repository once. As far as I can tell, this is almost purely a UI problem. Specifically, I did the following experiment:

This is a minimal fork of the community add-on repository, in which I have changed nothing whatsoever that should be material to hassio’s inner workings. There are exactly three differences:

  • name: Z-Wave JS UI is changed to name: Z-Wave JS UI alternate. I did this because, if I have two instances of the Z-Wave JS UI add-on, I want them be to distinguishable in the add-on settings. I don’t particularly care about the add-on /store/, but I want to be able to tell which one I’ve clicked when I go into the addon’s settings page.

  • panel_title: Z-Wave JS is changed to panel_title: Z-Wave JS alternate. I did this so I can tell which Ingress panel I’m selecting and using. (The backend doesn’t care at all as far as I can tell – this is only a UI change.)

I changed the repository metadata to make the add-on store page look less ridiculous when I add my repository.

So here’s my use case: the built-in Z-Wave integration natively supports multiple hubs, /and it will run multiple native supervised back-ends as needed/. It just works! The built-in Z-Wave integration also supports multiple zwave-js-ui backends. But HAOS does not know how to run multiple zwave-js-ui backends. But if I install my ridiculous add-on repository, it works perfectly – I tried it! Even the user experience is unoffensive.

So here’s my feature request: Allow this for real in hassio instead of requiring someone to hack up the metadata. My proposal would be to add three mini-features:

  1. Allow an installed add-on to have an extra description added to its name. The page at `hassio/addon/[ID]/config would have an optional string field like DESCRIPTION, and, if set, the add-on would be displayed by hassio as ‘name (DESCRIPTION)’.

  2. Allow an installed add-on to have its ingress pane’s name overridden, or alternatively just display the ingress pane’s name with ’ (DESCRIPTION)’ appended if there’s a nonempty description.

  3. Allow an add-on to be installed more than once. Optionally require a new field to be set in the add-on’s config.yaml to enable this – I can easily imagine some add-ons malfunctioning if installed more than once.

And that’s it! I think this would work fine and would satisfy the rather common user desire to have multiple instances of devices that require an add-on to operate.