Hoymiles switches off and on again when the battery is empty and DPL is on

[Napizaki]

What happened?

My Hoymiles HM-600 with DynamicPowerLimiter enabled keeps turning off and on when the battery is low, even though the restart voltage is set at 49V, and the restart SOC is set at 20%.
I only noticed this behavior with the latest "master version" - it worked with the previous ones.

The SOC of the battery at that time was constant at 11% and US2000c is connected to DTU..
At 5:52h, I disabled the DPL and switeched off the Hoymiles manually

To Reproduce Bug

• Enable DPL
• wait until "DC Voltage - Stop threshold" is reached

Expected Behavior

The HM-600 should shut down when the voltage drops below 47.5V or 10% SOC, and turn back on when the voltage exceeds 49V or 20% SOC.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

83b42a3

Relevant log/trace output

No response

Anything else?

No response

[helgeerbe]

Hi @Napizaki, I can confirm this behavior. And try to fix it today. I think it's related to PRs #164 #172 from @MalteSchm

[Napizaki]

Perfect, thank you!

[MalteSchm]

Noted and thanks
I'll also have a look

[helgeerbe]

@MalteSchm It's the Battery charging cycle condition

// Battery charging cycle conditions
    // The battery can only be discharged after a full charge in the
    // EMPTY_WHEN_FULL case 
    if (isStopThresholdReached(inverter)) {
      // Disable battery discharge when empty
      _batteryDischargeEnabled = false;
    } else if (!canUseDirectSolarPower() || 
                config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT) {
      // Enable battery discharge
      _batteryDischargeEnabled = true;
    }

    // This checks if the battery discharge start conditions are met for the EMPTY_WHEN_FULL case
    if (isStartThresholdReached(inverter) && config.PowerLimiter_BatteryDrainStategy == EMPTY_WHEN_FULL) {
      _batteryDischargeEnabled = true;
    }

_batteryDischargeEnable has to be always false until startThreshold is reached

[MalteSchm]

@helgeerbe Hm, from earlier conversations I understood that for:
EMPTY_AT_NIGHT => Battery can always be discharged as long as stopThreshold is not reached
EMPTY_WHEN_FULL => Battery can only be discharged again when startThreshold is reached (i.e. it cycles between empty and full)

But maybe I misunderstood the behavior.

@Napizaki : do you use the EMPTY_AT_NIGHT or the EMPTY_WHEN_FULL strategy? It would help to understand the issue.

I suppose the issue is when the strategy is EMPTY_WHEN_FULL and direct solar power is OFF. This immediately re-enables the battery. It could be sufficient to delete "!canUseDirectSolarPower() || "

Maybe you can quickly confirm your setting here so that I'm chasing the right issue...

[helgeerbe]

@MalteSchm

EMPTY_AT_NIGHT => Battery can always be discharged as long as stopThreshold is not reached

AND Not canUseDirectSolarPower

EMPTY_WHEN_FULL => Battery can only be discharged again when startThreshold is reached (i.e. it cycles between empty and full)

Correct

I suppose the issue is when the strategy is EMPTY_WHEN_FULL and direct solar power is OFF. This immediately re-enables the battery.

This seems to be the root cause.

I think this should do it:

// Battery charging cycle conditions
    if (isStopThresholdReached(inverter)) {
        // Disable battery discharge when empty
        _batteryDischargeEnabled = false;
    } 
    else if (isStartThresholdReached(inverter)) {
        // enable battery discharge
        _batteryDischargeEnabled = true;
    }
    else if (canUseDirectSolarPower() && 
                config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT) {
        // disable battery discharge
        _batteryDischargeEnabled = false;
    }

[Napizaki]

I use the following setting:

I haven't quite understood "solar passthrough" yet - I haven't found anything clear in the doc either. I have tried it once, but have not been able to recognize any other behavior to disabled. Possibly someone can explain this again exactly or post a link where it is described.

Thanks in advance

[MalteSchm]

@helgeerbe
Ah yes: So if solarPassthrough is disabled we're implicitly using the EMPTY_WHEN_FULL strategy. Probably we need to enable discharge as a last step and check if we have a power source available

