Technician manual — uMe: connection without IP search, and pairing¶
Status as of 31.10.2026. In development — network stage 1 is adopted in the app repository;
the follow-up changes of installation guide version 2.3 are still in development, not yet
adopted. Not yet installed on any device. Basis: installation guide of the uMe Gateway,
version 2.3 (gateway/INSTALL.md). Audience: service technicians of United Robotics Group and
appointed partners. The page follows in German below: Deutsch. Protocol details
for developers: uMe Gateway — discovery and pairing (API 1.1).
For IT, technicians and integration partners
Technical reference for IT departments, URG technicians and trained partners. It is not written as operating instructions for end users.
1 What changes¶
- The app finds the uMe by itself. Nobody has to find out or type an address.
- Only paired tablets can control the uMe. The pairing key is created once, when the Gateway is installed on the robot.
- The address of the robot is shown only in the technician area of the app, never on the customer screens.
- The robot keeps its previous name in the Wi-Fi. The installer does not rename it.
The app searches in three ways in parallel; the number only identifies the way:
| No. | Way | Condition |
|---|---|---|
| 1 | last connected uMe | the tablet was connected before |
| 2 | Name in Wi-Fi (mDNS): service record _ume-gw._tcp; additionally ume-<kennung>.local if the robot publishes this extra name |
the robot announces the service (step 3.2); the extra name exists only if avahi-publish is present on the robot; multicast is allowed in the Wi-Fi |
| 3 | Search in own network: every address of the tablet's own subnet on port 8765 |
private IPv4 network of size /24 or smaller; a larger network is skipped with a note in the technician area |
Without the extra name ume-<kennung>.local the app still finds the uMe through the service record
_ume-gw._tcp and the search in its own network.
A hit counts only if the device answers with a valid hello of the uMe Gateway in a compatible
API version; other devices in the network are ignored. If exactly one paired uMe is found, the
app connects without a tap.
Same ID twice. If the same ID shows up under two addresses (two devices with the same ID, or a device that imitates one), the app does not connect:
- On the customer page No connection both entries show "Kennung mehrfach im Netz – bitte den Service rufen" (English app text: "ID found more than once in the network – please call service"). Tapping such an entry does not connect; it shows the same text.
- The technician area shows "Kennung <kennung> unter zwei Adressen gefunden – kein automatisches Verbinden. Zwei Geräte mit gleicher Kennung? Bitte prüfen."
Remedy: give one of the two robots a different ID (re-installation with a new ID, then pair the tablets again).
2 Order when switching over (mandatory)¶
- First update all tablets to the new app. The new app also works with the old Gateway.
- Then run
install.shon the robot. Do not only copygateway_v2.py: withoutinstall.shthe ID and the pairing key are missing, and the Gateway does not start.
An old app cannot control a Gateway that requires pairing. It shows the message "Dieses Tablet ist nicht mit dem uMe gekoppelt …" (sent by the Gateway in German).
3 One-time set-up per uMe¶
You need two files from the repository robotics-group-app, folder gateway/: gateway_v2.py
and install.sh. <SERVICE-USER> is the service account of the Perception Board; its name is not
published on this site. Replace <SERVICE-USER> before running the commands – PowerShell
rejects the line otherwise. The address of the robot is in %USERPROFILE%\roboter-heute.env on the
service laptop, the password in the password manager — neither is on this page.
3.1 Copy the files into the subfolder ~/ume-gateway-neu/¶
Copy both files into the subfolder ~/ume-gateway-neu/ of the service account — not directly
into ~/. Reason: before overwriting, install.sh keeps the running version ~/gateway_v2.py as
~/gateway_v2.py.vorher. If the new file is already in ~/ itself, the old one has been
overwritten before the script runs and there is no backup (the script then warns).
For the first installation and for updates, use the address from
%USERPROFILE%\roboter-heute.env (line UME_IP=). PowerShell, no admin, on the service laptop:
cd $env:USERPROFILE\dev\robotics-group-app\gateway
$ip = ((Get-Content $env:USERPROFILE\roboter-heute.env | Select-String '^UME_IP=').Line -split '=',2)[1].Trim()
ssh <SERVICE-USER>@$ip mkdir -p ume-gateway-neu
scp gateway_v2.py install.sh "<SERVICE-USER>@${ip}:~/ume-gateway-neu/"
Option: ume-<kennung>.local instead of the address — only once the extra name is published, i.e.
after a run of install.sh version 2.3 or later and only with avahi-publish on the robot (the
script reports it).
3.2 Run the installer on the robot¶
Bash, on the robot, as the service account (no admin; the script itself asks for the sudo
password where it needs it):
bash ~/ume-gateway-neu/install.sh
Run it in a normal login shell of the service account (the service takes over the DDS/ROS
environment of this shell; in a stripped-down shell the motors do not respond). For /etc/avahi
and for autostart without login, the script asks for the sudo password of the service account.
Without sudo the Gateway is still set up (warning): only the service record _ume-gw._tcp is
missing, and the service starts only after a login. The extra name ume-<kennung>.local is a user
service and is still published if avahi-publish is present.
At the first installation the script asks for the ID of the uMe (device_id):
- lower-case letters, digits and hyphen, 1 to 20 characters, not starting or ending with a
hyphen, for example
messe1(checked byinstall.sh); - never a serial number.
On every later run the script takes the ID from the existing service file.
What the script does:
| Step | Result |
|---|---|
| Keeps the running Gateway as a backup, only if the files came from the subfolder | ~/gateway_v2.py.vorher |
| Copies the Gateway | ~/gateway_v2.py |
| Creates the pairing key once (256 bit, 64 hex characters) | ~/.config/ume-gateway/pairing.key, file permissions 0600; shown on the terminal only this one time |
| Writes the service file with ID and pairing switch | ~/.config/systemd/user/ume-gateway.service (UME_DEVICE_ID, UME_REQUIRE_PAIRING=1, UME_PAIRING_KEY_FILE) |
Announces the service in the Wi-Fi, only if avahi-daemon is present |
service _ume-gw._tcp, port 8765, with ID and display name; the previous name of the robot stays unchanged (the script shows it); a rename made by version 2.2 is taken back |
Publishes the extra name, only if avahi-publish is present |
ume-<kennung>.local via the user service ume-mdns-alias.service; not created if the robot is already named ume-<kennung> (the name exists anyway). Published is the IPv4 address of the default route — assumption: on the robot this is the Wi-Fi; check on the device |
| Enables and starts the service, autostart after reboot | status must read active (running) |
If avahi-daemon or avahi-publish is missing, the script says so and installs no package;
the app then finds the uMe through the service record (if present) and the search in its own
network. Running the script several times is harmless: one mDNS entry, key unchanged.
3.3 Put the pairing key into the password manager (mandatory)¶
Copy the key shown immediately into the password manager, entry name "uMe <kennung> Kopplung". It is never shown again, is not written to any log and is never sent over the network. Do not paste it into mails, tickets or chats.
3.4 Pair the tablet (once per uMe and tablet)¶
- Open the app. The page No connection searches by itself and lists the uMe with its name (for example uMe messe1) and the note Not paired with this tablet.
- Service (top right) → technician password → tab Device → section Connection and pairing → Search again.
- Next to the ID of the uMe, enter the key from the password manager (spaces,
-and:are ignored; at least 32 hex characters) → Save key. - Go back. From now on the app pairs automatically. If exactly one paired uMe is in range, it connects without a tap.
The key is entered once per tablet and uMe ID. It is stored in the app's private storage on the tablet (not encrypted; Android backup of the app is switched off).
3.5 Test¶
Live camera image and control (PREP/WALK, wave, dances) work without further action. Without pairing the Gateway refuses every command and sends neither status nor camera image.
4 Not paired — stop only on the device or the handheld remote¶
While a tablet is not paired with the uMe, the Gateway refuses every command, including the
software stop (estop). The app therefore shows, on every page and on the screen saver, the
notice "Nicht gekoppelt – Stopp nur am Gerät oder Handsender" (English app text: "Not paired –
stop only on the robot or the handheld remote"), and the stop button in the status bar is
disabled (grey). The notice also appears after the Gateway has asked for a key the tablet does
not have, or has rejected the stored key.
The emergency stop on the device and the handheld remote remain the safety layer. They do not depend on the app or on pairing (decision of 31.10.2026).
5 Protection — what pairing does and does not do¶
| Protects against | Does not protect against |
|---|---|
| Foreign tablets in the same Wi-Fi: without the key the Gateway executes no command and sends neither status nor camera image. A wrong answer, or no answer within 5 s, closes the connection. | An active attacker in the network. The connection runs unencrypted over ws://, and the tablet does not check the robot (no mutual authentication). Anyone who can read or redirect the traffic can take over a paired session. That needs TLS or mutual authentication — a later stage. |
Keep the uMe and its tablets in a Wi-Fi that only authorised devices can join.
6 iOS tablets¶
- At the first search, iOS asks for permission to use the local network. Allow it; without it the app finds nothing.
- Assumption, to be checked against the platform documentation: the name search sends an mDNS
query to the multicast address. From iOS 14 on this very probably needs the multicast
entitlement
com.apple.developer.networking.multicast, which must be requested from the platform vendor. Without it only the name search fails (note in the technician area: Name search in Wi-Fi (mDNS) not possible.); last connected and the search in the own network keep working once the local-network permission is given. - Decision 31.10.2026: the entitlement is not applied for for now. For the fair, Android tablets and the search in the own network are sufficient.
7 Everyday use and maintenance¶
- Robot on → app open. No manual start, no address entry.
- New Gateway version: copy both files into
~/ume-gateway-neu/as in step 3.1, then runbash ~/ume-gateway-neu/install.sh(ID and key stay; the previous version is kept in~/gateway_v2.py.vorher). - Show logs:
journalctl --user -u ume-gateway -f - Key lost: rename
~/.config/ume-gateway/pairing.key(do not delete it), runbash ~/ume-gateway-neu/install.shagain, put the new key into the password manager and pair all tablets again (technician area → Remove key → enter the new key). - Planned (decision 31.10.2026): after the MEDICA fair the pairing key of the fair devices is created anew, as under Key lost, and the tablets are paired again.
- Manual address (emergency only): technician area → Device → Enter address manually.
If pairing is required but the key or the ID is missing, the Gateway does not start (message in the log). It never runs unprotected.
8 Rollback¶
All blocks: Bash, on the robot, as the service account; lines with sudo ask for its password.
Previous Gateway version. install.sh keeps the previous version as ~/gateway_v2.py.vorher
(only after an update with the files in the subfolder, step 3.1). Back:
cp ~/gateway_v2.py.vorher ~/gateway_v2.py
systemctl --user restart ume-gateway.service
Fast — pairing off, behaviour as before version 2.0:
sed -i 's/^Environment=UME_REQUIRE_PAIRING=1$/Environment=UME_REQUIRE_PAIRING=0/' ~/.config/systemd/user/ume-gateway.service
systemctl --user daemon-reload
systemctl --user restart ume-gateway.service
Only until the next install.sh run
install.sh rewrites the service file, always with UME_REQUIRE_PAIRING=1. After every run of
install.sh, set the switch again if it is still needed.
Name in the Wi-Fi. From version 2.3 on, install.sh does not change the robot's name. If the
robot was installed with version 2.2 (line host-name=ume-<kennung> in
/etc/avahi/avahi-daemon.conf), running install.sh 2.3 once restores the previous name. By hand,
if a backup /etc/avahi/avahi-daemon.conf.vor-ume exists:
sudo cp /etc/avahi/avahi-daemon.conf.vor-ume /etc/avahi/avahi-daemon.conf
sudo systemctl restart avahi-daemon
If there is no .vor-ume (version 2.2 created the file), the system name was active before;
then only remove the line host-name=ume-…:
sudo sed -i '/^host-name=ume-/d' /etc/avahi/avahi-daemon.conf
sudo systemctl restart avahi-daemon
Service record and extra name completely off (the app then finds the uMe only through last
connected and the search in its own network). The next run of install.sh sets up both again:
systemctl --user disable --now ume-mdns-alias.service
sudo mv /etc/avahi/services/ume-gw.service ~/ume-gw.service.ausgelagert
sudo systemctl reload avahi-daemon
9 Files on the robot¶
Path (~ = home of the service account) |
Content |
|---|---|
~/gateway_v2.py |
Gateway |
~/gateway_v2.py.vorher |
previous version (only after an update) |
~/ume-gateway-neu/ |
new version to be installed (gateway_v2.py, install.sh) |
~/.config/systemd/user/ume-gateway.service |
service (ID, switches) |
~/.config/ume-gateway/pairing.key |
pairing key (0600) |
~/.config/ume-gateway/mdns-alias.sh |
publishes ume-<kennung>.local (only with avahi-publish) |
~/.config/systemd/user/ume-mdns-alias.service |
service for the extra name (only with avahi-publish) |
/etc/avahi/services/ume-gw.service |
mDNS service _ume-gw._tcp (only with avahi-daemon) |
/etc/avahi/avahi-daemon.conf |
no longer changed; only a line host-name=ume-<kennung> from version 2.2 is taken back |
/etc/avahi/avahi-daemon.conf.vor-ume |
backup from version 2.2 (if present; source for taking the name back) |
Faults: support@unitedrobotics.group.
Technikerhandbuch — uMe: Verbindung ohne IP-Suche und Kopplung¶
Stand 31.10.2026. In Entwicklung — Netzwerk Stufe 1 ist im App-Repository übernommen; die
Folgeänderungen der Installationsanleitung Fassung 2.3 sind noch in Entwicklung, noch
nicht übernommen. Noch auf keinem Gerät eingespielt. Grundlage: Installationsanleitung des uMe
Gateway, Fassung 2.3 (gateway/INSTALL.md). Zielgruppe: Servicetechniker der United Robotics Group
und beauftragte Partner. Protokolldetails für Entwickler:
uMe Gateway — Suche und Kopplung (API 1.1).
1 Was sich ändert¶
- Die App findet den uMe selbst. Niemand muss eine Adresse herausfinden oder eingeben.
- Nur gekoppelte Tablets können den uMe steuern. Der Kopplungsschlüssel entsteht einmalig bei der Installation des Gateways auf dem Roboter.
- Die Adresse des Roboters erscheint nur im Technikerbereich der App, nie in der Kundenoberfläche.
- Der Roboter behält seinen bisherigen Namen im WLAN. Das Installationsskript benennt ihn nicht um.
Die App sucht gleichzeitig auf drei Wegen; die Nummer bezeichnet nur den Weg:
| Nr. | Weg | Voraussetzung |
|---|---|---|
| 1 | zuletzt verbunden | das Tablet war schon einmal verbunden |
| 2 | Name im WLAN (mDNS): Diensteintrag _ume-gw._tcp; zusätzlich ume-<kennung>.local, wenn der Roboter diesen Zusatznamen veröffentlicht |
der Roboter meldet den Dienst an (Schritt 3.2); den Zusatznamen gibt es nur, wenn avahi-publish auf dem Roboter vorhanden ist; Multicast ist im WLAN erlaubt |
| 3 | Suche im eigenen Netz: jede Adresse des eigenen Teilnetzes des Tablets auf Port 8765 |
privates IPv4-Netz der Größe /24 oder kleiner; ein größeres Netz wird mit Hinweis im Technikerbereich übersprungen |
Ohne den Zusatznamen ume-<kennung>.local findet die App den uMe trotzdem über den Diensteintrag
_ume-gw._tcp und die Suche im eigenen Netz.
Ein Treffer zählt nur, wenn das Gerät mit einem gültigen hello des uMe Gateway in einer
passenden API-Version antwortet; andere Geräte im Netz werden ignoriert. Ist genau ein
gekoppelter uMe in Reichweite, verbindet die App ohne Antippen.
Gleiche Kennung doppelt. Taucht dieselbe Kennung unter zwei Adressen auf (zwei Geräte mit gleicher Kennung oder ein Gerät, das sich als ein anderes ausgibt), verbindet die App nicht:
- Auf der Kundenseite „Keine Verbindung“ zeigen beide Einträge „Kennung mehrfach im Netz – bitte den Service rufen“. Antippen verbindet nicht, sondern zeigt denselben Text.
- Der Technikerbereich zeigt „Kennung <kennung> unter zwei Adressen gefunden – kein automatisches Verbinden. Zwei Geräte mit gleicher Kennung? Bitte prüfen.“
Abhilfe: einem der beiden Roboter eine andere Kennung geben (Neuinstallation mit neuer Kennung, danach die Tablets neu koppeln).
2 Reihenfolge beim Umstieg (Pflicht)¶
- Zuerst alle Tablets auf die neue App aktualisieren. Die neue App arbeitet auch mit dem alten Gateway.
- Dann auf dem Roboter
install.shausführen. Nicht nurgateway_v2.pykopieren: ohneinstall.shfehlen Kennung und Kopplungsschlüssel, und das Gateway startet nicht.
Eine alte App kann ein Gateway mit Kopplungspflicht nicht steuern. Sie zeigt dann „Dieses Tablet ist nicht mit dem uMe gekoppelt …“.
3 Einmalige Einrichtung je uMe¶
Gebraucht werden zwei Dateien aus dem Repository robotics-group-app, Ordner gateway/:
gateway_v2.py und install.sh. <SERVICE-USER> ist das Servicekonto des Perception Boards; sein
Name wird auf dieser Seite nicht veröffentlicht. <SERVICE-USER> vor dem Ausführen ersetzen –
sonst weist PowerShell die Zeile ab. Die Adresse des Roboters steht in
%USERPROFILE%\roboter-heute.env auf dem Service-Laptop, das Kennwort im Passwortmanager – beides
nicht auf dieser Seite.
3.1 Dateien in den Unterordner ~/ume-gateway-neu/ kopieren¶
Beide Dateien in den Unterordner ~/ume-gateway-neu/ des Servicekontos legen – nicht direkt
nach ~/. Grund: install.sh legt die laufende Fassung ~/gateway_v2.py vor dem Überschreiben
als ~/gateway_v2.py.vorher ab. Liegt die neue Datei schon selbst in ~/, ist die alte bereits
vor dem Skriptlauf überschrieben und es gibt keine Sicherung (das Skript warnt dann).
Für die erste Installation und für Updates die Adresse aus %USERPROFILE%\roboter-heute.env
(Zeile UME_IP=) verwenden. PowerShell, kein Admin, auf dem Service-Laptop:
cd $env:USERPROFILE\dev\robotics-group-app\gateway
$ip = ((Get-Content $env:USERPROFILE\roboter-heute.env | Select-String '^UME_IP=').Line -split '=',2)[1].Trim()
ssh <SERVICE-USER>@$ip mkdir -p ume-gateway-neu
scp gateway_v2.py install.sh "<SERVICE-USER>@${ip}:~/ume-gateway-neu/"
Option: ume-<kennung>.local statt der Adresse – nur wenn der Zusatzname schon veröffentlicht ist,
also erst nach einem install.sh ab Fassung 2.3 und nur mit avahi-publish auf dem Roboter (das
Skript meldet das).
3.2 Auf dem Roboter installieren¶
Bash, auf dem Roboter, als Servicekonto (kein Admin; das Skript fragt selbst nach dem
sudo-Kennwort, wo es eines braucht):
bash ~/ume-gateway-neu/install.sh
In einer normalen Anmelde-Shell des Servicekontos ausführen (der Dienst übernimmt die
DDS-/ROS-Umgebung dieser Shell; in einer abgespeckten Shell reagieren die Motoren nicht). Für
/etc/avahi und den Autostart ohne Anmeldung fragt das Skript per sudo nach dem Kennwort des
Servicekontos. Ohne sudo wird das Gateway trotzdem eingerichtet (Warnung): es fehlt nur der Diensteintrag
_ume-gw._tcp, und der Dienst startet erst nach einer Anmeldung. Der Zusatzname
ume-<kennung>.local ist ein Benutzerdienst und wird trotzdem veröffentlicht, wenn avahi-publish
vorhanden ist.
Bei der ersten Installation fragt das Skript nach der Kennung des uMe (device_id):
- Kleinbuchstaben, Ziffern und Bindestrich, 1 bis 20 Zeichen, nicht mit Bindestrich beginnend
oder endend, z. B.
messe1(prüftinstall.sh); - nie eine Seriennummer.
Bei jeder weiteren Ausführung übernimmt das Skript die Kennung aus der vorhandenen Dienstdatei.
Was das Skript tut:
| Schritt | Ergebnis |
|---|---|
| Laufendes Gateway sichern, nur wenn die Dateien aus dem Unterordner kommen | ~/gateway_v2.py.vorher |
| Gateway ablegen | ~/gateway_v2.py |
| Kopplungsschlüssel einmalig erzeugen (256 Bit, 64 Hex-Zeichen) | ~/.config/ume-gateway/pairing.key, Rechte 0600; Anzeige im Terminal nur dieses eine Mal |
| Dienstdatei mit Kennung und Kopplungsschalter schreiben | ~/.config/systemd/user/ume-gateway.service (UME_DEVICE_ID, UME_REQUIRE_PAIRING=1, UME_PAIRING_KEY_FILE) |
Dienst im WLAN anmelden, nur wenn avahi-daemon vorhanden ist |
Dienst _ume-gw._tcp, Port 8765, mit Kennung und Anzeigename; der bisherige Name des Roboters bleibt unverändert (das Skript zeigt ihn an); eine Umbenennung durch Fassung 2.2 wird zurückgenommen |
Zusatznamen veröffentlichen, nur wenn avahi-publish vorhanden ist |
ume-<kennung>.local über den Benutzerdienst ume-mdns-alias.service; wird nicht angelegt, wenn der Roboter bereits ume-<kennung> heißt (der Name existiert dann ohnehin). Veröffentlicht wird die IPv4-Adresse der Standardroute – Annahme: am Roboter ist das das WLAN; am Gerät prüfen |
| Dienst aktivieren und starten, Autostart nach Neustart | Status muss active (running) zeigen |
Fehlt avahi-daemon oder avahi-publish, meldet das Skript das und installiert kein Paket;
die App findet den uMe dann über den Diensteintrag (falls vorhanden) und die Suche im eigenen Netz.
Mehrfaches Ausführen ist unschädlich: ein mDNS-Eintrag, Schlüssel unverändert.
3.3 Kopplungsschlüssel in den Passwortmanager übernehmen (Pflicht)¶
Den angezeigten Schlüssel sofort in den Passwortmanager übernehmen, Eintrag „uMe <kennung> Kopplung“. Er wird nie wieder angezeigt, steht in keinem Log und wird nie über das Netz gesendet. Nicht in Mails, Tickets oder Chats kopieren.
3.4 Tablet koppeln (einmal je uMe und Tablet)¶
- App öffnen. Die Seite „Keine Verbindung“ sucht selbst und zeigt den uMe mit seinem Namen (z. B. „uMe messe1“) und dem Vermerk Nicht mit diesem Tablet gekoppelt.
- Service (oben rechts) → Technikerkennwort → Reiter Gerät → Abschnitt Verbindung und Kopplung → Erneut suchen.
- Bei der Kennung des uMe den Schlüssel aus dem Passwortmanager eingeben (Leerzeichen,
-und:werden ignoriert; mindestens 32 Hex-Zeichen) → Schlüssel speichern. - Zurück. Die App koppelt ab jetzt automatisch. Ist genau ein gekoppelter uMe in Reichweite, verbindet sie sich ohne Antippen.
Der Schlüssel wird einmal je Tablet und Kennung eingegeben. Er liegt im privaten App-Speicher des Tablets (nicht verschlüsselt; die Android-Sicherung der App ist ausgeschaltet).
3.5 Testen¶
Kamera-Livebild und Steuerung (PREP/WALK, Winken, Tänze) gehen ohne weiteres Zutun. Ohne Kopplung weist das Gateway jeden Befehl ab und sendet weder Status noch Kamerabild.
4 Nicht gekoppelt — Stopp nur am Gerät oder Handsender¶
Solange ein Tablet nicht mit dem uMe gekoppelt ist, weist das Gateway jeden Befehl ab, auch den
Software-Stopp (estop). Die App zeigt deshalb auf jeder Seite und auf dem Bildschirmschoner den
Hinweis „Nicht gekoppelt – Stopp nur am Gerät oder Handsender“, und die Stopp-Taste in der
Statusleiste ist gesperrt (grau). Der Hinweis erscheint auch, nachdem das Gateway einen Schlüssel
verlangt hat, den das Tablet nicht hat, oder den gespeicherten Schlüssel abgewiesen hat.
Not-Aus am Gerät und Handsender bleiben die Sicherheitsebene. Sie hängen nicht von der App oder der Kopplung ab (Entscheidung vom 31.10.2026).
5 Schutzumfang — was die Kopplung leistet und was nicht¶
| Schützt gegen | Schützt nicht gegen |
|---|---|
| Fremde Tablets im selben WLAN: ohne Schlüssel führt das Gateway keinen Befehl aus und sendet weder Status noch Kamerabild. Eine falsche Antwort oder keine Antwort innerhalb von 5 s schließt die Verbindung. | Einen aktiven Angreifer im Netz. Die Verbindung läuft unverschlüsselt über ws://, und das Tablet prüft den Roboter nicht (keine gegenseitige Anmeldung). Wer den Verkehr mitlesen oder umleiten kann, kann eine gekoppelte Sitzung übernehmen. Dafür wäre TLS bzw. eine gegenseitige Anmeldung nötig — spätere Stufe. |
uMe und Tablets in einem WLAN betreiben, dem nur berechtigte Geräte beitreten können.
6 iOS-Tablets¶
- Bei der ersten Suche fragt iOS nach der Freigabe Lokales Netzwerk. Zulassen; ohne sie findet die App nichts.
- Annahme, gegen die Plattform-Dokumentation zu prüfen: Die Namenssuche sendet eine
mDNS-Anfrage an die Multicast-Adresse. Ab iOS 14 braucht das sehr wahrscheinlich die
Multicast-Berechtigung
com.apple.developer.networking.multicast, die beim Plattformanbieter beantragt werden muss. Ohne sie fällt nur die Namenssuche aus (Hinweis im Technikerbereich: „Namenssuche im WLAN (mDNS) nicht möglich.“); „zuletzt verbunden“ und die Suche im eigenen Netz funktionieren nach der Freigabe „Lokales Netzwerk“ weiter. - Entscheidung 31.10.2026: Die Berechtigung wird vorerst nicht beantragt. Für die Messe reichen Android-Tablets und die Suche im eigenen Netz.
7 Alltag und Wartung¶
- Roboter an → App auf. Kein manuelles Starten, keine Adresseingabe.
- Neue Gateway-Version: beide Dateien wie in Schritt 3.1 nach
~/ume-gateway-neu/kopieren, dannbash ~/ume-gateway-neu/install.shausführen (Kennung und Schlüssel bleiben; die bisherige Fassung liegt danach in~/gateway_v2.py.vorher). - Logs ansehen:
journalctl --user -u ume-gateway -f - Schlüssel verloren:
~/.config/ume-gateway/pairing.keyumbenennen (nicht löschen),bash ~/ume-gateway-neu/install.sherneut ausführen, neuen Schlüssel in den Passwortmanager übernehmen und alle Tablets neu koppeln (Technikerbereich → Schlüssel entfernen → neuen Schlüssel eingeben). - Geplant (Entscheidung 31.10.2026): Nach der Messe MEDICA wird der Kopplungsschlüssel der Messegeräte neu erzeugt, wie unter „Schlüssel verloren“, und die Tablets werden neu gekoppelt.
- Manuelle Adresse (nur Notfall): Technikerbereich → Gerät → Adresse manuell eingeben.
Fehlen bei eingeschalteter Kopplungspflicht Schlüssel oder Kennung, startet das Gateway nicht (Meldung im Log). Es läuft nie ungeschützt.
8 Rückweg¶
Alle Blöcke: Bash, auf dem Roboter, als Servicekonto; Zeilen mit sudo fragen nach dessen Kennwort.
Vorherige Gateway-Fassung. install.sh legt die bisherige Fassung als ~/gateway_v2.py.vorher
ab (nur nach einem Update mit den Dateien im Unterordner, Schritt 3.1). Zurück:
cp ~/gateway_v2.py.vorher ~/gateway_v2.py
systemctl --user restart ume-gateway.service
Schnell — Kopplung aus, Verhalten wie vor Fassung 2.0:
sed -i 's/^Environment=UME_REQUIRE_PAIRING=1$/Environment=UME_REQUIRE_PAIRING=0/' ~/.config/systemd/user/ume-gateway.service
systemctl --user daemon-reload
systemctl --user restart ume-gateway.service
Gilt nur bis zur nächsten Ausführung von install.sh
install.sh schreibt die Dienstdatei neu, immer mit UME_REQUIRE_PAIRING=1. Nach jedem
install.sh den Schalter bei Bedarf erneut setzen.
Name im WLAN. Ab Fassung 2.3 ändert install.sh den Namen des Roboters nicht. Wurde mit
Fassung 2.2 installiert (Zeile host-name=ume-<kennung> in /etc/avahi/avahi-daemon.conf),
genügt es, install.sh 2.3 einmal auszuführen – es stellt den bisherigen Namen wieder her. Von
Hand, wenn es eine Sicherung /etc/avahi/avahi-daemon.conf.vor-ume gibt:
sudo cp /etc/avahi/avahi-daemon.conf.vor-ume /etc/avahi/avahi-daemon.conf
sudo systemctl restart avahi-daemon
Gibt es keine .vor-ume (Fassung 2.2 hat die Datei neu angelegt), war vorher der Systemname
aktiv; dann nur die Zeile host-name=ume-… entfernen:
sudo sed -i '/^host-name=ume-/d' /etc/avahi/avahi-daemon.conf
sudo systemctl restart avahi-daemon
Diensteintrag und Zusatzname ganz zurücknehmen (die App findet den uMe dann nur noch über
„zuletzt verbunden“ und die Suche im eigenen Netz). Die nächste Ausführung von install.sh richtet
beides wieder ein:
systemctl --user disable --now ume-mdns-alias.service
sudo mv /etc/avahi/services/ume-gw.service ~/ume-gw.service.ausgelagert
sudo systemctl reload avahi-daemon
9 Dateien auf dem Roboter¶
Pfad (~ = Benutzerverzeichnis des Servicekontos) |
Inhalt |
|---|---|
~/gateway_v2.py |
Gateway |
~/gateway_v2.py.vorher |
vorherige Fassung (nur nach einem Update) |
~/ume-gateway-neu/ |
neue Fassung zum Einspielen (gateway_v2.py, install.sh) |
~/.config/systemd/user/ume-gateway.service |
Dienst (Kennung, Schalter) |
~/.config/ume-gateway/pairing.key |
Kopplungsschlüssel (0600) |
~/.config/ume-gateway/mdns-alias.sh |
veröffentlicht ume-<kennung>.local (nur mit avahi-publish) |
~/.config/systemd/user/ume-mdns-alias.service |
Dienst für den Zusatznamen (nur mit avahi-publish) |
/etc/avahi/services/ume-gw.service |
mDNS-Dienst _ume-gw._tcp (nur mit avahi-daemon) |
/etc/avahi/avahi-daemon.conf |
wird nicht mehr geändert; nur eine Zeile host-name=ume-<kennung> aus Fassung 2.2 wird zurückgenommen |
/etc/avahi/avahi-daemon.conf.vor-ume |
Sicherung aus Fassung 2.2 (falls vorhanden; Quelle für die Rücknahme) |
Störungen: support@unitedrobotics.group.