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.