Intermittent Communication Failure with Marstek Venus v153 Firmware

[cmer81]

What's the issue?

After updating my Marstek Venus battery to firmware v153, I'm experiencing intermittent communication failures with the b2500-meter solution. The Venus battery stops querying the simulated Shelly Pro 3EM after random intervals (10 seconds to 2 minutes), then communication halts for indefinite periods before spontaneously resuming.

The issue appears to be on the Venus side (firmware v153 regression), but I want to check if others using b2500-meter have experienced similar problems with recent Marstek firmware updates.

Your setup

• Installation method: Docker
• Storage system: Marstek Venus Battery (IP: 192.168.2.118) - Firmware v153
• Power meter source: Shelly 3EM with b2500-meter simulation (acting as Shelly Pro 3EM)

Configuration

[GENERAL]
DEVICE_TYPE = shellypro3em
SKIP_POWERMETER_TEST = False
DISABLE_SUM_PHASES = False
DISABLE_ABSOLUTE_VALUES = False
POLL_INTERVAL = 1
THROTTLE_INTERVAL = 0

[SHELLY]
TYPE = 3EM
IP = 192.168.2.85
USER = xxx
PASS = xxx
METER_INDEX = 0

Error messages or logs

Network trace showing the intermittent behavior:
- Normal communication: JSON-RPC requests every ~500ms
- Random stops: Venus stops sending requests completely
- Variable recovery: Communication resumes after unpredictable delays

Sample tcpdump output showing normal operation followed by communication gaps:
16:48:50.261171 eth0  B   IP 192.168.2.118.22222 > 192.168.2.255.1010: UDP, length 50
16:48:50.290580 eth0  Out IP 192.168.2.3.1010 > 192.168.2.118.22222: UDP, length 155
16:48:50.838059 eth0  In  IP 192.168.2.118.22222 > 192.168.2.3.1010: UDP, length 50
16:48:50.883743 eth0  Out IP 192.168.2.3.1010 > 192.168.2.118.22222: UDP, length 155
[... normal communication continues ...]
16:49:14.271951 eth0  In  IP 192.168.2.118.22222 > 192.168.2.3.1010: UDP, length 50
16:49:14.336046 eth0  Out IP 192.168.2.3.1010 > 192.168.2.118.22222: UDP, length 153
# Then complete silence for indefinite periods before resuming

Additional info

• The system worked perfectly before the Venus v153 firmware update
• Network analysis shows no connectivity issues - the problem appears to be in the Venus firmware's communication scheduler/retry logic
• The b2500-meter continues responding correctly when queried
• Issue is reproducible and cyclical (normal → failure → recovery → repeat)
• Already opened a ticket with Marstek support

Has anyone else experienced similar issues with recent Marstek firmware updates when using b2500-meter?

[cmer81]

Update - Solution Found with Push Mode

Hello,

I've developed a solution to work around this Venus v153 communication issue. Instead of waiting for the battery to query the Shelly (which randomly stops), I implemented
a "push" mode that proactively sends power data to the battery.

Results

• ✅ No more communication interruptions - synchronization is now stable
• ✅ Improved performance - even more reliable than the original request/response mode
• ✅ Backward compatibility maintained - UDP server continues to work normally

Implementation

I've opened a PR with this feature: #181

Configuration is straightforward:

[GENERAL]
DEVICE_TYPE = shellypro3em
SHELLY_PUSH_MODE = True
SHELLY_PUSH_TARGET_IP = 192.168.2.8  # Your battery IP
SHELLY_PUSH_TARGET_PORT = 22222      # Your battery port
SHELLY_PUSH_INTERVAL = 1.0           # Interval in seconds

If other users encounter the same issue with Venus v153 (or future versions), this solution might help them. Feel free to test it and share your feedback!

[Ativelos]

Hey, really cool that you made a solution. How is it possible to implement your solution?
I'm pretty new to the github world.
(I use Home Assistant OS, in case that's relevant).

[alekratec]

Marstek Support wrote me that the Venus E V2 is getting the API with firmware update v153....
They sent me the API docu. I tried to test it with a small powershell, but it seems I get no answer.

Marstek_Device_Open_API_EN_(Rev1.0).pdf

[tomquist]

@alekratec Thanks for sharing. I already had a preview-release of this document and started with an integration but this document contains the missing pieces.