Feature: Add ability to manage multiple z2m instances from a single frontend

[JoshuaDodds]

What does this PR do?

If you configure additional backends from dropdown item "UI Options", this feature adds a selector to the navbar component with a list of additional zigbee2mqtt service instances. If you configure nothing in this option menu. There is no change to the frontend behaviour at all.

What does it look like?

New Menu:

Configuration view:

Dropdown:

When active with one backend configured (the first is the derived default backend from window.location.host):

Why is this necessary?

Strictly speaking, it's not - However, as my zigbee network has grown and as I have a LOT of RF noise in the 2.4ghz spectrum, it has become necessary for me to run 2 coordinators and maintain two separate zigbee networks. I find it annoying and bothersome to switch between two different user interfaces if I need to work on both networks at the same time. Although a somewhat niche use case scenario, I am guessing I am not the only one (im thinking about people that run secondary test networks for testing and development as well as those who have far too many devices to keep in a single network). Anyway, I thought I would share this work in case @nurikk thought it would be as useful feature to include.

Implementation

Simply introduces the ability to disconnect/close the initial websocket session and re-establish a new one to another host. Uses local storage for building and storing a list of available backends and how to connect to them and for storing the current/last selected backend (So when you revisit the frontend it remembers the last backend you were connected to).

Caveats

I am NOT a front-end developer. I hacked this in where it seemed to make sense to me to get it to work.

Improvements that could be added

- add UI elements to configure additional back-ends in Settings->Backends and proper storage of the backend configuration instead of the JSON text file storing it uses at the moment Done!

• Multiplexing of data from multiple sources for an optional unified listing of devices in a single view (as opposed to switching between backend instances)

Testing

• Add a second z2m instance in the UI Options menu from the drop menu in the navbar.
• inspect local storage
• test switching between primary host and secondary one
• test editing an existing host
• test removing a host
• test for normal behaviour if no additional backend hosts have been added.

[nurikk]

Hi Joshua, thanks for spending time and proposing this pr.
I have a couple of thoughts about it.

1. Why can't you simply open two tabs in browser and switch between them using chrome shortcuts? (Switch to a specific tab: Press Ctrl + 1 through Ctrl + 8). This will maintain app state between tab switches and I think is much more convenient to use
2. Managing backends should be a thing, we can't hardcode backends in build-time

[JoshuaDodds]

Hi Nurikk,

1. Why can't you simply open two tabs in browser and switch between them using chrome shortcuts? (Switch to a specific tab: Press Ctrl + 1 through Ctrl + 8). This will maintain app state between tab switches and I think is much more convenient to use

Well, a few reasons... I maintain a home k8s cluster with 30 or so services many if not most with UI's and keeping of all of them is already a pain so any way i can find to minimize the number of dashboards i need to access is a win for me. Less shortcuts, less ingress's, less of everything really. I also run firefox not chrome but most importantly the idea was that if this was merged and had its own configuration tab in settings, the next step is to continue developing a merged view which enumerates and displays all devices from all backends in a unified view. This simplifies finding and configuring a specific device even further without the need to remember which network it is on, etc.

2. Managing backends should be a thing, we can't hardcode backends in build-time

Yes agree... the json manifest for backends was just to demo the idea and see if it had any traction from your end for the possibility for upstream inclusion. But just to be clear... if no file exists and no backends are configured the behaviour remains the same as always. Its only if you drop a backends.json file in the dist/ directory that the behavior of this project changes from default and only if that file has a valid configuration. 👍

On that note, what are your thoughts... with a bit of work would you be willing to merge something like this upstream for those who might find it useful? I don't want to spend a lot of time on it if you don't actually see enough intrinsic value that would allow inclusion in the project.

Let me know your thoughts! :)

[JoshuaDodds]

@nurikk @Koenkk In the meantime, i went ahead and sort of finished this up. What are your thoughts on this? Do you guys think it could be of use to other users?

[Koenkk]

I'm not really sure about such feature, you will also need to keep the z2m versions in sync because of api changes.