Reaction time and lack of participation with multiple devices

[blumstrauss]

What's the issue?

I operate AstraMeter with 5 Marstek B2500 connected to 3 APsystems EZ1-M.
My power meter is a Hichi/Tasmota and to get faster updates, I collect the current consumption every 3 secs via Rest-API.
I tried several parameters in UI config, but am not satisfied with reaction time and amount of power/batteries activated. This occurs more or less always, my setup just is not right, I guess.

As an example I am sending log entries from this morning. Unfortunately not in debug mode - if that is needed I can deliver it.
Situation:
5 B2500 are on/active in AstraMeter.
At 05:15:00 1 B2500 is handling power demand 220W, 2 additional are "kept alive" (saw that), 2 deliver 0W
Now there is a power demand of 2500W starting at 05:15:45. The one active B2500 puts out 415W, but none of the other B2500 comes for help. At 05:18:00 the two "live-kept" react and 3 B2500 now handle a demand of 1200W. This demand raises consistently during an hour to 1500W, but the remaining 2 B2500 are not jumping in over the whole period.

To abstract my concern:
a) my devices do not react quickly enough, except they are already active
2) devices put into "sleep" mode do not get activated

I read the manual, I tried each parameter, but am more confused than at the beginning. I appreciate support with my setup.

Version

2.2.4

Installation method

Home Assistant add-on

If "Other", which?

No response

Configuration

power_input_alias: sensor.verbrauch_aktuell_3s
power_output_alias: ''
device_types: ct002
throttle_interval: 2
wait_for_next_message: false
marstek_auto_register_ct_device: true
marstek_mailbox: ***
marstek_password: ***
cloud_reporting: false
active_control: true
min_efficient_power: 150
efficiency_rotation_interval: 1200
min_dc_output: 0
grid_predict_trust: 0
log_level: info
balance_gain: 0.2
balance_deadband: 5
smooth_target_alpha: 0.5
deadband: 6
fair_distribution: false
concentrate_deadband: 20
osc_damp_max: 0

Logs

2026-08-22 05:12:54 INFO:astrameter:Efficiency: probe succeeded for b42f0398a5ce at 56W
2026-08-22 05:15:01 INFO:astrameter:CT002: 6 W surplus but no AC-chargeable battery reporting — nothing here can absorb it. Reporting device_types: ['HMJ-2', 'HMJ-3']
2026-08-22 05:15:41 INFO:astrameter:Efficiency: activating consumer 009c17e01b79 (demand 403W, 2 active)
2026-08-22 05:15:49 INFO:astrameter:Efficiency: activating consumer 60323bd1490e (demand 629W, 3 active)
2026-08-22 05:15:53 INFO:astrameter:Efficiency: activating consumer 2419720d40da (demand 806W, 4 active)
2026-08-22 05:15:55 INFO:astrameter:Efficiency: activating consumer 7ce71219ae84 (demand 991W, 5 active)
2026-08-22 05:16:06 INFO:astrameter:CT002 consumer 60323bd1490e phase detected: A
2026-08-22 05:18:11 INFO:astrameter:Efficiency: deprioritizing consumer 60323bd1490e (demand 746W, 4 active)
2026-08-22 05:18:11 INFO:astrameter:Efficiency: 009c17e01b79 cannot follow target (sat=0.93), rotating to 60323bd1490e
2026-08-22 05:18:11 INFO:astrameter:Efficiency: probing consumer 60323bd1490e with backups ['009c17e01b79'] until 90.0s
2026-08-22 05:18:11 INFO:astrameter:Efficiency: deprioritizing consumer 009c17e01b79 (demand 738W, 4 active)
2026-08-22 05:18:11 INFO:astrameter:Efficiency: activating consumer 60323bd1490e (demand 738W, 4 active)
2026-08-22 05:18:53 INFO:astrameter:Efficiency: probe succeeded for 60323bd1490e at 121W
2026-08-22 05:18:53 INFO:astrameter:Efficiency: 2419720d40da cannot follow target (sat=0.89), rotating to 009c17e01b79
2026-08-22 05:18:53 INFO:astrameter:Efficiency: probing consumer 009c17e01b79 with backups ['2419720d40da'] until 90.0s
2026-08-22 05:18:53 INFO:astrameter:Efficiency: deprioritizing consumer 2419720d40da (demand 872W, 4 active)
2026-08-22 05:18:53 INFO:astrameter:Efficiency: activating consumer 009c17e01b79 (demand 872W, 4 active)
2026-08-22 05:18:53 INFO:astrameter:Efficiency: probe succeeded for 009c17e01b79 at 400W
2026-08-22 05:18:55 INFO:astrameter:Efficiency: activating consumer 2419720d40da (demand 908W, 5 active)
2026-08-22 05:19:25 INFO:astrameter:CT002: 11 W surplus but no AC-chargeable battery reporting — nothing here can absorb it. Reporting device_types: ['HMJ-2', 'HMJ-3']
2026-08-22 05:21:06 INFO:astrameter:CT002 consumer 7ce71219ae84 phase detected: A
2026-08-22 05:25:55 INFO:astrameter:CT002: 15 W surplus but no AC-chargeable battery reporting — nothing here can absorb it. Reporting device_types: ['HMJ-2', 'HMJ-3']
2026-08-22 05:33:06 INFO:astrameter:CT002 consumer 2419720d40da phase detected: A

[blumstrauss]

I now gave it another try with switching on "Fair distribution" but no B2500 was kicking in when I switched on the oven. See attached log - now in debug mode

3bc06276_b2500_meter_2026-08-22T16-40-11.108Z.log

[tomquist]

I think this is mostly your config, and two settings in particular.

The one I'd change first is grid_predict_trust: 0. It defaults to 0.5, and it's what lets the loop account for output the batteries have already reported but the meter hasn't shown yet. With it off, every correction is calculated from a reading that's already stale, so the pool overshoots your load, backs off too far, and does it again. That matches what I see in your screenshots, the batteries aren't ignoring the demand, they just never settle on it. osc_damp_max: 0 (default 0.95) turns off the other guard against the same thing.

The battery sitting at 0 W is fair_distribution: false. A B2500's DC channel switches off completely below about 40 W, so a unit that gets handed less than ~80 W produces nothing at all and with fair distribution off, nothing ever corrects that. It just stays parked while the others run at 800 W.

So I'd try:

grid_predict_trust: 0.5      # was 0
osc_damp_max: 0.95           # was 0
fair_distribution: true      # was false
balance_deadband: 25         # was 5
concentrate_deadband: 60     # was 20
smooth_target_alpha: 0       # was 0.5
deadband: 0                  # was 6

The last two are worth dropping because your meter already updates every 3 s, smoothing it just adds lag.

Keep min_efficient_power: 150 though. I'd expect the instinct to be "set it to 0 so all five join in", but that backfires with five B2500: a 220 W base load splits to 44 W each, which is under the channel floor, so none of them discharge and you import the lot.