Skip to content

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, then terraform apply <plan>), only from the workstation that holds the state, and only when the plan shows 0 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 from terraform 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.