Adding battery current limit to Huawei auto power control

[eu-gh]

Hi!

I've been using the combination of the Huawei R4850G2 PSU (with enabled auto power control based on power meter values) and a Pylontech US2000C battery for several weeks now, and for the most part, it has been working really smoothly. The only thing that really bothers me is the charge current limit as monitored by the battery's BMS.

Normally, this value is at 25A, which leads to a AC charger power of 1200-1300W. However, if the SoC passes 89%, the value is reduced to 10A, which is probably necessary to prolong the cell life.

Since the OpenDTU (at least in my case) is connected to both CAN busses and therefore has access to all these values, it should theoretically be able to combine them. So I tried adding the BatteryClass to HuaweiCanClass in order to get access to its values:

#include "Battery.h"
#include "BatteryStats.h"
[...]

        if (config.Battery_Enabled){
          MessageOutput.printf("[HuaweiCanClass::loop] config.Battery_Enabled is true, Battery_Provider %i \r\n", config.Battery_Provider);
          auto _batteryStats = std::make_shared<BatteryClass>()->getStats();
          uint8_t _batterySoC = _batteryStats->getSoC();
          MessageOutput.printf("[HuaweiCanClass::loop] _batterySoC %i \r\n", _batterySoC);
        }

It does compile and run, but the corresponding log output always tells me that the SoC is 0. which is less of a usable value and more of a testament to my limited/nonexistent C++ knowledge. I suppose the Battery class uses some kind of factory/singleton pattern which requires some specific syntax to use?

I would really appreciate some input on this by someone more knowledgeable than me 🧠

Thank you!

[schlimmchen]

std::make_shared<>() create a new instance of the respective object/class, here: BatteryClass. That's not what you want. You want to ask the one and only BatteryClass instance, which is in charge regardless of the actual battery interface. (That's technically a singleton, although the pattern is not actually implemented.) Access its stats by calling Battery.getStats() which returns a std::shared_ptr to the battery statistics, implemented by the actual battery controller in use. You don't care about those details, just use that std::shared_ptr which is always of the base type BatteryStats const and hence provides getSoC().

See src/PowerLimiter.cpp:289.

BTW: I don't understand what you are trying to achieve with the charger, I am only helping you get the SoC value through code.

[eu-gh]

Awesome, thank you! This works beautifully now.

Do you have another hint to get to the actual chargeCurrentLimitation value? I added:

class PylontechBatteryStats : public BatteryStats {
    friend class PylontechCanReceiver;
    public:
[...]
        float getChargeCurrentLimitation() const { return _chargeCurrentLimitation; }
[...]

to BatteryStats.h, but since my reference point in Huawei_can.cpp is BatteryStats and not PylontechBatteryStats class, it tells me that getChargeCurrentLimitation() method does not exist.

Nevermind, I'll simply add two new input fields (BatteryLimitCurrentAtSoC and BatteryLimitedCharingCurrent or something like this) to the charger settings config. This way, it is a) battery vendor independent and b) easier to with multiple batteries.

BTW: I don't understand what you are trying to achieve with the charger, I am only helping you get the SoC value through code.

I'm trying to keep the auto charger output current below the battery's reported maximum accepted value, and since this changes with the battery SoC, it must be actively corrected during the charging process.

[schlimmchen]

I'm trying to keep the auto charger output current below the battery's reported maximum accepted value

Does the Pylontech BMS tell you how much current it thinks is best? If so, can that information be fed directly to the charger instead?

[eu-gh]

Indeed, it does. For the US2000C, I observed values of 25A (default), 10A (between 90 and 95% SoC) and 5A (above 95%).

But I think the ability to set the power limits manually (as implemented in my PR) is better, since it is really simple, robust logic. Adding more factors to the mix increases the module's cohesion and makes it somewhat more vendor-specific.