Per-device phase assignment for multiple batteries on an unbalanced 3-phase house?

[supergeorg68]

What problem does this solve?

I have the following setup:

• 2x Marstek B2500-D storage units
• 1x Shelly Pro 3EM as the grid meter (3-phase, reports L1/L2/L3 separately)
• Each B2500-D feeds a single-phase Envertech EVT2000SE microinverter (2 outputs per battery → 2 of the 4 EVT2000SE MPPT inputs)
• The house is a standard 3-phase connection with unevenly distributed loads across L1/L2/L3

Marstek's own "Auto-Adaptive" zero-export mode regulates against the summed total of all three phases (as read from the Shelly Pro 3EM), not against the specific phase each inverter physically feeds. In practice this means: when one phase has heavy load (e.g. an electric water heater) and another phase (the one our inverter is on) has low load, the summed total looks close to zero, but the battery keeps discharging based on the total — pushing real export onto its own phase while the other phase still imports.

We've confirmed this live with a Fritz!SmartEnergy meter reading the actual utility meter (optical interface), showing sustained export (~500-700W) exactly correlating with the battery's output, even while total household demand was low.

Today there doesn't seem to be a way to make a single-phase inverter/battery combo regulate against only its own phase instead of the combined household total.

What would you like?

I'd like the ability to assign a specific phase (L1/L2/L3) as the regulation target for a specific battery/device, rather than always using the combined fleet total.

I saw the per-phase POWER_MULTIPLIER/POWER_OFFSET calibration option (e.g. "1,0,1" to null a phase) — could this be used per-device to effectively isolate a single phase as that device's target? Or is the CT002/CT003 "shared target across the fleet" architecturally always a single combined value for all coordinated batteries?

If there's currently no way to do this, is per-phase targeting something on the roadmap, or is there a recommended workaround for single-phase inverters on unbalanced 3-phase houses?

[demichve]

Hi,
You could change this in the Marstek app in the CT settings for the device.
Change from 3-phases sum to 1-phase . When I do this, the app recognize automatically, on which phase the device is running and controls only this phase.
But I didn‘t get, what the advantage would be?

[supergeorg68]

Thanks for the tip! I checked the app (v1.6.72) but couldn't find that option. Under "Konfiguration" I can only select which CT-device model I have (Shelly Pro 3EM / Shelly EM Gen3 / Shelly PRO EM-50 / EcoTracker Beta) — confirming the selection doesn't open any further settings, and there's no "3-phases sum vs. 1-phase" toggle visible there. Could you point me to the exact menu path (or send a screenshot)? Is this setting maybe per storage device rather than global on the CT device?

[demichve]

It‘s visible, when clicking on „CT“ for the device.

[supergeorg68]

"Thanks for the screenshot! Our CT002 page (app v1.6.72) looks different from yours — no 'Referenz der Ausgangsleistung' box appears on the main view, and it's not in the settings menu either (only WLAN configuration, reverse measurement direction, diagnostics, hardware reset, factory reset, device sharing, warranty, device info). Which app version are you running? Wondering if this feature requires an app update we haven't received yet."

[demichve]

No,
You have to navigate to the CT settings on your device page.

[supergeorg68]

Quick question: your screenshot shows "Marstek Venus E" — is that a different model from our B2500-D? We don't see a "CT" button anywhere on our real B2500-D storage pages (only checked the group/combination settings we mentioned before). Is the CT button specific to Venus-series devices, or should it also appear for B2500?

[supergeorg68]

Found it — in the virtual/preview device gallery, "Venus E" does show a CT button with the 3-phase/1-phase choice, but "B2500" doesn't have that button at all (checked both real and preview). So this confirms it's model-specific — B2500-D doesn't seem to support per-phase CT regulation natively. Can you confirm this is a hardware/firmware limitation of the B2500 series, or is there a way to enable it?

[thowiegit]

@supergeorg68 The only way to achieve what you want is to simulate a separate CT002 for each B2500 storage unit and to assign to it only the sensor that matches the phase on which the inverter for that specific B2500 is connected.

[supergeorg68]

Thanks! Just to clarify for our specific setup: our 2 B2500-D units share a single physical micro-inverter (all 4 inputs, 2 per storage), fully on one phase. So both storages should target the exact same phase value, not different ones. Does your advice (separate CT002 per storage) still apply here, or is FAIR_DISTRIBUTION within a single CT002 the right approach when multiple storages share one inverter/phase rather than each having their own?

[supergeorg68]

Follow-up with a fully reproduced, isolated bug report for our setup (single EVT2000SE feeding two B2500-D units, one CT002 fake device with FAIR_DISTRIBUTION).

Bug 1 (found and fixed on our side): sign convention mismatch in a custom [JSON_HTTP] powermeter source

Our Shelly Pro 3EM reports a_act_power with positive = feed-in, negative = import (verified via a controlled before/after plug-pull test). AstraMeter's built-in meter integrations (Fritz, Tibber, Fronius) all document the opposite convention (positive = import). Since we feed the Shelly value into AstraMeter via a custom [JSON_HTTP] source (to isolate a single phase — see earlier comments in this thread), the raw value was passed through with no correction, so AstraMeter treated every real import as phantom surplus and vice versa. Fixed with POWER_MULTIPLIER = -1 on the [JSON_HTTP] section (confirmed via LOG_LEVEL=debug: Successfully fetched TransformedPowermeter powermeter value now shows the correct sign, and the per-consumer target delta jumped from ~16 W to 30 W immediately).

