Common mistakes — VE.Direct gateway

General gateway problems (LED codes, box invisible on the bus, firmware update) are in Common mistakes. This chapter is what goes wrong on the VE.Direct side specifically.

Ask the gateway first

Before anything else, ask the box what it sees on its four ports:

muxen-uds -i can0 -F 17 -I <io-instance> routine --action 1 --routine 2

It answers 4, then three bytes per port: the product identifier and the MUXEN function code. That one answer separates the three failure families below.

A port shows FFFF — nothing is arriving

Likely cause	How to tell	Fix
The Victron device is not powered	the device's own display is dark	VE.Direct only talks on a powered device
The cable is on the wrong port	another port shows the device you expected	the ports are numbered in connector order, 1 to 4
The cable is faulty or wired the wrong way round	nothing on that port with any device	swap the cable with one from a working port to prove it
The device's VE.Direct port is already occupied	a Bluetooth dongle, a display or a Cerbo is plugged into it	VE.Direct is point to point: one consumer per port. Unplug the other one
The device's text output is off	the port is silent but the device works	some Victron devices can have their VE.Direct output disabled or put in another mode; re-enable the text output with the Victron tool

A port shows an identifier but function code FF

Something is talking, and the gateway does not know what it is. Compare the identifier with the table in Reference — VE.Direct gateway — the gateway matches on that value and on nothing else. Equipment outside those ranges is ignored, silently and on purpose. A newer Victron model can perfectly well fall outside a range that covers its predecessors.

A device on another port never appears

This is the one trap in the numbering, and it catches everyone who renumbers.

Each port claims its storage under its own port index — 0 for port 1, 1 for port 2, 2 for port 3, 3 for port 4 — combined with the device's function. A device that you renumber to 0, 1, 2 or 3 therefore occupies the slot belonging to that port, and a device of the same kind on that port can no longer register: it stays invisible for ever, and the routine above shows its identifier with function code FF.

What you did	What happens
Left everything at 0…3	fine, every port has its own slot
Renumbered a solar charger to 4 or above	fine
Renumbered the solar charger on port 1 to 1	the solar charger on port 2 never appears

Fix it by renumbering out of the 0…3 range, then power-cycle the gateway.

A solar charger or a charger switched itself off

The gateway switches chargers on and off by itself, following the charge request of the battery parc they are bound to. Three reasons for a device to sit at off:

Likely cause	How to tell	Fix
The parc has no battery on it	the device is bound to parc 1, 2 or 3 and no battery monitor publishes on that parc	a parc with no battery asks for no charge. Put a battery on it, or set BindToParc to 255 (standalone), which lets the device run permanently
A screen forced it off	it went off the moment somebody pressed something	release the command — a command frame with neither on nor off returns the device to automatic
The parc is full	the battery's charge request says no charge	that is the intended behaviour, not a fault

RevertControl reverses the rule for a device published as a solar charger, which is what a DC/DC converter feeding a low bank from a high one needs. Set it to 1 there and to 0 everywhere else.

The gateway asks a device to switch and nothing happens

The gateway sends the on/off command down the VE.Direct cable and does not read back whether it was applied — there is no acknowledgement in either direction. If a device ignores it, the gateway will keep asking and the MUXEN state will keep showing what the device actually reports. Check with the Victron tool that the device accepts being switched remotely.

The gateway also leaves a device alone rather than trying to switch it on while that device reports off-reason 1. A solar charger at night is the normal case.

The battery's limits look invented

They are — they come from the gateway, not from the monitor. A Victron battery monitor reports voltage, current, temperature and state of charge, and nothing about what the bank will accept. The gateway publishes the four limits written in that device's configuration, whose defaults are a 24 V bank at 50 A:

muxen-uds -i can0 -F 5 -I 0 readconfig

Set VChargeMax, VDischMax, IChargeMax and IDischMax to the real bank. Everything downstream believes them.

The battery shows 0 % state of charge

The gateway publishes the state of charge exactly as the monitor reports it. A monitor that reports none — because it has not been set up for the bank, or because it is a device that does not compute one — comes out at 0 %. That is on the Victron side, not on the gateway.

A converter shows no temperature

Correct. Inverters, chargers and DC/DC converters are published without a temperature. A solar charger publishes its regulator temperature, and a battery monitor its battery temperature when it has a sensor.

The equipment is gone but still on the screens

A port that stops delivering valid blocks is dropped after roughly seven seconds, and its MUXEN device disappears with it. A device that flickers in and out is one whose blocks are arriving corrupted — the gateway throws away any block whose checksum is wrong, and a bad cable does that several times a second. Suspect the cable, not the gateway.

I have a fifth Victron device

Four ports, four devices. There is no expansion and no sharing of a port. A fifth device needs a second gateway.

muxen-uds locate does not blink the box

On this firmware the routine that normally blinks the LED returns the list of the four ports instead. Identify the box by its UID, not by locate.

After a factory reset, everything came back with different numbers

Expected. The gateway rediscovers the four ports on its own, but the instance numbers you chose, the parc bindings and the battery limits are gone, and the numbering starts again from the port order. Restore them from the CSV you saved at commissioning.