Inverter power lagging reported limit by 100W [HMT-2250, Pylontech US5000)

[gitisgreat2023]

OpenDTU-on-Battery 2024.06.03
HMT-2250, Pylontech US5000 setup.
Over longer timeframes (15 minutes) the inverter power lags the set and reported limits from DPL by about 100-200W. I know that for example the HMS-2000 also is lagging at low (<15%) powers, but here it happens over the whole power range (200W up to 2250W).

The kWh inbalance over the 6 inputs up to now is small, they have the same cable lengths. Normalized to the mean, the inbalance is 98-101%. The RF connection is excellent.

Has anybody experienced something similar? What could be causes for this behaviour?

[schlimmchen]

they have the same cable lengths

This would have been my first guess. My second guess is that the resistances from the inputs to the battery are still slightly different due to different crimping quality of the MC4 connectors or other factors like not perfectly tight screw clamps. See the wiki (last picture and the text around it) for my experience with this, Manos copied it there.

There might be other causes, but I would double-check the wiring, even though you took care that the cable lengths match.

[gitisgreat2023]

I reconnected all cables (disconnect and connect again the MC4) and all wirings to the busbar. Tomorrow I'll be able to test.

Just a thought: the whole issue popped up because the DPL didn't manage the grid power to 0 though I would expect it to do so.
Should it actually be the case, that it increases the limit until the target value (let's assume it's 0 W) effectively is reached?
The grid power value stayed over minutes at 100-200Ws, while the Inverter Total power varied more than 200W, so the inverter could reach higher values such that the grid power would be close to 0.

In case it should converge under all circumstances to the target value: what kind of log would you need such that I can clarify the issue?

[schlimmchen]

Currently, it does not converge. The current output is subtracted from the power meter value if the inverter "is behind the power meter", but then we only calculate with limits.

Funny that you'd ask, because as a side effect of my current effort to support multiple inverters, this will change fundamentally (assuming that my approach works at all). Let's talk about it once there is an MVP.

Until then the DPL will calculate the same limit over and over again for the inverter, but if the inverter does not produce as much, this difference just has to be accepted.

[gitisgreat2023]

Okay that's interesting... I was involved in the "multiple inverters" Shelly script effort. There the Shelly provides virtual powermeters on which up to 5 OpenDTUonBatteries can regulate. There inverters[0].AC[0].Power.v is used to extract the current inverter powers.

A "simple" fix here for the DPL algorithm, which would results in convergence, would be to use the actual inverter output and the limit is then only a means to change this inverter output. Right? Would that work? What would be against that approach? Was that already discussed here somewhere?

That would eliminate quite some other issue people have where the inverter power doesn't match the limit, for whatever reasons. Probably it would be a good idea to issue a warning when the difference is too large though.

[schlimmchen]

Would that work?

No, I don't think so. That's because the whole approach would need to change from "let's calculate the expected output for the inverter and set that as the limit" to "let's calculate the expected output for the inverter and then look at the inverter's actual state, calculate the difference we would need to achieve in output, and increase (or decrease) its limit accordingly".

That's not a simple fix ☹️

[gitisgreat2023]

Every time it reports the actual inverter power, the difference to the limit can be calculated. Both are reported in the log. This difference can then be added to the amount that's going into the new limit calculation.

The only caveat I see is that with the limit close to the starting threshold, that delta shouldn't be added. Though I'm not sure whether the reported value in the GUI is really the actual value. For example if it says "Current Limit" 60 W (4%), and the total inverter power is 0.0 W, is the actual limit value from the inverter really 60 W?

Anyway, it could be coded in the Shelly script as well... there the delta is available as well. It doesn't matter (well apart from an increased time delay) whether I do it in the shelly script or it is done in the DPL loop. That could provide a proof-of-principle.

Funny that you'd ask, because as a side effect of my current effort to support multiple inverters, this will change fundamentally (assuming that my approach works at all). Let's talk about it once there is an MVP.

Apart from that you made me really curious with your teaser.... :-)
What does fundamentally change? Happy to talk about it already now... ;-)
Unfortunately I won't be able to test it, I have two OpenDTU-OB to a single battery, because currently the Huawei can't be combined with the CMT2300A (and with the NRF). Well, the Huawei with CMT combination might come available but I'm not sure whether the full combination Huawei, HMT, HM, Pylontech will be as well in the near future. So I have a Board with Huawei and NRF24L01+ and a Board with a CMT2300A (both read out the Pylontech using a Y Lan splitter). And the Shelly script provides the cascade virtual power meters for both.

[schlimmchen]

Sorry, I can't follow you. That is partially because I simply don't want to change anything in the DPL right now, as it means I have to rebase my work onto it...

Happy to talk about it already now... ;-)

Are you on discord?

I'm not sure whether the full combination Huawei, HMT, HM, Pylontech

Huawei is SPI, NRF24 is SPI, CMT2300 is SPI, so no, as long as we can't manage to share an SPI bus among peripherals, that combination is not possible as only two SPI hosts are available for peripherals.

[gitisgreat2023]

That's fine, I'll go for the proof-of-principle using the Shelly... and just show the results.

No, I don't use discord... but happy to join. Which channel is that discussed? (never used it, so no idea whether that's the right question ;-))
What's the reason discord is used additionally to github? Just because its more a chat like environment?

[schlimmchen]

What's the reason discord is used additionally to github?

I only joined the moving train, I never set it up.

Just because its more a chat like environment?

Yes, and it supports direct messaging.

The link is at the bottom of the Doku Home Page.

[gitisgreat2023]

I implemented the compensation of the limit-power mismatch in my Shelly script this morning. It was two lines, one to extract the current absolute limit and one to add the difference of the current limit and current power to the power meter output. A quick on/off switching of a water cooker + hair dryer test didn't derail my cascade setup with this compensation active, so doesn't look that bad. I will let this version run a week or two to be able to report back on its stability & whether it gives rise to unwanted behavior in practice.

[gitisgreat2023]

@schlimmchen
My code ran for a about 3 weeks 24/7 without issues.
What issue solves this code?
If the inverter limit is set, for example to 180W, but it delivers only 160W, there's a mismatch of 20W which is not further regulated to 0W.
My modification takes care of that by added this difference to the actual power reading, thereby tricking OpenDTU-on-Battery to regulate it indeed to the target value (of say 0W).

As I already mentioned it before I implemented it in a Shelly script, that runs anyway because it delivers power meter readings for a cascade of two inverters.

For each inverter I keep track how often the power meter reading is produced, I allow for one set/get mismatch compensation per 7 seconds. Otherwise I expect it to start to oscillate back and forth, didn't test it though, it ran 3 weeks with this 6 sec timescale.

Counters to book keep.

// factor to influence the waiting till the next call for NetPower and InverterPower
let DELAY = 0.9;

// Counter for the number of updates on the inverter
let COUNTER = []; 

// Settling time inverter, at this timescale difference between set and get are most probably constant
let COUNTER_CHG = Math.round(6/DELAY); 

// Difference set limit and actual produced power, after settling time
let wr_set_get_mismatch = [];

Compensation term, boxed by 250W max compensation (kind of arbitrary number).

if (newPower != 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] = 1*Math.max(Math.min(newLimit - newPower,250),-250)    	
			COUNTER[index] = 0;
		}
		limitedPowerMeter = limitedPowerMeter + wr_set_get_mismatch[index];
	}	

Of course it would be much more elegant to have this in OpenDTU(onBattery) native, maybe as an option "Set/Get Inverter mismatch compensation" active yes/no.