Huawei battery does not hold SoC as planned.

[emilio-valdes]

Describe the bug
Predbat plan shows charge to 100% and hold it for a long time (hours). When the battery SoC reaches 100%, it starts discharging and does not hold the 100% SOC as per the plan.

Expected behaviour
Forcible charge works well till SoC reaches 100%. Stop forcible charge works well too, following Predbat commands properly. During the night, when tariffs are cheaper, predbat plan shows starting to charge at midnight, by 2-3am the battery is completely charged. The forcible charge action stops (despite predbat says hold the charge at 100%), the battery starts discharging (instead of holding the charge). By the time the tariffs get expensive again around 7am, the battery is completely depleted, so the charge during the first hours of the night is useless.
It does happen during the day as well.

Predbat version

8.30.4

Environment details

• Huawei solar integration Version 2.0.0a9. Modbus/TCP
• Standard HAOS installer
• Home Assistant

Installation method
Home Assistant OS
Core 2025.12.4
Supervisor 2025.12.3
Operating System 16.3
Frontend 20251203.3

Screenshots
If applicable, add screenshots to help explain your problem. The most useful ones can be your battery chart, the Predbat HTML plan and your current settings in HA.

Log file
The log file does not show any errors.

PLAN

REALITY

[gcoan]

If I follow your explanation of the issue, predbat plans a charge overnight on the cheap rate, when the battery reaches 100% full predbat stops the charge which then puts the battery into demand mode and the battery then discharges overnight so by the morning the battery is empty.

The Huwaei inverter config for predbat is quite simple, only start/stop charge and start/stop discharge, there is no freeze charge option.

Predbat should ideally be delaying the stop charge until the end of the charge period to prevent the battery discharging.

The logfile which you haven't attached might show this behaviour, as would you including details of what happened to predbat status overnight and what commands were issued to the inverter.

I don't really understand what the plan you have included is meant to show and whether this is part of the problem or not. Predbat can plan something and then revise the plan. Again the logfile and a better explanation would help.

[emilio-valdes]

Thanks for your clarification, it's now clear the Huawei inverter config for predbat only start/stop charge and start/stop discharge, there is no freeze charge option. Very helpful.

This is Spain, and the tariff is quite cheap at night(8.5c), more expensive 8am-10am (base rate at 13.5c), and the peak 10am-2pm (19.80c), then base again 2pm-6pm, peak again 6pm-10pm, base till midnight and then cheap from midnight till 8am. During weekends, it's a cheap flat rate of 8.5c.

It has been working very well during the whole week (Tuesday-Friday/Saturday), charging at 4am or 5 am depending on the solar forecast. Then it did a really good job adjusting during the day, everyday.

The issue is with the plan on Sundays, to your point "Predbat should ideally be delaying the stop charge until the end of the charge period to prevent the battery discharging" on Sundays it should not try to get the battery completely charged from the grid, it should wait till Monday 4am or 5am and then charge depending on the solar forecast (as it does correctly on Tuesdays, Wednesdays, Thursdays and Fridays). This way, by 8am, when the base rate kicks in, there's enough energy in the battery.
Instead, this is the plan predbat has created for today (Sunday)

I'll monitor today and tomorrow, as I anticipate it will charge till 100% and then start discharging till 10%, by the time I need the battery partially charged around 8am on Monday, it will be completely depleted. Will send you the log after it reaches 100% and you can see how it fails to hold the charge at 100% as the plan indicates, as it does not recalculate and send the forcible charge action. Ideally the plan shouldn't try to charge from the grid on a Sunday, it should wait till 4 or 5am on Monday, but if the plan decides to charge at 100%, at least it should be able to hold the charge, which is not the case because Huwaei inverter config for predbat only start/stop charge and start/stop discharge, there is no freeze charge option.

I hope it's better explained now. I'll send the log tomorrow, so you'll see how it goes after reaching 100% SoC.

[gcoan]

as a plan, that looks OK to me. Predbat is charging your battery on the cheaper rate and then planning to hold the battery in charging mode until the end of the cheap rate period on Monday morning.

If it's executed like this the stop charging should be sent until Monday 08:00 when Predbat starts releasing the battery to meet house load.

Have you got switch.predbat_combine_charge_slots turned on? This will encourage Predbat to keep charge slots together (like this plan)

If the plan executes differently then be interesting to see what it does.

Thanks

[emilio-valdes]

thanks very much @gcoan, truly appreciate your support.

this is what happened...

As the battery cannot hold 100% as per the plan, then it charged and discharged multiple times during Sunday and Monday am. In my opinion, a much better plan would have been keeping the battery at 0 during Sunday, and then charge it around 5am on Monday, so it's ready by 8am when the 13.5c rate kicks in. If you look at the plan I posted yesterday, the rate during Sunday all the way till Monday 8am is 8.5c. (pls ignore the rates predbat shows for Sunday in the history plan, the correct rate for the whole Sunday and Monday am is 8.5c)

Is it possible to "train" predbat so the battery only charges when it's needed, rather than charging/discharging for no reason?

Do you want/need the log? If so, how can I get it? I can only find entries for the last hour or so, not what happened last night.

Many many thanks
Emilio

[gcoan]

At least one of the log files when predbat was doing this sawtooth behaviour would be useful, they should still be there. The log file when it reaches a certain size will be renamed predbat-2.log, predbat-3.log, etc so if you use studio code server or file editor or samba you should be able to find them.

Being able to see what happened to predbat.status would also give a clue. I'm guessing that the problem is when predbat changes from charging to hold charge, it issues a stop charge, putting your battery into demand mode and then your battery drops in SoC until Predbat realises and charges it up again.

