Code Fix for breaking changes

[AndrewTapp]

I'll start off with an apology, I've no idea how to use GitHub to incorporate these changes into this project!!

Given the issues over the last couple weeks, including the current breaking change, I've got everything up and running on my setup, amending these files init.py, config_flow.py and sensor.py

init.py
config_flow.py
sensor.py

I've also amended solaredgeoptimizers.py and included it within the same folder as the above files so that it doesn't pick up the HomeAssistant site package hidden within the operating system (and would be overwritten when a new release is installed).

solaredgeoptimizers.py

Hope this helps and happy to do this properly given appropriate instructions, or if someone else wants to incorporate the changes!!

[Mariusthvdb]

great.
it would be helpful if you could comment the actual changes in the files.

given your opening 'apology' ( ;) ) I take it you didnt 'dev' the changes in a forked repo? Suppose that would be the most productive way going forward.
Having to edit these files manually each and every update would be unfortunate. If you'd fork and share, we can point Hacs to it, and updating would be a breeze.

[AndrewTapp]

Many thanks for your comment, will have a go to try and create a fork shortly.

[AndrewTapp]

Have managed to create a fork and pull request with my changes, all commented now and a description of the changes.

Steep learning curve, wow!!

https://github.com/ProudElm/solaredgeoptimizers/pull/109

Hopefully all's good now, please advise anything else I need to do?

[Neo8101]

Thanks, that works perfect.. Just replaced all files with your files and could use the old entities again. Great Work, thank you!!!!

[GenMurdock]

Big thanks for rewriting this ... it is working again.

[kaijk]

Yes, thank you. All I could find was that r.text contained a bunch of HTML and no data. I was stumped.
@ProudElm , This is a PR worth merging, or changing slightly if you want solaredgeoptimizers.py to remain in PyPi.

[AndrewTapp]

I've made some further changes to this pull request to split out sensor.py into coorinator.py & sensor.py and now includes the UTC changes made in https://github.com/ProudElm/solaredgeoptimizers/pull/97

[JochenGr]

Thank you very much! Great work. Now all fixes are summarized in one repository.
I have changed the optimizers repository in HACS to your fork.
Many thanks also to @RichieB2B for the solution with the changed endpoints (ProudElm/packaging_solaredgeoptimizers#13).

[kaijk]

Good to go again!

[clanic70]

Genius, thanks a lot! I was struggling with AI to found a solution or workaround for days, but nothing to do!!! This the clear demonstration that human beings are much better of any AI 💪👍👏👏👏

[Schlichi83]

THANK YOU very much! Everything working again as it should.

[Mariusthvdb]

sweet, good to see the reports this is behaving again ;)

mentioned before, but we really should be checking the Fork Bdraco did of this CC. That has optimized the inner workings of the component, and the update coordinator. reduce_executor_usage.

this is the actual PR he did main...bdraco:solaredgeoptimizers:reduce_executor_usage

it was necessary because this CC caused serious issues in the system.

wondering if the logger doesnt show that with the original, and now this code fix (that has not yet integrated the Bdraco improvements)?

[Mariusthvdb]

I do fear this integration , just like its original, causes this problem

It has been a continued topic in the HA fora, finding causes for this effect.
Ultimately bricking the instance if descriptor count gets too high.

Not caused by this update though, even Bdraco's version did that

[AndrewTapp]

Can't promise anything, but I'm happy to take a look later.

[Mariusthvdb]

great, for some background see https://community.home-assistant.io/t/2025-11-pick-automate-and-a-slice-of-pie/947908/337?u=mariusthvdb

which itself points to the OS discussion on the subject: home-assistant/operating-system#4166 (reply in thread)

Note: I have to rule out one other integration too for the file descriptors issue. But given the exceeding numbers always, well almost always, happen during the night, that would seem a logical time frame for this integration to hiccup.