# ESS oscillation caused by the energy meter?

**URL:** <https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599>\
**Category:** DIY\
**Tags:** vm-3pct75, dess, diy, ess, cerbo-gx\
**Created:** [8 September 2026 06:58 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599 "2026-09-08T06:58:05Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 06:58 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/1 "2026-09-08T06:58:05Z")

</div>

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.

Cerbo software 3.79 large, VM-3P75CT firmware 1.11.

Is this a software or hardware issue?

---

<div class="post-metadata">

**Author:** ![DirkW](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/dirkw/32/33865_2.png) [@DirkW](https://community.victronenergy.com/u/DirkW)\
**Post date:** [8 September 2026 07:41 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/2 "2026-09-08T07:41:05Z")

</div>

> [@jules.bosma](#):
>
> VM-3P75CT

How did you connect the energy meter?

---

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 08:11 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/3 "2026-09-08T08:11:07Z")

</div>

On a dedicated circuit breaker, with the phase and CT clamps checked.

The problem doesn’t appear to be in the hardware; I’m carrying out an in-depth analysis.

The pattern now points mainly to:

**VM-3P75CT → healthy**  
**network/UDP → healthy during our tests**  
**Venus `dbus-modbus-client` → prime suspect**

The problem appears to be with Venus OS 3.79 / dbus-modbus-client 1.80.

---

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 08:18 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/4 "2026-09-08T08:18:35Z")

</div>

**VM-3P75CT: Periodically Stale D-Bus Values / Possible dbus-modbus-client Issue on Venus OS 3.79**

I am intermittently seeing outdated/stale grid readings from a VM-3P75CT connected to a Cerbo GX via Modbus UDP.

Configuration:

- Cerbo GX
- Venus OS **v3.79** , build **20260826152305**
- `dbus-modbus-client.py v1.80`
- VM-3P75CT firmware **v1.11**
- Meter via **Modbus UDP 192.168.2.216:502**
- D-Bus service: `com.victronenergy.grid.ve_HQ2543TN2Z2`

Observed behaviour:

- 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:

```auto

```

```auto
Device failed: Error reading registers 0x2000-0x2023:
Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response

```

and sometimes:

```auto

```

```auto
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?

---

<div class="post-metadata">

**Author:** ![DirkW](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/dirkw/32/33865_2.png) [@DirkW](https://community.victronenergy.com/u/DirkW)\
**Post date:** [8 September 2026 08:25 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/5 "2026-09-08T08:25:59Z")

</div>

> [@jules.bosma](#):
>
> The problem seems to be with Venus OS 3.79 / dbus-modbus-client 1.80

Have you tried it with a different Venus OS version?

3.79 Large runs flawlessly for me in this regard.  
I use a 1:1 Ethernet connection WITHOUT a switch or router (Multiplus GX)

It’s a standard image without mods or shell scripts.  
The only customised elements are a few Node-Red programmes.

---

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 08:39 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/6 "2026-09-08T08:39:17Z")

</div>

> [@DirkW](#):
>
> > [@jules.bosma](#):
> >
> > The problem appears to be with Venus OS 3.79 / dbus-modbus-client 1.80
> 
> Have you tried a different Venus OS version?
> 
> 3.79 Large is running perfectly for me in this regard.  
> I use a 1:1 Ethernet connection WITHOUT a switch or router (Multiplus GX).
> 
> It is a standard image without mods or shell scripts.  
> The only customised elements are a few Node-RED programmes.

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.

---

<div class="post-metadata">

**Author:** ![DirkW](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/dirkw/32/33865_2.png) [@DirkW](https://community.victronenergy.com/u/DirkW)\
**Post date:** [8 September 2026 09:13 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/7 "2026-09-08T09:13:31Z")

</div>

That sounds like it could be a network problem.

Have you tried restarting the router/switch or using a different one?

---

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 09:25 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/8 "2026-09-08T09:25:11Z")

</div>

Both the Cerbo and the energy meter are connected to the same switch, but I’m going to replace it; perhaps that will solve the problem.

---

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 09:55 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/9 "2026-09-08T09:55:01Z")

</div>

Dear Dirk,

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.

---

<div class="post-metadata">

**Author:** ![DirkW](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/dirkw/32/33865_2.png) [@DirkW](https://community.victronenergy.com/u/DirkW)\
**Post date:** [8 September 2026 10:14 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/10 "2026-09-08T10:14:04Z")

</div>

Oops

When I sit here in front of the remote console, I don’t see any freezes or dropouts in the figures. But that’s purely a visual check.

How far is the energy meter from the GX device?

Have you also tested the CAN connection or Ethernet 1:1 as an alternative?

---

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 11:06 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/11 "2026-09-08T11:06:19Z")

</div>

> [@DirkW](#):
>
> Oops
> 
> When I look at the figures here in the external console, I don’t see any stoppages or glitches at all. But of course, this is purely a visual check.
> 
> How far away is the energy meter from the GX device?
> 
> Have you also tried testing the CAN connection or Ethernet directly as an alternative?

They are right next to each other. I connected the energy meter directly to the Cerbo via the CAN bus, and tests show that far fewer errors occur.

Thanks for the support so far!

---

<div class="post-metadata">

**Author:** ![DirkW](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/dirkw/32/33865_2.png) [@DirkW](https://community.victronenergy.com/u/DirkW)\
**Post date:** [8 September 2026 13:34 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/12 "2026-09-08T13:34:06Z")

</div>

Great that you’ve made some progress

The fluctuation should be gone too, right?

Here are the CAN bus statistics from my battery; there’s no apparent error

 ![grafik](https://europe1.discourse-cdn.com/victron/original/3X/3/c/3cbb52f6de008dda76688fdd88b704ae1395352e.png)

---

<div class="post-metadata">

**Author:** ![jules.bosma](https://avatars.discourse-cdn.com/v4/letter/j/ecb155/32.png) [@jules.bosma](https://community.victronenergy.com/u/jules.bosma)\
**Post date:** [8 September 2026 13:54 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/13 "2026-09-08T13:54:03Z")

</div>

Similar result, thanks!

 ![image](https://europe1.discourse-cdn.com/victron/original/3X/b/a/bafb002ccf21556a4e95e377bb109c0cff393f00.png)

---

<div class="post-metadata">

**Author:** ![drs68](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/drs68/32/7744_2.png) [@drs68](https://community.victronenergy.com/u/drs68)\
**Post date:** [8 September 2026 22:12 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/14 "2026-09-08T22:12:37Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![AMH0815](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@AMH0815](https://community.victronenergy.com/u/AMH0815)\
**Post date:** [9 September 2026 04:12 UTC](https://community.victronenergy.com/t/pendelgedrag-ess-veroorzaakt-door-de-energiemeter/62599/15 "2026-09-09T04:12:32Z")

</div>

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….
