DPL: Design flaw causing unexpected limits to be set (only battery-powered inverters?)

[schlimmchen]

What happened?

@Sorbat kept nagging me that the DPL would not work as expected. I kept nagging for proof in the logs. We finally found it, see below.

The DPL calculates how much more or less power the inverters shall produce to achieve the desired total output. The change is then applied to a list of inverters, one by one, until it is expected that the inverters will match the expected output.

However, the diff is calculated based on the inverter's actual output, whereas the diff is applied based on the inverter's current limit. If the actual output and the current limit don't match, which can indeed happen even for battery-powered inverters, the new limit will be way off.

To Reproduce Bug

Somehow cause the actual inverter output to be significantly different from the current limit and this issue will present itself.

Expected Behavior

The DPL must somehow take into account that the actual inverter output can be significantly different than the current limit.

Install Method

Pre-Compiled binary from GitHub releases

What git-hash/version of OpenDTU-OnBattery?

2025.01.23

What firmware variant (PIO Environment)?

generic_esp32s3_usb

Relevant log/trace output

[DPL] up 97 s, next inverter restart at 38551 s (set to 0)
[DPL] battery interface enabled, SoC 68.3 % (used), age 0 s (valid)
[DPL] BMS: 53.01 V, MPPT: 53.00 V, inverter 114494803536: 53.10 
[DPL] battery voltage 53.01 V, load-corrected voltage 53.01 V @ 1 W, factor 0.00100 1/A
[DPL] battery discharge restricted, start 55.20 V or 80 %, stop 52.00 V or 20 %
[DPL] full solar-passthrough dormant, start 56.00 V or 100 %, stop 54.00 V
[DPL] start NOT reached, stop NOT reached, solar-passthrough enabled, use at night disabled and dormant
[DPL] total max AC power is 800 W, conduction losses are 3 %
[DPL] targeting 10 W, base load is 50 W, power meter reads 474.5 W (stale)
[DPL] requesting 50 W from 0 solar-powered inverters currently producing 0 W (diff 50 W, hysteresis 2 W)
[DPL] battery allowance is 0/0 W DC/AC, solar power is 26/23 W DC/AC, requested are 50 W AC
[DPL] requesting 23 W from 1 battery-powered inverter currently producing 1 W (diff 22 W, hysteresis 2 W)
[DPL] will cover 76 W using 1 battery-powered inverter
[DPL inverter 114494803536]:
    battery-powered, producing 1 W
    lower/current/upper limit: 26/54/800 W, output capability: 800 W
    sending commands enabled, reachable, eligible
    max reduction production/standby: 0/1 W, max increase: 746 W
    target limit/output/state: 76 W (update)/76 W/production, 0 update timeouts
    MPPTs AC power: a: 1 W b: 1 W
[DPL inverter 114494803536]: sending limit of 9.5 % (76 W respectively), max output is 800 W
[DPL] waiting for a start/stop/restart/limit command to complete

Anything else?

No response

Please confirm the following

• I believe this issue is a bug that affects all users of OpenDTU-OnBattery, not something specific to my installation.
• I have already searched for relevant existing issues and discussions before opening this report.
• I have updated the title field above with a concise description.
• I have double checked that my inverter does not contain a W in the model name (like HMS-xxxW) as they are not supported.

[schlimmchen]

Options

Stop caring about the inverter's actual production

This would mean we have to calculate the diff based on the inverter's current limit.

Issues (assuming a stable power meter reading):

• If a battery-powered inverter does produce more or less than its current limit, which is possible, the DPL will calculate that no adjustment is required, as the inverter's limit is already set to the expected value that would allow to compensate the household consumption.
• For solar-powered inverters this completely falls apart, especially if overscaling is involved.

Stop caring about the inverter's current limit

DPL says "please produce xW more power". Inverter says "alright, since I am currently producing aW of power, I am going to set a new limit of a+xW".

Issues:

• If the inverter has a limit set at bW, but it only produces b-xW of power (x > 0), assuming the household consumption is stable, the inverter will always lag xW behind what is needed to compensate the household consumption, even though we could increase the limit and would probably be able to nudge the inverter to produce the amount of power we actually want from it.

We could assume that nudging occurs eventually as the household consumption is not stable anyways.

