Site computer and building — how the pieces talk¶
What runs where when a site has u-IoT modules, doors and a lift, and which credential each connection carries. Read from tablet-ui (branch zugriffsschutz, uGo service 1.0.4) and the level-change service dienste/gebaeude/multilevel-accessibility. BELEGT = taken from code; OFFEN = not in the code yet.
Status of this page: 12.09.2026.
Software state
The frozen software state is uGo 1.0.8, kiosk 1.0.3, network guard 1.1.9 (frozen 10.09.2026). The service access window of 15, 60 or 240 minutes named in §5 belongs to network guard 1.1.9. The code statements on this page were read from uGo service 1.0.4; the re-check against 1.0.8 is still open (A0c of the building findings, state 06.09.2026). No build id is on record for 1.0.8.
The building interface description and the technician manual chapter Building now exist as version 1.1 of 12.09.2026 in DE, EN, FR, ES, IT and NL and carry the same software state; they are the leading documents for the site side. See Integrations and uLog and uServe — Documents.
1 The pieces¶
| Piece | Where it runs | Speaks to | Credential |
|---|---|---|---|
uGo server (the robot's own server, /api/**, technician page with the Building tab) |
on the robot's tablet (port 5301) — or, in a site-computer setup, on the site computer, one instance per robot | chassis (CHASSIS_BASIS), u-IoT modules, level-change service, network gate, uSuite (outbound only) |
is the server of sessions and service key |
| u-IoT module (call button, light, sound, door contact) | in the building, in the same network segment as the site computer | is called by the uGo server (REST, port 80 by default); calls the robot's uGo server when a button is pressed (see §4) | none towards uGo (the uGo server calls it); service key when it calls uGo |
Level-change service (multilevel-accessibility) |
site computer, port 3100 | chassis (maps, moves), its own database (map/level profiles, point catalogue) | MULTILEVEL_SHARED_KEY — the uGo server sends it as Authorization: Bearer from EBENENWECHSEL_SCHLUESSEL |
Lift bridge / door service (elevator-control, door-control) |
site computer | lift controller adapter; door contacts | ELEVATOR_SHARED_KEY (bearer) — not called by the uGo server in this stage OFFEN |
| Network gate | on the robot's tablet, 127.0.0.1:5302 |
iptables / device policy | reachable from the device only |
| Fleet | every uGo server, UDP 45301 broadcast | the other robots of the site | FLOTTE_SCHLUESSEL — a different key from the service key |
Two keys, two purposes
FLOTTE_SCHLUESSEL (fleet, UDP, per site) and the service key (x-urg-dienstschluessel, HTTP, per robot) are not the same thing and are not interchangeable. The fleet needs no HTTP endpoint and no service key; a site computer that calls a robot's /api/** over HTTP needs that robot's service key. BELEGT
2 How the site computer speaks to a robot — the service key¶
Every HTTP request from the site computer to a robot's uGo server comes from the network and therefore needs a session. A site computer has nobody to type a password, so it sends the robot's service key in a header:
x-urg-dienstschluessel: urg-<64 hex characters>
| Rule | BELEGT |
|---|---|
| one key per robot, generated by the technician on that robot's technician page (Device → Service key), shown once, stored as hash | the site computer keeps one key per robot it talks to |
the key counts as an operator session: start/stop a tour, trigger a rule (/api/regeln/aktion), create/cancel a move (POST /api/chassis/chassis/moves, PATCH …/moves/<n>), read everything |
— |
the key can not configure: /api/gebaeude/** (even GET), settings, drive values, passwords, WLAN, cloud enrolment, pose/map/service switching of the chassis, /api/servicezugang, /api/dienstschluessel → 403 |
building configuration is done by a technician in the Building tab, not by the site computer |
| a valid key is never throttled; a wrong key counts per address (5 → 60 s, doubling); after "renew" the old key is void immediately | keep the key in the site computer's environment file with mode 0600, never in a script or a chat |
liveness without any credential: GET /api/leben → {ok, fassung} |
use this for monitoring and install checks, nothing else |
Example — the site computer starts a tour on a robot:
curl -s -H "x-urg-dienstschluessel: $UGO_DIENSTSCHLUESSEL" \
-H "content-type: application/json" \
-d '{"aktion":"start","tourId":"abend-runde"}' \
http://192.168.0.10:5301/api/touren/lauf
A 401 {"fehler":"Nicht angemeldet."} means the header is missing; 401 {"fehler":"Der Dienstschlüssel stimmt nicht."} means the key is wrong or has been renewed; 403 means the call is configuration and needs a technician.
In a site-computer setup (uGo servers running on the site computer, tablets reaching them over the LAN): the operator tablet is "network" too and needs an operator password — from the network there is no login without a password, even with the operator set to "frei". The cookie lasts 8 h at most, the session 10 min sliding; a tablet that polls stays logged in but must log in again at least every 8 h. BELEGT
3 Level-change service — what the uGo server does with it today¶
| Call | From | Purpose | In 1.0.4 |
|---|---|---|---|
GET /health-check |
uGo server, 2.5 s | "Dienst erreichbar" on the Lift card | BELEGT |
GET /points[?mapId=] |
uGo server, bearer key | point catalogue for the active map, with gelesenAm; an outdated catalogue is marked when the map overlay changes |
BELEGT |
POST /moves {robotId, targetPointId, targetMapId?, requestedBy:"api", correlationId, owner:"ugo-gebaeude", ownerToken?} |
adapter ebenenwechselAnfordern() |
request a level change; the service answers accepted \| rejected \| ambiguous with moveId and ownerToken, or 409 robot_owned when another owner (e.g. the tour run) holds the robot |
adapter exists, no route calls it — test ride button disabled OFFEN |
GET /moves/{id} |
adapter bewegungsstand() |
state, detail of a move |
not wired OFFEN |
POST /moves/{id}/pause, /resume |
— | pause/resume at the next safe boundary (never mid-cabin) | not used by uGo OFFEN |
Ownership. The service holds an ownership lock per robot ("one writer per robot"): a move carries owner and, on acceptance, an ownerToken; another owner gets 409 {"status":"rejected","reason":"robot_owned","owner":"…"}. The Building tab would appear as owner ugo-gebaeude. BELEGT
Drive profile. The service resolves the profile for the cabin legs as: the lift's own MapLevelProfile.cabinProfile (speedMps, thresholdMode) → service default CABIN_ENTRY_SPEED_MPS (0.35 m/s) → hard cap MAX_SPEED_MPS (0.5 m/s), and logs when it had to clamp. The Building tab stores the same two values per lift and validates them against min(0.5, vehicle max_forward_velocity) — but the service does not read the tab's storage, and POST /moves strips an unknown cabinProfile field. Today a per-lift profile has to be entered in the service's own configuration to take effect. OFFEN
Map identity. The tab binds floors to mapUid; the service keys MapLevelProfile and points by mapId (= String(map.id) of the chassis). The tab passes the id the service expects when it asks for points; nothing is converted. A data migration mapId → uid in the service is open question 2 of the requirements document. OFFEN
Known defects of the service (requirements 2.3, not fixed by the tab): relocalize returns before the new pose is confirmed; the point catalogue is read at start-up only. The tab shows an outdated catalogue as such and never releases a cabin — that is why the test ride is locked.
4 Call buttons — three paths, one of them live¶
| Path | What happens | State |
|---|---|---|
A — firmware call (call_me) |
The technician assigns the button in the Building tab: POST /actions on the module with action_type: call_me_request, linked_inputs: [DI_x], call_me_action.point_id: <point name>. On a press the module (or its coordinator) queues the request and dispatches the robot from its u_logs list to point_id. The tab reads the queue via /call-me/status every second, lets a person accept (local note) and complete (POST /call-me/cancel while cancellable, otherwise local note). |
live BELEGT — the dispatch itself is firmware behaviour |
| B — rule trigger on the uGo server | A module (or the site computer) calls POST /api/regeln/aktion {"aktion":"taster","kennung":"<button id>"} on the robot's uGo server; a rule on the technician page decides what the press does. Since ULS-238 this call needs the service key — a module or site computer without the header gets 401. |
live BELEGT |
C — "On call" actions of the tab (drive, sound, light, with output references) |
stored with the button | not executed OFFEN |
Which path a site uses is a commissioning decision. Path A keeps the queue and coordinator logic in the modules; path B keeps it in uGo's rules. Both are configured by the technician; in path B the module firmware has to be able to send the header (or the site computer relays the press).
Coordinator. Exactly one module per site is coordinator; the others are client with coordinator_base_url pointing at it. The tab sets this via PUT /config {call_me: …} on the new and the previous coordinator, and enters this robot into an empty u_logs list with the chassis address uGo uses. Fields whose name looks like a secret are never written back. BELEGT
5 Network — the site computer as the only gateway¶
| Direction | Allowed | Blocked |
|---|---|---|
| robot (tablet, chassis) → internet | uSuite (443, 8883), the remote support tool, time and name service of the building | everything else — logged and rejected by the network gate (root mode) or blocked at the site router |
| customer network → chassis (8090/9000/9001 behind the tablet's NAT) | only from the registered site computer (standortrechner in the gate's settings); SSH 22 never |
everything else |
| customer network → tablet 5301 (uGo), 5555 (adb) | only from the service network / registered site computer when the inbound block is enabled; 5301 always needs a session or the service key; adb only within an opened time window | — |
| uGo server → modules, level-change service, door/lift services | LAN, inside the protected segment | — |
| cloud → robot | nothing — no inbound connection, no drive command from the cloud; data in Europe, data centre Frankfurt | — |
In tunnel mode of the gate (no root on the tablet) the chassis is not blocked by the gate; then the site computer as the only gateway and the block at the site router are mandatory. BELEGT (gate handover 1.1.2, §4.1)
5.1 Ports on the site computer — the rule of 11.09.2026¶
The principle: manufacturer services keep their ports; the services of United Robotics Group move out of the way. Use this table for the port list and the firewall rules of a site, so that both sides agree.
This is the one port table on this portal
Since 12.09.2026 the table stands here and nowhere else on this portal; the Building API and the building interface description 1.1 point here instead of repeating it, so that a port change has exactly one place to be made. Offline, the interface description 1.1 carries the table in its chapter 11.1 and remains the leading document for the values; if the two ever differ, the offline document wins and this page is out of date.
| Service | Port | Direction and scope |
|---|---|---|
lift service of the manufacturer (elevator-control) |
8080 and 8085 | local on the site computer; unchanged |
| lift simulator of United Robotics Group | 8185 (until 11.09.2026: 8085) | test and hall operation only, local on the site computer; no simulator runs on a site computer in customer operation |
| level-change service | 3100 to 3103 (one instance per robot) | local on the site computer |
| uGo server of the robot | 5301 | site computer → robot, with service key |
| network guard on the device | 5302 | loopback on the device only |
| fleet coordination of the robots | 45301/UDP | robot network |
| chassis | 8090, 9000, 9001 | from the site computer only |
| u-IoT modules | 80 (or the port fixed during commissioning) | site computer → module, protected segment |
Only the lift simulator of United Robotics Group moved, from 8085 to 8185. Ports 8080 and 8085 of the manufacturer service are unchanged, and a port list written before 11.09.2026 that carries the simulator on 8085 has to be corrected. Older test and hall-test papers still name 8085 for the simulator; they are superseded by this rule.
6 Checklist for a site-computer setup¶
- Every uGo server on the site computer starts via
node server.js(systemd unit) — otherwise its own kiosk counts as network. - Service password set on every robot before it joins the customer network; operator password set for the tablets.
- One service key per robot, generated on that robot, stored on the site computer (mode 0600) and entered wherever the site computer or a module calls that robot's
/api/**. EBENENWECHSEL_SCHLUESSELin the environment of the uGo server =MULTILEVEL_SHARED_KEYof the level-change service;ebenenwechselAdresseandroboterKennungon the Lift card.- Modules in the same segment as the site computer, or the scan range entered by hand; module port 80 (or set on the Modules card).
- Monitoring on
GET /api/lebenonly. - Network gate with the workshop settings file first; customer file only after the service access from the technician page has been verified.