Need help: CT002 detected correctly but output regulation stops working

[A-Void-Me]

What's the issue?

I need some help with the CT002 setup.

On both of my Marstek B2500 devices I can successfully select the CT002, and the current power consumption is displayed correctly.

However, both batteries regulate the output power only for a few seconds and then stop adjusting completely. After restarting the AstraMeter App, regulation works again for a few seconds before stopping again.

The logs continue normally and both devices keep communicating with the CT002 emulator, but the actual output regulation stops.

It does not matter whether I use the UI configuration or config.ini.

I already tried:

complete app reinstall
restarting both batteries
recreating all configs from scratch

Both batteries have a stable network connection.

Your setup

Installation method:

• Home Assistant Add-on

Storage system:

• Marstek B2500 HMA1 (Firmware V230.7)
• Marstek B2500 HMA2 (Firmware V230.7)

Power meter source:

• JSON_HTTP ($.power)

Installed apps:

• AstraMeter (Dev)
• Hame Relay
• hm2mqtt

Configuration

[GENERAL] 
DEVICE_TYPE = ct002 
POLL_INTERVAL = 1 
THROTTLE_INTERVAL = 0 

[CT002] 
CT_MAC = 
UDP_PORT = 12345 
DEDUPE_TIME_WINDOW = 0 
ACTIVE_CONTROL = True 
FAIR_DISTRIBUTION = True 
SATURATION_DETECTION = True 

SMOOTH_TARGET_ALPHA = 0.9 
DEADBAND = 30 
WIFI_RSSI = -50 
MIN_EFFICIENT_POWER = 150 
EFFICIENCY_ROTATION_INTERVAL = 900 

[JSON_HTTP] 
URL = http://192.168.100.143/v1/json 
JSON_PATHS = $.power

Error messages or logs

Add-on version: next You are running the latest version of this add-on. System: Home Assistant OS 17.3 (amd64 / qemux86-64) Home Assistant Core: 2026.5.1 Home Assistant Supervisor: 

2026.05.0 2026-05-14 09:54:41 INFO:astrameter:CT002 UDP server listening on port 12345 2026-05-14 09:54:41 INFO:astrameter:MQTT Insights connected to 192.168.100.30:1883 2026-05-14 09:54:42 INFO:astrameter:CT002 consumer 94706ccdaf22 phase detected: A 2026-05-14 09:54:44 INFO:astrameter:CT002 consumer e88da6f35471 phase detected: A 2026-05-14 09:54:44 INFO:astrameter:Efficiency: deprioritizing consumer e88da6f35471 (demand 272W, 1 active)
...
2026-05-14 09:55:30 DEBUG:astrameter:CT002 request from ('192.168.100.50', 10000): 010235307c484d412d327c6538386461366633353437317c484d452d347c3032623235303135626134337c417c3230033137
2026-05-14 09:55:30 DEBUG:astrameter:CT002 parsed fields from ('192.168.100.50', 10000): meter_dev_type=HMA-2 meter_mac=e88da6f35471 ct_type=HME-4 ct_mac=02b25015ba43 phase='A' power=20 consumer_id=e88da6f35471
2026-05-14 09:55:30 DEBUG:astrameter:CT002 response to ('192.168.100.50', 10000): 010239337c484d452d347c3032623235303135626134337c484d412d327c6538386461366633353437317c2d32307c307c307c2d32307c317c307c307c307c2d35307c38327c307c307c307c307c307c307c34317c307c307c30033464 (fields=['HME-4', '02b25015ba43', 'HMA-2', 'e88da6f35471', '-20', '0', '0', '-20', '1', '0', '0', '0', '-50', '82', '0', '0', '0', '0', '0', '0', '41', '0', '0', '0'])
2026-05-14 09:55:30 DEBUG:astrameter:CT002 request from ('192.168.100.124', 10000): 010235307c484d412d317c3934373036636364616632327c484d452d347c3032623235303135626134337c417c3230033466
2026-05-14 09:55:30 DEBUG:astrameter:CT002 parsed fields from ('192.168.100.124', 10000): meter_dev_type=HMA-1 meter_mac=94706ccdaf22 ct_type=HME-4 ct_mac=02b25015ba43 phase='A' power=20 consumer_id=94706ccdaf22
...
Keeps repeating

Additional info

Both batteries continue sending CT002 requests and receiving responses normally, but the actual output regulation no longer changes after a few seconds.

I am not sure if this is a configuration issue, firmware limitation, or a problem with active control mode.

[tomquist]

Can you please send more logs than a timeframe of less than a second? Ideally at least 10 minutes.

[A-Void-Me]

Thanks for the fast reply.

