Open schlimmchen opened 1 week ago
Hi @schlimmchen suchst du weiterhin nach [Tersters]? (ich habe eine Test-Installation mit 2-3 Hoymiles online).
Naja, jetzt ist die Katze ja aus dem Sack. Unsere Nutzer werden das neue Release sicherlich ausprobieren und wir hΓΆren sicherlich, wenn es Probleme gibt.
Ich hab aktuell nur 1 wechselrichter und viel zu wenig Sonne.
Das Feature testen werde ich dann ab April 2025 π
Jesus! π± π± π± π± π±
π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯ π₯
following the discussions and inputs on discord, having 3 single phase inverters (2 PV, 1 battery) at my house, several rather high single phase loads and a limit of unbalanced loads of 3.7kW ..
if it were possible (and from what i read so far i assume it is) to make the DPL work 'per phase', i.e. having meter readings per phase and set 3 inverter(phase)s according to these, then this probably would make a lot of sense to have as a strategy. esp. for the setups people are using OpenDTU for.
arguments for preferring to use as little inverters as possible for efficiency reasons for sure are valid either, but i'm not sure this needs to be first priority with the small loads/powers the majority of users are dealing with in these setups.
my2c.
written it, went on thinking..
actually any strategy should prefer serving the most strained phase as directly as possible (so if phase 1 had a high load on and there's potential production there it should be used) to avoid unbalanced loads..
So you are advocating for a per inverter phase setting for A/B/C.
Here is the same request upstream https://github.com/tbnobody/OpenDTU/issues/1936#issuecomment-2441603583 and here discussion about it and references to more issues / threads https://github.com/tbnobody/OpenDTU/issues/1325#issuecomment-2272225548
@drahdiwaberl Your input is valuable, but I want to point out that you are mixing things here. This issue originally was about "how to I handle multiple inverters if multiple are eligible to fulfill the desired total output". That question in your scenario is only relevant if there are multiple inverters per group/phase/powermeter reading.
Right now I don't see that we will support assinging inverters to a group/phase but still allow to increase production in another group/phase to meet the total need. That would certainly have to wait until managing inverters per group/phase is implemented and works well.
I created #1428 to keep track of support for grouping of inverters per powermeter value.
Is your feature request related to a problem? Please describe.
The implementation merged in #1216 prefers to change the limit of those inverters which promise to implement the needed change in AC output with a single limit update. If none can implement the change in one go, the inverters are sorted by the contribution they can make to the required change.
This tries to make sure that the DPL reacts as quickly as possible.
This also means that the DPL is happy to put inverters online, but hesitant to put them into standby.
However, people objected that this can lead to less than ideal situations, where multiple inverters are online producing at less efficiency while less inverters could be producing at the same total power with higher efficiency.
Describe the solution you'd like
Without too much trouble, we could implement different strategies in the DPL. The respective function implementing a particular strategy would always receive a bunch of inverters as input as well as the desired change in output, and it would be responsible to determine which of those inverters are supposed to change their limit by how much.
Describe alternatives you've considered
No response
Additional context
I am happy to help implement different strategies and make them selectable (config switch, UI changes, etc.). If you think the DPL should implement a different strategy, please see https://github.com/hoylabs/OpenDTU-OnBattery/blob/61aa32ab5e5d0bfd876a4b008342c6b54f82d0d0/src/PowerLimiter.cpp#L546-L588 for inspiration and describe the method you would like to see the DPL using. The more technical (flow-chart, pseudo-code) and detailed, the better.