Capteurs SolarSense750 sur Cerbo esclave + problème d'unités sur Virtual Device

Been scratching my head over something similar with my garden office setup and wondering if anyone else has hit this wall.

Running a dual-Cerbo configuration — one master in the main house distribution board, one slave out in the office — and I've got a couple of temperature/energy monitoring sensors tied to the slave unit. The data feeds through Node-RED into a dashboard I've cobbled together, which mostly works fine.

The issue I keep running into is around Virtual Devices on the slave Cerbo. When I pull the sensor readings through Node-RED, the units are coming through inconsistently — sometimes watts, sometimes kilowatts, no obvious pattern I can pin down. It's making my consumption graphs look absolutely daft.

A few specific questions for anyone who's done this:

• Does the slave Cerbo handle unit scaling the same way as the master, or does something get lost in the MQTT relay between the two?
• Has anyone successfully mapped custom sensor data from a slave device into a coherent Virtual Device that the master then presents cleanly on VRM?
• Is there a Node-RED flow pattern that normalises units before they hit the dashboard, rather than relying on the Cerbo to do it?

My sensors are fairly basic clamp-type units, nothing exotic. The Victron ecosystem generally plays nicely with Node-RED in my experience, but this master/slave arrangement seems to introduce some quirks I wasn't expecting.

Would be especially interested if anyone running a van conversion alongside a fixed installation has tried bridging two Cerbos — seems like a niche but relevant use case here.

@FormerMariner dual-Cerbo setups are a right faff tbh. Had a similar units mismatch on my boat when I added a second GX device — Victron's VRM portal just gets confused about which instance is reporting what.

Worth checking your MQTT topics are actually publishing from the right com.victronenergy service path. The Virtual Device units issue is usually because the slave Cerbo is inheriting the master's device instance numbering.

Quick fix that worked for me:

• SSH into the slave Cerbo
• Force a unique VRM device instance in the settings
• Restart Venus OS

Also double-check your SolarSense sensors are mapped to the correct input on that specific Cerbo rather than both trying to claim the same modbus address. Renogy kit had me chasing a similar ghost for weeks before I spotted it.

@BirchTrevor is right that dual-Cerbo setups are painful, but the units mismatch on Virtual Devices is a known Victron firmware headache specifically — not just a display quirk.

In my static caravan setup I had sensor data coming through a slave GX showing kW when everything else was reading W, which completely broke my consumption calculations. Root cause was the Virtual Device instance on the slave not inheriting the master's unit scaling properly across the VRM portal aggregation.

Fix that worked for me:

• Force a firmware reinstall on the slave Cerbo (not just update — full reflash via VictronConnect)
• Manually set the dbus unit attribute on the offending sensor path using the GX device's SSH console
• Rebuild the Virtual Device from scratch rather than cloning it

The SolarSense750 specifically has form for this — their MODBUS mapping doesn't play nicely with Cerbo's auto-scaling.

@FormerMariner this is exactly the pain I hit when I wired up my garden office Cerbo as a slave to the house master. The Virtual Device units mismatch specifically seems to happen when your slave Cerbo is running a different firmware revision than the master — DVCC negotiation gets confused about what's a raw value versus a scaled one.

Worth checking in VRM whether both units report identical firmware strings under the Remote Console diagnostics. Even a minor point release difference (e.g. 3.30 vs 3.31) can cause the scaling to misalign on custom sensor channels.

Also — SolarSense750 specifically uses a non-standard Modbus register map, so if you're pulling that into a Virtual Device manually, double-check your multiplier settings on the slave side. I had to set mine to 0.1 rather than the default 1 to get sensible kWh figures rather than garbage.

@FormerMariner what firmware version are you on? I hit something similar on my narrowboat when I bodged together a secondary monitoring setup and half the temperature readings were showing in Fahrenheit despite everything being set to Celsius in the VRM portal.

Worth checking whether the Virtual Device is inheriting its unit settings from the slave Cerbo locally rather than pulling from the master — Victron's documentation on this is genuinely awful.

Also, is this a SolarSense issue specifically or does it affect other devices on the slave? If it's only the SolarSense750 readings that are mangled, I'd be looking at the driver/integration rather than the dual-Cerbo architecture itself. Might be worth logging a ticket with Victron directly — painful process but sometimes the only way to get a straight answer rather than guessing in forums.