Dbusmonitor Causing Lag in Virtual Battery Aggregation on Cerbo GX?

Modifications
, , , ,
1

I’ve built a virtual battery D-Bus service (com.victronenergy.Virtualbattery) that aggregates data from multiple serial-connected batteries.
It works, but updates freeze for long periods and then burst-update all values suddenly.
This makes real-time monitoring and system responsiveness very inconsistent.

What I’m Building:

I have multiple batteries connected via serial (USB) to the Cerbo GX.
Each battery registers its own D-Bus service (e.g., /com.victronenergy.battery/ttyUSB0_*, /ttyUSB1_*, etc.).

I aggregate key metrics — Voltage, Current, SoC, etc. — based on physical configuration:

  • Example: 4 batteries in Parallel etc.

The aggregated values are published to a custom virtual battery D-Bus service:
com.victronenergy.Virtualbattery

I then set this as the system Battery Monitor via:
Settings > System setup > Battery monitor

The Problem:

The virtual battery works and eventually shows the correct values, but:

  • Values freeze for long periods
  • Then suddenly update all at once
  • Then freeze again — the cycle repeats

This makes the system feel unresponsive or delayed, especially for real-time monitoring and control.

Setup Details:

  • Cerbo GX + Venus OS

  • Multiple serial-connected batteries (ttyUSBx)

  • Each battery exposes its own D-Bus service

  • Aggregation logic uses dbusmonitor to read battery values

  • Aggregated data is pushed to com.victronenergy.Virtualbattery

    //----------------//

  • Has anyone experienced this freeze-and-burst pattern with dbusmonitor?

  • Is dbusmonitor known to behave like this under load?

  • Are there better D-Bus listeners or approaches for aggregating high-frequency battery data?

  • Any tuning advice or tools to make this more real-time and reliable?

Any thoughts, experiences, or alternate approaches would be much appreciated!

2

I’ve not seen this behavior from Dbus before.
LouisVanDerWalt has done a lot of work integrating non standard batteries via dbus, and his software is worth a look at.
Freeze and burst data indicates that the processor is possibly overloaded, and is trying to handle too many tasks.

3

I will certainly look into this as well.
I developed my driver using Louis Van Der Walt, then shifted my development to Mr. Manuel’s dbus-serialbattery driver.

4

When you register your dbus-service, you need to make sure you initialize everything, BEFORE registering it - else dbus-monitor whil stuck a while, trying to read paths, that your service has not yet created.

Lot of third party examples currently start with something like

self.dbusService = VeDbusService(self.serviceName, bus=dbusConnection())

here it is important, that you provide register=false, then do all the mandatory paths, and finally call .register():

self.dbusService = VeDbusService(self.serviceName, bus=dbusConnection(), register=False)

# create all paths required

self.dbusService.register()

dbusmonitor will then start to read your service, when register() is called, and all required paths exist -without stucking.

IF this happens over and over - it just indicates that your service is crashing, restarting, registering again - and causing a dbus-monitor-stuck again. It will become way quicker with the above change, but you still should log when your service restarts / re-registers and eventually fix that bug :wink:

2 Likes
5

I was looking for that information some months ago, but could not find it. Thank you.

1 Like
7

Yes , I will surely rearrange as mentioned. will post if something comes up.
This is really helpful.
Thank you