Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] DPL inverter set/get compensation #1314

Open
gitisgreat2023 opened this issue Oct 8, 2024 · 2 comments
Open

[Request] DPL inverter set/get compensation #1314

gitisgreat2023 opened this issue Oct 8, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@gitisgreat2023
Copy link

gitisgreat2023 commented Oct 8, 2024

Is your feature request related to a problem? Please describe.

See the issue in this discussion. In DPL, when the set limit value for the inverter doesn't match the actual value, the target value isn't reached.

Describe the solution you'd like

A set/get compensation for each inverter.

Describe alternatives you've considered

I implemented a set/get compensation in a Shelly script, added the difference between the set limit and actual produced inverter power. Every 5 seconds I update that value, thereby avoiding oscillations due to the response time of the inverter setting a new limit. This solution works perfectly fine now for four weeks, applying it on two inverters individually working parallel on a shared battery.

As I currently anyway already need the Shelly script to distribute the power on the two inverters, I'm happy with my current solution. But others could profit from having it available in OpenDTU-OnBattery itself, for example if there is for some reason an asymmetry in the inverter strains (not equal cable lengths etc) which typically causes a set/get mismatch.

Additional context

The DPL convergences to the target value if and only if the get (read) value from the inverter is indeed accurate. If for example cable losses between the output of the inverter and the meter are substantial, the target value won't be reached accurately.
I also didn't change the 5 secs over the 4 weeks period, it might be for these relative small changes (say max 100 W) the timescale the inverter reacts is shorter. I didn't study that.

@gitisgreat2023 gitisgreat2023 added the enhancement New feature or request label Oct 8, 2024
@schlimmchen
Copy link
Member

Do you agree that the offset should be in percent of the current limit?

When coding the support for multiple inverters, I thought about this already. It would be nice if the DPL learned, for each DPL inverter instance, whether or not the AC output matches the limit closely or not. If not, the relative difference could be recorded for a pre-set time or number of updates or until a range of limits was set, and then that difference could then be taken into account for future calculations. Does that sound reasonable?

@gitisgreat2023
Copy link
Author

No, I would go for an absolute correction. But yes, you're reasoning is exactly like I implemented it! Just add the set/get difference to the DPL value that is going to be set. I'm running now this scheme on two inverters since almost two months. My implementation uses absolute values. However I box this compensation with a max(min(delta,250),-250). I also update the compensation value only every 5 secs, to avoid oscillations.

For beta testing you could implement it say, with the 5 sec update frequency and box it to say +-75W and wait for the testers feedback.

To be honest I see sometimes a kind of oscillation with the charger and inverters going on/off. That happens a sometimes and then it catches itself. So some finetuning is probably still required, I run it with aggressive settings (every 0.9 sec the shelly updates the values), power meters and DTU are read out every second. That can be due to one of these factors, too lazy at the moment to chase it down.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants