Dynamic Power Limiter - unplanned behavior? Bug or my fault?

[OlSteph]

Hello,

i have the DTUonBattery with 2 inverters - one HM-600 is permamently at 100% and the 2nd Inverter HM-1500 is set as to limit.
No Battery is connected (i have no Battery System yet - maybe later)
Here are my Settings:

The Problem is - sometimes - like today with the washing machine heating and the Limit goes to 100%, after the heating the limit stays there and after a "long" time the limit is set correctly, but to Late.

When it is not my mistake, how can i "debug" od analyze this to maybe help to fix this.
If this is an Bug / Error i woult open a Issue.
Thank You

[spcqike]

how does your opendtu gets the reading if your mains meter? have you connected boths inverters to the same DTU?

if this happens again, you can check and monitor the konsole in webgui

there should be total power readings

and power limiter readings

[spcqike]

can you see how frequent the total power reading (powermeterclass) is updated? it should be updated every 10s, unless you changed it in your config.

also, yesterday i changed my setting to yours. so i switched off solar-passtrough. this morning, my inverter was stopped from DTU.
(i have a HM-600 only, without battery. battery voltages and SoC set to 0, and, of course, other power limits than you :D)

for me, dynamic limiting without a battery only worksflawlessly, if i have solar passtrough enabled. but, other than you, my problem is that it stops the inverter at all.

maybe you can try this, too.

[OlSteph]

At the moment it is working right, i will let the konsole open and check later - the situation ws eralier today but i wasn't on the pc at that time.

here is an actual log

[OlSteph]

it happened again:

For tomorrow i will test solar passtrough on.
The Symptom that the inverter ist stopped sometimes comes here to, then i had to restart the inverter to get it on again.
Bit i tought that there is already an issue somewhere for that

[spcqike]

I guess this occurs because of your high hysteresis. Insist possible that your new target voltage (after your high load) is smaller than your 200W hysteresis?

The line can be found here
https://github.com/helgeerbe/OpenDTU-OnBattery/blob/master/src/PowerLimiter.cpp#L261

You can try a smaller hysteresis. But, if it’s really the root cause, it could happen in any situation where you get a smaller load, I guess.

Edit:
As I see all your new limit targets are >200W. Is it possible that you can’t dynamically limit the power to 0-200W?

My hysteresis is 15W, so 0-15W is nothing my limiter ever would set, as my consumption is at least 150-200W 24/7.

Edit:
Just tried set my hysteresis to 350W, so higher than my usual load. It started using the old limit value.

With a hysteresis of 300W, it calculated new values all over the place (every 10s), even so it only changed total value by 5-20W, as my real load changed.

I guess, the hysteresis doesn’t work as expected.

@helgeerbe how should hysteresis work? I thought it should be a threshold to only calculate new values of the change to the last set value is greater or smaller than hysteresis. But that’s not how it works right now. Is it?

[helgeerbe]

@helgeerbe how should hysteresis work? I thought it should be a threshold to only calculate new values of the change to the last set value is greater or smaller than hysteresis. But that’s not how it works right now. Is it?

Your are right. But there was a complete refactoring of the old code lately. So there might be an issue.

[MalteSchm]

@OlSteph
It could be that the specific combination of values triggers a bug. You could start trying to set the upper limit to a value that the inverter can actually handle. (change the 1695W to 1500W). This is anyhow a good idea.

The other option is to set the "angestrebter Netzbezug" to 0W for testing

[OlSteph]

@spcqike
I let solar passtrough enabled this mrning for test purpose and deactivated it later:

@MalteSchm
This is the Graph so far (see above) - with this settings starting around 11:00 :

I have played around with the upper limit, because of the strange behaviours of the hysteresis - at first i have set to 1500.
(or should it be set to the total-upper limit of all inverters - which would be 2100w ?)

[spcqike]

Can you plot your power consumption? Like grid_import + pv_production? Is it possible that your power consumption wasn’t higher than 200W until 11.00? (And if it was was it long enough so that the opendtu could recongnize it? Like 10-20sec at least?)

11.00 you changed your Netz Bezug and hysterese to 0 and 30, right?

Afterwards the limiter worked. Or?

IMO upper limit doesn’t matter in this case as, regardless what power limit gets calculated within the processs, at the end it’s maximum will be set to your inverters hard coded maximum (if the calculated target power is higher than what the inverter can do)

Need to check this in the code but I think the Lower and upper limit are used before the calculation of the real limit.

[MalteSchm]

The upper limit should be set to the max power of the inverter that is controlled by the power limiter. In your case that is 1500W (max)

[OlSteph]

@spcqike
do you mean this? above is grid import and export, the upper picture is pv prodiction (both inverters) - marked 4 are the HM-1500
the lower are detailed plots from the panels

