Skip to content

Identity — what makes a device this device

A device has exactly one identity, and it comes from the chassis: the serial number. Everything else is derived from it.

That sounds obvious and is the single most frequent source of confusion in this system, because there are three further numbers in play that look like an identity and are not.

Number What it identifies Stable across
Serial number of the chassis the device everything — this is the identity
Map id a map on this device nothing; a copied map gets a new one
Point id a point in this map nothing; same problem
MAC address a network interface replacing a radio module

The consequence runs through the whole system: fleet reservations, lift queues and neighbour awareness are keyed on the serial number and on names — never on ids. Two independent teams found this out the same way and paid for it twice; see Fleet and Lift Control.

Reading it out

The server asks the chassis for its serial number at start-up and keeps asking until it gets one — every thirty seconds, without giving up, with a note in the log at most once every five minutes.

That is not defensive programming for its own sake. Measured on 24.08.2026 in Stuhr: both servers came up, the surfaces ran, and the fleet stayed off because device/info did not answer at start-up. Our server starts with the device, the chassis takes longer, and a robot switched off in the evening is only reachable after a while in the morning. Whoever asks once here builds a fleet that depends on the moment of power-on.

The key pair

Generated on first start, private part with permissions 0600, in the identity folder outside the repository. The public fingerprint is shown on the technician page — it is what a technician compares when a device appears twice in the console.