// Battery charging cycle conditions
    if (isStopThresholdReached(inverter)) {
        // Disable battery discharge when empty
        _batteryDischargeEnabled = false;
    } 
    else if (isStartThresholdReached(inverter)) {
        // enable battery discharge
        _batteryDischargeEnabled = true;
    }
    else if (canUseDirectSolarPower() && 
                config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT) {
        // disable battery discharge
        _batteryDischargeEnabled = false;
    } else {
       _batteryDischargeEnabled = true;
    }

and:

   // Calculate and set Power Limit
    int32_t newPowerLimit = 0;
    if (canUseDirectSolarPower() || _batteryDischargeEnabled) {
      newPowerLimit = calcPowerLimit(inverter, canUseDirectSolarPower());
    }
    setNewPowerLimit(inverter, newPowerLimit);

But then there is still an issue in calcPowerLimit as the required power may be more than what is supplied if consumeSolarPowerOnly is enabled.

I somehow feel that the heart of the problem is the fact that calcPowerLimit has two energy sources available that can be independently enabled/disabled but there is only one energy source in the interface.

@Napizaki
Yes I think the documentation needs to be improved in that aspect

[MalteSchm]

I created a (drafty) PR #196
@helgeerbe : EMPTY_AT_NIGHT really means that the battery should only be discharged when there is no sunshine right?

[swingstate]

Well, one thought Malte after reading your comment - I sometimes want to use my HM-300 & its Battery to feed into my household, even tough there is still sun light / the sun is above horizon.
Since my main solar system is shaded after 7pm it's not generating much so the HM-300 tops up the low power generation from my HM-1500.

So my question is, would your comment interfere my what I described?

[MalteSchm]

@swingstate
I think right now the idea is to bring the old functionality back. (certainly to address this bug raised here). So if that worked before it should work again.
My comment was about a function calcPowerLimit that has a single parameter useSolarPowerOnly. If that is true the battery discharge is implicitly disabled although you may be able to use both: solar and battery power. (it seems that this is your case)
If useSolarPowerOnly is false it does not mean that you can discharge the battery as the battery might be empty. But you don't know that from the data provided.

Hence my comment that there are two energy sources that impact the power limit and my thought to enhance the interface of this function. This could simplify implementing additional usecases going forward. But right now this is not my intention

[helgeerbe]

Checked 6b437b5 into development branch. Test it tomorrow with the next sun cycle.

[Napizaki]

OK, I have updated to 6b437b5 - the battery should be empty by tomorrow morning. I will report. THX

[Napizaki]

Still the same issue this night:

[MalteSchm]

@Napizaki
Can you indicate your startThreshold voltage?

my guess is that we're running into the condition copied below as the start threshold is reached and because the (invisible UI Drain Strategy) is set to Empty when full

// This checks if the battery discharge start conditions are met for the EMPTY_WHEN_FULL case
   if (isStartThresholdReached(inverter) && config.PowerLimiter_BatteryDrainStategy == EMPTY_WHEN_FULL) {
     _batteryDischargeEnabled = true;
   }

[helgeerbe]

@MalteSchm I left comments in #199

What I see so far:

• If inverter is switched off, due to low voltage and the battery recovers, the inverter is switched on again...
  Old implementation kept the inverter switched off, until start condition was reached:

  • startThreshhold is reached
  • if solarPassthrough is activated, solar power could be consumed

