[Bug] SolarFlow AC/AC+ batteries failing to start charging due to mathematical sign conflict in power distribution logic

[thib3113]

Home Assistant Version

2026.3.4

Zendure Integration Version

1.2.7-pre3

Describe the bug

I have observed a bug where my SolarFlow batteries (sf2400ac and sf2400ac+) remain in INACTIVE state even when there is a significant solar surplus (over 1000W of grid injection). The batteries stay in "Idle" mode and refuse to transition to "Charge" mode because the internal power distribution logic fails to handle the negative sign convention used by these AC models.

To Reproduce

1. Have a SolarFlow AC or AC+ battery in INACTIVE state (Idle).
2. Configure the device with a fusegroup (in my case: "Device has its own circuit or phase" for each battery).
3. Generate a solar surplus (negative P1 value) between 0W and 1200W.
4. Observe that the battery remains in INACTIVE state and does not start charging, despite the surplus being available.
5. The system only recovers if the surplus exceeds ~1200W or after a long delay via the "50W pulse" fallback mechanism.

Expected Behaviour

The batteries should immediately transition to CHARGE mode as soon as a negative surplus (injection) is detected on the P1 meter, respecting the SmartMode.POWER_START threshold.

What device are you using?

• SF2400 AC
• SF2400 AC+

Log Extracts

2026-03-25 09:13:50 INFO (MainThread) [custom_components.zendure_ha.manager] P1 ======> p1:-1069 isFast:False, setpoint:-1069W stored:0W
2026-03-25 09:13:50 INFO (MainThread) [custom_components.zendure_ha.manager] Charge => setpoint -1069W
2026-03-25 09:13:50 DEBUG (MainThread) [custom_components.zendure_ha.manager] Device sf2400ac 063 state: INACTIVE, SOC: 12%, homeInput: 0W, homeOutput: 0W
2026-03-25 09:13:50 DEBUG (MainThread) [custom_components.zendure_ha.manager] Adding sf2400ac 063 to idle list

Other Information

The "HTTP Timeout Rescue" (Strange Recovery)

Ironically, in my case, the only thing that eventually "saves" the system and starts the charge is a communication bottleneck on the battery side. The internal ESP processor sometimes fails to keep up with the volume of requests, leading to timeouts.

1. The system is stuck in the 0W bootstrap loop.
2. It sends periodic -50W pulses to "test" the idle batteries.
3. Multiple HTTP TimeoutErrors (due to the ESP being overwhelmed) delayed the state update for over a minute.
4. When a request finally succeeded, it reported a 49W consumption.
5. This 49W value (from the pulse) is what finally moved the battery to the charge list, breaking the 0W capping logic.
   Without these communication timeouts and the 50W fallback, the system would likely stay stuck at 0W indefinitely.

Evidence: Timeline of the failure (2026-03-25)

Time (Local)	Solar Prod	House Cons	Net Export	Battery State	Battery Charge	Status
09:13:45	1116 W	56 W	-1060 W	INACTIVE	0 W	Stuck (Bug)
09:13:50	1116 W	56 W	-1060 W	INACTIVE	0 W	Stuck (Bug)
09:13:55	1116 W	56 W	-1060 W	INACTIVE	0 W	Stuck (Bug)
09:13:57	1116 W	56 W	-1060 W	ACTIVE	-1019 W	Recovered via Fallback

Technical Analysis: The "1200W Invisible Wall"

For sf2400ac models, the integration defines a "Charge Limit" of -2400W. The manager calculates an "Optimal Charge" (1/4 of the limit), resulting in -600W.
The wake-up condition if dev_start < 0 is never met as long as the surplus is less than 1200W because:
dev_start = Surplus(-1000) - (Optimal_Charge(-600) * 2) = +200 (which is > 0).

graph TD
    A[Surplus Detected: -1000W] --> B{Are batteries charging?}
    B -- No --> C[Calculate dev_start threshold]
    C --> D["dev_start = Surplus - (Optimal_Charge * 2)"]
    D --> E["dev_start = -1000 - (-600 * 2) = +200"]
    E --> F{Is dev_start < 0?}
    F -- No (+200) --> G[STAY IN IDLE]
    F -- Yes --> H[WAKE UP BATTERY]
    G --> I[Invisible Wall: No charging starts]

