DPL : Complete yoyo with B2500

[leoai-81]

With DPL enabled since last release(or previous), the algo goes in yoyo mode and overreact... Setting a slower DTU send value does nothing to mitigate the issue.

Has anyhow seen the same issue ?

Thanks

[AndreasBoehm]

Settings and Logs please

[leoai-81]

Will be attached once available at next occurrence (wasn't activated following hard reset unfortunately).

I guess I have pinned the issue to the following: The DPL algorithm scales depending on the updates received by the meter and not its own clock.

So whenever the system takes too long to react (which is the case with external batteries) and the clock of the meter is too fast to reflect the change on the next tick, then the DPL overscale, thus the yoyo.

Context:
bitshake tasmota: 1 second clock
openDTU: DTU with 1 second clock.

• There and important... Setting a slower DTU sendout does nothing as the DPL algo seems to calc a new value on each meter update and sends the lasted calculated to DTU.
• DPL calcs and -over-scales on each value coming from meter no matter what (not bounded to internal clock, not bounded to DTU sendouts).

marstek b2500: needs a good 4 seconds to react

Result: you get a yoyo where the battery desperately tries to follow the setting from openDTU

Suggestion: Search into having an internal clock for the DPL and not something based on meter value update. Maybe a combo of both

Workaround: Slow down the clock of the meter to make sure new value sent reflects the battery output change.

[AndreasBoehm]

If you reduce the DTU interval the DPL will get slower as well, because without up to date inverter stats the DPL won't do anything.

I still need more details about your setup, please post screenshots of your batterie settings, powermeter settings and especially your DPL settings

[spcqike]

marstek b2500: needs a good 4 seconds to react

i thought that the battery is .... just a battery. can and do we control its output? i thought, its "open" and the inverter pulls as needed / set by its limit.

[leoai-81]

@spcqike it's not reacting "instantly" let say.

[gitisgreat2023]

Additionally: how do you measure grid power? I see Tasmota, you're using a Hichi IR readout? What polling interval?

[leoai-81]

bitshake tasmota, 1 second sendout via MQTT.

[gitisgreat2023]

First quick & dirty solution: set polling interval in opendtu-onbattery at 5 sec. Then the battery has reacted and it shouldn't oscillate anymore. Let us know whether that works.

[leoai-81]

I've now tried it, I do not think it is going to drastically help as it's the DPL algo which seems to behave so since it's been reworked (last or previous release?). Could be good to set the DPL on / off and give a bit more settings as suggested before.

I need to see how I can get logs of when the phenomenon happens.

[viking-1992]

Hello, I also have the above problem.
I operate an HM-1500 to which two B-2500 storage batteries are connected.
In combination with smartmicrosolar and openDTU, the control works very well. The update rate is 1 second.
If the HM-1500 is controlled by openDTU-OnBattery, there are very large jumps. If 2000 watts are permanently required, the DPL regulates between 30W and 1500 every second.

[viking-1992]

The poll rate is every second. At the moment it is still very stable & fast.

[leoai-81]

Didn't work for me... Still investigating. Was out of home on the timeframe.

Again this evening:

Happens whenever the DPL calculates a new value before meter reflects the "previously updated" consumption.

I'd suggest to leave the possibility to select the clock of the DPL...

[viking-1992]

After 8 hours of operation, the problem occurred again.
I disconnected the DTU & HM-1500 from the mains for 2 minutes and switched off the battery storage. Unfortunately this was not successful. At 200W house load the HM fluctuates between +35 and -40 watts.
I will try to read the error log with Putty tomorrow.
At the moment the system is running again via the SmartMicroSolar

[gitisgreat2023]

Didn't work for me... Still investigating. Was out of home on the timeframe.

Again this evening:

Happens whenever the DPL calculates a new value before meter reflects the "previously updated" consumption.

I'd suggest to leave the possibility to select the clock of the DPL...

Play with the update interval of both the DPL and power meter. Choose the latter twice as long as the previous.

[leoai-81]

Didn't work for me... Still investigating. Was out of home on the timeframe.
Again this evening:
Happens whenever the DPL calculates a new value before meter reflects the "previously updated" consumption.
I'd suggest to leave the possibility to select the clock of the DPL...

Play with the update interval of both the DPL and power meter. Choose the latter twice as long as the previous.

Indeed, that is the way to "workaround" the issue. I'm still wondering what would help long term:

• Setting to enable / disable overscaling ?
• Setting to set to which % of the needed power it will overscale ?
• Setting for the own internal clock of the overscaling algo to "kick in" ?

[viking-1992]

Thanks for the tip with „Stromzähler beinhaltet Wechselrichter“. I had deactivated this option during troubleshooting. Now it is activated again.
I have just set the controller to a continuous load of 2500W (kettle). It periodically jumps from approx. 1000W to 1500W.
The attached *.txt file from the console is not sufficient?

[AndreasBoehm]

The log shows normal operation, i need a log that is captured while the DPL is regulating up and down like crazy to understand whats happening.

[leoai-81]

So, I was able to get the issue reproduced.

Settings:

First occurrence:

opendtu-log-2025-07-04_18-52-15.txt

Small yoyo with no reason

Second occurrence:

opendtu-log-2025-07-04_19-02-38.txt

Don't mind the UTC setting of Grafana.

The increase of power is fine to some extend, but the reduction goes nuts... It just keep over-reducing below the current load...

[AndreasBoehm]

Minimum Power Limit should be at least 52, not 0. I will check the logs and come back to you.

[leoai-81]

Minimum Power Limit should be at least 52, not 0. I will check the logs and come back to you.

That does not change anything. It's set to 0 to avoid OpenDTU to shutdown the inverter while doing the yoyo.