• If solar passthrough is enabled:

  • If voltage is above start threshold, battery will be used until voltage is below start threshold again. (don't waste usable energy)

• When inverter is switched off the old implantation sets the power limit to minimum (10w), bevor turning off

• Safty mechanism is missing:

  • if power meter values are older than 30 seconds, set limit to lower power limit
  • I have two inverters and inverter statistics update takes some time
    • I allowed 15 seconds, your implementation waits allows 10 second. I set limit to lower power limit. You just return without doing anything. I saw in my stats, that I exported power in the night to the grid, because power limiter was not responsive.

[MalteSchm]

My fix looks like this but I can't really test as our internet is buggy and I cannot update the ESP32 OTA :-(

    // Battery charging cycle conditions
    // First we always disable discharge if the battery is empty
    if (isStopThresholdReached(inverter)) {
      // Disable battery discharge when empty
      _batteryDischargeEnabled = false;
    } else {
      // UI: Solar Passthrough Enabled -> false
      // No other conditions apply and battery discharge can be enabled
      if (!config.PowerLimiter_SolarPassThroughEnabled) {
        _batteryDischargeEnabled = true;
      }

      // UI: Solar Passthrough Enabled -> true && EMPTY_AT_NIGHT
      // In this case we should only discharge the battery when there is no sunshine
      if (config.PowerLimiter_SolarPassThroughEnabled && config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT) {
        _batteryDischargeEnabled = !canUseDirectSolarPower();
      }

      // UI: Solar Passthrough Enabled -> true && EMPTY_WHEN_FULL
      // In this case we should only discharge the battery when it is full
      if (config.PowerLimiter_SolarPassThroughEnabled && isStartThresholdReached(inverter) && config.PowerLimiter_BatteryDrainStategy == EMPTY_WHEN_FULL) {
        _batteryDischargeEnabled = true;
      }
    }

[helgeerbe]

// UI: Solar Passthrough Enabled -> true && EMPTY_AT_NIGHT

You have to allow battery usage if start threshold is reached

[MalteSchm]

@helgeerbe
ok I think I got it. See below. Please let me know if this is not correct

I'll look at your other points now.
I never run into these cases since I use the battery SOC which does not have these effects.

    // Battery charging cycle conditions
    // First we always disable discharge if the battery is empty
    if (isStopThresholdReached(inverter)) {
      // Disable battery discharge when empty
      _batteryDischargeEnabled = false;
    } else {
      // UI: Solar Passthrough Enabled -> false
      // Battery discharge can be enabled when start threshold is reached
      if (!config.PowerLimiter_SolarPassThroughEnabled && isStartThresholdReached(inverter)) {
        _batteryDischargeEnabled = true;
      }

      // UI: Solar Passthrough Enabled -> true && EMPTY_AT_NIGHT
      // In this case we should only discharge the battery when there is no sunshine
      if (config.PowerLimiter_SolarPassThroughEnabled && config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT) {
        _batteryDischargeEnabled = !canUseDirectSolarPower();
      }

      // UI: Solar Passthrough Enabled -> true && EMPTY_WHEN_FULL
      // Battery discharge can be enabled when start threshold is reached
      if (config.PowerLimiter_SolarPassThroughEnabled && isStartThresholdReached(inverter) && config.PowerLimiter_BatteryDrainStategy == EMPTY_WHEN_FULL) {
        _batteryDischargeEnabled = true;
      }
    }

[Napizaki]

You can see my current values in the inital post:

[MalteSchm]

About your points:

• If solar passthrough is enabled:
• If voltage is above start threshold, battery will be used until voltage is below start threshold again. (don't waste usable energy)

--> Does this also apply to EMPTY_AT_NIGHT? Right now the battery is only used at night.

• When inverter is switched off the old implantation sets the power limit to minimum (10w), bevor turning off
  --> Changed to set inverter to config.PowerLimiter_LowerPowerLimit. Will submit a PR later

• Safty mechanism is missing:

  • if power meter values are older than 30 seconds, set limit to lower power limit
  • I have two inverters and inverter statistics update takes some time
  • I allowed 15 seconds, your implementation waits allows 10 second. I set limit to lower power limit. You just return without doing anything. I saw in my stats, that I exported power in the night to the grid, because power limiter was not responsive.

Ok sorry about that. I think you refer to this code here, right?

    // If the last inverter update is too old, don't do anything.
    // If the last inverter update was before the last limit updated, don't do anything.
    // Also give the Power meter 3 seconds time to recognize power changes after the last set limit
    // as the Hoymiles MPPT might not react immediately.
    if ((millis() - inverter->Statistics()->getLastUpdate()) > 10000
            || inverter->Statistics()->getLastUpdate() <= _lastLimitSetTime
            || PowerMeter.getLastPowerMeterUpdate() <= (_lastLimitSetTime + 3000)) {
        return;
    }

There is code currently in calcPowerLimit() to address said issue but I guess this conflicts with the check performed at the beginning of the PowerLimiterClass::loop()

    // Safety check, return on too old power meter values
    if (millis() - PowerMeter.getLastPowerMeterUpdate() > (30 * 1000)
            && (millis() - inverter->Statistics()->getLastUpdate()) > (config.Dtu_PollInterval * 10 * 1000)) {
        // If the power meter values are older than 30 seconds, 
        // and the Inverter Stats are older then 10x the poll interval
        // set the limit to 0W for safety reasons.
        MessageOutput.println("[PowerLimiterClass::loop] Power Meter/Inverter values too old. Using 0W (i.e. disable inverter)");
        return 0;
    }

First thing I noticed is that this needs an or statement

    // Safety check, return on too old power meter values
    if (millis() - PowerMeter.getLastPowerMeterUpdate() > (30 * 1000)
            || (millis() - inverter->Statistics()->getLastUpdate()) > (config.Dtu_PollInterval * 10 * 1000)) {
        // If the power meter values are older than 30 seconds, 
        // or the Inverter Stats are older then 10x the poll interval
        // set the limit to 0W for safety reasons.
        MessageOutput.println("[PowerLimiterClass::loop] Power Meter/Inverter values too old. Using 0W (i.e. disable inverter)");
        return 0;
    }

Also I changed this to disable the inverter. I saw the issue that a prolonged network outage would keep the inverter running with minimal power and this would eventually completely drain the battery. This would have occurred in my old code. The new code with the extended interface to calcPowerLimit() can actually handle this if the inverter is set to the lower limit.
I think I change this back to use LowerPowerLimit if you like. Personally I think it would be better to use longer timeouts and then apply a real hard safety measure here then rely on the other logic to somehow kick in.

[helgeerbe]

--> Does this also apply to EMPTY_AT_NIGHT? Right now the battery is only used at night.

Yes as long voltage is above start threshold. Have a look at the state diagram.

I'm fine to turn the inverter off or minimum power, if there is a problem instead to lower limit.
And maybe you can move the safty check out of calcPowerLimit() at the beginning, on a problem turn the inverter off.

[MalteSchm]

@helgeerbe o.k. I did all of these changes and created #201
Note that this is not tested as I still have issues with my provider. But I learned from this discussion that testing this with my system will only provide limited confidence as there are many factors that play a role here.

[helgeerbe]

Yes, testing is actual a nightmare. I just think about to write a small unit test framework for the power limiter. Have to mock up the inverter a power meter. But for future changes this might increase the code quality.

[Napizaki]

I will test what I can and then give you feedback.

[helgeerbe]

@Napizaki wait a little. I'll do some more minor changes and will merge it into the development branch.

[helgeerbe]

@MalteSchm Thanks for your work and support. And for not giving up.

[helgeerbe]

Merged it into development: c621f2d

[MalteSchm]

@MalteSchm Thanks for your work and support. And for not giving up.

:-) Thanks. I feel responsible though after causing these issues in the first place. But we will get back to a stable state

[helgeerbe]

@MalteSchm
Setting the upper Power limit to 300W (max for my HM-300), I see this behavior:

Orange line is battery. If Power Limit is set to 300 (I see it in the icon), the invert is set to 0W.

If I set the upper power limit to 299. Everything is fine. I see 299 in the icon, and inverter is set to 299.

[Napizaki]

Good morning,

unfortunately it still does not work with version c621f2d:

At 23:16h I have then manually deactivated the DPL.

[MalteSchm]

Couple of things:

@helgeerbe
EDITED TEXT: Nevermind, I'm no longer certain what has happend here. Removing this comment

@Napizaki
I must admit that I don't understand where the issue is in your case. If there is no change in the Power Limiter settings (compared what you've shown in this bug report) this does not make sense to me. I did the math and think the battery discharge should not be re-enabled.
If I prepare a branch that has some extra printouts: can you install that and dump the output of the console (available via the web interface) here or in pastebin? This case needs extra information to understand where the problem is.

