uSuite — console and administration, state 15.09.2026¶
Info
This page describes what the uSuite console and its administration interface can do after the September 2026 night runs (merged 14./15.09.2026). The device side — MQTT, job document, rollout stages, enrolment — is unchanged and documented in URG cloud (uSuite). Nothing on this page adds a driving command: the cloud still sends the device exactly two things, a release and a lock.
What is new for operators and service¶
| Area | What it does | Since |
|---|---|---|
| Device master data (Stammblatt) | Per device: delivery date, warranty months, contract level and end, maintenance interval, last maintenance, display name, floor, contact. Without these entries the device shows as without data in the service view — nothing is estimated. | 14./15.09.2026 |
| Product series (Baureihe) and type records | Every device carries its series (ulog-deliver-80, ulog-deliver-150, ulog-lift-150, userve, …). Documents can be filed for the whole series in one go — data sheet, quick guide, service description, user manual, IT notes, network requirements, declaration of conformity. Service booklets are filed per device. The batch dialog classifies files by name and shows the class before anything is stored. |
15.09.2026 |
| Superseded editions | A newer edition of the same class, language and product marks the older one as superseded by …; operators and partners see only the valid edition. Older entries are never deleted. A dry-run stock pass links the existing duplicates (Rev. 02/Rev. 03, 2.0/2.1). | 15.09.2026 |
| Decommissioning | Two separate paths: retire (reversible, device stays in the list, messages keep flowing into the log) and revoke credential (final, two-step confirmation, log line). Revoking is prepared but switched off until the infrastructure step is applied. | 15.09.2026 |
| Certificate expiry | The watch service reads each device certificate's expiry and opens a case with a deadline below 90 days (notice / warning / fault at 90 / 30 / 7 days). Renewal itself is not part of this stage. | 15.09.2026 |
| Updates page — version distribution | A bar over the update page: 14 devices on 2.4.1, 3 on 2.3.9, 1 unknown. Clicking a segment filters the device list. Numbers come from the existing fleet and version data, no new route. | 15.09.2026 |
| Updates page — preselection before release | Choose the version, choose the target (one device, one site, one customer), read how many devices are affected and how many already run it, then release. Releasing does not mean immediately: every robot picks it up at its next charging break. | 15.09.2026 |
| Updates page — “What is new” | Per version a fold-out with the change list. The list is a Markdown file stored next to the signed package (pakete/<layer>/<version>.md); the package itself is untouched. Rendered without a library, no links, no raw HTML. |
15.09.2026 |
| Session | The console now renews the sign-in ticket silently. Before, every session ended after 60 minutes with not signed in — a console-side omission, the identity provider was configured correctly. | 15.09.2026 |
| Thing groups per site | For every site node the administration keeps a device group (kunde-<customer>, haus-<customer>-<site>) next to the existing release group. Prepared for release by site; switched off until applied. |
15.09.2026 (branch) |
| Automatic cases carry the device | Cases opened by the watch service (emergency stop, battery, wheel overload, reporting gap) now carry serial number, path, customer and type — before, they were visible to no site. A stock pass fills the missing fields on existing cases (dry run first). | 15.09.2026 (branch) |
Administration routes added¶
All routes sit behind the administration HTTP API, are authorised by the same JWT check as the existing ones, and write a log line per change. None of them deletes data.
| Route | Purpose | Roles |
|---|---|---|
POST /geraet/{seriennummer}/stammblatt |
Set the master data fields of one device | service, administrator |
POST /geraet/{seriennummer}/stilllegen |
Retire a device (reversible) | administrator, service |
POST /geraet/{seriennummer}/wieder-in-betrieb |
Put a retired device back into operation | administrator, service |
POST /geraet/{seriennummer}/kennung-entziehen |
Revoke the device credential (two-step; the IoT action stays behind a switch until applied) | service only |
GET /fassung/{fassung}/{schicht}/neu |
Read the change list of a version (404 if none is stored, 501 in an environment without version management) |
everyone with a scope |
Routes that existed before this stage — knots, join codes, customers, accesses, cases, service requests, version release, records — are unchanged; see Services overview.
Operating notes¶
- The console is published by hand. Netlify does not build from Git; after every merge that
touches
konsole/the console is pulled to Netlify manually. New files must be included (standverteilung.js,freigabe-vorauswahl.js,was-ist-neu.js,schein-erneuerung.js), otherwise the page stays blank. - Infrastructure changes are applied per branch with a saved plan (
terraform plan -out, thenterraform apply <plan>), only from the workstation that holds the state, and only when the plan shows0 to destroy. - Change lists are placed next to the package:
aws s3 cp <version>.md s3://<package bucket>/pakete/server/<version>.md --content-type text/markdown. The bucket name comes fromterraform output.
Known gaps (15.09.2026)¶
- Documents whose file name names two product families (
uServe_uLog_Serie,uLog_uServe) — the declaration of conformity and the network requirements — could only be filed per device for the uLog series; the classifier treated them as uServe documents. Fixed on a branch (A43), to be re-filed series-wide after the merge. - Netlify is not coupled to Git (decision pending).
- Where the credential is revoked (administration or enrolment service), and whether retired devices count in the fleet figures, are open decisions.