Add support for HomeWizard Plug-in Battery

[mluiten]

This pull request adds support for the HomeWizard Plug-in Battery

It uses the v2 of the HomeWizard API which has a bit of a complicated setup: each HomeWizard device has an IP address and local API, and to create a token for that API, you have to physically press the button after sending a /api/user REST call. After the button press, the next call will return a token.

The Plug-In battery itself is also interesting because it's modular (you can stack them) but it controlled from the HomeWizard P1 meter; you always need both. To fetch all of the info that EVCC would need you have to call the P1 meter for the current power stats input/output, and the individual battery units for their state of charge.

To control the batteries, you also send commands to the P1 meter; you cannot control the modules individually.

Therefore, I've chosen to add them as a single device, and call each battery and average their SoC (they the same size, after all)

To help users, I've added a evcc token homewizard helper to (1) discover the devices on their local network through mDNS, (2) help them generate tokens for each devices and (3) generate the config they need to copy/paste in evcc.yaml. It looks like this: https://github.com/user-attachments/assets/8eb9499e-9243-4789-8eef-8e108b85d5b3

Each battery has a capacity of 2,45kWh usable, so I've added that calculation as the "capacity" unless explicitly configured by the user.

Still testing, so pull request is still a Draft. Curious to hear your thoughts.

[andig]

Thank you for this comprehensive PR! At this time, I'd not be too eager to merge:

• +1k LoC is a lot of code to maintain- core team won't be able to do that
• the token command is a nice touch but won't work well for config UI users

Is there any chance, we could integrate the token logic into the providerauth framework? Not sure that's possible if we really need one token per device.

I feel it might be a better decision for use to rely on 3rd party integration here like HomeAssistant or others instead of adding this much complexity.

[mluiten]

Thank you for this comprehensive PR! At this time, I'd not be too eager to merge:

• +1k LoC is a lot of code to maintain- core team won't be able to do that
• the token command is a nice touch but won't work well for config UI users

Is there any chance, we could integrate the token logic into the providerauth framework? Not sure that's possible if we really need one token per device.

I feel it might be a better decision for use to rely on 3rd party integration here like HomeAssistant or others instead of adding this much complexity.

Thanks for the comments :) yes, the CLI command is doing most of the heavy lifting with regards to the LoC count there... I'll check if there is any overlap with the providerauth, thanks for the pointer 👍 The good news is that the integration will also work fine if the user manages to fetch the tokens in another way; the CLI is helpful but not required.

In the meantime I've actually refined it to be a more generic implementation of the HomeWizard v2 API, which will replace the v1 API that is already implemented at some point, so I hope that will make the integration more useful and a reason for you to consider it. It supports the P1 meter, kWh meters, and also the battery as separate devices. It uses their preferred method; websockets.

[andig]

Seems this has just doubled it to 2k LoC. If you see any option of hiding these LoC in an external module I'd be happy to reconsider.

[mluiten]

I would be more than willing to maintain the code; so yes I'll see if I can extract these to an external module to make sure the core team isn't overloaded :) will let you know