Thanks for the link to the logs. I am certainly no expert reading those logs but let’s assume for a moment the presence of an EMI related ‘root cause’, what would we expect to see in those logs, where and why? I expect there must be at least one of two signals we should be able to detect and find in the logs (may need to increase log detail level)
a low level (hardware/driver/hal) ‘link lost / data corrupt’ signal
AND/OR
a high level (venusOS, grid meter code) ‘meter disconnected’ signal
Are you saying you cannot identify any low level signal in those logs at all?
What should I look at on our system?
It is not too hard to reproduce the issue, only takes a longer/extension USB cable and either patience to wait for a high power buy/sell moment (or manually overriding any setting to force the inverter to take/deliver max power) The BMW (in our case) will instantly disappear (very easy to spot in the Node-RED flow that uses its data) usually not returning until the inverter has returned to idle, sometimes sooner, sometime not at all, also depending on that cable length.
Another hint pointing to an EMI problem right at the hardware level is the consistency of the issue over many firmware updates. I do not know if this would motivate Victron to (re)investigate this to be a possible widespread hardware problem, it should.
This is a bit over my head. I made a NodeRed flow identifying grid meter lost, simply by checking when /Ac/Grid/DeviceType switches to “null”. That is the easy part, and shortly after the VeBus state will change to passthru, up to this release. These state changes I also monitor in a NodeRed flow.
First signs in the log are always (composed from two different log filess): 2025-12-05 12:52:41.922967500 ERROR Lost connection to energy meter "298156V" @ "/dev/ttyUSB0" : 1 2025-12-05 12:52:41.942027500 INFO:dbusmonitor:com.victronenergy.grid.cgwacs_ttyUSB0_mb1 disappeared from the dbus. Removing it from our lists
Not more info, the rest of the logs is about restarting the service and looking for the grid meter. The grid meter always returns in my case within one or two restarts of the serial starter service. Normally within a minute or so.
The problem is consistent over several releases, but some firmware releases seemingly improved performance for a while, but that could be confirmation bias on my site, or just coincedence.
I know AI content is generally frowned upon here so I will only copy in a summary and provide a link to the full shared discussion for those interested. And reader beware, do your own research when using AI, always verify:
Summary of Findings
Venus OS, Victron’s embedded Linux distribution for GX devices like the Cerbo GX, handles USB-connected devices (e.g., BMV SmartShunt via VE.Direct to USB interface) primarily through standard Linux kernel mechanisms rather than custom Victron-specific drivers or a full Hardware Abstraction Layer (HAL). The core USB stack relies on the Linux USB subsystem (e.g., usbcore, usbserial, and chipset-specific drivers like ftdi_sio for FTDI-based VE.Direct adapters or pl2303 for Prolific chipsets). Device detection and management occur via udev rules and the serial-starter service, which scans for connected devices on /dev/ttyUSB* ports and launches protocol-specific daemons (e.g., vedirect-interface for VE.Direct devices like the BMV).
Intermittent connection losses, especially EMI-induced (e.g., during high-power charging/discharging from the MultiPlus II GX), manifest as USB enumeration failures, URB (USB Request Block) errors, or serial port timeouts. These are often logged as kernel-level disconnects (e.g., “USB disconnect, device number X” or “urb stopped: -32” for input/output errors). The issue correlates with cable length because longer unshielded USB cables act as antennas for EMI from the inverter, causing signal integrity degradation and triggering Linux’s USB error recovery (which can fail under sustained noise).
No direct EMI mitigation code exists in Venus OS source (it’s a hardware/cabling issue), but kernel patches for USB stability (e.g., fixing race conditions in serial drivers) have been backported in upstream Linux kernels post-5.10.110. Venus OS uses a customized 5.10.y kernel (e.g., 5.10.110 in older releases), which predates some fixes for PL2303/FTDI disconnects. Custom scripts for USB resets or retries can address symptoms software-side.
As usual (sorry Jan ) AI produces nonsense when asked for things like this. The kernel we use 6.12.something. Not 5.10.y.
To be honest, I’m not very interested in troubleshooting why Rob his system has an issue with his energy meter now; and especially not in this already far too long beta thread.
The remarks and thoughts on how to handle the situation of a lost grid meter - we’ll consider that carefully before releasing v3.70.
After clicking send, I’ll move all replies concerning this, including this one, to a new topic.
Yes I noticed that. As always garbage in = garbage out and still needs a ‘dev in the loop’. But it does accelerate digging into an issue immensely, especially in unfamiliar territory. The link included does provide useful hints on what to log on the kernel side as that was what I prompted grok for. My interest isn’t anybody’s system perse, just looking into this to understand what special precautions are required to safeguard reliable operation when dealing with USB connected critical components, such as energy meters.
Thanks for the ‘move’
Have a great weekend, ..
Fair enough. I started out from the point that the current beta does not handle lost grid meter as I expected. I will move from serial to IP based communication and hope that my problem is solved.
Having said this, I do think that I am not the only one with recurring loss of grid meter. You will find more on this forum if you search.
So maybe there is a common denominator or root cause, and that may be EMI. Or a timing issue. A clue for finding the cause might be that it almost exclusively happens during charging in my case.
And that is what I experience as well.
Anyway, the grok link answers my question where to look for logs assuming an EMI relation. I think (need to check) you have have been looking at userspace logs (VenusOS) only while it is more likely to find the actual issue in the kernel logs:
dmesg -w | grep -E "(usb|ttyUSB|urb)" # Watch for disconnects/URBs; Ctrl+C to stop
You are right, today I did not look into kernel messages. I had before on earlier investigations. But dmesg is clean apart from startup messages.
However I found two links that suggest grounding issues. The first one is this one where Wilm says that a cheap USB-isolater did the trick:
The second one suggested not to use terminal 10 at the Grid Meter.
I am not an EMI expert at all, but it could problably explain why it happens under high loads. If the Grid meter picks up EMI, and passes it on to the Cerbo, that could be a problem.
Might still be EMI as well, albeit traveling through a grounding connection. That’s the tricky part with EMI, it can be picked up by something acting as antenna, then travel through wiring before doing it’s dirty deeds elsewhere, then they’d need to scope it out. Are you using a Cerbo GX at a distance or a MP II GX?
Ok, not within the MP housing as with our MP-II GX but still close by enough to (all 3) MP and grid meter for a possible EMI issue. Talking about EMI, these issues can pop op most unexpectedly in various places, you’d really need a scope to catch ‘m all: https://youtu.be/r-V_Z3bD_PA?si=nfHAXxzO8dMFqPID
I told you, this is a bit over my head. I chose the practical approach: the 10 euro usb-isolater that I bought on Amazon. It works. Now I have to wait and see if it fixes my problem. No charging planned for the next 26 hours, because of grey weather and flat prices.
I give up. I tried the following 3 configuartions for my CG-EM340, Victron USB/RS485, CerboGX combi.
USB-isolator, pin 10 connected: Works, but no noticable improvement during charging
No USB-isolator, pin 10 disconnected: Works, but immediate grid meter lost when charging starts
USB-isolator, pin 10 disconnected: Works, but no noticable improvements during charging
While I still think this might be solvable in software (timeout settings as @UpCycleElectric suggested), I will replace the EM340 by a EM24/ethernet. In this way I will bypass the serial connection and thus the EMI-problem.
I will do this next week, and again. I will keep you updated.
Sorry to hear that. The EMI theory seems to hold with a focus on the usb hardware interface on the Cerbo GX / MP-II GX. Trial and error and logical induction can only get you so far, the next step requires an actual test setup for reproduction of the issues with both software (low level debugging probes) and hardware (multichannel oscilloscoop and signal tracers) measurements. This is way out of scope for us unpaid community members / beta testers. I am worried Victron will refuse to take on this responsibility reasoning they don’t see enough complaints, despite the fact this will leave an unknown number of installations at risk for undetected intermitted failures in a critical core system function: reliably actual power measurements.
Thanks, I agree with your analysis and conclusion that Victron could do more since it is all Victron hardware (cable and Cerbo) and Victron supported hardware (CG-EM340). On the other hand, probably there are bigger fish to catch and there is only so much they can do.
People complain about their system going into passthru mode. This is often caused by “grid meter lost”. The solution in the current beta to just not switch to passthru seems a poor mans solution to me. Especially, when there are (potentially heavy) loads on AC-in such as EV-chargers as in my case.
Today I Installed the CG EM24 ethernet. So far so good. I expect no problems because UTP cables in general do not suffer from EMI-problems, as far as I know.
Edit Dec 18th:
Two days in a row with zero “grid meter lost” events. Replacing the RS485 with an ethernet Energy Meter was expensive, but worth every euro.
) AI produces nonsense when asked for things like this. The kernel we use 6.12.something. Not 5.10.y.