Hi, lately I’ve been repeatedly seeing very high, unrealistic peaks in consumption (approx. 2500 kWh) for very short periods.
Does anyone have any idea what could be causing this?
Setup: 3x MP2 5000/70, 2x MPPT 450/200, Cerbo, EM 24 grid, EM 540 for PV with 2x Hoymiles HMS1600W on MP Out 1
Best regards, Matthias
Have a look at the new beta versions — apparently that’s exactly what they’re trying to prevent in future.
Wasn’t there something posted somewhere in the last few days saying that it’s already prevented in the latest VRM version?
Hmm, the last peak was on 25/05/2026. Yeah, I’ll take a look. I sent in a screenshot via Beta Feedback two weeks ago. Has there been any feedback on that? I don’t think so.
Thanks.
But to get to the bottom of this… It happens fairly often: is it that consumption data that, for whatever reason, wasn’t transmitted in a timely manner is simply “caught up” later? So the consumption did take place, just spread out and earlier, but wasn’t transmitted that way. Is this “offset” used to bring things back up to date? I hope that makes sense. Is that right?
At least the figures seem to add up. I keep seeing this mentioned here, but I’ve never understood how it comes about, or whether it all adds up in the end. I think the values are being backfilled here.
So far, I’ve only read about this in connection with Shelly meters or other meters that aren’t officially supported.
Apparently, a reset or something similar causes the meter to be read again, and the total consumption stored in its memory is transmitted in the process.
It would be better the other way round.
So use the newer, faster EM540 as the grid sensor and the EM24 for PV.
I thought I’d read something about it being fixed at the VRM level too, but I can’t find it right now.
Yeah, true, that doesn’t make any sense. But the overall assessment seems to be right… At least, otherwise that’d be bloody annoying.
These spikes occur when the energy meter, which normally only ever increments, briefly returns a “0”: 5001, 5002, 0, 5002 → bam, 5002 kWh in an hour.
(Of course, this can also happen with any other outlier value — but 0 is responsible in 99% of cases here 
)
How have you connected the EM? If you’re using Node-RED, you must NOT initialise the Node-RED meter with defaults, otherwise every time Node-RED restarts, a “zero” gets into the system.
It’s also a good idea to use a filter that blocks any 0 coming from the Shelly or MQTT.
Thanks, that explains a lot. So a meter replacement would mean that although there’s a spike, the VRM data continues correctly. I’ve always wondered what happens when you replace the meter. Thanks again.
Although my explanation doesn’t quite add up: there’s no spike, since the new one carries on from 1.
Yes, correct, but something like that should be caught server-side.
The question is also: why does it report zero? Because the transmission has no checksum?
Exactly. A lower counter reading always has no effect — there are devices that start at 0 when they “boot”, and for those, it’s necessary.
Only jumping back to a previous value after a 0 then results in a “false-positive-spike”.
Not at all, see above. There are devices where it’s important to reduce delta tracking when a lower value comes in. There are even counters that have just one register and go “up and down”, depending on whether power was fed in or drawn — so you have to do this in both directions if you want to separate the readings.
The analysis takes all of that into account — ensuring that a forever-forward-incremental counter doesn’t produce an incorrect value is the counter’s job, not the reader’s.
Transmission errors are essentially ruled out with TCP. It’s either a bug in the sender or in the receiving script. With MQTT transmission, retained values can also cause grey hairs for a long time, since they can crop up from time to time when the recipient reconnects, even if the sender stopped publishing retained messages ages ago, but the broker is still holding on to retained values for a topic that are three months old.
Yes, that’s right. Once everything is up and running, they’ll be swapped.
The Victron EMs are each connected via USB. Other than that, there aren’t any other components such as Node-RED or anything like that.
Do you have a Raspberry Pi as a GX, or a Victron GX?
Oh, and which Venus version? (Just checking it’s not a known issue with your exact version.)
Cerbo GXC00A HQ2215ZJYVG v3.73v3.73 Up to date
SmartSolar MPPT RS 450/200A111 0252868 HQ2222G3QU2 v1.29v1.29 Up to date
SmartSolar MPPT RS 450/200A111 0261060 HQ222644WEP v1.29v1.29 Up to date
EVCS-Wellnes Oase EV Charging Station 32AC025 HQ2231VQXFW v2.07v2.07 Up to date
MultiPlus-II 48/5000/70-502623 HQ2219T7HKT v505v560 Update device - I’ll do it in winter-
Just out of interest — I don’t use VRM much and log things myself — what actually gets transmitted?
Meter readings or power values?
I have a lot of experience with Volkszähler — things like this don’t happen there.
You might also want to take a look at this thread, where I posted about my problem with it.
This one is only about Virtual Devices (AC load) in NodeRed, though.
https://community.victronenergy.com/t/ac-load-spikes-in-vrm/58738/6
It includes both links with information and explanations/solutions.
It’s worth bearing in mind, anyway, even though the latest beta, ~27, has now added OS-level “filtering” for these events for the second time.
For the non-NodeRed things, I hope the changes in ~21 and ~27 are enough for you, since unfortunately you have no control over those yourselves.
I have a Modbus meter and a smart meter with an optical reader that sometimes report wildly inaccurate readings.
I’ve since filtered those out. But if meter readings are stored somewhere and not reset or discarded on the same day, I can imagine that could lead to peaks like that.
