Skip to content

Search documentation

Find a section by name or by what it says.

Documentation

Installing a device pool

A device pool is a small program that runs on the machine your boards are plugged into. It owns the serial ports, and it is the only thing that talks to a board directly — everything else talks to it. It connects out to the platform, so there is no port to open and no address to publish.

Install it

On Linux, one line. It detects your architecture, fetches the matching build, checks it against the published checksum, and installs it.

sh
curl -fsSL {{ORIGIN}}/downloads/install.sh | sh
Installs to /usr/local/bin. Pass --help to see the options.

On Windows, download the .zip below and run the executable. There is nothing to install and no runtime to add.

The installer verifies the download against the checksum in the release manifest and refuses to continue if they disagree. If you would rather do it by hand, every published file is listed in SHA256SUMS beside it.

Which build to take

There are two Linux builds. The difference is whether the reference sensors are included, and that decides what your machine needs to have on it already.

staticthe default
One file, no dependencies of any kind. Runs on any Linux of the right architecture, including minimal container images. Handles ESP boards; no camera or microphone reference sensors.
full--flavour full
Adds camera and microphone reference sensors, which record alongside the CSI and give you something to check an answer against. Needs libudev1, libasound2 and libv4l-0 present — the installer checks and tells you the exact command if they are missing.

Take the static build unless you know you want reference sensors. It is the same detector code either way; the sensors are extra inputs, not better ones.

On Debian, Ubuntu or Raspberry Pi OS the full build is also published as a .deb, which lets apt pull the libraries in for you:

sh
curl -fsSLO {{ORIGIN}}/downloads/<version>/cm-pool-<version>-aarch64-linux-full.deb
sudo apt install ./cm-pool-<version>-aarch64-linux-full.deb
The exact filenames for a release are listed in its manifest.json.

The package installs the binary to /usr/bin and nothing else — no service unit, and nothing is started for you. To run it as a service, pass --systemd to the install script or write your own unit.

Pair it with your account

The pool needs exactly one thing from you: where to connect. Everything else — its identity, its access token — it generates for itself on first run.

sh
csi-device-pool --agent-url wss://{{HOST}}/ws/pool

On startup it prints a claim code:

text
=== This pool is UNCLAIMED. Claim code: A1B2C3D4 ===

In the app, go to Fleet → Device pools → Claim pool and enter it. That is the whole pairing step. The pool dials out, so there is no port to forward, no address to register, and no token to copy between machines.

The claim code is a live credential for as long as it is valid — whoever enters it claims that pool into their organization. Treat it like a password rather than a serial number, and do not paste it into a ticket.

Keeping it running

Pass --systemd to the installer and it writes a service unit and an environment file, then tells you what to fill in. Nothing is started for you: name the address to connect to in the environment file, then enable and start the unit.

The pool's data directory is its identity. It holds the id and access token generated on first run. A pool started against an empty data directory enrols as a brand-new, unclaimed pool — and every board registered against the old one is orphaned. Back that directory up before moving a pool to another machine, and restore it rather than re-pairing.