Throttle update rate of data published via MQTT

Hi,

I’ve setup MQTT locally and I’m bridging data published by Venus OS (Ekrano GX) to Home Assistant. This works just fine - actually it works “too good”.

The data published via MQTT seems to be updated multiple times a second. I can understand that this needed internally for proper regulation of power flows, etc. In my case I just want to visualize the data and I’m perfectly happy to receive data only once a second (or every 5 seconds, etc.).

Is there any easy way to throttle those updates on the Venus OS side of things? Obviously I can filter / setup the data on the receiving side, too, but personally I would like to just receive less data rather than receiving a whole bunch of data and throwing it away essentially.

Happy to receive some ideas on how to do this.

As short as possible “receiving” functions, in order to use as little as possible CPU.
Average info on these functions based on your desired timeframe.
Store the averaged result locally.
Use trigger to receive the averaged info instead, at your desired timeframe, from those local stored values.

Sorry, I’m not really understanding what you’re saying. Where should I do the averaging, etc.?

Now I realized…
You are using the HA as an user or do you want to make your own application as a programmer?
I’ve commented from a programmer (coder) point of view… Sorry… habit… :innocent:

I had the same question a few weeks ago. Apparently, there is no obvious direct way to throttle it.

I actually tried Home Assistant with the MQTT bridge, and it used excessive CPU time on my Cerbo GX. This is probably because I have multiple Energy Meters with 10 Hz update rates.

I ended up going with a MODbus TCP yaml file which polls once per second for only the things I need. This woks well in Home Assistant, and does not burden the Cerbo GX.

1 Like

How did you do the “keep-alive” of the gx mqtt?

Do you receive too many publishes of all thausand variables, or is it just that single values publish to frequently?

If the later is the case, that cannot really be influenced. Some Gridmeters for example reporting every 50 to 100ms, and then that will be published on mqtt right away.

If your case is the first one, you may just accidenly request a “full-publish” of every value with any keep-alive package you send to the gx.

Ok, that’s also an possibility. I’m using Modbux TCP all over the place, but wanted to go with MQTT with this setup, as it feels more smart. But in this case it works too good.

It seems it might be possible to throttle it using NodeRed running on the GX device (Venus OS Large), but that sound’s messy.

I’m not keeping alive anything, just subscribing to the appropriate topics. Still getting an update every few milliseconds, as my smart meter updates quite frequently (EM540).

I’m not explicitly requesting a full-publish. I’ve done this for testing purposes, but with Home Assistant I’m just subscribing to the appropriate topics itself.

Oh, I really liked how MQTT worked when I was running it, but the occasional stalls in the updating due to being overwhelmed was just too annoying for me. It’s possible there is a solution out there, I only spent a few hours researching and tinkering and failed.

Weirdly, there are a few things not available in MQTT that are available in ModbusTCP, like the operational mode of the MPPTs (off, active, limited). So I was happy to switch over to Modbus. On the other hand, there are things in MQTT like sums of all phases that are not available in Modbus (you have to add them yourself).

Ok. Yeah, the grid meters can report very rapidly, and that goes 1:1 on mqtt.

But don’t worry too much: Something like 20 values per second looks like a ressource heavy operation for us humans - but that’s nothing even moderate systems would mind.

As a Software-Developer I’m always impressed by the computation power of even smallest devices. Thousands of iterations that would take me a week to do on paper - done in a few milliseconds.

My Home-Dashboard is currently processing ~1631 msg/s, resulting in 10040 calculations/s - and idling at 5% CPU load :grinning_face_with_smiling_eyes:

Hi @ricardocello

This is available under the topic MppOperationMode. The meaning of the values is the same as with Modbus.

Actually: everything available to Modbus should also be available via MQTT as both of them use the data from the dbus. MQTT makes all data on the dbus available, Modbus only a selection. The MQTT topic can be found in the dbus-obj-path column in the Modbus-TCP register list on our website: https://www.victronenergy.com/upload/documents/CCGX-Modbus-TCP-register-list-3.50.xlsx

Kind regards,
Thiemo van Engelen

1 Like

Thanks Thiemo.

I saw the value for MppOperationMode in dbus-spy, but I wasn’t patient enough in the MQTT analyzer I was using to wait for the topic to publish, as it does not change very often.

Hi @ricardocello

You don’t have to wait for a change. When you first subscribe to the wanted topics and then send a keepalive you should receive all topics. This is described here: GitHub - victronenergy/dbus-flashmq: Plugin for FlashMQ that interfaces between DBUS and MQTT.

Kind regards,
Thiemo van Engelen

1 Like