Might be worth a doc note for anyone rolling their own [JSON_HTTP]/generic source against a meter whose polarity isn't already normalized — this cost us a full day of chasing a phantom "phase" issue before we found it.

Bug 2 (still open, not something we can fix on the AstraMeter side): B2500-D auto CT-follow mode doesn't sustain the CT002 target at all

With the sign fixed, AstraMeter now sends a correct, persistent discharge request (confirmed via debug log: request/response pairs every ~1s, delta pinned at the pacer's first step and holding). Live A/B test on one of our two B2500-D units:

Step	Reported output (device→AstraMeter, power= field)	Real grid deficit on the relevant phase (independent smart meter)
Auto CT-follow, correct signal, sustained >10 min	3–6 W	≈ −280 W (unchanged)
Switched to Manual, set 150 W	ramps to 150 W within ~1 min	improves to ≈ −220 W
Switched back to Auto immediately	collapses 281 W → 2–8 W within ~10 s	reverts to ≈ −286 W within ~10 s

So the hardware/inverter path is fine (manual mode proves it can sustain 150 W without issue), and the CT002 signal from AstraMeter is now provably correct — but the device's own auto CT-follow logic doesn't seem to act on it at all, dropping back to near-zero within seconds regardless of what's requested. This looks like either a firmware bug/limitation in the B2500-D's CT-follow implementation, or something in the CT002 packet format/cadence that this firmware doesn't trust/parse the way AstraMeter emits it.

Device info: B2500-D, firmware V116, Wi-Fi V202409090159, device_type=HMJ-2 in the CT002 handshake.

Has anyone seen this specific "auto mode ignores the CT002 target entirely" behavior before, as opposed to a slow/rate-limited response? Happy to gather more debug output (raw UDP hex, timing) if useful.

[thowiegit]

Just to clarify for our specific setup: our 2 B2500-D units share a single physical micro-inverter (all 4 inputs, 2 per storage), fully on one phase. So both storages should target the exact same phase value, not different ones. Does your advice (separate CT002 per storage) still apply here, or is FAIR_DISTRIBUTION within a single CT002 the right approach when multiple storages share one inverter/phase rather than each having their own?

At least all of them should be on the Same CT002.

It wasn't really a advice, but rather a suggestion on how you can achieve the goal you described above.
Nor was the intention to have one CT002 per storage unit, but rather one CT002 per phase, which would then serve all storage units on the same phase. Of course, each per phase CT002 should only be able to "see" that one specific phase.

If you want my advice, I'd completely abandon the idea of having the individual storage units balance consumption exclusively on the phase to which they're connected.

[supergeorg68]

Thanks for clarifying — good to know our single-CT002-per-phase setup (both B2500-D units, same phase) already matches what you meant.

On the last point: could you elaborate on what you'd do instead of phase-exclusive balancing? Was that a general architectural take, or specifically informed by the "auto CT-follow ignores the target entirely" behavior we're seeing in Bug 2 above? We're trying to figure out whether that's a B2500-D firmware limitation we should report elsewhere, or something an alternative AstraMeter approach could route around.

[tomquist]

You can do this today with per-battery powermeter sections, but it only works cleanly in some setups.

Add one section per phase and restrict each to the polling battery's IP:

[SHELLY_L1]
TYPE = 3EMPro
IP = 192.168.1.101
POWER_MULTIPLIER = 1,0,0
NETMASK = 192.168.1.50/32

[SHELLY_L2]
TYPE = 3EMPro
IP = 192.168.1.101
POWER_MULTIPLIER = 0,1,0
NETMASK = 192.168.1.51/32

Same meter twice, other phases nulled. The first section whose netmask matches wins, so give the batteries static leases.

Two things to know before you build on it:

With active control this breaks. The balancer keeps one grid estimate and one distribution pool per CT002 instance, so whichever battery polled last overwrites it, and a battery on L1 can be told to cover L3's import. To really split phases you need a separate CT002 instance per phase, each on its own IP with its own batteries. Without active control it's a plain relay and per-battery meters are fine. In your setup both units sit on the same phase, so one instance with one phase-filtered meter is the right shape anyway.

I'd question the goal. If your utility meter nets the three phases, and most do that, then zeroing the sum is what minimises your bill, and per-phase regulation costs you money. You later found your Shelly feed had the sign inverted, which would produce exactly the "battery discharging while the house imports" picture you started from. Worth re-measuring the original export before changing the architecture.

The auto-mode collapse looks unrelated to phases, better as its own issue. One thing to check in the debug log: the phase character the battery sends. If it's 0, the device hasn't settled on a phase and AstraMeter relays raw readings instead of steering it.

[supergeorg68]

Checked the debug log for the phase character tomquist mentioned — across the entire log since DEBUG was enabled (~35k CT002 packets from both units), it's consistently phase='A', never 0. So the device has settled on a phase correctly; that's not what's causing the auto-mode collapse.

Happy to pull other fields from the debug log (raw UDP hex, timing between request/response, target vs. reported power fields) if that would help narrow it down further.

[tomquist]

Converting this issue to a discussion: the question is answered, and there's no per-phase work planned.

The auto-mode collapse is unrelated to phase assignment. Please open it as a separate bug report.