Common mistakes

This chapter covers what goes wrong on any can-enocean, whatever firmware it carries. Anything about a particular switch model, or about pairing, is in the application's own FAQ.

Read the LED first — then stop reading it

The box has one LED, and on this line it is a heartbeat, not a diagnostic channel — two states, not the four some MUXEN boxes show. See The system LED.

The LED	The box is	What to do
blinking once a second	powered, and its program is running	the fault is elsewhere — bus, settings, pairing or the switch itself
not blinking — dark, or lit and steady	not running its program	power-cycle it once. If it comes back the same way, note the product ID and software version and report it; it does not fix itself

A blinking LED tells you nothing about the CAN bus or the radio: a box whose CAN controller failed to start, or whose radio module is silent, blinks exactly like a healthy one.

The box does not appear on the bus at all

Likely cause	How to tell	Fix
It has never been given an instance number	muxen-uds -i can0 uid --scan shows it at instance 63, marked (parking)	write an instance number — addressing it by UID is what reaches a parked box
The MUXEN bus is not terminated correctly	60 Ω across a powered-down bus; anything near 120 Ω or 40 Ω is wrong	one 120 Ω at each physical end, nowhere else
No power, or CAN not wired	LED off	check the supply and the CAN connector
The box could not start its CAN controller	LED blinks normally, nothing at all on the bus, not even to a UID scan	power-cycle once; if it repeats, report it

A box with no instance number is not broken. It is waiting to be told who it is: it answers a UID scan, it will not serve anything else until it is given an instance, and it publishes nothing in the meantime.

Note that a passive scan cannot prove a can-enocean is absent — a box that has an instance but no paired switches still publishes its own heartbeat, but a parked one is genuinely silent. Use uid --scan, which asks, rather than scan, which only listens.

Two boxes fight over the same identity

Two devices with the same function and the same instance number on one bus produce switch states that jump between two sources and commands that reach the wrong place. It happens whenever a second box is added with the settings of the first, or a spare is fitted without being reconfigured.

muxen-uds -i can0 uid --scan

Each function + instance pair must appear once; the tool marks a contended address with X. Fit and number boxes one at a time.

The box is on the bus but no switch reaches the screens

Likely cause	How to tell	Fix
The switch is not in the box's pairing list	the box publishes the identifier of every switch it hears and does not know	pair it — see the application manual
The pairing was written but the box was not restarted	the parameter reads back correctly and nothing changes	restart the box (see below)
The switch is out of range, or shielded by metal	nothing at all is published when it is pressed, from anywhere	move the box, or the switch; compare the published signal-strength figures between positions
A dead or unpressed switch	nothing published from that one switch only, from any distance	try another switch first, before moving anything

Work the list in that order. Almost every "the radio does not work" call is an unpaired switch or a box that was never restarted.

A setting I changed has no effect

Every parameter on a can-enocean takes effect only after a restart. Writing a setting stores it; the box reads its settings once, when it starts — the pairing list included — and works from that copy until it is restarted. Nothing rejects the write, nothing warns you, and reading the parameter back shows the new value. The box is simply still running on the old one.

Always write with --reboot:

muxen-uds -i can0 -d <address> writeconfig --name <name> --value <value> --reboot

If you changed several settings without it, one restart at the end applies them all:

muxen-uds -i can0 -d <address> reset

After a factory reset, the box has disappeared again

The factory-reset routine restores every parameter to its default, and on a can-enocean that means the entire pairing list is gone — all 63 slots, every switch the boat had. Depending on how the routine is called, the instance number goes with it, and the box returns to the parking address and stops publishing.

There is no undo. Read the configuration out and keep it before resetting anything:

muxen-uds -i can0 -d <address> readconfig --save-as-json before.json

The firmware update failed

Nothing is damaged. The box is still running the firmware it had before — that is by design, see Loading and updating a firmware. The usual causes, in order: an image from the other software version family, a bus interrupted during the transfer, or the wrong product ID. Read the version and hardware ID back, pick the matching image, retry.