DPL: Honor battery-provided discharge power limit (including UI adjustments)

[AndreasBoehm]

Based on the great work from @ranma!
Base: #1198

Additions

• add UI to configure limit manually
• add toggle to enable/disable the use of the battery (bms) provided limit
• add support for discharge current limit for MQTT battery provider
• show live view for MQTT battery when discharge current limit is present

MQTT Battery Provider	Other Battery Providers	MQTT Battery Live View

[spcqike]

One question after a first glance:
How does the manual limit fit to the BMS value? The hint says it’s a fallback. So I guess the BMS value has greater priority, even I f it’s higher than the manual value?
so a manual limit of like 10A won’t work, if the BMS reports 25A?

[AndreasBoehm]

Good catch @spcqike, i need to update the hint text.

Whatever limit is lower will be used

min(bmsLimit, userLimit)

[AndreasBoehm]

Screenshots updated

[AndreasBoehm]

We will now also show a live view for MQTT batteries when the discharge current limit is present.

[schlimmchen]

Some nitpicking to annoy you 😉

[schlimmchen]

Github did not manage to detect that the first commit is merely already on development. I had to rebase manually. This set me as the committer, which I don't like and wasn't my intention. After a quick Internet search it seems this is tedious to avoid...

[AndreasBoehm]

Dont worry about having my name on a commit.. its alright.

after a rebase we will be both mentioned in the commit, thats fine for me

[schlimmchen]

Interesting. "Squash and Merge" cleaned it up the way I wanted it to. Guess "authored by and committed by" is only ever a thing when pushing from the CLI? Don't know for sure. Glad that this turned out well 😉

its alright.

Thanks!

[spcqike]

@AndreasBoehm after following #1236, i thought...maybe it's good to also introduce a mqtt topic, where the user can set a "soft discharge limit" on its own. soft, as not persistent and only applied, when provided via mqtt or whatever, but available for all providers.

right now, we can set a fixed and persistent default current. we than have the battery provider, who "overwrites" the default limit (only if its lower). so an on-the-fly, self-defined lower limit only works for MQTT batteryprovider, and not for VE or CAN.

do you think, this is needed or usefull at all? (the same applies for DPL max limit, which can only be set persistant right now, can it?)

[AndreasBoehm]

Could you describe a scenario in which this soft limit would be needed?

[spcqike]

if you try to manage a weather forecast charging, somehow (which needs to be done external in IOBroker, HA, Node-Red, ..). like if you now, that the next days will be very cloudy, you won't charge your battery to 100% and you would like to limit discharge current (or inverter output in general), to not more than X, to keep currents and losses (as power losses increase with increasing currents) small, but still provide your basic load.

iguess, i would limit my system to ~ 400W in such cases.

or, if you want to charge your EV, but don't want to empty your battery. so you would just throttle or limit battery discharge to 0A, can still use PV for charging. but just "soft", without writing to persistant memory.

[AndreasBoehm]

hmm, for me this does not sound like a feature that brings a benefit besides the possibility to be in full control. If i use the energy of my battery within 2 hours or 12 hours doesn't really make a difference imho.

If you want to limit the charge of your EV to PV power only this should be done on the charger side, limiting it to the value that your inverter or solar charger provides.

[spcqike]

If you want to limit the charge of your EV to PV power only this should be done on the charger side, limiting it to the value that your inverter or solar charger provides.

thats not wrong, but its complicated and not easily doable.

its easier to say "ok, we charge the car, stop using the battery for now" and "finished / unplugged, use the battery again" (to commands, set current to 0 and back to whatever you want) and let openDTU-oB handle all PV production on its own, instead of creating another controlsystem that checks the available PV power and controls the wallbox all the time. its just another loop with its problems and disadvantages.

and, not all chargers are remotly controllable. like my "stupid" charger, where i can pre-set a current beforehand, but i can't change it, after charging started.

If i use the energy of my battery within 2 hours or 12 hours doesn't really make a difference imho.

it does make a difference. A little bit a difference. P=UI. Emptying the battery within 2 hours instead of 12 means 6 times more power losses, doesn’t it?

As an EV will most likely empty all consumer battery’s, IMO it would be good to disable battery discharge without writing to persistent memory.

But the whole point was just an idea and wanted to discuss (:

I know that all this is more a tasks for an HEMS. So I guess I will check out what EVCC or openems can do with openDTU together (:

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.