"11.00 you changed your Netz Bezug and hysterese to 0 and 30, right?" -> around 11:45

"Afterwards the limiter worked. Or?" Yes

The whole day (yesterday)

The little Peaks later should be "normal" - when high loads end insttantly then the few seconds hing export till the power limiting happens. (in my opinion)

[OlSteph]

the problem with the powermeter values here - they have steps each 1 minute only, therfore i cannot go to 10 sec.
This is the other inverter - the HM-600:

around 9 at 340W

The HM-1500 around 9:00 was around 600W

The powermeter said -814W at that time

This should mean than an this moment the consumption was 600+340-814=126Watts (normal power usage here if nothing is turned on like TV, PC etc)

[spcqike]

yes, and thats what i meant.

you have ~126W real consumption. in addition you produce ~344W with your HM-600.

this should result in a grid meter reading of -218W. assuming, that there are small timing differences and some difference while reading and calculating, it is possible that your HM-1500 got a grid meter reading of slightly under (or over?) -200W, so -195W or something. (in this particular timestamp: 9.00 am)

your old setting was target -200W, hysterese 200W.

if i am right, and the hysterese is used wrongly, your inverter wont change its powerlimit target if your grid meter reading is inbetween -hysterese < 0 < hysterese. thats what you showed in your screenshot "reusing old limit" #256 (reply in thread))

thats why i asked, if you can plot your "real" consumption ("real", because it must be the allready reduced consumption because of your always producing HM-600). i guess, its always within -200<0<200 W more or less (small timing differences, like mentioned above can occur. but the total meter reading shound't be <-200 or >200 for like 20-30 sec, otherwise it should have re-set the powerlimit of your HM-1500)

the relevant part in the code is to be found at
https://github.com/helgeerbe/OpenDTU-OnBattery/blob/master/src/PowerLimiter.cpp#L271

so, i guess thats a bug that happens, when the inverter is behind the powermeter.

i also see, that the hysterese is ignored. at least in the way, i thought it would work.

i thought, with a target of -20W and a hystrese of 20W, it would reuse the old limit as long as the powermeter reports a value between -40W to 0W. but, my powerlimit is changed every 10s, even when the powermeter only changes by 1W

[helgeerbe]

i thought, with a target of -20W and a hystrese of 20W, it would reuse the old limit as long as the powermeter reports a value between -40W to 0W. but, my powerlimit is changed every 10s, even when the powermeter only changes by 1W

This seems indeed to be a bug. I will check this.

[spcqike]

i also tried to wrap my head around this.

unfortunately i don't know how to create two PRs, as my first is still open :) so if i also change the hysterese, this PR would include the changed powerlimiter. How can one create a second, independent PR?

my solution would be something like store the newPowerLimit as a newly created _lastPowerLimit (right before return newPowerLimit) and check if newPowerLimit - _lastPowerLimit is within hysterese.

edit:
in my fork i simply changed acPower to int32_t and keep it out of the if(), so one can later check if(newPowerLimit-acPower) is out of hysterese, which seems to work.

int32_t acPower = 0;
    if (config.PowerLimiter_IsInverterBehindPowerMeter) {
        // If the inverter the behind the power meter (part of measurement),
        // the produced power of this inverter has also to be taken into account.
        // We don't use FLD_PAC from the statistics, because that
        // data might be too old and unreliable.
        acPower = static_cast<int>(inverter->Statistics()->getChannelFieldValue(TYPE_AC, (ChannelNum_t) config.PowerLimiter_InverterChannelId, FLD_PAC));
        newPowerLimit += acPower;
    }

    // We're not trying to hit 0 exactly but take an offset into account
    // This means we never fully compensate the used power with the inverter 
    // Case 3
    newPowerLimit -= config.PowerLimiter_TargetPowerConsumption;

    // Check if the new value is within the limits of the hysteresis and
    // if we can discharge the battery
    // If things did not change much we just use the old setting
    if ((newPowerLimit-acPower) >= (-config.PowerLimiter_TargetPowerConsumptionHysteresis) &&  
        (newPowerLimit-acPower) <= (+config.PowerLimiter_TargetPowerConsumptionHysteresis) &&
        batteryDischargeEnabled ) {
            MessageOutput.println("[PowerLimiterClass::loop] reusing old limit");
            return _lastRequestedPowerLimit;
    }

but of course only when target is reached.

in 1 and 2, there is a lot of changing, even so the target is reached, after the change, in 3, it uses the same PowerLimit value without changes.

[helgeerbe]

had the same idea. Will push it into development in a minute.

[helgeerbe]

Should be fixed with 2023.06.12