Obey in CT mode upper & lower target

[tuxianerDE]

2025-06-08 05:09:35,301:INFO: SMT triggers limit function: 8.9 -> -3.7: skipped
2025-06-08 05:09:32,717:INFO: SMT triggers limit function: 12.1 -> 1.4: executed
2025-06-08 05:09:32,717:INFO: Sun: 05:19 - 21:41 Demand: 196.4W, Panel DC: (0.0W), Hub DC: (195.0W), Inverter Limit: 392.0W, Hub Limit: 850.0W
2025-06-08 05:09:32,717:INFO: Setting inverter output limit to 392W (1 min moving average of 98W x 4)
2025-06-08 05:09:32,717:INFO: Solarflow is willing to contribute 98.0W (per channel) of the requested 196.4!
2025-06-08 05:09:32,717:INFO: Not setting solarflow output limit to 850.0W as it is identical to current limit!
2025-06-08 05:09:32,717:INFO: Based on time, solarpower ( 0.0W) minimum charge power (10W) and bypass state (False), hub could contribute 196.4W - Decision path: 1.3.1. (not enough power to cover demand and minimum charge power during night/dusk/dawn)	
2025-06-08 05:09:32,716:INFO: Direct connected panel are producing 0.0W, trying to get 196.4W from hub.
2025-06-08 05:09:32,716:INFO: SFC: BatteryTarget: charging, SoC at sunrise: 2, SoC increase: 33
2025-06-08 05:09:32,716:INFO: SMT: T:Smartmeter P:-4.0W [ 23.5,23.5,21.1,18.0,12.1,1.4 ]
2025-06-08 05:09:32,716:INFO: INV: AC:196.1W, DC:206.5W (0.6|0.6|105.2|100.1), L:380W (94.9W/channel) [1500W]
2025-06-08 05:09:32,716:INFO: HUB: S:0.0W [ 0.0 ], B: 1% ( 1| 1| 1| 2) low: 0 high: 100 target: charging, V:47.1V (47.1|46.9|47.2|47.2), C:-196W, P:False (manual, possible), F:34.5h, E:-1.0h, CT:ON (120hrs) discharging, H:187W, L:850W

Hey,
I noticed on the latest master build that in the morning the HUB stops ingesting energy, as the - probably- the logic hits that the dusk SoC is taken and certain amount shall be charged to be batteries before discharging again.

From the above log:

• The SoC at sunrise taken is the highest SoC of all 4 batteries is there a reason why we dont take the absolute average which would be 1%?
• I would argue during CT as we have it during charging the absolute aim is to charge to 100% - thus the day during discharge is ignored - as the target of 100% superseeds. I would vote that the same applies for the lower end, i.e. when in CT and the target is 0% the logic at dusk of the SoC is surpressed as the target of calibrating and reaching 0% superseeds.

[reinhard-brandstaedter]

Hi Torsten,

the first point is purely a mathematical topic. We are not taking the lowest of the four batteries , but (1+1+1+2)/4 = 1.25% the hub reports it's electrical level as whole number 1%, this is what we are working with.

The second point is what I'm working on, with the situation of not fully discharging during the shorter nights now the 0% likely aren't reached and the CT mode will actually stay and charge again to 100% even though it has reached that already the day before.
Actually it would make sense to perform a "force-discharge" to 0% as soon as possible after the charge has reached 100% during the day before.
e.g.: in my case the battery already starts charging again after sunrise before there is even a chance to deplete it to 0.
So I'm thinking to perform this force discharge within the sunrise+offset window and even give away to the grid to ensure a timely 0 SoC (but only perform this force discharge if we are below a certain SoC Level).

Caveats: it could be that the discharge is done in the morning of a rainy day and that the charge could be used better throughout the day...

But somehow also large batteries have to reach zero at some point for calibration...

[tuxianerDE]

Hey,

ok understood, have not had a chance to look through the code at that point.

To the 2nd point, I have the same observation, what I would argue:

• I would argue to make this "forced discharge" with a discharge even to grid configurable. Especially discharge to grid from battery is quiet sensitive as people want to maximize utilization.
• Question: How is your observation with your AB2000 (I might remember correctly that oyu have one in your stack)? At least with my AB1000, the 100% -> 0% "calibration" helps that the SoC is not off by miles but still by kilometers in my opinion. Case: Is there a way to determine the type of battery in the stack? Because it might be limited to the AB1000 type of battery and the AB2000 is improved when it comes to "guessing" the SoC.