So dealing with the hold charge better could be one way to fix this. I think that still will be the better answer than delaying the charge until late because that would still run the batteries down to empty which would be less efficient than just holding whatever is in the battery at the start of the cheap period.

Have you got switch.predbat_combine_charge_slots turned on which I suggested yesterday?

[emilio-valdes]

Hi @gcoan, many thanks again for your reply and support, pls find the logs attached.

I agree with you, predbat sends the order to hold charge (or the battery reaches 100%), in both cases the forcible charge action stops, and the battery drops in SoC until Predbat realises and charges it up again.

Regarding your comment: "So dealing with the hold charge better could be one way to fix this. I think that still will be the better answer than delaying the charge until late because that would still run the batteries down to empty which would be less efficient than just holding whatever is in the battery at the start of the cheap period."... I completely agree with you. On a good sunny Sunday, it would be better to hold the "free solar charge" rather than discharge it when prices are low. What happens though is different... first it discharges completely (free solar is still cheaper than low rate), then it charges the battery to 100% at a low rate, then forcible charge stops and the battery discharges, then it charges again, then it stops again, and so on and so forth.

The two issues I've noticed are:
a) it does not hold at a given %
b) when it reaches 100% the forcible charge action stops.

What happened yesterday between 6am and 7:30am is very interesting. Because in this case it managed to hold the charge.

predbat.1.log

predbat.2 (1).log

[emilio-valdes]

It seems to do a good job holding SoC now, pls look at the plan execution last night. It held 52% 54% (as planned) for a very long time.

The problem (sawtooth behaviour) seems to happen only with predbat plans 100% charge and hold the full charge for a long time. May I suggest we try to set up predbat to reach to 95% or 98% max. Would that fix the problem? Could we try? if so, how can I do it?

[emilio-valdes]

Last night the predbat behaviour was pretty bad. The plan was charging to 100% when the tariff became cheap at midnight, and when it reached the max SoC the forcible charge stopped, a new version of predbat was installed, it triggered the forcible charge again, it reached the Soc limit again, and then the forcible charge stopped again. Predbat thought the battery was charging from grid for the rest of the night, so it skipped the forcible charge service for the rest of the night.

the SoC of the battery was like this:

The forcible charge started at midnight when the tariff became cheap, it stopped when the battery was full, restarted when the new version of predbat was installed and it noticed SoC was below the target, then stopped again when the battery was full, and it continued to discharge for the rest of the night

I attach the log, where we could see:

• the forcible charge service was successfully triggered by predbat at 00.00:52, and it remained charging till 03.17:52 when the SoC reached 98% (full), and that point the forcible charge status changed to Stopped. Next predbat's cycle ran at 03:20, at 3:20:19 predbat noticed the SoC was 96% (below the 100% target), however it skipped the forcible charge service. It didn't recompute the plan because it was only 5min old.
• At 3.23:54 predbat was updated to a new version.
• At 3.28:00 the new version of predbat noticed SoC was 92%, target was 100% and then predbat called the service stop forcible charge, and then immediately after it called the service charge battery from grid successfully, the forcible charge status changed to charging at 4500W until 98%.
• At 3.43:22 the SoC reached 98% and the forcible charge stopped again, and it remained stopped till 8am.
• At 3.45 predbat ran another cycle and it noticed SoC was 96% (target was 100%), and it decided to recompute the plan. After that it skipped the forcible charge service, and it concluded "compete run, status Charging/", not true because the forcible charge status was "stopped" since 3:43:22 when the SoC reached 98%
• Every 5 minutes predbat cycles ran, with the same results.

you can see in the history what happened.

I BELIEVE THE SOLUTION IS CHANGING THE FORCIBLE CHARGE SCRIPT TO 100%, AND CONFIGURE PREDBAT WITH A MAX TARGET OF 95% SO THE FORCIBLE CHARGE WILL NEVER STOP WITHOUT PREDBAT'S CONSENT.

How can I configure Predbat Max SoC =95%?

[springfall2008]

It seems like forcible charge script doesn't do what Predbat expects, if it says charge to 100% then it should stay at 100% until something else changes.

I wonder what JohanAlvedal used for his script, it seems not to be posted?

[emilio-valdes]

Hi @springfall2008 , first of all massive congrats for building Predbat. It's an amazing piece of software. I use it in London with a Givenergy battery, and in Spain with a Huawei battery.
I just need to fix this Huawei issue to have two perfectly optimised systems in two locations with two different inverters.

It looks like JohanAlvedal built his blueprint to control his Huawei battery, it does not look like Predbat is doing it. He mentioned "I could not get Predbat to control the Huawei inverter, so I have been using my own automation.I will feed back on the results"

My problem happens when predbat's plan says "charge to 100% and stay at 100%". The forcible charge action the Huawei integration provides (Huawei_solar.forcible_charge) is triggered by Predbat successfully, but when the SoC reaches 100%, then it stops and the battery goes back to demand mode. Predbat assumes it is still charging because it never triggered the service (huawei_solar.stop_forcible_charge), and it does not check the status of (sensor.batteries_forcible_charge).

So the 3 solutions I believe could fix the problem are:

a) When predbat concludes the battery is charging and states('sensor.batteries_forcible_charge')="Stopped", then launch the Huawei_solar.forcible_charge service again. (this would require a change in predbat's code)
b) configure predbat in a way that never plans to charge to 100%, just 90% or 95%. (I don't know how to do it. Is this possible?)
c) I'm testing now forcible charge with a very long duration (instead of forcible charge to a 100% SoC), (I'll let you know how it goes)

Feedback will be welcome!