Marstek Venus E v3: Modbus becomes unresponsive and manual discharge resets after reconnect

[Remueb]

Affected area

Battery communication or availability

Omnibattery version

1.4.0

Home Assistant version

2026.9.2

Installation details

Battery brand and exact model: Marstek Venus E 3.0
Battery firmware version: V150
Connection method or adapter: Ethernet, Modbus TCP port 502, Slave ID 1
Number of batteries: 1
Consumption sensor and update interval: EcoTracker IR, 60 s
Installation type (single-phase or three-phase): Three-phase

What happened?

When the Marstek Venus E v3 is manually commanded through Omnibattery to Force Mode "Discharge" with a discharge power of 500 W, the battery initially discharges correctly.

After a variable amount of time, Modbus communication becomes unresponsive. Omnibattery reports multiple failed reads, marks the battery unavailable and attempts a fresh connection.

Immediately after this communication failure/reconnect, Force Mode changes from "Discharge" to "None" and the discharge setpoint changes from 500 W to 0 W. The battery then stops discharging.

The problem is reproducible and has occurred several times after different operating durations.

During a controlled test I continuously monitored network connectivity. The Venus remained reachable on the local network during the actual Modbus failure, so the event did not coincide with a general Ethernet/IP connectivity loss.

Battery Manual Mode and RS485 Control Mode remained enabled during the controlled tests.

Steps to reproduce

1. Enable Battery Manual Mode for the Marstek Venus E v3.
2. Ensure RS485 Control Mode is enabled.
3. Set Force Mode to "Discharge".
4. Set discharge power to 500 W.
5. Do not interact with the Marstek app or change any other settings.
6. Wait while the battery discharges normally.
7. After a variable amount of time, observe Modbus read failures and a fresh connection attempt in the Home Assistant log.
8. Observe that Force Mode changes to "None", discharge power changes to 0 W and the battery stops discharging.

Expected behavior

Omnibattery should maintain the manually configured Discharge mode and 500 W discharge setpoint.

If the Modbus connection temporarily fails and reconnects, the previous manual control state should either remain active on the battery or be restored after communication has recovered.

A temporary communication failure should not permanently terminate the manually requested discharge.

Relevant Home Assistant logs

[Marstek Venus 3] Critical telemetry groups failed 3 consecutive polls: [('battery_power',), ('ac_power',), ('force_mode',), ('inverter_state',)]; attempting fresh reconnection

[Marstek Venus 3] Creating fresh connection to <local IP>:502 (consecutive failures: 3)

[Marstek Venus 3] All read attempts failed - marked unavailable

[Marstek Venus 3] Failed to read ['force_mode']

No response received after 2 retries, continue with next request

Diagnostics file

No response

Additional context

Possibly related to #445, which reports similar Modbus read failures and reconnect attempts with a Marstek Venus A. However, this report concerns a Venus E 3.0 and a different recovery behavior: communication recovers, but the manually configured Force Mode "Discharge" and 500 W discharge setpoint are lost and reset to None / 0 W after the communication failure/reconnect.

Additional network testing:

During a controlled reproduction test, continuous ICMP monitoring was performed.

862 packets sent
859 packets received
3 packets lost
Average latency: 1 ms

There was no ping loss at the time of the actual Modbus/discharge failure.

TCP testing also showed that while Omnibattery is active, an additional TCP connection to port 502 cannot be established. After disabling the Omnibattery integration, repeated TCP connections to port 502 succeed immediately.

This appears consistent with the Venus E v3 allowing only one Modbus TCP client/connection.

No second Home Assistant Modbus client for the Venus is configured.

Short inverter transitions between Discharge and Standby also occur during normal operation, but these normally recover without losing the 500 W command. The permanent loss of the command correlates with the Modbus communication failure/reconnect.

Confirmations

• I am using the latest available Omnibattery release and restarted Home Assistant after updating.
• I searched the documentation, existing issues, and existing discussions.
• I can reproduce this unexpected behavior; this is not a request for installation or configuration help.
• I removed passwords, tokens, API keys, complete serial numbers, IP addresses, and other sensitive information.

[Remueb]

Update: reproducible discharge interruption with v1.5.0b2

I was able to reproduce the issue twice today under controlled conditions.

Setup:

Marstek Venus E v3, firmware V150
Omnibattery v1.5.0b2
Manual battery mode enabled
Forced discharge at 500 W via Home Assistant
Marstek app completely closed

Test 1

08:13:23: No response received after 2 retries
08:13:41: Failed to read [force_mode]
08:13:41: All 9 read attempts failed ... marked unavailable
08:13:41: 3 consecutive failures - attempting fresh reconnection
08:13:41: Creating fresh connection to 192.168.0.44:502
08:13:48: discharge power changed to 0 W, force_mode changed to None, inverter went to Standby

Test 2

08:47:43: No response received after 2 retries
08:48:01: Failed to read [force_mode]
08:48:01: All 9 read attempts failed ... marked unavailable
08:48:01: Critical telemetry groups failed 3 consecutive polls ... attempting fresh reconnection
08:48:01: Creating fresh connection to 192.168.0.44:502
08:48:08: discharge power changed to 0 W, force_mode changed to None, inverter went to Standby

In both tests, the forced 500 W discharge initially worked correctly. There were several short Discharge → Standby → Discharge transitions before the final interruption.

The interesting part is that in both cases the final reset to 0 W / None occurred exactly 7 seconds after the logged fresh connection attempt.

After recovery, sensor.omnibattery_non_responsive_batteries returned to normal (unreachable: false, fail_count: 0, consecutive_failures: 0). Manual battery mode remained enabled.

I am not concluding that Omnibattery itself sends the 0 W / None command, but there appears to be a reproducible correlation between the communication failure/reconnect sequence and the forced discharge being cleared.

Is there any additional debug logging or diagnostic data I can provide to determine what clears set_discharge_power and force_mode after the reconnect?

[ffunes]

Thanks for the detailed reproduction, the timestamps made this traceable.

What we found. Omnibattery does not send that None / 0 W. In manual mode the integration never writes to a Marstek. The battery itself drops the forced mode. I tested on a Venus E v3 with EMS 148: a fresh TCP connection and the RS485 re-enable write both leave Force Discharge and its setpoint intact. So the reconnect is not what clears it. In your logs the reset lands about 25 s after the first failed read, during the stall itself. This looks like V150 firmware behaviour: its Modbus stack gets stuck (same root cause as #445) and it gives up the forced mode while it is stuck.

Recommendation. If you can, downgrade the firmware to V149. V150 is the version behind these Modbus stalls.

Fix. The next beta re-asserts your manual Charge/Discharge setpoint once the battery answers again after a stall. If it re-asserts, you will see this in the log:
Manual Discharge 500W lost on the battery (reads 0W) - re-asserting
The battery still stops for the duration of the stall itself; that part is firmware. Once you are on the beta, please confirm whether the discharge now resumes by itself.