A system with 3x MP2 5000 exhibits oscillating behaviour, switching several times within a minute from heavy charging to heavy discharging. DESS is disabled; only ESS is enabled.
The VM-3P75CT energy meter regularly fails to provide an update for several seconds at a time. A custom-written log file script confirms this, causing ESS to control the system using outdated measurement data. The same script also reads the HomeWizard P1 meter, which confirms that the values do change in the meantime. Usually, the two meters track each other almost 1:1, but this issue occurs occasionally.
Grid values on D-Bus sometimes remain exactly the same for several seconds.
Manual GetValue calls to the VM-3P75CT D-Bus service occasionally time out.
The dbus-modbus-client logs repeatedly contain messages such as:
Device failed: Error reading registers 0x2000-0x2023:
Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response
and sometimes:
Modbus Error: [Input/Output] timed out
The meter is then found again and registered on D-Bus again.
To rule out the meter and network connection, I tested the VM-3P75CT directly via Modbus UDP, outside Venus OS and D-Bus.
Result:
601/601 successful reads of 0x3000-0x303F
601/601 successful reads of 0x2000-0x2023
0 timeouts
response times usually only a few milliseconds
readings continue to refresh normally
The meter and Modbus UDP communication therefore appear to be stable when tested directly, while the problem seems to occur mainly in the Venus OS / dbus-modbus-client chain.
Has anyone seen similar behaviour with a VM-3P75CT via Modbus UDP under Venus OS 3.79 / dbus-modbus-client 1.80? Is there a known fix, patch or workaround for this?
Thank you, that is interesting information.
I am also running Venus OS 3.79, but the VM-3P75CT is connected via the usual LAN and therefore through a switch/router.
In the meantime, I have tested the meter directly from the Cerbo via Modbus UDP. Both register blocks, 0x2000-0x2023 and 0x3000-0x303F, were each read successfully 601 times in succession, without a single timeout and with response times of only a few milliseconds.
Nevertheless, dbus-modbus-client has historically produced multiple Device failed messages for the same meter, after which it is registered on D-Bus again. I have also noticed that D-Bus values sometimes remain unchanged for several seconds.
Since your 1:1 Ethernet connection works without any problems, I am now going to investigate whether the difference in network topology is relevant. A direct Ethernet connection between the Cerbo and the VM-3P75CT therefore seems like a worthwhile A/B test.
I repeated the tests before and after replacing the switch; the analysis is below:
However, the comparison between direct Modbus and Venus D-Bus shows almost the same problem as before the switch:
Characteristic
Before switch
After switch
Direct Modbus errors
0
0
Total D-Bus errors
354
347
Longest period stalled vic_total_w
8.37 s
7.41 s
Longest period stalled system
1.71 s
3.06 s
Median difference system vs direct Modbus
33 W
30.5 W
So the new switch may have made the network path slightly cleaner, but the fundamental phenomenon remains: the VM-3P75CT responds perfectly when queried directly, while the direct Victron D-Bus service still has many GetValue problems and can hold the same value for several seconds.
This makes it rather unlikely that the switch is the primary cause.
My conclusion is therefore stronger: the problem is probably in the Venus OS / dbus-modbus-client layer or in the way that service is being queried, not in the meter hardware and probably not in the switch either.
I had similar problems connecting the VM-3P75CT meter to the Cerbo GX via a network interface. I tried lots of different network configurations, WiFi, lan, router, switch etc. Nothing fixed the sparodic momentary pauses. Ultimately ended up going with the VE.Can connection (and sacrificing the visibility of the meter on my network) and it’s been flawless ever since.
From the outset, I connected the Cerbo GX and the VM-3P75CT in my installation via VE.can. In addition, I connected both devices to my home network using a LAN cable. This way, I have no problems with the control system and can access both devices from my network….
