Skip to content

Technician manual — chapter Building tab

The building equipment of a site — u-IoT modules, call buttons, doors, lift — is configured in one place on the uGo technician page: the Building tab. This page carries the full content of the document uGo Technician Manual, chapter Building tab, version 1.1 of 12.09.2026.

Audience: service technicians of United Robotics Group and appointed partners.

Document control

Item Value
Document uGo Technician Manual — chapter Building tab
Version 1.1 · as of 12.09.2026
Applies to uGo service 1.0.8, Kiosk 1.0.3, network guard 1.1.9 — software level frozen on 10.09.2026 — Building tab stage 1, access protection per ULS-238
Written by Product Management and Service, 12.09.2026
Reviewed by Product Management and Service, 12.09.2026
Release Released by management on 12 September 2026; QM review pending
Languages DE, EN, FR, ES, IT, NL — see uLog and uServe — Documents

This chapter describes what the software does today

What is deliberately not available in this stage — test ride, door test run, execution of call actions — is stated at the place where a technician would look for it. A technician looking for such a function finds the information that it does not exist yet, not an instruction that leads nowhere.

1 What the Building tab is

It is the second tab in the tab bar:

Map and zones | Building | Device | Display and media | Site | Administration

The tab has three cards:

Card What it holds
Modules scan for u-IoT modules, module list with freely chosen names, inputs and outputs live, switching an output, clock, own wireless network, backup of the module settings, location of the module on the map
Calls coordinator of the calls, assignment call button ↔ point on the map, list of open calls with accept and complete
Doors and lift doors per map (name, output, zone, opening and closing point), lifts with floors ↔ maps, waiting points, lift doors, drive profile per lift, point list of the level-change service, state of the level change

Three principles apply on all three cards:

  1. The tablet never talks to a module or a service directly. Every call goes through the uGo server on the site computer. The tablet only sees what the server makes of it.
  2. No network address, no serial number, no channel id without the switch "Show technical details". The switch is off every time the tab is opened and is not stored.
  3. No drive command from the Building tab. The tab assigns and displays. It does not drive — not even as a test ride. A call is kept as a job in the tour list, never as a direct drive command.

The call logic — who gets which call, queue, fallback — lives in the firmware of the modules. The tab reads and configures it; it does not rebuild it.

2 Prerequisites