Loading

Affected Code (manager.py)

# custom_components/zendure_ha/manager.py:531
limit = self.charge_limit # is 0 if no batteries are charging
setpoint = max(limit, setpoint) # max(0, -1069) = 0W. Surplus is deleted.

# custom_components/zendure_ha/manager.py:558
if (dev_start := dev_start - d.charge_optimal * 2) >= 0: # logic fails with negative optimal
    break

Proposed Fix

1. Use Absolute Values: Update formulas to use abs(charge_optimal) to handle both positive and negative sign conventions.
2. Protect Setpoint during Bootstrap: Allow the setpoint to remain negative even if the current active limit is 0, as long as idle batteries are available.

[harrymayr]

Just a question: do you have assigned a fusegroup to your devices?

[thib3113]

@harrymayr Yes, both my batteries are assigned to a fusegroup. I am using the 'Device has its own circuit or phase' option for each of them.

[harrymayr]

self.charge_optimal (manager variable, not a device variable) is only -600 if there is already a device discharging.
It will be set to 0 in _p1_changed() and will be added up with d.charge_optimal (device value) if the device is charging
if (home := -d.homeInput.asInt + max(0, d.pwr_offgrid)) < 0
...
self.charge_optimal += d.charge_optimal
So if all devices are idle, self.charge_optimal is 0 and dev_start = min(0, setpoint).
There must be another reason that it does not start charging for your devices.
Could you please provide a debug-log which show the behaviour (not only the 4 lines). Also MQTT logging in the setup of the integration should be enabled.

[thib3113]

Hi, thank you for the detailed explanation. You are completely right about self.charge_optimal; I misunderstood how dev_start evaluates during the initial loop.

Unfortunately, I don't have the exact full logs from that initial occurrence anymore. To properly debug this and isolate the issue, I have been running clean tests by simulating the P1 meter with an input_number. I am also currently adding extensive custom debug logs all throughout the integration to trace the exact variable states during the process.

Here is what I found, and it actually ties perfectly into your request about the MQTT logs.

Regarding the MQTT logs: My batteries are blocked from the internet, so they don't communicate with the Zendure cloud. I am relying entirely on the local ZenSDK. I enabled the MQTT logging option as you requested, but it doesn't log anything extra in my specific case.

This leads me to a hypothesis: the difference in state update speed between the local ZenSDK and the real-time push of MQTT might be a contributing factor as to why this infinite loop gets triggered so easily in my setup:

1. When a sudden surplus arrives (e.g., -500W) and the battery is idle, self.charge_limit is 0. The calculation setpoint = max(limit, setpoint) mathematically caps the actual surplus to 0W.
2. The system then falls back to sending the -SmartMode.POWER_START (-50W) wake-up pulse.
3. Because I am using ZenSDK, I suspect the entity status update (homeInput > 0) might take a bit longer to register locally compared to an immediate MQTT push.
4. By the time the next calculation cycle runs, the battery hasn't reported its updated charging state yet. The system still sees it as idle, the limit is still 0W, the real surplus is discarded again to 0W, and it just sends another 50W pulse.

It creates an infinite loop. The 50W pulse doesn't seem to trigger a fast enough state update over ZenSDK to move the battery to the charge list in time, causing the system to get stuck capping the real solar surplus to 0W.

---

Side note regarding Local MQTT: I know you are currently working on a local MQTT implementation for the integration. I actually already have this system fully set up at home (an external MQTT broker outside of HA, with my batteries already configured via the Zendure app to publish to it). If you ever need someone to run tests with this specific local MQTT setup, feel free to ask, I'd be glad to help!

[harrymayr]

Make a try and increase SmartMode.POWER_START in const.py to i.e. 60. @FireSon reported that for some reason 50W does not trigger his SF2400 to start.

[thib3113]

Ok, I just switch POWER_START to 60 . I didn't have the time to test manually, and it didn't happen at the moment ... I've setup more intensive logs (storing in loki), so I hope the bug will came back to debug .