@helgeerbe
I will put these printouts under define and create a PR so that we have at least the ability to better debug the power limiter in various user setups. I leave it up to you if this gets merged or not.

[Napizaki]

@MalteSchm
here my complete DPL-Settings (I did not change anything):

Of course, I can do the test and post the output of the console.

[MalteSchm]

@Napizaki
I think I found the issue.
PowerLimiter.cpp line ~50 contained the statement below
The issue is that isStopThresholdReached(inverter) is checked here and the inverter is powered off if this is true. This is done without clearing the battery discharge enabled flag. If the battery recovers and exceeds the stop threshold again, discharge is started with will trigger this condition the next time.

    // Make sure inverter is turned off if PL is disabled by user/MQTT
    // Make sure inverter is turned off when low battery threshold is reached
    if (((!config.PowerLimiter_Enabled || _disabled) && _plState != SHUTDOWN)
           || isStopThresholdReached(inverter)) {
        if (inverter->isProducing()) {
            MessageOutput.printf("PL initiated inverter shutdown.\r\n");
            inverter->sendActivePowerControlRequest(config.PowerLimiter_LowerPowerLimit, PowerLimitControlType::AbsolutNonPersistent);
            inverter->sendPowerControlRequest(false);
        } else {
            _plState = SHUTDOWN;
        }
        return;
    }