Prerequisite What must be in place How to recognise it
Site computer The uGo server runs on the site computer (or on the robot's tablet) and reaches the network segment of the modules. The server is started through server.js — only then does it know the origin of a request (device or network). The technician page opens; the tab bar shows "Building" in second place.
u-IoT modules Modules are on the network, have an address and answer on their port (default 80). All modules of a site are in the same segment as the site computer; otherwise the scan range has to be entered by hand. The scan finds the modules; the serial number is visible under "Show technical details".
Level-change service For the "Lift" card the level-change service runs on the site computer (default http://127.0.0.1:3100). Its access key is in the environment of the uGo server (EBENENWECHSEL_SCHLUESSEL) — never in the user interface, never in a file of the tab. The "Lift" card shows "Service reachable".
Service password and technician session Every function of the tab — reading included — requires the technician role. A logged-in operator and an automaton with a service key get the refusal "Only the technician may change this." Login with the technician password; the session ends ten minutes after the last access.
Map loaded Points, zones and locations can only be chosen while the chassis reports an active map. Without a map the tab says "No map is loaded."

Storage. Everything the tab stores lives in one file on the site computer (daten/gebaeude.json, adjustable via GEBAEUDE_DATEI). It is written as a side file first and then renamed; a power failure during writing does not leave half a file. Passwords or keys are not in it: a lift only carries the reference to an entry in the password store, never the value.

2.1 Ports on the site computer (rule of 11.09.2026)

Principle of the rule: manufacturer services keep their ports; the services of United Robotics Group move out of the way. The one substantive change is the lift simulator of United Robotics Group, which moved from 8085 to 8185; ports 8080 and 8085 of the manufacturer service stay unchanged.

The full port table is in § 5.1 of Site computer and building and nowhere else on this portal, so that a port change has exactly one place to be made.

3 Login and access protection

3.1 Factory state

A robot without a service password is in factory state. What applies then depends on where the access comes from:

Origin Reachable in factory state
From the device (kiosk shell on the tablet, loopback) everything — including the technician page. A test setup does not lock itself out.
From the network (technician's notebook, operator tablet of a site-computer setup, any computer in the building) only the setup of the service password (/einrichtung), the login page, the liveness endpoint /api/leben and the files these pages need to render. Every other page is redirected to /einrichtung; every API answers 401 "Set up the service password first."

Whoever opens the setup page from the network first is the technician of this robot. Therefore: set the service password before the robot joins the customer network — at the kiosk via the technician page or from the notebook via http://<robot address>:5301/einrichtung. An operator password alone does not end the factory state.

3.2 Roles

Role How it is obtained What it may do
Technician login with the technician password (service password) everything: technician page, configuration, Building tab, service key, service access
Operator login with the operator password — or the customer exempts the operator ("needs none") operator interface, logbook, start and stop a tour, create and cancel a move; no change to the configuration, no access to the technician page or the Building tab
Service key (automaton) header x-urg-dienstschluessel in every request; the key is generated by the technician counts as operator: driving yes, configuring no. Opens no remote access, generates no key.

From the network, since access protection: everything needs a session — the start page, the map and reading the chassis state included. A page without a session is redirected to the login and returned to the requested page afterwards; an API answers 401 "Not logged in.". An operator who opens the technician page lands in the logbook (APIs: 403 "Only the technician may change this.").

From the device itself (kiosk) nothing changes: without a password everything is open, with a password operation is open, technician page technicians only, logbook according to the operator setting. The stop button needs no password.

Sessions. A session is valid ten minutes after the last access and is extended on every access; the session cookie in the browser lasts eight hours at most. Sessions survive a restart of the uGo server — a restarted service logs nobody out. Changing the technician password ends all other sessions. After five failed logins from the same address the server waits 60 seconds, doubling on further failures.

3.3 Service key

Technician page → Device → tile Service key.

Action Expected result
"Generate key" (or "Renew key") confirmation prompt. Then the key is shown once: urg- followed by 64 characters. Copy it to the password store now and enter it into the site computer or the test script. "I have stored it" hides it; after that there is no way back to it. The tile shows "present, generated on …".
"Renew" with an existing key the previous key is invalid immediately, everywhere it was stored.
"Revoke" confirmation prompt. Afterwards no automaton reaches this robot from the network; the tile shows "none".

There is exactly one service key per robot. Only a hash is stored; a valid key is never throttled, a wrong one counts per sender address (five failures, then 60 seconds, doubling) — a neighbour with wrong keys cannot lock out the site computer.

3.4 Service access (adb and remote support with a time window)

Technician page → Device → tile Service access. The tile talks to the network guard 1.1.9 on the device (section 5). The time window is 15, 60 or 240 minutes. It shows the mode of the guard and, for each access — adb and remote support — the state: "open, … min left", "closed" or "no information".

Action Expected result
choose duration (15, 60 or 240 minutes) and "Open adb" "adb opened for … minutes." The state shows the remaining minutes. When it expires the guard closes by itself.
"Open remote support" as above; the remote support tool becomes visible on the device and may connect.
"Close" "Service access closed." Both accesses closed.
guard does not answer "The network guard does not answer. Access stays as it is." — do not press again; check the guard first (section 5.4).

Only the technician may open and close; operator and service key get 403. The tile cannot be operated through the maintenance tunnel.

3.5 Restart

A restart of the uGo server (update, service restart) logs nobody out and discards no setting of the Building tab. Only the two notes "accepted" and "completed" on open calls are lost (section 4.7): after the restart the firmware of the modules is the only truth, and a call that is still open there appears again.

There is no "Restart device" button on the technician page in this version. The tablet is restarted at the device or through an opened service access (adb).

4 Work instructions

Each instruction names the action and the expected result — what has to be on the screen before the next step starts. If something else is shown, section 6 helps.

4.1 Open the tab and "Show technical details"

  1. Log in as technician, open the technician page, choose the Building tab. Expected: header "Building" with the sentence "Modules, calls, doors and lift of the site in one place …", below it the three cards. The "Modules" card reports "… modules in the list." or "No module in the list yet."
  2. For work that needs addresses or serial numbers, set the switch Show technical details. Expected: the module list shows address, serial number, MAC, station address and the channel ids (DI_1, DO_2). The next time the tab is opened the switch is off again.

4.2 Scan for a module and add it

  1. Card Modules, check the field Scan range. Preset is the network of the site computer (/24 of the device address). Allowed: a network (192.168.0.0/24), a range (192.168.0.10-60) or a single address; at most 1024 addresses. If the device address is not an IPv4 address there is no preset — then enter the range.
  2. Check Port of the modules (default 80).
  3. Scan for modules. Expected: "Scan running over … addresses.", below it "… of … addresses checked". A network of 254 addresses takes just under half a minute. "Cancel scan" stops it. At the end: "… modules found, … addresses checked." A device counts as a module only if it answers /ping with pong and reports a serial number — a foreign web server does not appear.
  4. Give each find a name and Add to list. A find that is already in the list is marked "already in the list"; if it has a new address the row offers "Adopt new address".
  5. Save module list. Expected: "Module list saved: … modules." Rejected: a module without a name ("Every module in the list needs a name."), a duplicate name (case and whitespace do not count as a difference) and a module without a serial number.

The mapping name ↔ device runs on the serial number, not the address. If the address changes via DHCP the name stays; the next scan offers to adopt the address.

4.3 Check a module: inputs and outputs, switch an output, clock, wireless network

  1. Open a module in the list. Expected: "Reading state …", then the channels Input 1, Input 2 ("active" / "idle") and Output 1, Output 2 ("on" / "off") — re-read every second while the module is open. Also Clock set / Clock not set, the own wireless network (on/off), the firmware build with build date (as the module reports it — there is no invented version number) and "last reached …". If the module does not answer within three seconds: "Not reachable. No previous state is shown." — no value is shown then, not a frozen one either.
  2. Per channel a label and a purpose can be set (door, light, sound, button, unused). Then save the module list.
  3. Switch an output: On, Off or Toggle. Expected: if the purpose of the output is "door", the prompt "… switches a door. Really switch?" comes first. Then: "…: the output is now on (re-read at the module)." The state shown comes from re-reading the module, not from the command sent. If the module refuses, its error sentence is shown and nothing was switched.
  4. Clock: a time source cannot be set from the tab; it is configured during commissioning of the module. The tab only shows the state.
  5. Switch the own wireless network on or off. Expected: when switching off, the prompt with the note: the rescue function of the wireless network can only be disabled from the station address; at the device, input 1 held for ten seconds restores it. Then "The module's own wireless network is switched off." or "Applied; the module needs a restart for it."

4.4 Location of a module on the map

  1. Open the module, Set location on the map. Expected: "Tap the map where the module is." The map view is active; setting only works with a loaded map.
  2. Tap the map, Adopt location, save the module list. Expected: the row shows "Location: ". After leaving and returning the location is at the same place on the same map. "Delete location" removes it.

4.5 Choose the coordinator of the calls

Exactly one module per site keeps the calls and distributes them. Without a coordinator every module works on its own, and the tab asks every module for its open calls.

  1. Card Calls, section Coordinator, choose a module, Make coordinator. Expected: prompt "Make … the coordinator? The previous coordinator becomes a participant." Then "… is now the coordinator." In the module list the module carries the role "Coordinator", a previous coordinator the role "Participant".

The server writes the role to the new coordinator first; if that fails the old one stays, and there is still exactly one coordinator. If no robot is entered in the new coordinator yet, the server enters this robot with the address uGo uses for the chassis.

4.6 Assign a call button to a map position

A call button hangs on an input of a module and calls to a point of the active map.

  1. Card Calls, section Call buttons: choose the module, choose the input (input 1 or 2), choose the point from the list of points of the active map. Under On call tick the action: drive to the point, sound, light; for sound and light choose the output of a module.
  2. Assign button. Expected: "The button now calls to point "…"." The server writes the assignment into the module first (one call action per input; a second assignment replaces the first) and only then into the storage. If the module refuses, nothing is stored.
  3. Check: the list of call buttons shows the point name. If the point is missing on the active map (renamed, other map) the row shows "Point missing on this map" — the firmware would send the call into nowhere; fix this before anybody presses.
  4. Remove assignment takes the entry out of the tab's list.

In this stage

The "On call" action (drive, sound, light) is stored but not executed. The call itself runs through the firmware of the modules and the robot entered there. "Remove assignment" only removes the tab's entry; the call action in the module stays until it is overwritten there or deleted in the firmware interface.

4.7 Open calls: accept and complete

Expected list: Open calls with point name, time (when the tab saw the call for the first time), state ("waiting", "waiting for robot", "point being resolved", "dispatching", "dispatched", "moving") and assigned robot. Refreshed every second while the card is visible.

Action Expected result
Accept "Call to "…" accepted." — a note on the site computer (somebody takes care); the row carries "accepted". The firmware knows no accepting.
Complete before the move was dispatched "Call to "…" completed — the module has withdrawn it." The call is withdrawn in the firmware.
Complete after the move was dispatched "Call to "…" noted as completed. The move continues; nothing is cancelled." — a note only; no cancel at the chassis.

The notes do not survive a restart of the uGo server (section 3.5).

4.8 Create a door per map

A door consists of five mandatory fields: module, output, zone on the map, opening point, closing point — plus name and map. Without one of the five the door is created but not armed, and the row says what is missing.

  1. Card Doors and lift, section Doors, Create door (only with a loaded map). Expected: a new row with the fields name, module, output, zone on the map, opening point, closing point; state "not armed — missing: …".
  2. Enter the name, choose module and output, choose opening and closing point from the points of the active map.
  3. Draw zone: switches to the "Map and zones" tab and enables drawing a zone. Draw the zone, return to the Building tab, choose the zone in the door row. There is no second drawing tool.
  4. Save doors. Expected: "Doors saved: …, of which … armed." A door without a zone is saved and stays "not armed". Rejected is only what cannot coexist on one map: two doors with the same name on the same map, two doors on the same output on the same map, a door without a name, a door without a map — the message names the door and the reason.
  5. Door marks from the map overlay: if the map carries door marks that are not doors yet, the card says "The map carries … door marks that are not doors yet." Adopt as door creates the door; nothing changes without saving, and values set by hand are kept.

Doors of other maps stay stored and idle ("This door belongs to another map …"). The same door name may occur on several maps.

In this stage

There is no test run of a door. A door output can be switched under "Modules" with a prompt (section 4.3). The door list of the tab is stored locally; it is not handed to the door service.

4.9 Lift: floors ↔ maps, waiting points, lift doors

Every floor of a lift is exactly one map, and every map exactly one floor. In front of the cabin there is one waiting point per floor.

  1. Section Lift, Create lift, enter the Designation of the installation — the site's designation (e.g. "Lift building 2"), no manufacturer name.
  2. Add floor: floor number (positive integer, as the lift service expects it), choose the map, name of the waiting point (point on the map of this floor, in front of the cabin), lift doors (door numbers of the lift on this floor, e.g. 1, 2; at most eight).
  3. If needed check Address of the level-change service and Id of this robot (the robotId under which the level-change service keeps this robot; default robot-1).
  4. Save lift. Expected: "Lift saved: … floors." Rejected: the same map for two floors ("… this map is already assigned to another floor.") and a duplicate floor number. A floor without a waiting point is saved but shown as "locked without waiting point".
  5. State (right): active map, its floor ("not assigned to a floor" if there is no binding), Level change "Service reachable" / "Service not reachable", sequence "No level change active".

4.10 Drive profile per lift

The robot drives over the sill into the cabin and out again at a fixed, sufficient speed. Approached too slowly, it stops at the sill or gets stuck. The value belongs to the lift — every installation has its own sill.

Section Driving into the cabin per lift:

Field Values Rule
Cabin approach speed (m/s) 0.20 to 0.50, default 0.35 The interface shows "Upper limit: … m/s". It is the smaller of the fixed limit 0.5 m/s and the forward maximum speed the vehicle itself carries in its drive values. If the drive values cannot be read at the moment, the fixed limit applies, and the interface says so.
Sill behaviour Standard (the robot treats the sill like any obstacle) or Cabin: no stop at the sill (default) The same words as in the level-change service.

Expected when saving: a value above the upper limit is rejected, not clamped: "…: 0.5 m/s is above the upper limit 0.4 m/s. That is the maximum speed the vehicle itself carries; it is not raised from the Building tab." The upper limit is read fresh from the vehicle when saving, not taken from the display. A value below 0.2 or above 0.5 is clamped to the range.

In this stage

The drive profile is stored and checked in the tab. The level-change service today drives its cabin legs with the profile from its own lift configuration; the profile stored in the tab is not yet read by it. Whoever wants to change an approach speed effectively enters it in the level-change service as well.

4.11 Point list of the level-change service

  1. Section Lift, Request point list. Expected: "Point list read: … points." and below it "Point list from
  2. If the map overlay changes afterwards, the card shows "Point list from …, map changed since — please request again". Then request again.

The level-change service itself reads its point catalogue only at start-up today (known defect). The tab does not cover that up: an outdated list is marked as such; the fix lies in the service.

4.12 Test ride — deactivated in this stage

The button "Test ride floor …" is present per floor and is locked. Next to it stands the reason: "The test ride is locked in this stage: no drive command leaves this tab while the position after a level change is not confirmed. It will be released with the next stage."

In this version there is no way to trigger a lift ride from the Building tab. A test ride on site runs through the level-change service and the tour run, not through this tab.

4.13 Backup, restore and factory state of a module

The backup is kept in the module itself. An export or import of the module settings is not possible from uGo — the export would contain passwords in clear text.

Action Expected result
Back up "The module's settings are backed up."
Restore prompt "Restore the backed-up settings of "…"? The current ones are overwritten." Then "The backed-up settings are restored."
Factory state two prompts. Then "The module is in factory state. The previous settings are kept as a backup in the module."
Remove module prompt "Remove module "…" from the list? Calls and doors referring to it lose their connection." The module's channels drop out of the list on saving.

5 Network guard

The network guard is a separate application on the robot's tablet. It governs what the tablet and the chassis may reach outside and what may come in from outside, and it keeps adb and remote support closed until the technician opens a time window. It is reachable from the device only; the uGo server passes the instructions of the "Service access" tile through.

5.1 What the technician sees and may do

On the technician page At the device (adb, install scripts)
read the mode of the guard diagnosis, install, check, roll back with the scripts of the handover
open adb and remote support for 15, 60 or 240 minutes; close install the guard's settings file (workshop or customer)
– restart the device

What the guard answers is shown unchanged by the tile. If the guard refuses (for instance because it cannot verify the caller), its sentence is shown and access stays as it is.

5.2 Modes

Mode What applies
wurzel (root, preferred) rules in the kernel of the device for tablet and chassis: outbound only to allowed destinations (uSuite, remote support tool, time and name service of the building); no new connection from the chassis to the outside or into the customer network; to the chassis only from the registered site computer. Everything rejected is logged.
tunnel (fallback without root) blocks only the applications on the tablet, not the chassis. For the chassis the block at the site router or the site computer as the only gateway remains binding.
aus (off) only through the settings file; own rules are withdrawn.

Which mode is possible on a device is stated by the diagnosis of the install script (ROOT: ja/nein, Betriebsart: wurzel/tunnel).

5.3 Workshop and customer

Two settings files of the guard: workshop (adb and remote support on) and customer (adb and remote support off; opening only through the time window of the technician page). The order is mandatory: set the service password → uGo service 1.0.8 → guard with the workshop file → check the service access from the technician page → only then the customer file. Whoever installs the customer file before the service access has been checked can only get in through a time window that cannot be opened.

5.4 Way back

  • Inbound block: after installing, the inbound block must be confirmed within ten minutes (the install script does that). Without confirmation the block unhooks itself — a wrong service address does not lock anybody out permanently.
  • Time window: an opened service access expires by itself after the chosen duration and survives a restart within the window.
  • Withdraw the guard: betriebsart=aus in the settings file, or the script schranke-aus.sh — it ends with SCHRANKE ZURUECKGENOMMEN. The way back needs adb; hence the workshop file while checking.

Operation must always be recoverable without physical access and without a working service access — that is the guideline for every setting at the guard.

6 Typical fault pictures

On the screen Cause Remedy
page jumps to /anmeldung, APIs answer "Not logged in." access from the network without a session; session expired after ten minutes without access log in as technician. After login you return to the requested page.
page jumps to /einrichtung, APIs: "Set up the service password first." factory state: no service password set the service password (section 3.1).
"Only the technician may change this." (403) login as operator or access with the service key log in as technician. Logging in as operator again does not help.
call buttons or site computer stop working after the update; 401 automaton without service key generate the service key and send it in the header x-urg-dienstschluessel (section 3.3).
"Too many failed attempts. Please wait … seconds." (429) throttle after five failed logins or five wrong keys from the same address wait; for automatons check the stored key (old key after "Renew").
scan finds nothing wrong range or port; modules in another segment; device address not an IPv4 address check range and port; "Show technical details" and scan a module's address by hand as a single address.
"The scan range … is not readable or too large." more than 1024 addresses or unreadable notation /22 is the largest prefix; otherwise range a.b.c.10-60.
module "Not reachable. No previous state is shown." module does not answer within three seconds (off, network, address changed) check module and network; scan, "Adopt new address".
"The name "…" is used twice." two modules with the same name (case, whitespace do not count) use unique names.
call button shows "Point missing on this map" point renamed, deleted or on another map check the point on the map, reassign the button.
"The module refused the assignment: …" firmware rejects the call action read the firmware's error sentence; check the module in the firmware interface. Nothing was stored.
door "not armed — missing: zone on the map" mandatory field missing draw and choose the zone, save.
"Floor …: this map is already assigned to another floor." the same map for two floors exactly one floor per map.
"locked without waiting point" floor without waiting point name a waiting point on the floor's map.
"… is above the upper limit … m/s." approach speed above the vehicle value or the fixed limit lower the value; the upper limit is not raised from the Building tab.
"Service not reachable" on the Lift card level-change service not running, wrong address, no key check service and address; EBENENWECHSEL_SCHLUESSEL in the environment of the uGo server.
"The level-change service did not deliver the point catalogue (401)." key of the service missing or wrong check the key in the environment.
"Point list from …, map changed since" map overlay changed request the point list again; the service re-reads its catalogue only after a restart.
"The network guard does not answer. Access stays as it is." guard not reachable or older than 1.1.0 do not press again; check the guard at the device (section 5).
service access: "Caller not verifiable – access stays as it is." (403 of the guard) the guard cannot determine the caller on this device time window via adb or workshop file; report to development.
kiosk suddenly asks for a login uGo server not started through server.js — every request counts as network start through server.js (service 1.0.3 and newer does; site computer: check the systemd unit).

7 What is not available in this stage

  • Test ride floor (button locked) and any drive command from the tab.
  • Test run of a door; handover of the door list to the door service.
  • Execution of the call actions drive, sound, light (they are stored).
  • Effect of the drive profile in the level-change service (it is stored and checked).
  • Validation of a lift configuration against the lift service; state of a lift session (the "Sequence" display shows "No level change active").
  • Setting a time source at the module; export and import of the module settings.
  • Restart of the device from the technician page.

8 State of the findings

The internal review of the building functions against the source code recorded twenty findings (A1 to A20). They are the reason why several statements in this chapter read "not available in this stage" (section 7). No finding is reported as fixed in this version.

As of 06.09.2026 — the re-check against uGo 1.0.8 is still pending (A0c)

The findings below were read against uGo 1.0.4; the frozen software level is 1.0.8.

The twenty findings are listed in short form on Building integration — interface description 1.1 § 15. The complete list is an internal paper and not part of this chapter.

Change history

Version Date Change
1.1 12.09.2026 Software level updated to uGo 1.0.8, Kiosk 1.0.3, network guard 1.1.9 (frozen on 10.09.2026); the build id of service 1.0.4 was dropped because none is documented for 1.0.8. Service access with a window of 15, 60 or 240 minutes assigned to network guard 1.1.9 (section 3.4). Order in section 5.3 set to 1.0.8. New section 2.1 with the port rule of 11.09.2026. New section 8 "State of the findings" (as of 06.09.2026, re-check against 1.0.8 pending, A0c). Contact and publisher added. Term "network gate" replaced by "network guard" throughout, per the terminology rule. Released by management on 12 September 2026; QM review pending.
1.0 06.09.2026 First version for uGo service 1.0.4, Building tab stage 1, access protection ULS-238, network guard 1.1.2.

Fault and service: support@unitedrobotics.group.