In the same time, I've added lot of logs, so I will follow that

[jghaanstra]

Ok, I just switch POWER_START to 60 . I didn't have the time to test manually, and it didn't happen at the moment ... I've setup more intensive logs (storing in loki), so I hope the bug will came back to debug .

In the same time, I've added lot of logs, so I will follow that

Have you come to any conclusion? I'm experiencing the exact same behaviour with my Solarflow AC+. It's stuck on 50W in the settings in an idle state pretty much every start of a new day. I have to manually set it to something higher to trigger the auto charge and recharge mechanism.

Where can I change SmartMode.POWER_START to see if this has any effect? [edit] Nevermind, found it and changed it, let see if this helps.

[thib3113]

@jghaanstra not really ... I'm always on my first thought ...

I've added lot of logs, and I wait to reproduce in real

[jghaanstra]

@jghaanstra not really ... I'm always on my first thought ...

I've added lot of logs, and I wait to reproduce in real

You are correct, just had the same issue even though I changed SmartMode.POWER_START to 60. Not sure if that resulted in this not occuring for at least 3 days in a row but it's definitely not a proper fix.

[thib3113]

Hello again,

I wanted to provide a quick update: I experienced the exact same issue again yesterday.

I am attaching a new, fully annotated log capturing the whole morning to help investigate. If you look specifically around the 10:00:13 to 10:00:16 timeframe, you will clearly see both bugs actively blocking the charge:

1. The 0W Setpoint Override (Bootstrap Bug): At 10:00:13.904, the log outputs max(limit=0, setpoint=-1031) resulted in 0W. This confirms that the software limit is incorrectly overriding the actual negative setpoint (the surplus) while the system is trying to wake up idle batteries.
2. The Subtraction Logic Error (1200W Invisible Wall): At 10:00:16.821, the wakeup loop evaluates the threshold with -1056 - (-600*2) = 144. Because 144 is >= 0, the loop triggers a break and the battery stays stuck in the idle list, completely ignoring the 1056W surplus.

The attached log should provide all the necessary evidence regarding the negative sign convention failing on the AC models' power distribution logic. Please let me know if you need me to test a specific fix or if you need any additional information!

zendure_full_morning_annotated.log

PS : Logs are in UTC / graph is in UTC+2

On this graph, the blue line, is the charging power of the AC+ , and I manually set it to input 2400 near 12h, before this, the manager never ask the AC+ to charge, even when the solar input is more than 2400w (more than one hub) .

here is the csv with solar production / consumption / battery power of 2400AC and 2400AC+

[harrymayr]

Sorry, with this log I can't do any analysis. 3 minutes mqttProperties, 11-12 minutes nothing. This repeats the whole log. I need the original log. You can sent it to harryzagithub@gmail.com.

[thib3113]

@harrymayr re reading, I saw that the debug log level failed ... so there are only my debug logs, and the info of the plugin ... I will need to wait the next problem .

What do you need about logs ?

---

I figure out I just do a bad filter ... Here are the new logs ( too big for one file )

zendure_log_part_00.log
zendure_log_part_01.log
zendure_log_part_02.log
zendure_log_part_03.log

[harrymayr]

too big for one file

There is a nice function: Compress into ... 😉😁
However, I see that the "Wakeup" command is not proceed by the AC+. But you still have it at 50W. Can you increase it to 100W in const.py (START_POWER)?
It seems, that it doesn't start with 50W and once it is started, it follow the command down to ~30W. InputLimit less the 30W will result in 0 charge power.

[thib3113]

There is a nice function: Compress into ... 😉😁

Hum, I think it's really safer receiving 4 plain text log files, than a compressed one ( from users on internet / zip can contain lot of bad things ) 😉😁

However, I see that the "Wakeup" command is not proceed by the AC+. But you still have it at 50W. Can you increase it to 100W in const.py (START_POWER)?

I've done the change, now I will wait if the problem came back

[jghaanstra]

To add to the discussion. I changed START_POWER to 60W and only experienced the described issues once after that. Been solid for about 2 weeks now.