ESSMQTT: Multitenancy / support multiple inverters

[SIMULATAN]

Currently, ESSMQTT only supports a single ESS instance as it publishes to the root of the MQTT server (specifically, under /home and /common).

Since we have 2 ESS inverters, I was tasked with altering the code of this (awesome!) project.
In my fork, I implemented a basic namespacing system. It allows users to specify the ESS name using --ess_name. You can find the commit here: d152e67
With this change, ESSMQTT publishes to /ess/{name}/(home|common). This allows me to run two docker containers publishing data for both our inverters in parallel without MQTT topic conflicts.

Currently, I am in the process of forking and altering the homeassistant addon to finally get ESSMQTT to run alongside HomeAssistant instead of a separate server. My current approach is to implement a "supervisor" / watchdog in bash that executes multiple ESSMQTT instances in the background (using bash's &). This would allow maximum flexibility (different ESSes, different settings) but, more importantly, reduces the amount of code changes required (modifying ESSMQTT to support this would be quite the task).

Would you be interested in upstreaming these changes? If so, I'd create separate branches and prepare a version that is as unopinionated as possible so everyone can enjoy them. The biggest problem is that changing the topic name is a breaking change (if you configured sensors manually or use the MQTT topics outside of HASS' autoconfiguration) and the addon configuration would be changed to an array of ESS configurations.

Please let me know what you think, I'd be happy to get my changes into the main codebase to avoid fragmentation and innovate efficiently going forward. Thanks in advance.

[gluap]

Generally I'm in favor of having multi ESS support. However a breaking change wrt the setup dialogue may be a big obstacle for some users. And changes in the mqtt topic will be disruptive to all users (but we could prevent that by leaving the mqtt patches for the first ess with the current default if unconfigured) Ideally we might find a way to prevent also the addon setup from breaking. I'll hopefully find time to look closer into this next weekend (around August 26th).

[SIMULATAN]

I absolutely agree with you, especially given that 99% of the users probably only have one anyway. We could make the ess_name optional and just fall back to the old behavior. As for HASS, I had to rewrite the config parsing to support arrays anyway. With that, I can absolutely just use the root object (=> supporting the existing schema keys) too. Apart from the UI looking off due to the two options (or lacking the array option alltogether, thus looking exactly like before) this wouldn't have any impact on existing users and still support "power users" that want to configure multiple inverters.

Thank you for your commitment! Don't stress it, I just see this as a long-term goal to foster a sustainable future (maintaining a soft-ish fork is hard!)

[fitorfun]

I wanted to ask the same Issues.
Would it be possible to query at least a second ESS with the add-on?
Unfortunately, there is no way to do this, neither in the app nor in the cloud at the same time.
I was hoping to be able to do this with HA and finally have all the values ​​to be able to add them together.
That's why I bought a calculator specifically for HA.

My idea was to install the add-on twice to perhaps be able to address 2 ESS.
Even better is that it only needs one add-on.

By the way: Is there a reason why only 2 inputs are retrieved?

@SIMULATAN
If the perfect implementation is already finished, can I use yours?

[SIMULATAN]

@fitorfun absolutely, please use it and give us feedback! It'd be great to get a second opinion and not just have to rely on my own experiences.

I've been using a local developer build of my fork so far, just tested the GitHub version and had to fix the repository it points to. You can add https://github.com/SIMULATAN/pyess-addon to your HA addon repositories and install the "pyess add-on" from there. The version is still 0.0.1, dunno if I'll release a proper one at some point.

The configuration is the same as the official one - just with an array of the keys instead of them being at the root. It'll auto-fill demo keys (i.e. inverter), just copy-paste it for your inverters and modify the parameters. Let me know if you have any issues or need further help (also, feel free to open an issue on my forks to avoid cluttering this issue)