feat: support multi-location

[XD-Builder]

I have two SunPower systems, and the devices have been switching between error and working states when both systems are enabled. I realized this may be caused by non-unique IDs. I have hard-coded changes to the SunPower repository to ensure each device has a unique identifier, preventing conflicts and errors. So far, I have committed a testing document and modified the entry_id to ensure unique identification. I have verified these changes manually by downloading the updated code and physically replacing the directory contents.

➜  custom_components cp -r /tmp/hass-sunpower/custom_components/sunpower/ .

I restarted the Home Assistant instance and successfully configured the SunPower system with an additional location name. After adding both systems, the conflict was resolved, and both systems are now reporting metrics correctly while my energy dashboard continues to function as expected.

I'm creating a pull request to gather feedback on this change and determine if it helps others experiencing similar issues. Additionally, I would appreciate guidance on adding this repository to HACS so it can be included as a custom repository. Currently, it shows as an unauthorized repository from my fork, though I'm unsure why this restriction exists.

[krbaker]

First of all, thank you so much for the PR this has a lot more than just the change you mentioned. All of the testing and setup docs are fantastic to have contributed.

Some initial thoughts, happy to discuss.

1. Would you like to become a maintainer? As I mentioned in the repo I switched to Enphase and I don't have as much time as I'd like, I'd love to keep pulling in good ideas from the community and hopefully give people 'the one integration they can trust' for Sunpower but I don't think I can do that alone.

2. I thought all of my entity ids were using serial numbers that should be unique.. are you finding that's not true on your two systems? (😱). Do you have a specific conflict you were seeing? Mainly I want to make sure that entity IDs also stay stable on reinstalls etc.

3. What do you think of splitting this PR into .. at least 2? I think the documentation / testing / vscode setup etc might be better as its own change(s)

Can you screenshot what you mean about the 'unauthorized repository from my fork'? I didn't do anything special with this repo but maybe a HACS maintainer or other user got it listed somehow? (I know HASS always flags this as third party because its not been an official addition)

Oh, the pre-commits fail :-)

[XD-Builder]

@krbaker, thank you for your feedback.

1. I can definitely help as I own two systems and have the incentive to make the monitoring better, consistent and trustworthy. However, I would have some learning curve to do working on the community issues.
2. I have been vibe-coding to resolve the multi-location issue, while diving deeper into the code in this repo over the last weekend. Now I looked deeper into the generated code and reflected on my experience with interacting with SunPower Integration interface, I believe the root cause is the init.py caching the previous sunpower monitor response data (https://github.com/krbaker/hass-sunpower/blob/main/custom_components/sunpower/__init__.py#L267-L268). My assumption is when there are two monitors updating at the same time, it returns the previous cached data, leading to conflict. My change adds an entry_id key to the key instead of the global key, leading to the resolution of the conflict and the retrieval of fresh device data per location instead of from the same cache. Thus, my change can probably be simplified to include just this specific change.
3. For sure, if you believe my reasoning on item 2 is good, maybe I can spend some time tomorrow to code and test it. The VSCode debug and test do work. I can CR a multi-location fix, testing, documentation in three separate CR to make it clear.

it's not the unauthorized repository but because my repo fork is not registered with HACS. I just learned that after your feedback. So keep this repo up-to-date is probably the best route for community users. I will be careful with the next PR request to ensure pre-commit hook passes.

[krbaker]

Merging this into a branch so I can keep commits as XD-Builder so I can make suggestions