Anormal change from Discharge to Standby status on VENUS Ev3

[pvodoz]

Hi All,
I noticed some regular changes on both Venus E v3 from inverter state Discharge to standby:

I assume it's not a normal behaviour and I wonder if this is due to RS485 stability from Marstek... Alone with this behaviour?

[ffunes]

Hi,

Doesn't look normal to me, to be honest. And I can't relate that frequency, every 2 mins or so, to any process running in the integration. Would be nice if you could share a debug trying to capture when the issue happens.

Thanks

[pvodoz]

Here is a trace in the morning around 07:30:49 when it occured.

Batterie 1 went from Discharge to Standby then Discharge
We can see that the power of "Batterie 1" power changed from around 80W to 0 then 80W (no change on Batterie 2)

marstek_only.log

[ffunes]

Just to confirm, you are on the latest integration version?

[pvodoz]

yes v1.8.1

[pvodoz]

@ffunes , I have enabled the debug mode this morning in the integration and then tested 3 periods:

1. enable the manual mode of the integration and set the batterie 1 in self antifeed mode (without RS485 control)
2. set discharge mode with RS485 control on batterie 1
3. set the automatic mode with the integration.

I only reproduce the switching to 0W during the automatic mode. No problem in self antifeed mode and static discharge mode.

My reading of the logs:
2026-05-14 05:30:07.549 ==> MANUAL MODE ENBALED in manager
I disabled the RS485 control of Batterie 1 and set in antifeed mode
During the antifeed period, no trace of Battery power value polling in logs but the values are updated in statistics (lacks of logs or uncomplete debug mode?)
no power switching to 0W during this period

Around 05:36:30 to 2026-05-14 05:50:57.992 , enable RS485 in Batterie 1, mode discharge and set discharge port to 150W
No logs of the actions at 05:36:30 except the log: "PD parameters hot-reloaded..."
For unknown reason, start of DEBUG logs at 2026-05-14 05:45:10.944, no logs before...
no power switching to 0W during this period

2026-05-14 05:50:57.992 MANUAL MODE DISABLED ==> the Batterie 2 is choosen for power supply handling
First switching to 0W at 2026-05-14 05:52:32.995 (Received data from register 32302 (0x7E2E): [0])
No change of mode Discharge to standby because no modbus request on inverster state

Next, We can see mulitple switching to 0W and standby mode (when request on inverter state)
marstek_logs_nettoyes.txt

[ffunes]

Hi,

Sorry for the lack of information, two days ago one of my batteries died and I have been dealing with Marstek support so they can replace the battery. Regarding this discussion, unfortunately I am not able to tell what is going on in your setup, however I am pushing a new release with clearer debug messages, that maybe will help us see what is going on. It will be ready in a couple of minutes.

Best regards

[pvodoz]

Upgrade done. All logs are clean, the polling is complete and the power_ac is really at 0w and inverter state in standby mode! It seems that the issue comes from the battery. I tried with another battery and haven't this issue. I have asked an upgrade of the communication module from 202409090159 to 20250624541
Wait & see...
Thank you for your help and great job!!

[pvodoz]

@ffunes , Both Venus E are now in same firmware (communication module 20250624541, BMS 113, EMS 148, VMS 119)
I still have the issue on the second battery which seems to bug every 2 minutes.
I tried to configure the integration with just one battery (the faulty one) and same issue.
The problem even occurs in manual mode when I set the charge or discharge power value...

I also have unused ESP32 RS485 dongle that I can use by connecting in the RS485 port of my Venus E v3. Then, I can drive the battery through ESPHome entities.
I will try to set a charge or discharge power value to see if same problem occurs...
By the way, if no issue with the RS485 dongle, do you think it could be possible to drive the battery with your integration through ESPHome entities?

[ffunes]

I am not aware of how ESPHome entities work, sorry. Do you connect like an elfin ew11?

[pvodoz]

