CT003, two B2500: per-battery entities (Distribution Weight) missing despite active, steering consumers (v2.2.2)

[DamivanKenobi]

Hi,

WHAT I'M TRYING TO DO
I want my two Marstek B2500 to equalize their SoC: the fuller battery should take
the larger share when discharging, the emptier one spared - instead of one filling
early while the other carries the whole load. For that I need the per-battery
"Distribution Weight" entity so I can drive it by SoC via automation (the approach
from Discussion #443).

SETUP

• Two Marstek B2500 on a single Hoymiles HMS-1600-4T
• AstraMeter HA add-on v2.2.2, internal Mosquitto broker
• CT003 mode, ACTIVE_CONTROL = on, Fair Distribution = on
• CT003 is registered and visible in the Marstek app
• Both batteries run in auto mode via the CT003 and steer correctly to AstraMeter

PROBLEM
The consumers work - both batteries are being steered. Yet all per-battery controls
are missing in Home Assistant: Distribution Weight, Manual/Auto Target, Active,
Min DC Output. In MQTT only the "AstraMeter Powermeter" device appears with power
values (Power L1/L2/L3). No per-battery device, no weight entity. I'm on the latest
version (2.2.2), so it's not an outdated build.

QUESTIONS

1. Why are the per-battery entities missing even though both batteries are actively
   steered as consumers? Does the HA discovery of the per-battery controls need a
   separate setting, independent of the steering itself?
2. Is there a difference between CT003 and CT002 in how the per-battery entities are
   created?
3. Which MQTT topics show the active consumers (astrameter/ct003/+/consumer/+) so I
   can verify the consumer objects are actually being published?
4. If the entities can't be created: can I set the Distribution Weight directly via
   an MQTT set-topic? What's the per-consumer topic?

WHAT I WANT TO DO WITH IT (once the entities exist)
My end goal is to run the SoC-weighted distribution automation from Discussion #443:
it biases each battery's Distribution Weight by its deviation from the average SoC,
so the fuller battery takes the larger discharge share and the emptier one is spared,
with a weight floor so neither battery is ever parked, and writes only when both SoC
values are valid. Without the Distribution Weight entities this automation has
nothing to write to - which is why my whole plan hinges on the question above.

Thanks for any pointers!

CT003, zwei B2500: Per-Batterie-Entitäten (Distribution Weight) fehlen trotz
aktiver, regelnder Consumer (v2.2.2)

Hallo zusammen,

MEIN VORHABEN
Ich will, dass sich meine zwei Marstek B2500 im SoC angleichen: Der vollere Speicher
soll beim Entladen den größeren Anteil übernehmen, der leerere geschont werden -
statt dass einer früh voll ist und der andere die ganze Last trägt. Dafür brauche
ich die Per-Batterie-Entität "Distribution Weight", um sie per Automation
SoC-abhängig zu steuern (Ansatz aus Discussion #443).

SETUP

• Zwei Marstek B2500 an einem Hoymiles HMS-1600-4T
• AstraMeter als HA-Add-on v2.2.2, interner Mosquitto-Broker
• CT003-Modus, ACTIVE_CONTROL = an, Fair Distribution = an
• CT003 ist registriert und in der Marstek-App sichtbar
• Beide Speicher laufen im Auto-Modus über das CT003 und regeln korrekt nach
  AstraMeter

PROBLEM
Die Consumer funktionieren - beide Speicher werden gesteuert. Trotzdem fehlen in
Home Assistant sämtliche Per-Batterie-Controls: Distribution Weight, Manual/Auto
Target, Active, Min DC Output. In MQTT erscheint nur das Gerät "AstraMeter
Powermeter" mit den Leistungswerten (Power L1/L2/L3). Kein Per-Batterie-Gerät, keine
Weight-Entität. Version ist die aktuellste (2.2.2), an einer zu alten Version liegt
es also nicht.

FRAGEN

1. Warum fehlen die Per-Batterie-Entitäten, obwohl beide Speicher als Consumer aktiv
   gesteuert werden? Braucht die HA-Discovery der Per-Batterie-Controls eine
   separate Einstellung, unabhängig von der reinen Steuerung?
2. Gibt es bei CT003 einen Unterschied zu CT002 bei der Erzeugung der
   Per-Batterie-Entitäten?
3. Welche MQTT-Topics zeigen die aktiven Consumer (astrameter/ct003/+/consumer/+),
   damit ich prüfen kann, ob die Consumer-Objekte überhaupt publiziert werden?
4. Falls sich die Entitäten nicht erzeugen lassen: Kann ich das Distribution Weight
   direkt per MQTT-Set-Topic setzen? Wie lautet das Topic pro Consumer?

WAS ICH DAMIT VORHABE (sobald die Entitäten da sind)
Mein Endziel ist die SoC-gewichtete Verteil-Automation aus Discussion #443: Sie
gewichtet das Distribution Weight jedes Speichers nach seiner Abweichung vom
Durchschnitts-SoC, sodass der vollere Speicher den größeren Entlade-Anteil übernimmt
und der leerere geschont wird - mit einem Weight-Floor, damit kein Speicher geparkt
wird, und Schreiben nur bei gültigen SoC-Werten. Ohne die Distribution-Weight-
Entitäten läuft diese Automation ins Leere - deshalb hängt mein ganzes Vorhaben an
der obigen Frage.

Danke für jeden Hinweis!

[thowiegit]

Ich kann das Problem auch für die CT002 Variante bestätigen.
Nicht immer, aber manchmal sind die Steuerungs Entitäten von aktuell aktiv gesteuerten Speichern nicht verfügbar.
Das ganze muss etwas mit dem Verhalten der Speicher selbst zu tun haben. Ich bin der genauen Ursache noch nicht wirklich auf den Grund gekommen, aber grundsätzlich entsteht das Problem immer dann wenn einer, oder mehrere der Speicher zum falschen Zeitpunkt gerade nicht im Smartmeter Modus sind und erst später in diesen hinein wechseln.
Leider konnte ich das ganze auch noch nie nachstellen wenn ich mal das Debug Log aktiv hatte, kann das aber auch nicht dauerhaft aktiv lassen, da es doch sehr große Mengen an Daten erzeugt.
Insgesamt würde ich es schon bevorzugen, wenn die Entitäten zur Anpassung der Speichersteuerung jederzeit verfügbar wären, auch wenn vielleicht gerade ein Speicher nicht in einem Zustand ist in dem das eine Auswirkung hätte.
Das Problem ist halt das die Speicher zum Teil sehr zickig in der Kommunikation sind.
Wenn ich die AstraMeter App neu starten muss, weil ein Speicher gerade zwar aktiv gesteuert wird, aber seine AstraMeter Entitäten nicht verfügbar sind, dann bringe ich durch den AstraMeter Neustart so manches mal einen der anderen 5 Speicher zusätzlich aus dem Tritt.
Entsprechend verstehe ich zwar das derzeitige Verhalten von AstraMeter, die Anpassungs Entitäten nur für aktuell als korrekt reagierend erkannte Speicher verfügbar zu halten, sehe darin aber auch klare Nachteile im Umgang mit zickigen Speichern, da es so deutlich komplexer ist einen aus der Reihe tanzenden Speicher automatisiert wieder einzufangen.

[DamivanKenobi]

Ja, das Problem bei mir ist eben, dass sie wirklich nie in der MQTT-Liste auftauchen, nicht nur manchmal.

[DamivanKenobi]

und nach dem neustart steht

2026-07-01 10:35:35 INFO:astrameter:MQTT Insights connected to core-mosquitto:1883
2026-07-01 10:35:35 INFO:astrameter:CT002 consumer 7cxxxxxxxxxxx phase detected: D
2026-07-01 10:35:37 INFO:astrameter:CT002 consumer 1xxxxxxxxxxxx phase detected: D

[DamivanKenobi]

Hallo zusammen,

ich habe den ganzen Tag experimentiert und die Lösung für das Problem gefunden. Damit beide Speicher korrekt in Home Assistant (HA) erkannt werden, müssen folgende Schritte durchgeführt werden:

Vorbereitung: Beide Speicher vorab manuell auf den Modus Manuell umstellen.

Gerätetausch: Den aktuellen CT003 komplett löschen und stattdessen einen CT002 neu anlegen.

Modus zurücksetzen: Nach dem erfolgreichen Anlegen des CT002 die Speicher wieder in den Auto-Modus versetzen.

Initialisierung:

Der erste Speicher wurde danach sofort automatisch erkannt.

Der zweite Speicher musste manuell neu gestartet werden. Anschließend war zusätzlich ein Neustart von Ahoy-DTU (Astra-Meter) erforderlich.

Nach diesem Ablauf sind nun beide Speicher ordnungsgemäß und dauerhaft in Home Assistant verfügbar.