[helgeerbe]

@MalteSchm

I think I found the issue.

I think so, too. Good finding.

I added this code to your PR

      // UI: Solar Passthrough Enabled -> true && EMPTY_AT_NIGHT
      if (config.PowerLimiter_SolarPassThroughEnabled && config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT) {
        if(isStartThresholdReached(inverter)) {
            // In this case we should only discharge the battery as long it is above startThreshold
            _batteryDischargeEnabled = true;
        }
        else {
            // In this case we should only discharge the battery when there is no sunshine
            _batteryDischargeEnabled = !canUseDirectSolarPower();
        }
      }

For solar passthrough and EMPTY_AT_Night.
Battery discharged should be enabled as long voltage is above start threshold.
-> Intention is, that if the battery is quite full, and there is not enough sun, battery should support power consumption.
Is voltage is between stop and start threshold, just use battery, if there is no sun.

I also added

 if(!inverter->isProducing()) {
       return PL_UI_STATE_CHARGING;
    }

to get the charging icon back.

I have one more issue.
If power limit is set to maximum power of my inverter (HM-300). I see in the icon 300w, but the inverter is switched off. If I reduce the upper limit to 299W everything works as expected. I hadn't time to search for the root cause.

[helgeerbe]

@MalteSchm

Do you think, this will do the trick?

  // Make sure inverter is turned off if PL is disabled by user/MQTT
    // Make sure inverter is turned off when low battery threshold is reached
    if (((!config.PowerLimiter_Enabled || _disabled) && _plState != SHUTDOWN)
           || isStopThresholdReached(inverter)) {
        if (inverter->isProducing()) {
            MessageOutput.printf("PL initiated inverter shutdown.\r\n");
            inverter->sendActivePowerControlRequest(config.PowerLimiter_LowerPowerLimit, PowerLimitControlType::AbsolutNonPersistent);
            inverter->sendPowerControlRequest(false);
        } else {
            _plState = SHUTDOWN;
        }
        _batteryDischargeEnabled = false;
        return;
    }

I could add the line without PR.

[MalteSchm]

I think we should just remove || isStopThresholdReached(inverter) here and not worry about the battery at this point
isStopThreshold is reached is checked in the codeblock that deals with the battery discharge enabled flag below and is correctly handled here (famous last words :-D)

I mean this part of the code:

    // Battery charging cycle conditions
    // First we always disable discharge if the battery is empty
    if (isStopThresholdReached(inverter)) {
      // Disable battery discharge when empty
      _batteryDischargeEnabled = false;
    } else {
      // UI: Solar Passthrough Enabled -> false
      // Battery discharge can be enabled when start threshold is reached
      if (!config.PowerLimiter_SolarPassThroughEnabled && isStartThresholdReached(inverter)) {
        _batteryDischargeEnabled = true;
      }

      // UI: Solar Passthrough Enabled -> true && EMPTY_AT_NIGHT
      if (config.PowerLimiter_SolarPassThroughEnabled && config.PowerLimiter_BatteryDrainStategy == EMPTY_AT_NIGHT) {
        if(isStartThresholdReached(inverter)) {
            // In this case we should only discharge the battery as long it is above startThreshold
            _batteryDischargeEnabled = true;
        }
        else {
            // In this case we should only discharge the battery when there is no sunshine
            _batteryDischargeEnabled = !canUseDirectSolarPower();
        }
      }

      // UI: Solar Passthrough Enabled -> true && EMPTY_WHEN_FULL
      // Battery discharge can be enabled when start threshold is reached
      if (config.PowerLimiter_SolarPassThroughEnabled && isStartThresholdReached(inverter) && config.PowerLimiter_BatteryDrainStategy == EMPTY_WHEN_FULL) {
        _batteryDischargeEnabled = true;
      }
    }