We could also implement some sort of integral part "I" as in "PID algorithm", where the difference between the setpoint and the current value is integrated over time into the new limit. I guess this is the best approach. Unfortunately, from experience, I am no good at this. Maybe AI can help me out to come up with something reasonable.

[SW-Niko]

The DPL must somehow take into account that the actual inverter output can be significantly different than the current limit.

That's for sure. The good news are: "Were are several ways out of this issue"
Let me finalize my thoughts before I post the options.

[SW-Niko]

I would recommend using 2 different methods to regulate battery powered inverter.

Method 1:
Calculate and set a delta limit value from the delta of the power meter. Example: If the target is 0W and the power meter measures 30W then increase the limit by a delta of 30W regardless of the current inverter limit. (The inverter AC values ​​are not used).

Method 2:
Simply set the limit value (without inverter AC values ​​and delta calculation). Example: 100W is required and this is simply set as a inverter limit.

At first glance, this may sound contradictory, but I will explain why I think this is a good compromise.
In terms of control, I leave all other factors out of the equation (time, I-components, D-component) and limit myself to the so-called control deviation, i.e. the P-Component of the loop.

First, a few basic considerations of the situation. The P-Errors that come from the inverter can be reduced to:

• The inverter AC measured values ​​are not correct.
• The transfer function from the control value “limit” to the AC power value is not linear.

Both problems interfere with the control loop. If you regulate according to the limit, then you have to live with the transfer function error and if you regulate according to the AC value, then you have to live with the AC measurement error and with the error of the transfer function.

But if you regulate according to the power meter, then the two P-Errors from the inverter no longer play a role, because they are automatically corrected when method 1 is used.
We dependent now on the measurement accuracy of the power meter, but all P-Errors in the control loop to the power meter are recorded and corrected. It does not matter where the P change comes from. Change in consumption, or error in the transfer function.

That changes, the moment, we no longer regulate according to the power meter. That is, when any power limits come into effect. For example, the lower or upper DPL power limit, but also other "limits" such as surplus power or battery limitations. Then the power meter is no longer part of the control loop. Now method 1 is problematic because both inverter P-Problems come into play.

That's why my proposed solution is: If the power meter is in the control loop, then use method 1. Otherwise, use method 2.
In other words: As long as the power meter is in the control loop, we get the accuracy of the power meter and otherwise the accuracy of the inverter transfer function.

Just for the sake of completeness, I want to mention that there are other solutions. I've been trying to find a slightly more complex solution for a few weeks and it looks like this: I've eliminated both inverter problems. I replace the inverter AC measurement with an additional external AC measuring device (Shelly) and I correct the non-linear transfer function of the inverter using a transfer correction table.

@schlimmchen, If I understood you right. "Stop caring about the inverter's current limit" is identical to "Method 1"

[gitisgreat2023]

See also this potential new feature.
I use it now since months with a script on my Shelly device, works like a charm.

@SW-Niko @schlimmchen
I also use a Shelly as power meter. My solution runs on the Shelly as a script and is very simple and works perfectly since many months.

The two core parts: calculation of the mismatch
// Inverter set/get mismatch compensation if (newPower != 0 && huaweiPower[0] == 0) { COUNTER[index] = COUNTER[index] + 1; //print("Index: " + index + " Power:Limit " + Math.round(newPower) + ":" + Math.round(newLimit) + " delta: " + Math.round(newLimit - newPower)) if (COUNTER[index] % COUNTER_CHG == 0){ wr_set_get_mismatch[index] = Math.round(Math.max(Math.min(newLimit - newPower,250),-250)); //print("WR"+index+" set/get comp: "+wr_set_get_mismatch[index]) COUNTER[index] = 0; } limitedPowerMeter = limitedPowerMeter + wr_set_get_mismatch[index];

Getting the data via mqtt:

body = JSON.parse(result.body); newPower = body.inverters[0].AC[0].Power.v; newLimit = body.inverters[0].limit_absolute;

@schlimmchen Since yesterday I switched to two inverters on one board, so I use your parallel DPL version now. (don't ask, after replacing the 4MB ESP32 with the 8MB ESP32, I can't get connection to the HMT anymore! Tried everything, swapping RF modules etc, no idea why its broken now. I'm a bit sad...).
I have to rewrite part of the code and then test it, but it should work as well as it does now. Instead of correction two inverters separately it will be a single correction for the both inverters combined.

Edit: done implementing the shelly script for the parallel DPL version, see details here.