The Marstek B2500s are real divas! - Solutions that might help you!

[RothMick]

Tom Quist is doing an excellent job of improving battery utilization.
I use two B2500 batteries and have encountered numerous quirks—both minor and major—that many other users have already described elsewhere. I’ve developed some small workarounds and tools for these issues, and things are running quite well at the moment. Perhaps this will be helpful to you, too:
Issues covered here:

• Reaching the discharge depth or 0 % SOC puts a battery into an off state. It does not leave that state when the feed-in threshold is reached again, for example because another battery is already covering the entire demand.
• If a battery is allocated less than its configured minimum output (min_dc_output), AstraMeter stops regulating it and only ever commands that exact minimum. From then on it no longer takes part in rising demand and stays stuck — usually at 0 W, because it will not start up at such a low output. The other battery keeps covering the demand alone, so it goes unnoticed.
• A battery does not start, or drops to 0 W, if no min_dc_output of 80 W or more is set. For some batteries 80 W sits right on a threshold that sends them into an idle state; some need 90 W or more as min_dc_output to run smoothly.
• After a brief connection dropout (blip) of bothe batteries, one comes back on only one of its two output channels. The ceiling is halved (eg ~200 W instead of ~400 W), but no reading shows it — the total sensor simply reports the single channel that is running. So far I have no Idea where the 30min Blips come from but looks like it is caused by the firmeware of the batteries.
• Or one output channel can be significantly below the other one for a longer time.
• The two batteries charge at different rates and drift apart in SOC. The emptier one reaches its discharge limit sooner and drops out of the control loop, instead of the difference evening out by itself.

First of all you have to install and run Tom Quists add-ons AstraMeter and HM2MQTT.

Automations:
A:
Problem: Some b2500 batteries won't start automatically when in
off state based on reaching the set discharge depth or 0% SOC.
Solution: This automation polls the actual values of both batteries
every 30sec and keeps adaptive_mode in sync: off below SoC 6 %, on
above SoC 10 %. Poll-based instead of edge triggers, so a threshold
crossing missed during Home Assistant downtime is corrected within a minute.

Hint: Keep a discharge depth of 97% as fallback to not reach 0% SOC

b2500_adaptive_switch.yaml

B:
Problems: A b2500 battery can't start or can stop delivering while the other
one covers the load alone - it sits at 0 W pinned to its minimum output, and
nothing reacts. A battery can also come back from a connection blip on only
one of its two output channels, which halves its ceiling without any sensor
showing it: the total output sensor simply reports the single channel that
still runs. Also one output channel can be significantly below the other
one for a longer time, which is an indicator for a malfunction.
Solution: This automation watches all cases per battery. A stall needs five
criteria at the same time for 10 minutes (0 W, saturation >= 99.5, command
equal to min_dc_output, SoC >= 13, other battery above 80 W). Channel
asymmetry needs the two output channels to differ by more than 60 W, also
for 10 minutes - this covers both a channel stuck at exactly 0 W and a
channel merely running well below the other. Both are cleared in two
stages: an AstraMeter consumer eviction, and if that does not help, a
battery restart.
Replace the placeholders battery1_mac / battery2_mac with their
actual hm2mqtt MAC addresses before using them.
b2500_watchdog.yaml

C:
Problem: When using two batteries, they charge at different rates and
have different SoCs.
Solution: Determines the two AstraMeter values ​​for the distribution
weighting (distribution_weight) based on the SoC difference between
the two batteries. A stepped table with three ranges is used, incorporating
hysteresis at each range boundary. Outside the operating range, a value
of 1.0/1.0 is actively written (instead of doing nothing) to ensure
that no skewed weighting persists.
Replace the placeholders battery1_mac / battery2_mac with their
actual hm2mqtt MAC addresses before using them.
b2500_weight_adjustment.yaml

Currently I'm using these settings for AstraMeter:

power_input_alias: sensor.electricity_meter_current
power_output_alias: ''
device_types: ct002
throttle_interval: 0
wait_for_next_message: true
marstek_auto_register_ct_device: false
marstek_mailbox: ''
marstek_password: ''
cloud_reporting: false
active_control: true
min_efficient_power: 0
efficiency_rotation_interval: 900
min_dc_output: 90
grid_predict_trust: 0.5
dashboard_allow_write: true
dashboard_direct_access: false
dashboard_allowed_hosts: ''
log_level: info
pace_base_step: 100
pace_max_step: 200