SOC-based load distribution for CT002/CT003 multi-battery setups

[RothMick]

When running multiple batteries in CT002/CT003 mode, AstraMeter currently distributes load based on fair-share balancing or efficiency optimization — but without any awareness of each battery's State of Charge (SOC), as far I know. This can lead to situations where a battery with very low SOC takes on the full load while a battery with high SOC stays idle.

Proposed Implementation
Add optional SOC entity configuration per battery MAC (e.g. via [CT002] section in config.ini)
Use SOC as a weighting factor in the existing fair-distribution algorithm
Fall back to current behavior if no SOC entities are configured

[robdidu]

Maybe this is a related issue: I have a two batteries setup, where each battery has only output 1 connected to the inverter. Due to load distribution, one battery is full a lot earlier than the other - which then triggers the surplus feed-in. Since only Output 1 is connected to the inverter, only the power from input 1 will be passed through. The surplus feed-in also seems to be capped, so that the other battery (that still isn't full), has to provide a lot of the necessary load, while the other kind of idles. This leads to a big waste of energy (One Panel off completely, passthrough of the other panel capped).

[irs-mima1]

In the case of a B2500 battery I heard that surplus feed-in only works from IN1 to OUT1 and from IN2 to OUT2 (real panel passthrough).

[robdidu]

That is exactly the case, that is why I want the each battery charged as long as possible, not one of them charging to full, while the other stems the most load.

[tomquist]

You don't need a code change for this, AstraMeter already exposes a per-battery Distribution Weight entity (the number.<battery>_distribution_weight you get from mqtt_insights: discovery). It's the relative fair-share weight the balancer uses when it splits the target across batteries: 1.0 is neutral, higher means that battery takes a bigger share, and 0 parks it. So instead of building SoC handling into the balancer, you can hook your batteries' SoC up to those weights with a Home Assistant automation and get exactly the behavior you described.

A simple approach: map each battery's weight inversely to its SoC so the emptier battery takes the larger share of charging power (neutral 1.0 at 50%, ~2.0 when empty, down toward 0 as it fills, so it stops pulling charge before it overflows into feed-in):

alias: AstraMeter – SoC-weighted battery distribution
description: >
  Bias AstraMeter's per-battery Distribution Weight by State of Charge so the
  emptier battery takes the larger share. Neutral (1.0) at 50% SoC, ~2.0 when
  empty, ~0 when full.
mode: restart
trigger:
  - platform: state
    entity_id:
      - sensor.battery_1_soc
      - sensor.battery_2_soc
action:
  - service: number.set_value
    target:
      entity_id: number.battery_1_distribution_weight
    data:
      value: >
        {% set s = states('sensor.battery_1_soc') | float(50) %}
        {{ [[ (100 - s) / 50, 0] | max, 10] | min | round(1) }}
  - service: number.set_value
    target:
      entity_id: number.battery_2_distribution_weight
    data:
      value: >
        {% set s = states('sensor.battery_2_soc') | float(50) %}
        {{ [[ (100 - s) / 50, 0] | max, 10] | min | round(1) }}

Swap in your own SoC sensors and the actual distribution_weight entity IDs (and add a block per battery if you have more than two). You can tune the curve by changing the divisor. / 50 gives the empty/neutral/full → 2.0 / 1.0 / 0.0 mapping above; a smaller divisor makes the bias more aggressive.

One thing to keep in mind: a single weight applies to whatever the balancer is doing at that moment, so "emptier gets more" is ideal for charging (which is the feed-in case you ran into) but is the opposite of what you'd want while discharging. If you also want to bias discharge, you can extend the automation to flip the mapping based on whether the system is currently charging or discharging (e.g. branch on grid/target power sign).

[sygys]

Thats indeed a very nice feature. Even better would be if you could configure the SOC entities in the astrameter config and adding a switch to the add-on to enable or disable even distribution.

What i would also like to see is an option to nerf charge and discharge min/max. So i could nerf the charge when it reaches 95% SoC. I have a cell in one of my batteries that has a 0.4 volt difference when the battery reaches 99% charge. When the battery charges on a lower wattage these values are allot less and for my feeling is safer then pumping 2500 watts in the battery and hope the bms will kick in on time.

But still i really love all the amazing work you have done by making this. Thank you for that!!

[sygys]

By the way i saw that yet again the repository changed to a new one. I was on version "next" and saw it was changed and has 2.1.2 now. My addon in home assistant didnt give me the update warning because yet again the repository changed. I hope at this point it will stay this way and every new version will be posted in the current repository. Its becoming a mess at the moment. Lots of people run different versions which state to have the latest version and missing functionality that people are talking about here. its confusing to say the least.. Must say i never had an add-on in home assistant that changed so many repositories in a few weeks/months.

[tomquist]

What do you mean, "yet again the repository changed to a new one"? The repository only renamed once from b2500-meter to AstraMeter and that change was backwards compatible, which means you could stay on the old repository and everything continues to work.

The next version doesn't auto-updated and should only be used if you want to test a pre-release. It's not meant for production. This is documented in the readme and always was like that. Not sure why you ever switched to the next version but it looks like you're confusing something. There was never the need to change the repository if you installed it correctly, not even when the renaming to AstraMeter happened.

[RothMick]

Thanks. I will try.

[RothMick]

Very cool project and many thanks!

[RothMick]

Works perfect with an automation

alias: AstraMeter - SoC-weighted battery distribution (output)
description: >-
  Distributes discharge output via Distribution Weight based on deviation
  from average SoC. g=2. Runs every 10min AND reactively on SoC change >=5%.
  Weight floor 0.3 instead of 0 -> no battery is ever parked (both stay active); guard: only computes
  when both SoC values are available (no writes during cloud flicker/unavailable).
triggers:
  - trigger: time_pattern
    minutes: /10
    id: tick
  - trigger: state
    entity_id:
      - sensor.hame_energy_hmj_2_123456789abc_host_battery_soc
      - sensor.hame_energy_hmj_2_cba987654321_host_battery_soc
    id: soc_jump
conditions:
  - condition: numeric_state
    entity_id:
      - sensor.hame_energy_hmj_2_123456789abc_host_battery_soc
      - sensor.hame_energy_hmj_2_cba987654321_host_battery_soc
    above: -1
  - condition: or
    conditions:
      - condition: trigger
        id: tick
      - condition: template
        value_template: >-
          {% set s3 =
          states('sensor.hame_energy_hmj_2_123456789abc_host_battery_soc') |
          float(50) %}{% set s4 =
          states('sensor.hame_energy_hmj_2_cba987654321_host_battery_soc') |
          float(50) %}{% set avg = (s3 + s4) / 2 %}{% set g = 2 %}{% set w3 =
          states('number.astrameter_consumer_hmj_2_123456789abc_distribution_weight')
          | float(1) %}{% set w4 =
          states('number.astrameter_consumer_hmj_2_cba987654321_distribution_weight')
          | float(1) %}{% set d3 = s3 - avg %}{% set dl3 = (w3 - 1) * 25 / g
          %}{% set d4 = s4 - avg %}{% set dl4 = (w4 - 1) * 25 / g %}{{
          (d3-dl3)|abs >= 5 or (d4-dl4)|abs >= 5 }}
actions:
  - action: number.set_value
    target:
      entity_id: number.astrameter_consumer_hmj_2_123456789abc_distribution_weight
    data:
      value: >-
        {% set s3 =
        states('sensor.hame_energy_hmj_2_123456789abc_host_battery_soc') |
        float(50) %}{% set s4 =
        states('sensor.hame_energy_hmj_2_cba987654321_host_battery_soc') |
        float(50) %}{% set avg = (s3 + s4) / 2 %}{% set g = 2 %}{{ [[1 + (s3 -
        avg) * g / 25, 0.3] | max, 10] | min | round(1) }}
  - action: number.set_value
    target:
      entity_id: number.astrameter_consumer_hmj_2_cba987654321_distribution_weight
    data:
      value: >-
        {% set s3 =
        states('sensor.hame_energy_hmj_2_123456789abc_host_battery_soc') |
        float(50) %}{% set s4 =
        states('sensor.hame_energy_hmj_2_cba987654321_host_battery_soc') |
        float(50) %}{% set avg = (s3 + s4) / 2 %}{% set g = 2 %}{{ [[1 + (s4 -
        avg) * g / 25, 0.3] | max, 10] | min | round(1) }}
mode: restart

[RothMick]

Settings for AstraMeter are tricky but currently works perfect.