Marstek Venus E 3.0 (Firmware V148) does not discover AstraMeter (CT002/Shelly emulation)

[weisssven-iob]

What's the issue?

Summary

I am trying to use AstraMeter as a replacement for a Marstek CT002 Smart Meter with two Marstek Venus E 3.0 battery systems.
Unfortunately, AstraMeter is never contacted by the batteries although everything appears to start correctly.
I'm wondering if something has changed in Venus firmware V148.

Environment

• AstraMeter: latest GitHub version (current master)
• Docker deployment on Ubuntu Server
• ioBroker used as power source
• Two Marstek Venus E 3.0
• Firmware: V148
• One genuine Marstek CT002 available for comparison
• All devices connected to the same LAN/WLAN

Network:

Ubuntu Server (AstraMeter): 192.168.2.101

Venus #1
LAN: 192.168.2.48
WLAN: 192.168.2.47

Venus #2
LAN: 192.168.2.50
WLAN: 192.168.2.49

Original CT002
192.168.2.53

What works

• AstraMeter starts successfully.
• ioBroker values are read correctly.
• Modbus TCP communication to both Venus batteries works.
• Batteries can be read via Modbus without issues.

AstraMeter log:

Successfully fetched IoBroker powermeter value: XXXX W
Shelly emulator listening on UDP port 1010

or
Shelly emulator listening on UDP port 2220
depending on configuration.

Tested device types

ct002
DEVICE_TYPE=ct002
No communication observed.

shellypro3em_old
DEVICE_TYPE=shellypro3em_old
Initially failed because Linux prevented binding to UDP port 1010.
After:
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=1010
AstraMeter starts correctly and listens on UDP 1010.
Still no communication from Venus.

shellypro3em_new
DEVICE_TYPE=shellypro3em_new
Starts successfully on UDP port 2220.
Still no communication from Venus.

Network captures

The following ports have been monitored using tcpdump:

UDP 1010
UDP 2220
UDP 12345

Result:
No packets from either Venus battery to AstraMeter.

Observations

While monitoring general network traffic we observed that older captures contained broadcast packets like

{
  "id":0,
  "method":"EM.GetStatus",
  "params":{"id":0}
}

However, with the current setup and firmware V148 we cannot reproduce communication towards AstraMeter.
The original CT002 works correctly with both batteries.

Source code investigation

The current source contains:

shelly.py

if request.get("method") == "EM.GetStatus":
    response = self._create_em_response(...)

Therefore AstraMeter appears to support the expected RPC message.
The emulator also starts successfully.

Question

Has anyone tested AstraMeter with:

• Marstek Venus E 3.0
• Firmware V148

Has Marstek changed

• discovery,
• UDP ports,
• registration,
• or the communication protocol

in recent firmware versions?

Available diagnostics

I can provide:

• PCAP captures
• Docker logs
• tcpdump output
• Modbus register dumps
• Original CT002 available for comparison
• Two Venus E 3.0 systems

If needed, I can also perform additional packet captures or protocol tests.

PCAP Files.zip

venus-v148-debug.pcap.zip

Additional note
The original CT002 is detected and works correctly with both batteries, therefore the batteries themselves appear to function normally. The issue only occurs when replacing the CT002 with AstraMeter.

Version

Current Git master

Installation method

Docker

If "Other", which?

No response

Configuration

# Generated with the AstraMeter config generator.
# Re-import this file there any time to keep editing.

[GENERAL]
DEVICE_TYPE = ct002
SKIP_POWERMETER_TEST = False
WEB_CONFIG_ENABLED = True

[IOBROKER]
IP = 192.168.2.101
PORT = 8087
CURRENT_POWER_ALIAS = 0_userdata.0.Variablen.total-Power-Netz-HH

[CT002]
CT_MAC = 009c17c24dc8

Logs

astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:started astrameter application
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:Git commit not logged (set GIT_COMMIT_SHA at image build for CI images)
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Device Types: ['ct002']
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Device IDs: ['device-1']
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Skip Test: False
astrameter-1  | 2026-07-07 21:44:42 DEBUG:asyncio:Using selector: EpollSelector
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Starting web server...
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Web server started on 0.0.0.0:52500
astrameter-1  | 2026-07-07 21:44:42 WARNING:astrameter:Config editor is ENABLED — unauthenticated read/write access is active. Disable WEB_CONFIG_ENABLED when not in use.
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Config editor accessible at http://0.0.0.0:52500/config
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Web server started successfully
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:Testing powermeter configuration... (attempt 1/4)
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Successfully fetched IoBroker powermeter value (filter 0.0.0.0/0): -1W
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:Starting device: ct002
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:CT002 Settings for device-1:
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:CT Type: HME-4
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:CT MAC: 009c17c24dc8
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:CT UDP Port: 12345
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:WiFi RSSI: -50
astrameter-1  | 2026-07-07 21:44:42 DEBUG:astrameter:CT control model: active control (emulator computes targets)
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:Active control enabled: load split + fair distribution + saturation detection
astrameter-1  | 2026-07-07 21:44:42 INFO:astrameter:CT002 UDP server listening on port 12345
astrameter-1  | 2026-07-07 21:44:45 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:45:15 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:45:45 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:46:15 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:46:45 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:47:16 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:47:46 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:48:16 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:48:46 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:49:16 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:49:46 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:50:16 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:50:46 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:51:16 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:51:46 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:52:16 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:52:47 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:53:17 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:53:47 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:54:17 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:54:47 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:55:17 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:55:47 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:56:17 DEBUG:astrameter:Health check request received from 127.0.0.1
astrameter-1  | 2026-07-07 21:56:47 DEBUG:astrameter:Health check request received from 127.0.0.1

[tomquist]

How are you starting the container? Please share your docker run command or docker-compose.yml.

Most likely the batteries' UDP packets never reach the container because it isn't on network_mode: host.

[weisssven-iob]

I'm already using network_mode: host.
docker-compose.yml:

services:
  astrameter:
    build: .
    network_mode: host
    restart: unless-stopped
    environment:
      - LOG_LEVEL=debug
    volumes:
      - ./config.ini:/app/config.ini

I also verified this with tcpdump running on the Ubuntu host (not inside the container).
I monitored UDP traffic on ports 1010, 2220 and 12345 while both Venus E 3.0 batteries (firmware V148) were operating in Self-Adaption mode.
No UDP packets from the batteries were observed on any of these ports.
Therefore it appears that the packets are not being lost by Docker. Instead, the batteries don't seem to send traffic to the expected ports anymore.

Has the communication protocol for Venus E 3.0 / firmware V148 changed compared to previous firmware versions? Or are you aware of any changes in the discovery mechanism?

[tomquist]

In the 10-minute venus-v148-debug.pcap, no CT traffic from the batteries reaches the capture machine. The only packets from 192.168.2.48/.50 are Modbus TCP responses. Zero UDP, no broadcasts to 12345/1010/2220.

This is not a V148 protocol issue. Plenty of users run V148 with AstraMeter successfully. The batteries most likely do send their CT requests, but the broadcasts never reach the segment your server is on:

• The batteries' WLAN IPs (.47/.49) don't appear in a single frame, and your router's ARP requests for .49 and the original CT002 (.53) go unanswered.
• marstek-wlan.pcap is empty (0 packets).

This points to an AP/mesh that doesn't forward broadcasts between WLAN and wired LAN (client isolation, broadcast filtering). To confirm:

1. Power the original CT002 back on, then run tcpdump -i <iface> udp port 12345 on the Ubuntu host. If the working CT002 traffic is also invisible, the traffic exists but doesn't reach your server. That's a network path problem, not AstraMeter or firmware.
2. Check your AP/router for client isolation or broadcast/multicast filtering between WLAN and LAN.
3. Confirm both batteries were in Self-Adaption mode with a CT paired during the capture. The Venus only polls a CT once one is paired.

I'll convert this issue into a discussion because it looks like this is an infrastructure problem.