[MalteSchm]

PR is here: #209
@Napizaki
This branch https://github.com/MalteSchm/OpenDTU-OnBattery/tree/debug_printouts does also include printouts that could help if the issue still exist

@helgeerbe
I will look at your issue with the 300W limit next. But I can only do that tomorrow

[Napizaki]

So, I have tested now:

It looks like it works now, although the inverter still switched on 4 x after falling below 47.5V. But that was probably because the SOC was still at 20%. The low voltage at the battery and the high SOC can be explained by the high load that the inverter had to perform at that time.

I'll check again tomorrow when the inverter draws less load - but it seems to work now.

[MalteSchm]

Thanks for the feedback @Napizaki

[helgeerbe]

Merged the PR and it is already in master release 2023.04.29

[helgeerbe]

Keep this open and wait for further feedback.

[MalteSchm]

@helgeerbe
Do you have further infos on the issue that you observed? I tried to re-create the setup that you have (based on my assumption)
Solar PT on
Empty at night

And an upper limit is correctly handled. I only tested during daytime though. Was there solar power when you saw that?

There are not many places in the code that actually check the upper limit so I'm not fully convinced yet that that we're on the right path here

[helgeerbe]

@MalteSchm Hadn't time. But I just set the upper limit to 300W. Voltage is above start threshold. I turned a water heater on, and power limit jumps to 300W limit in the inverter. So at the moment I can't reproduce it. Will wait and check again, when sun is down.

By the way. I see that we calculate the limit as int. Inverter expects float, and we don't do a proper cast.

[helgeerbe]

@MalteSchm I could reproduce it now.

• No Sun

• 1

  • Power Import 692.9 W
  • Power Limit is set to 300W
  • Limiter sets limit to 300 W
  • Inverter is on (circle with checkmark icon), but shows current limit 0W and 0%

• 2

  • if power import drops to 400W
  • limiter sets limit still to 300W
  • but inverter shows 299W 100%

• 3

  • if power import is 692,9 W
  • limit is set to 300 W
  • inverter shows 0W, 0% again

[MalteSchm]

Ok I'll check.
Is the inverter at 300W all the time (I.e. is this a display problem) or is this the actual inverter power affected as well?

[MalteSchm]

Hi @helgeerbe
It may be related but the last requested inverter limit was not stored in all cases. I doubt that this is the issue but I consider this as bug. The PR is here #213
I doubt that this fixes what you're observing though but maybe we're lucky :-)

I also added the static casts

[helgeerbe]

I will check my logs in the evening. But I think the inverter delivers around 8 W, so no display error.
Maybe due to rounding errors, limit as float was above max inverter limit and inverter goes to minimum. But this is guessing

[helgeerbe]

I checked my influxdb. At the beginning (power limit set to 299 W) everything was OK. Setting power limit to 300 W, inverter produces around 6 W, although limit was set to 300 W. Power import and power consumption is high.

[MalteSchm]

@helgeerbe
I tested this (with the old code), with disabled CAN bus / battery connection and with Empty at night but I'm not able to reproduce this.
Can you also check the log messages and potentially post them here?

[helgeerbe]

Hi @MalteSchm I think we can close this issue. I did a lot of tests, but couldn't find out why I have this behavior. At the end I rebooted the inverter and since then everything is fine. So it looks like it was the inverter.

[helgeerbe]

Should be fixed with 569edbe

[MalteSchm]

@helgeerbe
Thanks for the feedback. In case something comes up we have to continue the investigation

[github-actions]

This issue 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.