muxen-boat — Overview

muxen-boat is the daemon that makes the boat's own equipment readable. Every MUXEN box on board — the battery monitors, the power distribution blocks, the solar and wind chargers, the inverter/charger, the motors, the watermaker, the air conditioning, the wind and speed instruments — talks on a private CAN bus in a compact binary format that nothing but another MUXEN box understands. muxen-boat listens to that bus, decodes every frame it recognises, and republishes it as plain JSON on the Brain's MQTT broker.

It works in the other direction too. A screen that switches a light on, starts the watermaker or changes the air-conditioning setpoint publishes a small JSON message on a command topic; muxen-boat encodes it back into a CAN frame and puts it on the bus.

For the owner and the crew, this is the machinery behind every live figure on the boat's screens. The daemon itself has no user interface and nothing in it runs on its own initiative: it repeats what the boat says, and it forwards what somebody asks the boat to do.

For an installer or an integrator it is the boat's data plane. If a value is wrong on a screen, this is where you look first — a mosquitto_sub on one topic settles whether the problem is in the device, in the bridge, or in the screen.

Where it sits in the MUXEN stack

             screens / HMI (@muxen/boat)        other muxen-* daemons
                       |                                 |
                 ws://…/ws/boat  (1884)            mqtt 127.0.0.1:1883
                       |                                 |
                 ┌─────┴─────────────────────────────────┴─────┐
                 │            mosquitto broker                 │
                 └───────────────────┬─────────────────────────┘
                                     │  device/…  system/time
                                muxen-boat
                                     │  (decode / encode)
                                   can0
                 ┌──────────┬────────┴────────┬──────────────┐
             battery      bloc8            solar          motor  …

muxen-boat is the bottom of the MQTT half of the Brain, and most of what runs above it depends on it:

• It is the package that configures the broker. muxen-boat ships /etc/mosquitto/conf.d/mosquitto-boat.conf, which is what opens mosquitto's MQTT listener on 1883 and its WebSocket listener on 1884. Every other MQTT client on the Brain — daemon or browser — connects through the listeners this package defines, and the package's postinst restarts mosquitto so they exist immediately after install.
• It is the only producer of the device/… topics. Any service or screen that reads live equipment data reads topics this daemon publishes. Nothing else decodes the MUXEN CAN frames into JSON.
• It publishes the shared wall clock. system/time goes out once a second and is what the @muxen/boat clients use to decide whether a reading is still fresh. A client that never sees it treats everything as stale — see Web clients.

It is very nearly a read-only participant on the bus. It transmits only when an MQTT command topic tells it to, and it never polls.

What it talks to

It reads	From	Purpose
MUXEN CAN frames	can0 (configurable, --interface)	live equipment data
device/<f>/<i>/command	MQTT	per-device commands
device/<f>/<i>/reset	MQTT	generic device reset
device/<f>/<i>/rtr/<frameId>	MQTT	generic frame request
the CAN link state	the kernel, via netlink	the device/interface report

It writes	To	Purpose
device/<f>/<i>/<subtopic>	MQTT	one topic per decoded frame
device/<f>/<i>/error/<code>	MQTT	Diagnostic Trouble Codes
device/interface	MQTT, every 10 s	CAN link state, counters, bit timing
system/time	MQTT, every 1 s	the Brain's UTC clock
MUXEN CAN frames	can0	encoded commands, resets, frame requests
NMEA-0183-style sentences	UDP, when --udp is given	off-Brain consumers

The daemon holds no state of its own: no configuration file, no database, no control socket. What it knows is on the bus, and what it says is on the broker.

Addressing in one paragraph

Every MUXEN device on the bus has a function code — what kind of equipment it is — and an instance — which one of them it is. A battery monitor is function 5; the second one on the boat is instance 1. That pair is the whole address, and it is what the MQTT topic carries: device/5/1/life. The catalogue in The device catalogue lists every function code the daemon decodes and links to a page per device model.

Document map

Document	Content
Getting started	install, verify the service, watch the first topic, send the first command
The device catalogue	the device catalogue: addressing, payload shape, generic commands, one page per device model
Web clients	the @muxen/boat TypeScript client for screens and web interfaces
Troubleshooting	symptom → cause → check → fix, plus FAQ and tips
Reference	CLI, units, files, broker and proxy configuration, exit status
The CAN bridge	how CAN frames become topics and topics become CAN frames