ESPHome entities are created in HA (switch, numbers, etc) when importing the device.
Rather than define the battery through its IP address, we should define the different entites like (SOC, working mode, etc...)

[ffunes]

Hi,

Unfortunately, the connection method you mentioned is not supported, nor will it be implemented in the future. You can purchase an Elfin EW11A and connect it to the ethernet port, that mode is supported on v3 batteries.

Best regards

[engelsofta]

I have been able to trace this error back to the fact that, during these spikes, the API query consistently takes a very, very long time to return a response. Typically, response times range from 0.5 to 1.5 seconds; during these spikes, however, it takes up to five seconds. I suspect that a conflict within the control system is occurring at these moments. I received firmware version 149 today—I will report back on whether this has resolved the issue.

[engelsofta]

I am still experiencing the problem with the new version—it has improved, but it persists. At irregular intervals, the API still takes a very long time to respond.

2026-05-27 11:53:24.990 DEBUG (MainThread) [custom_components.marstek_venus_energy_manager.coordinator] Finished fetching Marstek Venus V3 data in 3.540 seconds (success: True)
2026-05-27 11:53:25.390 DEBUG (MainThread) [custom_components.marstek_venus_energy_manager.coordinator] [Marstek Venus 1] Poll summary: attempted=20 succeeded=20 updated=20 skipped_interval=7 skipped_disabled=9 dependency_reads=2 values={'battery_soc': 83, 'battery_power': -13, 'internal_temperature': 35.3, 'ac_power': 0, 'inverter_state': 1, 'battery_voltage': 53.6, 'max_cell_voltage': 3.336, 'min_cell_voltage': 3.333, 'fault_status': 0, 'alarm_status': 0, 'ac_offgrid_power': 0, 'set_charge_power': 0, 'set_discharge_power': 0, 'max_charge_power': 2250, 'max_discharge_power': 2200, 'charging_cutoff_capacity': 100.0, 'discharging_cutoff_capacity': 12.0, 'force_mode': 0, 'backup_function': 1, 'rs485_control_mode': 21930}
2026-05-27 11:53:25.390 DEBUG (MainThread) [custom_components.marstek_venus_energy_manager.coordinator] Finished fetching Marstek Venus 1 data in 3.598 seconds (success: True)
2026-05-27 11:53:26.926 DEBUG (MainThread) [custom_components.marstek_venus_energy_manager] Power plan [pd]: mode=charge grid=-148.8W target=0.0W error=-148.8W prev=552.4W request=590.0W allocated=590W available=2 selected=['Marstek Venus V3'] allocation={'Marstek Venus V3': 590} restricted=False charge_blocks=none discharge_blocks=none setpoints=offsets=user_target=0.0W active_override=none overrides=none

@ffunes I need your help now ;-) ... could this lead to a control system issue, given that it is expecting—or operating with—incorrect values ​​in the meantime?

[pvodoz]

@ffunes , only "None" value...

[ffunes]

Hi
v2.0.0b1 is out, you will need to manually download from HACS. I have included a fix for PD starvation, maybe it can help:

• PD control starved by polling on slow batteries (v3): The Modbus poll loop acquired and released the coordinator lock for each register but never yielded the event loop between iterations. On v3 batteries where a full poll cycle takes ~3 s, the PD control writer waiting on the lock was repeatedly bypassed as the tight for loop re-acquired the lock before asyncio could schedule the writer. Added await asyncio.sleep(0) after each register read so the event loop gets a tick to hand the lock to the PD control coroutine between reads.

[pvodoz]

Same result with v2.0.0b1.
But very weird. With 2 batteries in same software version, different behaviour for each battery.
I must try a faulty battery with an esp rs485 dongle to check if the issue still exists

[ffunes]

Hi,

Did you find the culprit to this issue? #414 looks like the same issue.

Best regards

[pvodoz]

Without any reason, the issue disappeared... maybe by trying cell balancing...