I am pretty sure something is wrong with my configuration, but it does not seem to matter how I change it. Even running with the default configuration does not work properly.

Here are some logs:

34dea19a_b2500_meter_longertimeframe.log
34dea19a_b2500_meter_10Min.log

[tomquist]

The logs show that AstraMeter is working correctly, but the batteries aren't following the targets it's sending. Across the whole 10‑minute capture, both HMA‑1 (94706ccdaf22) and HMA‑2 (e88da6f35471) report a near‑constant AC output of ~18–22 W, with only a handful of samples ever above 50 W. The CT002 emulator is continuously sending varying targets (150–280 W demand), the batteries acknowledge them on every cycle, but they refuse to discharge.

The saturation detector picks up on this:

Efficiency: 94706ccdaf22 cannot follow target (sat=0.41), rotating to e88da6f35471
Efficiency: e88da6f35471 cannot follow target (sat=0.42), rotating to 94706ccdaf22

So the "regulates for a few seconds then stops" you're seeing is the rotation thrash between two saturated batteries< neither is actually discharging.

Please check on each B2500 in the Marstek app:

1. Work mode is set to "Automatic" (not Manual / Self‑use schedule).
2. Current SoC and configured DoD: if SoC is at or below the DoD floor, the battery will stay paired and keep reporting, but won't discharge. Note the SoC on each unit and what DoD limit is configured; adjust the DoD temporarily (or wait for more PV) to confirm.

To take the efficiency rotation out of the picture while you debug, temporarily set MIN_EFFICIENT_POWER = 0 (or comment it out). That forces both batteries to be commanded simultaneously instead of rotating one at a time, which makes it much easier to see whether a battery responds at all.

[A-Void-Me]

Both batteries are set to Automatic and are at 100% SoC. The DoD was set to 0%, and I changed it to 10%.

Both batteries have PV input, but since they are already full, they do not discharge. "Surplus Feed-In" is active.

I will also try your suggestion with MIN_EFFICIENT_POWER = 0 and report back later.

Thanks for your help.

[tomquist]

DoD of 0% means the battery can not be discharged at all. DoD of 10% means it can be discharged to 90% only. You might want to set the DoD to 90% instead.

[A-Void-Me]

Yeah, sorry, I think I mixed them up.

The "Backup Capacity" is set to 10%, the DoD at 90% ;D

[A-Void-Me]

I let it run for about 40 minutes now, but unfortunately the problem still exists even with MIN_EFFICIENT_POWER = 0.

My house constantly has a demand between 150W and 300W, but both batteries only feed in around 20W continuously. Anything above that only happens briefly for a few seconds / minutes.

So at the moment I cannot achieve a low house consumption because the batteries are not properly following the requested targets.

At around 2026-05-14 16:50:27, the output dropped from 177W down to 20W.

After that, it stayed at 20W continuously.

Am I missing something? Are my settings wrong, or could there be something wrong with my overall setup?

I also have another inverter running that feeds power into the house. Could that possibly interfere with this system?

34dea19a_b2500_meter_2026-05-14T14-51-55.234Z_10min.log

[tomquist]

I think this might already be fixed by #359, which just landed on develop. Your "another inverter feeding into the house" is the smoking gun: any time the B2500s' output plus that inverter momentarily exceeds your house load, the grid reading briefly goes negative — and the old code reacted to any negative reading by slamming all DC-only batteries to 0 W via steer_to_zero, even with no Venus in the pool to protect. That matches your screenshot exactly: brief spikes up to ~177 W, then a collapse to a ~20 W floor, repeating. The 20 W is the B2500's idle/minimum-active level after each slam, and it never gets to recover before the next transient triggers another collapse.

Could you try the next develop build (should be available shortly) and report back? With the fix, pure-DC pools ride brief negative-grid transients through the smooth fair-share path instead of collapsing.

[A-Void-Me]

As soon as I can update, I will report back.

Thank you very much for the fast fix and the quick responses.

[A-Void-Me]

I tried the update now and updated to 2.0.1, but unfortunately the problem still persists.

Do I need to change my config or anything else?

At night, only these two batteries are active, so there should be no other inverter interfering with the system then.

11e5258b_b2500_meter_2026-05-16T21-56-03.730Z.log

[ghino18]

Hi, i think that i have a similar problem. I have the battery on one of the input of my hoymiles inverter. And i think that It interfers . If i have Power from a panel It blocks b2500 Power supply. In fact It starts to work correctly After sunset . Strangely if the battery works until sunrise and It feeds Power before PV start to produce Energy the b2500 continue to work correctly also After that PV produce Energy, while the battery does not start After PV give Energy and It is blocked.