UpNrun — Online-Handbuch

Overview #

Die UpNrun-Suite ist ein Netzwerk-Monitoring- und Remote-Management-System fuer AV-, Licht- und Gebaeudetechnik. Sie scannt das Netz, erkennt Geraete automatisch ueber herstellerspezifische Plugins, zeigt Status/Alarme und erlaubt — abgesichert ueber den Trust-Layer — Fernzugriff (Remote Desktop, KNX, Q-SYS).

Bausteine

• Lokale App — laeuft vor Ort (oder auf einem OnSite-Pi), scannt das LAN.
• Platform — zentrale Cloud-/VPS-Oberflaeche, spiegelt mehrere Standorte (Sites).
• OnSite-Pi — Raspberry-Pi-Sonde vor Ort, via Pairing mit der Platform verbunden.
• Plugins — 43 Geraete-Treiber (Switches, Projektoren, Mischpulte, Lichtpulte …).

Erste Schritte #

1. Scan starten: Auf den grossen Scan-Button klicken. Die App durchsucht das lokale Netz und ordnet gefundene Geraete den passenden Plugins zu.
2. Geraeteliste: Erkannte Geraete erscheinen mit Icon, Service-Badges und Plugin-Zuordnung. Filter in der Sidebar grenzen nach Typ/Status ein.
3. Plugin oeffnen: Ein Klick auf ein Geraet oeffnet das Plugin-Panel mit Lese-Werten und (je nach Rolle) Steuer-Aktionen.
4. Settings: Plugins aktivieren/deaktivieren, Aussehen, Telegram-Alarme und Sicherheit konfigurieren.

Was in dieser Nacht neu ist (29.07.2026) #

In der Nacht vom 28. auf den 29. Juli 2026 hat sich an mehreren Stellen etwas geändert, das den Arbeitsablauf vor Ort betrifft. Dieses Kapitel ist die Kurzfassung: was anders ist, woran man es merkt, und was man ab jetzt anders macht. Jeder Abschnitt verweist auf das ausführliche Kapitel.

1. Geräte-Weboberflächen im Browser — von 1 auf 14 von 17

Der Knopf „Web-UI öffnen“ gab es vorher schon, aber er führte meistens auf eine leere Seite. Gemessen am 28.07. an Theater Uri: von 59 Geräten lieferten 5 über den Tunnel überhaupt eine Antwort — benutzbar war keines. Nach dem Umbau sind es 14 von 17 Geräten mit Weboberfläche.

Was du ab jetzt anders machst: die Geräteoberfläche zuerst über UpNrun aufmachen, statt VPN aufzubauen oder hinzufahren. Erscheint oben ein braunes Band, fehlen auf der Seite Teile — das liegt am Gerät, nicht an der Verbindung. Einzelheiten und die drei bekannten Grenzen stehen unter Geräte-Weboberflächen über den Tunnel.

2. Die Überwachung sitzt jetzt am Standort

Alarme entstehen ab jetzt auf der Onsite-Box und werden mit dem ohnehin laufenden Heartbeat an die Plattform gemeldet. Die Plattform fragt eine Anlage, die meldet, nicht mehr im Minutentakt selbst ab. Gesehen, quittiert und abonniert werden Alarme weiterhin ausschliesslich auf der Plattform — nur das Erkennen ist umgezogen.

Was du ab jetzt anders machst: nichts — ausser einer Sache. Der Monitorpunkt „PoE-Überlast“ ist ersatzlos entfernt. Wer ihn sucht, sucht vergeblich: keine der vier Switch-Familien liefert ein PoE-Budget, nur die Summe des Verbrauchs. Eine Überlast ist damit nicht benennbar, und der Punkt konnte nie auslösen. Einzelheiten unter Alarme entstehen am Standort.

3. Die Portzuordnung wird wirklich erhoben

Die Spalte „Hängt an“ (Switch und Port) stand seit dem 28.07. in der Tabelle, war aber leer, weil sie niemand befüllte. Jetzt befüllt sie jemand: LLDP zuerst, MAC-Tabelle als Rückfall. Am echten Bestand von Theater Uri gemessen: 8 von 66 Geräten hängen nachweislich an einem Port (6 über LLDP, 2 über die MAC-Tabelle). Jede Angabe trägt ihre Quelle und ihr Alter; nach 72 Stunden ohne Bestätigung wird sie als veraltet markiert, aber nicht gelöscht.

Was du ab jetzt anders machst: die Spalte schaltet sich einmalig von selbst ein, sobald eine Anlage wirklich eine Zuordnung liefert. Danach entscheidest du. Erwarte keine 100 %: hinter einem Uplink wird bewusst nichts zugeordnet (siehe Punkt 4).

4. Netzwerkplan als Strang — und warum so viele Geräte im Sammelast stehen

Der Reiter Netzwerkplan zeigt die Anlage jetzt als eingerückten Strang Onsite → Switch → Port → Gerät statt als gezeichnete Grafik (die gibt es weiterhin unter „Netzwerkplan im Vollbild“).

Warum stehen an Theater Uri 58 Geräte im Ast „Ohne Portzuordnung“? Weil sie hinter einem Uplink hängen. Der Befehl swctrl mac show auf dem UniFi 10.20.1.99 liefert 43 Einträge — alle auf Port 21, dem STP-Uplink zum zweiten Switch. Würde UpNrun das wörtlich nehmen, stünde bei 43 Geräten „hängt an Port 21“: kein Baum, ein Haufen. Ein Uplink ist kein Steckplatz. Hinter einem Uplink wird darum bewusst nichts zugeordnet; der Port wird trotzdem gezeichnet, mit Ziel und Anzahl der dort gelernten Adressen. Dazu kommen Switches, die gar nicht antworten — jeder mit Klartext-Grund.

Was du ab jetzt anders machst: den Sammelast nicht als Fehler lesen. Er nennt für jedes Gerät den Grund. Einzelheiten unter Netzwerkplan — Strang.

5. Der Zustand „wacklig“ existiert jetzt wirklich

Ein Gerät gilt als wacklig, wenn es noch antwortet, dabei aber einzelne Pings verfehlt hat. Das ist der früheste Hinweis auf ein Problem — eine schlechte Funkstrecke, ein wackliges Patchkabel, ein überlastetes Gerät.

Bis zum 28.07. stand dieser Zähler auf jeder Anlage dauerhaft auf 0: die Plattform konnte den Zustand gar nicht berechnen, wackelnde Geräte erschienen als glatt „online“. An Theater Uri gemessen waren es vier Geräte (10.0.1.82/.87/.88/.92), die 1–2 von 3 Pings verfehlten und 38–52 Zustandswechsel hinter sich hatten. Nachher: 47 online / 4 wacklig / 8 offline.

Was du ab jetzt anders machst: vor einer Vorstellung auf die Zahl wacklig schauen, nicht nur auf offline. Karte, Sidebar-Filter, Statusampel, CSV-Export und Ausdruck verwenden dieselbe Einstufung.

6. Fehlt ein Zugang, führt das Panel dich hin

Wo ein Management-Zugang fehlt, zeigt das Plugin-Panel jetzt in jeder Sparte eine Ampel (SSH an / SSH aus / Gerät nicht erreichbar), sagt in einem Satz was fehlt, und stellt eine Kurzanleitung für genau dieses Fabrikat darunter. Bei Geräten mit belegtem Weg kann UpNrun SSH sogar selbst über die Weboberfläche des Geräts ein- und ausschalten.

Die Falle, die einen halben Tag kostet: bei den meisten Herstellern öffnet ein und dasselbe Konto die Weboberfläche und SSH. Wer beim Einschalten von SSH ein neues Web-Passwort vergibt, ändert damit auch das SSH-Passwort. Das Plugin arbeitet danach mit den alten Daten weiter und bricht ab — es sieht aus, als hätte das Einschalten von SSH das Gerät zerschossen.

Was du ab jetzt anders machst: jedes neu vergebene Gerätepasswort sofort in UpNrun eintragen, bevor du das Fenster schliesst. Einzelheiten und alle 12 hinterlegten Kurzanleitungen unter Wenn SSH aus ist.

Nebenbei korrigiert: der oft gehörte Satz „bei einem EdgeSwitch ist SSH ab Werk aus“ stimmt nicht. Am ES-8-150W (Firmware 1.12.2-lite) war Port 22 offen und sshServer.enabled=true, ohne dass jemand etwas eingeschaltet hatte. Ab Werk wirklich aus sind NETGEAR M4250/M4350 und Biamp Tesira.

7. Die Box merkt, wenn die Plattform sie entkoppelt hat

Bisher hing der Kopplungszustand allein daran, dass eine Datei auf der Box lag. Wurde eine Anlage auf der Plattform entkoppelt, meldete die Box weiter „gekoppelt“, der Kiosk zeigte keinen QR-Code, und jede Neukopplung im Feld brauchte SSH. Jetzt fragt die Box selbst nach — beim Start und an jedem Heartbeat — und zeigt wieder den Kopplungs-QR, sobald sie entkoppelt wurde.

Die Kernaussage: Schweigen zählt nicht. Nur eine ausdrückliche Ablehnung der Plattform entkoppelt, und erst drei in Folge. Zeitüberschreitung, totes DNS, abgewiesene Verbindung, HTTP 5xx, HTTP 429 oder ein Captive Portal lassen den Zustand unverändert. Eine Box, die sich bei jedem Internetausfall selbst aussperrt, wäre schlimmer als der Fehler.

Was du ab jetzt anders machst: nach dem Entkoppeln auf der Plattform nicht mehr zur Box fahren — nach etwa einer Minute steht der QR-Code auf dem Kiosk. Einzelheiten unter Main-Instanz entkoppeln.

8. Gerätetyp aus Beweisen statt aus der Herstellerliste

Ein EdgeSwitch stand in der Geräteliste als Access Point — allein weil „Ubiquiti“ in der Access-Point-Herstellerliste stand. Ubiquiti, Cisco, Aruba und Meraki bauen Switches und Access Points und Router; ein reiner Herstellertreffer sagt über den Typ nichts. Solche Geräte heissen jetzt ehrlich „Network Device“ (Hersteller belegt, Typ unbestimmt), bis ein echter Hinweis kommt.

Was du ab jetzt anders machst: ein „Network Device“ in der Liste ist kein Fehler, sondern eine ehrliche Auskunft. Einzelheiten unter Gerätetyp aus Evidenz.

9. Companion wird auch ohne Firewall gefunden

Theater Uri meldete „keine Companion-Instanz“, obwohl Companion lief. Die Erkennung hing komplett am Firewall-Agenten, den die Anlage gar nicht hat — und rund 80 % der Anlagen laufen ohne Firewall. Erkennung und Prüfung laufen jetzt auch ohne: Firewall-Agent, sonst Proxmox-API des Standorts, sonst Scan-Cache.

Was du ab jetzt anders machst: nichts. Nur die Meldungen sind jetzt brauchbar: vier verschiedene Befunde statt einer irreführenden Sammelmeldung. Einzelheiten unter Instanzen finden.

10. Locate am UniFi ist freigeschaltet

Der Weg, alle Port-LEDs eines UniFi Pro Max blinken zu lassen, war seit Tagen gebaut und funktionierte — nur war die Freigabemarke nie gesetzt, darum konnte der Knopf gar nicht erscheinen. Jetzt ist er da. Merke: eine Fähigkeit ist erst geliefert, wenn sie in der Oberfläche steht; ein funktionierender Weg im Hintergrund ist für dich nicht vorhanden.

Am EdgeSwitch bleibt Locate gesperrt: dort liegt nur die Selbstauskunft des Geräts vor (running:true), die LED hat niemand gesehen. Siehe Schreibpfade & Verifikation.

11. Gerätepasswörter beim Export

Beim Export von Einstellungen und beim Projekt-Export (.upnrun-Datei) ersetzt UpNrun gespeicherte Gerätepasswörter durch einen Platzhalter. Zwei von vier Gerätefamilien waren dabei nie erfasst und kamen im Klartext heraus — das ist behoben. Einzelheiten unter Gerätepasswörter und Export.

Gebaut, aber noch nicht am Gerät belegt

Diese Liste gehört zum Handbuch, weil ein Handbuch, das mehr verspricht als die App kann, schlimmer ist als eine Lücke. Alles hier ist gebaut und getestet, aber der letzte Beweis am echten Gerät fehlt:

Was hier steht, ist kein Mangel an Sorgfalt, sondern der ehrliche Stand. Sobald eines davon am Gerät belegt ist, verschwindet die Zeile aus dieser Tabelle.

What is new tonight (29 July 2026) #

During the night of 28 to 29 July 2026 several things changed that affect the way you work on site. This chapter is the short version: what changed, how you notice it, and what you do differently from now on. Every section links to the detailed chapter.

1. Device web interfaces in the browser — from 1 to 14 of 17

The “Open Web UI” button existed before, but it usually led to a blank page. Measured on 28 July at Theater Uri: of 59 devices, 5 answered at all through the tunnel — none of them was usable. After the rebuild, 14 of 17 devices with a web interface work.

What you do differently: open the device interface through UpNrun first instead of setting up a VPN or driving there. If a brown banner appears at the top, parts of the page are missing — that is the device, not the connection. Details and the three known limits are under Device web interfaces through the tunnel.

2. Monitoring now sits on site

Alarms are now detected on the onsite box and reported to the platform on the heartbeat that runs anyway. The platform no longer polls a site that reports. Alarms are still seen, acknowledged and subscribed to exclusively on the platform — only the detection moved.

What you do differently: nothing — except for one thing. The monitor point “PoE overload” has been removed without replacement. Looking for it is pointless: none of the four switch families reports a PoE budget, only the sum of consumption. An overload cannot be named from that, and the point could never fire. Details under Alarms are raised on site.

3. Port assignment is actually collected now

The “Attached to” column (switch and port) had been in the table since 28 July but stayed empty because nothing filled it. Now something does: LLDP first, MAC table as a fallback. Measured against the real inventory of Theater Uri: 8 of 66 devices demonstrably hang on a port (6 via LLDP, 2 via the MAC table). Every entry carries its source and its age; after 72 hours without confirmation it is marked stale but not deleted.

What you do differently: the column enables itself once, as soon as a site really delivers an assignment. After that you decide. Do not expect 100 %: behind an uplink nothing is assigned on purpose (see point 4).

4. Network plan as a chain — and why so many devices sit in the collecting branch

The Network plan tab now shows the site as an indented chain Onsite → switch → port → device instead of a drawn diagram (which is still available under “Network plan full screen”).

Why do 58 devices at Theater Uri sit in the “No port assignment” branch? Because they hang behind an uplink. swctrl mac show on the UniFi at 10.20.1.99 returns 43 entries — all on port 21, the STP uplink to the second switch. Taken literally, 43 devices would read “attached to port 21”: not a tree, a heap. An uplink is not a socket. Nothing is assigned behind an uplink on purpose; the port is still drawn, with its target and the number of addresses learned there. On top of that come switches that do not answer at all — each with a plain-language reason.

What you do differently: do not read the collecting branch as a failure. It names the reason for every device. Details under Network plan — chain view.

5. The state “flaky” now really exists

A device counts as flaky when it still answers but has missed individual pings. That is the earliest hint of a problem — a poor radio link, a loose patch cable, an overloaded device.

Until 28 July this counter sat at 0 on every site: the platform could not compute the state at all, and flaky devices appeared as plain “online”. Measured at Theater Uri there were four (10.0.1.82/.87/.88/.92) missing 1–2 of 3 pings with 38–52 state changes behind them. Afterwards: 47 online / 4 flaky / 8 offline.

What you do differently: before a show, look at the flaky figure, not only at offline. Card, sidebar filter, status light, CSV export and printout all use the same classification.

6. If access is missing, the panel walks you through it

Wherever a management access is missing, the plugin panel now shows a traffic light in every category (SSH on / SSH off / device unreachable), says in one sentence what is missing, and puts a short guide for exactly this make underneath. On devices with a proven path UpNrun can even switch SSH on and off itself through the device's web interface.

The trap that costs half a day: on most vendors one and the same account opens the web interface and SSH. If you set a new web password while enabling SSH, you change the SSH password too. The plugin then keeps using the old credentials and fails — it looks as if enabling SSH had broken the device.

What you do differently: enter every newly set device password in UpNrun immediately, before you close the window. Details and all 12 stored guides under When SSH is off.

Corrected along the way: the widespread claim “SSH is off from the factory on an EdgeSwitch” is wrong. On an ES-8-150W (firmware 1.12.2-lite) port 22 was open and sshServer.enabled=true without anyone enabling anything. Genuinely off from the factory are NETGEAR M4250/M4350 and Biamp Tesira.

7. The box notices when the platform decoupled it

Until now the coupling state depended solely on a file existing on the box. If a site was decoupled on the platform, the box kept reporting “coupled”, the kiosk showed no QR code, and any re-coupling in the field required SSH. Now the box asks — at startup and on every heartbeat — and shows the coupling QR again as soon as it has been decoupled.

The key statement: silence does not count. Only an explicit rejection by the platform decouples, and only three in a row. Timeout, dead DNS, refused connection, HTTP 5xx, HTTP 429 or a captive portal leave the state untouched. A box that locks itself out on every internet outage would be worse than the fault.

What you do differently: after decoupling on the platform you no longer need to drive to the box — after about a minute the QR code appears on the kiosk. Details under Decoupling the main instance.

8. Device type from evidence, not from a vendor list

An EdgeSwitch was listed as an Access Point — purely because “Ubiquiti” appeared in the access-point vendor list. Ubiquiti, Cisco, Aruba and Meraki build switches and access points and routers; a pure vendor match says nothing about the type. Such devices are now honestly called “Network Device” (vendor proven, type undetermined) until real evidence arrives.

What you do differently: a “Network Device” in the list is not a fault, it is an honest answer. Details under Device type from evidence.

9. Companion is found without a firewall too

Theater Uri reported “no Companion instance” although Companion was running. Detection hung entirely on the firewall agent, which the site does not have — and roughly 80 % of sites run without a firewall. Detection and probing now work without it: firewall agent, else the site's Proxmox API, else the scan cache.

What you do differently: nothing. Only the messages are useful now: four distinct findings instead of one misleading catch-all. Details under Finding instances.

10. Locate on the UniFi is unlocked

The path that makes all port LEDs of a UniFi Pro Max pulse had been built for days and worked — only the release marker was never set, so the button could not appear at all. It is there now. Remember: a capability is only delivered once it is in the interface; a working path in the background does not exist for you.

On the EdgeSwitch locate stays locked: there we only have the device's own claim (running:true), nobody has seen the LED. See Write paths & verification.

11. Device passwords on export

When settings are exported, and in the project export (.upnrun file), UpNrun replaces stored device passwords with a placeholder. Two of four device families were never covered and came out in clear text — that is fixed. Details under Device passwords and export.

Built, but not yet proven on the device

This list belongs in the manual, because a manual that promises more than the app can deliver is worse than a gap. Everything here is built and tested, but the final proof on real hardware is missing:

What is listed here is not a lack of diligence but the honest state. As soon as one of them is proven on the device, the row disappears from this table.

Platform / Login / Rollen #

Die Platform buendelt mehrere Standorte (Sites). Login mit E-Mail-Adresse und Passwort, optional mit 2FA. Bestandskonten mit klassischem Benutzernamen funktionieren unveraendert weiter.

Passkey / Biometrisches Login & 2FA

Unter Einstellungen → Sicherheit (/2fa) stehen zusaetzlich zum klassischen Passwort-Login mehrere Absicherungen zur Wahl, alle optional:

• Passkeys — passwortloser Login per Face-/Touch-ID, Windows Hello oder Sicherheitsschluessel. Ein registrierter Passkey ersetzt Passwort und 2FA in einem Schritt (kein zusaetzlicher Code noetig). Auf der Login-Seite erscheint dafuer ein eigener Button "Mit Passkey anmelden", sobald der Browser Passkeys unterstuetzt. Nur fuer benannte Benutzerkonten verfuegbar, nicht fuer den Master-Zugang.
• Authenticator-App (TOTP) — wie bisher: 6-stelliger Code aus einer App wie Google Authenticator oder 1Password.
• Backup-Codes — 10 Einmal-Codes, die einspringen, wenn Authenticator-App oder Handy nicht verfuegbar sind. Werden bei der ersten TOTP-Aktivierung automatisch erzeugt (und jederzeit unter "Backup-Codes" neu erzeugbar) und nur EINMAL im Klartext angezeigt.
• Email-Code — Alternative zur Authenticator-App: ein 6-stelliger Code wird an die hinterlegte E-Mail-Adresse geschickt. Nur wirksam, solange keine Authenticator-App-2FA aktiv ist.

Site-Rollen

Pro Standort hat jeder Nutzer genau eine Rolle. Sie bestimmt, was sichtbar und bedienbar ist; der Trust-Layer setzt sie serverseitig durch — die UI blendet Gesperrtes aus.

• Client — sieht nur die ihm zugewiesenen eigenen Geraete (Status/Infos) und Datei-Freigaben. Keine Netz-Interna, keine Steuerung.
• View — nur Lesen: Status, Geraeteliste, Alarme. Keine Steueraktionen.
• Service — Lesen + definierte Service-Aktionen (z.B. Reboot, Input-Wechsel).
• Full — voller Zugriff inkl. Remote Desktop und kritischer Steuerung.
• Owner — wie Full, zusaetzlich Notfall-Revoke (Kill-Switch) fuer die Anlage.
• Temporary Guest — eine der obigen Rollen mit Ablaufdatum; der Zugriff endet automatisch.

Org-Rollen (Firma)

Unabhaengig von den Site-Rollen hat jeder Nutzer eine Rolle innerhalb seiner Firma:

• Owner — Firmeneigentuemer: verwaltet Mitarbeiter, vergibt Org-Rollen, laedt per Link ein.
• Admin — darf die Firma mitverwalten (Mitarbeiter, Site-Rollen).
• Member — arbeitet im Rahmen seiner Site-Rollen.

Externe Techniker und Kunden, die nur per Site-Einladung Zugriff haben, sind keine Firmen-Mitglieder — sie erscheinen ausschliesslich im Zugriff einer Anlage.

Benutzerverwaltung #

Die Benutzerverwaltung buendelt Profil, Firma, Site-Zugriff und persoenliche Alarme. Du erreichst sie ueber die Einstellungen (Zahnrad) bzw. das Zugriff-Modul einer Anlage.

Profil & Avatar

Im Profil pflegst du Anzeigename, Kontaktdaten und dein Profilbild (Avatar).

• Avatar — jpg/png/webp/heic, max. 3 MB; erscheint in Topbar, Kanban und Zuweisungen. Ohne Bild werden deine Initialen gezeigt.
• Anzeigename — wird in Listen und Zuweisungen statt der E-Mail gezeigt.
• E-Mail — zugleich dein Login-Name; nur ueber Support/Superadmin aenderbar.
• Telefon — optional, nur fuer dich und deinen Firmen-Owner sichtbar.
• Telegram-Chat-ID — numerische ID fuer persoenliche Telegram-Alarme (per @userinfobot ermitteln).

Firma verwalten

Der Firma-Bereich ist nur fuer Org-Owner und -Admins sichtbar. Er zeigt alle Mitarbeiter mit ihrer Org-Rolle und buendelt die Verwaltung:

• Mitarbeiter — Mitglieder der Firma; Org-Rolle (owner/admin/member) setzen oder entfernen.
• Einladen — erzeugt einen Einladungslink fuer neue Firmen-Mitglieder (siehe Einladungen).
• Anlagen-Zuweisung — welche Sites ein Mitarbeiter mit welcher Site-Rolle sieht.
• Alarme — pro Mitarbeiter pro Standort die Alarm-Zustellung festlegen.
• Aufgaben-Ueberblick — Kanban-Aufgaben aller Standorte der Firma auf einen Blick.

Zugriff auf eine Anlage

Jede Anlage hat im Modul Zugriff eine Liste, wer sie sehen darf: Firmen-Mitglieder mit explizitem Site-Recht sowie extern eingeladene Techniker und Kunden. Von hier vergibst du Rollen und erzeugst Einladungslinks.

Einladungen (3 Szenarien)

Einladungen laufen immer ueber einen Link (mit QR-Code), 7 Tage gueltig, einmalig einloesbar:

• Mitarbeiter (Firma → „Einladen") — der neue Nutzer wird Firmen-Mitglied mit Org-Rolle member oder admin und kann den Anlagen der Firma zugewiesen werden.
• Externer Techniker (Anlage → „Techniker einladen") — bekommt Zugriff NUR auf diese eine Anlage (Rolle service, auf full editierbar), ohne Firmen-Mitgliedschaft.
• Kunde (Anlage → „Kunde einladen") — bekommt die Rolle client NUR fuer diese Anlage, ohne Firmen-Mitgliedschaft; sieht nur seine eigenen Geraete und Freigaben.

Externe Techniker und Kunden zaehlen nicht gegen das Mitarbeiter-Limit deines Tarifs.

Persoenliche Alarm-Abos

Unter Meine Alarm-Abos (Einstellungen) abonnierst du pro Standort die Alarm-Zustellung per E-Mail und/oder Telegram — zusaetzlich zu den zentralen Alarm-Webhooks. Telegram erfordert deine Chat-ID im Profil.

Dashboard / Standorte-Uebersicht #

Nach dem Login landest du auf dem Dashboard — der Uebersicht aller Standorte (Menuepunkt Standorte). Ein Admin sieht alle Anlagen, ein benannter Benutzer nur die ihm zugeteilten.

Tabelle oder Kacheln

Oben rechts schaltest du zwischen Tabelle und Kacheln um. Die Wahl wird im Browser gemerkt und bleibt beim naechsten Besuch erhalten.

Kennzahlen-Leiste (Ampel-Filter)

Ueber der Liste zeigt eine Leiste die Ampel-Kennzahlen: Standorte (gesamt), Online, Alarme und Offline. Jede dieser Kacheln ist ein anklickbarer Zustands-Filter — ein Klick zeigt nur Anlagen in diesem Zustand, ein erneuter Klick hebt den Filter wieder auf. Die Geraete-Kachel daneben ist rein informativ.

Tabellen-Ansicht

Die Tabelle listet die Standorte mit den Spalten Name, Firma, Zustand, Supervisor, Besitzer, Geraete, Zuletzt gesehen und Aktionen. Ein Klick auf eine Kopfzeile sortiert nach dieser Spalte (erneuter Klick dreht die Richtung). Das Suchfeld filtert nach Name, Firma, Supervisor oder Besitzer. Sortierung und Zustands-Filter bleiben ueber Reloads erhalten; „Filter zuruecksetzen" erscheint nur, wenn ein Filter aktiv ist — die Sortierung bleibt dabei bestehen.

Rechts in der Werkzeugleiste exportierst du die sichtbaren (gefilterten und sortierten) Standorte als CSV oder druckst sie als PDF. Der Knopf Etiketten fuehrt direkt zum Etiketten-Designer.

Kacheln-Ansicht

Jeder Standort erscheint als Kachel mit:

• Name und Rollen-Abzeichen (View / Service / Full); bei aktivem Kill-Switch zusaetzlich gesperrt.
• Status-Pille (Online / Offline bzw. neutraler Hinweis, siehe unten).
• Anzahl Geraete online und Zeitpunkt des letzten Scans.
• Adresse des OnSite-Pi (IP:Port) und des Windows-Remote-Ziels.
• Verbinden oeffnet den Standort; das Stift-Symbol erlaubt Umbenennen / Farbe. Eine gesetzte Farbe erscheint als farbiger linker Rand der Kachel.

Live-Status und ehrliche Fehlermeldungen

Die Uebersicht aktualisiert sich automatisch alle 30 Sekunden und pausiert, solange der Tab im Hintergrund liegt (spart Last, da jede Anlage einzeln abgefragt wird). Faellt eine Abfrage aus, zeigt die Kachel bewusst keinen falschen Offline-Zustand, sondern einen neutralen Hinweis: Sitzung abgelaufen, Mesh nicht erreichbar oder Zeitueberschreitung. So wird ein abgelaufener Login oder ein haengendes Mesh-Relay nie mit „Anlage offline" verwechselt.

Netzwerkgeraete (Liste / Filter) #

Die Ansicht Netzwerkgeraete ist das Herz der App. Jede Zeile zeigt Geraet, erkannten Typ, zugeordnetes Plugin und Service-Badges.

Fruher hiess diese Ansicht „Device Liste". Umbenannt am 28.07.2026, weil im Seitenmenue derselben Anlage bereits ein Eintrag Devices steht — der zeigt die gekoppelten Geraete. Hier stehen die im Netz gefundenen.

Filter

Die Sidebar filtert nach Geraetefamilie, Status (online/offline/Alarm) und Plugin. Die Filter sind additiv — mehrere gleichzeitig grenzen die Liste weiter ein.

Neu scannen

„Neu scannen" wiederholt den Netz-Scan und aktualisiert Status/Neuzugaenge, ohne bestehende Zuordnungen zu verlieren.

Herz-Spalte — Erreichbarkeit auf einen Blick

Die Herz-Spalte zeigt fuer jedes Geraet einen kompakten Verlaufsbalken der letzten 20 Ping-Checks. Jeder Block steht fuer einen Scan-Durchlauf:

• ▮ gruen = Geraet war online und hat geantwortet
• ▮ grau = Geraet war offline oder nicht erreichbar

Der Dot links zeigt den aktuellen Status: gruen (online), grau (zuletzt gesehen), rot (offline). So siehst du auf einen Blick, ob ein Geraet dauerhaft laeuft oder immer wieder ausfaellt.

Screenshot folgt — Bild noch nicht vorhanden.

Netzwerk waehlen — und was die Zahlen bedeuten

Ueber der Tabelle steht je Netz dieser Anlage eine Karte. Jede Karte traegt ihre eigenen Zahlen: online, wacklig, offline. Ein Klick schraenkt die ganze Ansicht auf dieses Netz ein — Tabelle, Filterspalte und saemtliche Zaehler. Auswahl und Zahl sind damit dasselbe Objekt.

Vorher war das nicht so: die Netzwahl steckte in der Filterspalte, waehrend oben „51 Geraete online" stand — die Gesamtzahl ueber alle Netze. Wer das AV-Netz waehlte, bekam weiterhin die Zahlen aller Netze zu sehen. Seit dem 28.07.2026 bezieht sich jede Zahl der Seite auf die getroffene Auswahl.

Was heisst „wacklig"? Ein Geraet, das noch antwortet, aber bereits einzelne Pings verfehlt hat und damit auf dem Weg in den Offline-Zustand ist. Es ist der frueheste Hinweis auf ein Problem — eine schlechte Funkstrecke, ein wackliges Patchkabel, ein ueberlastetes Geraet — und genau die Anlage, die man vor der Vorstellung anschaut. Fuer „offline" muss ein Geraet mehrere Pings hintereinander verfehlen.

Bis zum 28.07.2026 stand hier auf jeder Anlage dauerhaft eine 0: der Zustand „wacklig" wurde in der Plattform gar nicht erst berechnet, und auch der gleichnamige Filter in der Spalte links blieb deshalb immer leer. Wackelnde Geraete erschienen als glatt „online". Das ist behoben — Karte, Filter, Statusampel, CSV-Export und Ausdruck verwenden jetzt dieselbe Einstufung.

Tabelle und Netzwerkplan

Beides sind Darstellungen desselben Bestands und stehen als Reiter nebeneinander. Der Reiter „Tabelle" traegt die Zahl der gerade sichtbaren Geraete. Die Wahl bleibt pro Anlage erhalten.

Der Reiter Netzwerkplan zeigt denselben Bestand als Strang: Onsite → Switch → Port → Geraet, eingerueckt, jede Ebene zuklappbar. Beim Wechsel bleiben Netzauswahl, Filter und Suche unveraendert — beide Reiter arbeiten mit genau derselben, gefilterten Liste. Einzelheiten dazu stehen unter Netzwerkplan — Strang.

Zeilendichte

Zwei Stufen: kompakt (32 px) und normal (40 px). Die Zeilenhoehe ist fest — laengere Werte werden abgeschnitten, der vollstaendige Text steht im Tooltip der Zelle. Die Schriftgroesse aendert sich dabei nicht; die Dichte kommt allein aus der Polsterung. Die Wahl bleibt pro Browser erhalten.

Spalte „Haengt an" (Switch und Port)

Zeigt, an welchem Switch und an welchem Port ein Geraet steckt — vor dem Rack die wertvollste Angabe einer Zeile.

Seit dem 29.07.2026 wird die Spalte wirklich befuellt. Bis dahin war sie gebaut, stand default aus und blieb leer, weil sie niemand fuellte. Die Erhebung fragt jetzt die Switches selbst: LLDP zuerst (Switch und Geraet melden einander gegenseitig, praezise), sonst die MAC-Tabelle des Switches. Am echten Bestand von Theater Uri gemessen: 8 von 66 Geraeten haengen nachweislich an einem Port (6 ueber LLDP, 2 ueber die MAC-Tabelle).

Die Spalte schaltet sich einmalig selbst ein, sobald eine Anlage wirklich eine Zuordnung liefert — nicht vorher. Danach entscheidest du ueber Spalten.

Jede Angabe traegt Quelle und Alter. Nach 72 Stunden ohne Bestaetigung gilt sie als veraltet und wird gedaempft dargestellt — sie bleibt aber stehen, weil der letzte bekannte Steckplatz wertvoll ist. Geloescht wird nur eine Angabe ohne Zeitstempel. Ein Scan ueberschreibt die Zuordnung nicht mehr; vorher haette der naechste Durchlauf jede gerade gemessene Zuordnung wieder entfernt.

Warum nicht bei jedem Geraet etwas steht: hinter einem Uplink wird bewusst nichts zugeordnet. An einem UniFi der Anlage stehen 43 gelernte Adressen auf einem einzigen Port — dem Uplink zum zweiten Switch. Wuerde UpNrun das woertlich nehmen, stuende bei 43 Geraeten dieselbe Portnummer. Ein Uplink ist kein Steckplatz. Dazu kommen Switches, die auf keinem Management-Weg antworten; sie erscheinen mit Klartext-Grund statt als stille Leerzeile. Der Ast „Ohne Portzuordnung" im Netzwerkplan nennt fuer jedes Geraet den Grund.

Portdaten, die ein Switch-Plugin auf Knopfdruck live abfragt, erscheinen weiterhin im Plugin-Panel des Switches — sie landen nicht im Geraetebestand und damit auch nicht in dieser Spalte.

Spalten

Spalten lassen sich am Tabellenkopf verschieben, ein- und ausblenden und als benannte Ansicht speichern. Reihenfolge und Sichtbarkeit bleiben pro Browser erhalten.

CSV, Drucken und Vollbild

Selten Gebrauchtes steht im Menue „…" rechts in der Reiter-Leiste: CSV-Export, Drucken/PDF und Netzwerkplan im Vollbild. Exportiert und gedruckt wird immer genau das, was gerade sichtbar ist (gefiltert und sortiert).

Scan-Bedienelemente

Alles, was den Scan steuert, sitzt in der Filterspalte im Kasten Scan: die Live-Anzeige, „Neu scannen", „Tiefensuche" und der Schalter „Alle Plugins".

Projekt

Speichert den Geraetebestand als Datei und spielt ihn wieder ein; das Boot-Projekt wird bei jedem Onsite-Neustart geladen. Die Funktion wird selten gebraucht und ist darum eingeklappt.

Network Devices (list / filters) #

The Network Devices view is the heart of the app. Each row shows the device, its detected type, the assigned plugin and service badges.

This view used to be called "Device List". It was renamed on 28 July 2026 because the site menu already has an entry called Devices — that one lists the coupled devices, while this one lists the devices found on the network.

Choosing a network — and what the figures mean

Above the table there is one card per network of this site. Each card carries its own figures: online, flaky, offline. One click narrows the entire view to that network — the table, the filter column and every counter. Selection and figure are therefore the same object.

That was not the case before: the network selector sat in the filter column while the header said "51 devices online" — the total across all networks. Selecting the AV network still showed the figures for all networks. Since 28 July 2026 every figure on the page refers to the current selection.

What does "flaky" mean? A device that still answers but has already missed individual pings and is therefore on its way to going offline. It is the earliest warning of a problem — a weak wireless link, a loose patch cable, an overloaded device — and exactly what you want to look at before a show. To count as "offline" a device has to miss several pings in a row.

Until 28 July 2026 this figure was permanently 0 on every site: the platform never calculated the "flaky" state at all, which is why the filter of the same name in the left-hand column also stayed empty. Flapping devices appeared as plain "online". This is fixed — the cards, the filter, the status indicator, the CSV export and the printout now all use the same classification.

Table and network plan

Both are views of the same inventory and sit next to each other as tabs. The "Table" tab carries the number of currently visible devices. The choice is remembered per site.

The Network plan tab shows the same inventory as a chain: Onsite → switch → port → device, indented, every level collapsible. Switching tabs leaves network selection, filters and search untouched — both tabs work on exactly the same filtered list. Details are in Network plan — chain view.

Row density

Two levels: compact (32 px) and normal (40 px). Row height is fixed — longer values are truncated and the full text is available in the cell tooltip. Font size does not change; density comes purely from padding. The choice is remembered per browser.

The "Attached to" column (switch and port)

Shows which switch and which port a device is plugged into — the most valuable detail in a row when you are standing at the rack.

Since 29 July 2026 the column is actually populated. Until then it was built, off by default and empty because nothing filled it. Collection now asks the switches themselves: LLDP first (switch and device announce each other, precise), otherwise the switch's MAC table. Measured against the real inventory of Theater Uri: 8 of 66 devices demonstrably hang on a port (6 via LLDP, 2 via the MAC table).

The column enables itself once, as soon as a site really delivers an assignment — not before. After that you decide via Columns.

Every entry carries its source and its age. After 72 hours without confirmation it counts as stale and is dimmed — but it stays, because the last known socket is valuable. Only an entry without a timestamp is dropped. A scan no longer overwrites the assignment; previously the next run would have deleted every freshly measured one.

Why not every device shows something: behind an uplink nothing is assigned on purpose. On one UniFi of the site, 43 learned addresses sit on a single port — the uplink to the second switch. Taken literally, 43 devices would carry the same port number. An uplink is not a socket. On top of that come switches that answer on no management path; they appear with a plain-language reason instead of a silent blank. The “No port assignment” branch in the network plan names the reason for every device.

Port data that a switch plugin queries live on demand still appears in that switch's plugin panel — it never enters the device inventory and therefore never reaches this column.

Columns

Columns can be reordered by dragging the table header, shown or hidden, and saved as a named view. Order and visibility are remembered per browser.

CSV, printing and full screen

Rarely used items live in the "…" menu on the right of the tab bar: CSV export, print/PDF and network plan in full screen. Exporting and printing always cover exactly what is currently visible (filtered and sorted).

Scan controls

Everything controlling the scan sits in the filter column inside the Scan box: the live indicator, "Rescan", "Deep search" and the "All plugins" switch.

Project

Saves the device inventory to a file and restores it; the boot project is loaded on every Onsite restart. Rarely needed, hence collapsed.

Tags / Geraete-Gruppen #

Tags gruppieren Geraete mit farbigen Pillen — z.B. alle Audiogeraete, das ganze Lichtnetzwerk oder die Netzwerkinfrastruktur einer Anlage. Jedes Geraet kann mehrere Tags tragen; sie erscheinen als farbige Pillen in der Geraetezeile und im Geraete-Detail. Ueber der Geraeteliste sitzt die Tag-Leiste („Tags") mit je einer Chip pro vergebenem Tag und dem Knopf Tags verwalten.

Automatische Vergabe

UpNrun vergibt Tags automatisch aus der Geraete-Klassifizierung — aus Hersteller, Geraetetyp und zugeordnetem Plugin. So landet ein Dante-/Q-SYS-/AES67-Geraet unter Audionetzwerk, ein Art-Net-/sACN-/DMX-Node oder ein Lichtpult (GrandMA, ETC Eos …) unter Lichtnetzwerk, ein Switch unter Netzwerkinfrastruktur. Acht Standard-Tags sind eingebaut:

• Audiogeraete — Verstaerker, DSP, Mischpulte, Funkstrecken, Lautsprecher.
• Audionetzwerk — Audio-ueber-IP-Transporte (Dante, Q-SYS, AES67, Ravenna, AVB …).
• Lichtnetzwerk — Art-Net/sACN/DMX-Nodes, Lichtpulte und Moving-Light-Marken.
• Netzwerkinfrastruktur — Switches, Router, Access-Points.
• Computer — Windows-/Mac-Rechner (mit Remote-Helper).
• Video/Kamera — Kameras, Grabber, Video-Prozessoren.
• Buero — Drucker und Buerogeraete.
• Sonstiges — nicht sicher zuzuordnende Geraete.

Filtern nach Tag

Ein Klick auf eine Chip in der Tag-Leiste filtert die Geraeteliste auf genau diesen Tag; ein zweiter Klick hebt den Filter wieder auf. Der Chip „Ohne Tag" zeigt Geraete ganz ohne Tag — praktisch, um Luecken in der Klassifizierung zu finden. Die Auswahl bleibt pro Anlage gespeichert und ueberlebt einen Reload.

Mehrfachauswahl und Bulk-Vergabe

Ab der Rolle Service zeigt jede Zeile eine Checkbox. Sobald Geraete markiert sind, erscheint die Bulk-Leiste: einen Tag eintippen und + Tag haengt ihn allen ausgewaehlten Geraeten an, − Tag entfernt ihn. Ueber Notiz … laesst sich eine gemeinsame Notiz setzen; Auswahl leeren hebt die Markierung auf. So lassen sich Dutzende Geraete in einem Schritt taggen.

Tags verwalten (Farben, Umbenennen, Loeschen)

Tags verwalten oeffnet den Tag-Manager: eigene Tags anlegen, umfaerben (freie Farbwahl — die eigene Farbe schlaegt auch die eines Standard-Tags), umbenennen oder loeschen. Standard-Tags haben feste, kraeftige Farben; unbekannte Tags erhalten automatisch eine stabile Farbe aus ihrem Namen. Die Tag-Definitionen gelten anlagenweit.

Im Netzwerkplan ordnet das Layout Nach Tag gruppiert Geraete mit gleichem Tag raeumlich zusammen — dieselben Tags, andere Ansicht.

Netzwerkplan #

Der Netzwerkplan zeichnet die Anlage als grafische Karte: jedes Geraet ist eine Karte, nach Subnetz mit der jeweiligen Hauptverteilung verbunden. In der Geraeteliste schaltet der Umschalter Tabelle | Netzwerkplan die Ansicht direkt um; das Symbol daneben oeffnet den Plan im Vollbild (eigener Tab). Die Karten lassen sich frei ziehen — die eigene Anordnung wird pro Anlage gespeichert.

Karten und Legende

• Rote Karte = Hauptverteilung / Subnetz (Knotenpunkt), blaue Karte = einzelnes Geraet.
• Der Status-Punkt zeigt die Erreichbarkeit: gruen = online, rot = offline, grau = unbekannt.
• Verbindungslinien lassen sich nach Kabeltyp einfaerben; die Legende unten links erklaert die Farben.
• Das Suchfeld findet Geraete nach Name, IP, MAC, Hersteller und Typ (Enter = naechster Treffer, Umschalt+Enter zurueck).

Layouts

Ueber das Layout-Menue ordnet sich der Plan automatisch: Baum (Top-Down) zeigt die Subnetz-Hierarchie, Netz (Kraefte) verteilt die Knoten kraeftebasiert, und Nach Tag gruppiert stellt Geraete mit gleichem Tag zusammen. Auto-Layout verwirft die eigene Anordnung und ordnet neu, Einpassen zoomt den ganzen Plan in den sichtbaren Bereich.

Beschriften und verkabeln

Mit Service-/Admin-Rechten: Doppelklick auf ein Geraet oeffnet die Geraete-Details (inklusive passender Plugins), Doppelklick auf eine Subnetz-Karte vergibt einen Standort-/Raum-Titel, Doppelklick auf eine Verbindungslinie setzt den Kabeltyp. Der Knopf Verkabelung ordnet Geraete manuell einem Switch-Port zu — noetig bei unmanaged Switches ohne LLDP.

Export

Der Plan laesst sich als PNG-Bild herunterladen oder als PDF (A4 quer, mit Erzeuger-Zeile) exportieren — fuer Dokumentation, Uebergabe oder Ausdruck.

Netzwerkplan — Strang #

In der Ansicht Netzwerkgeraete zeigt der Reiter Netzwerkplan die Anlage als Strang: Onsite → Switch → Port → Geraet, als eingerueckte Liste mit fester Zeilenhoehe. Jede Ebene laesst sich zuklappen, ein Klick auf eine Geraetezeile oeffnet dasselbe Detail-Fenster wie die Tabelle. Netzauswahl, Filter und Suche gelten fuer beide Reiter gemeinsam; jede Zahl in der Fusszeile bezieht sich auf die getroffene Auswahl. Die gezeichnete Karte gibt es weiterhin unter Netzwerkplan im Vollbild.

Woher die Portzuordnung kommt

Die Zuordnung „welches Geraet steckt an welchem Switch-Port" wird getrennt vom Netz-Scan erhoben: ueber LLDP (Switch und Geraet melden einander gegenseitig — praezise) und ueber die MAC-Tabelle des Switches (er hat die Adresse an diesem Port gelernt). Die Spalte Zuordnung nennt beides: Quelle und Alter. Der Tooltip zeigt den genauen Zeitstempel. Eine Angabe, die 72 Stunden lang nicht bestaetigt wurde, gilt als veraltet und wird gedaempft dargestellt — sie bleibt stehen, weil der zuletzt bekannte Steckplatz wertvoll ist, gibt sich aber als alt zu erkennen.

Uplinks — und warum sie kein Steckplatz sind

Ein Port, an dem ein anderer Switch haengt, ist ein Uplink. Der Plan zeichnet ihn als eigene Zeile mit dem Ziel, aber ohne Geraete darunter.

Warum das wichtig ist: An Theater Uri liefert die MAC-Tabelle des UniFi 10.20.1.99 43 Eintraege — alle auf Port 21, dem Uplink zum zweiten UniFi. Wer diese Tabelle naiv uebernimmt, behauptet fuer 43 Geraete „haengt an Port 21". Das waere kein Baum, sondern ein Haufen. Hinter einem Uplink meldet kein abfragbarer Switch, an welcher Buchse ein Geraet wirklich steckt — also behauptet der Plan es auch nicht.

Der Ast „Ohne Portzuordnung"

Geraete, die kein Switch an einem Zugangsport meldet, verschwinden nicht und bekommen auch keinen Strich. Sie stehen in einem eigenen, benannten Ast — mit dem Grund: welche Ports als Uplink eingestuft wurden und wie viele Adressen dahinter gelernt sind, und welcher Switch gar nicht geantwortet hat. Liegt fuer die Anlage noch keine Erhebung vor, steht genau das da; es wird nichts geschaetzt.

Kopfzeile je Switch: Kapazitaet und Netze

Jede Switch-Kopfzeile nennt rechts belegt X / Y — belegte Zugangsports von den Ports, die dieser Switch gemeldet hat (nicht die Zahl der Buchsen an der Frontblende). Liegt keine Portliste vor, steht dort „Portbelegung nicht erhoben". Ebenso ehrlich beim Strom: solange die Anlage keine PoE-Messwerte liefert, steht „PoE nicht erhoben" statt einer Schaetzung.

Links im Kopf steht, in welchem Netz der Switch verwaltet wird und welche Netze er traegt. Das ist kein Schmuck: an Theater Uri tragen beide UniFi ihre Verwaltungsadresse im AV-Netz (10.20.1.98/.99), haengen daran aber Geraete des Buero-LAN. Ohne diese Angabe stuende ein Netz ohne Switch da. Derselbe physische Switch unter zwei Adressen (gleiche MAC) erscheint als ein Ast mit beiden Adressen.

Freie Ports, Dichte, Zustaende

• Freie Ports blendet unbelegte Ports ein — aber nur dort, wo die Erhebung wirklich eine Portliste geliefert hat und die Ports schlichte Nummern tragen. Ein Switch, der seine Ports „0/3" nennt, bekommt keine erfundenen Nummern.
• Alle einklappen / aufklappen faltet den ganzen Strang; einzelne Ebenen per Klick auf ihre Kopfzeile. Der Zustand bleibt pro Anlage und Browser erhalten.
• Die Zeilendichte (kompakt 32 px / normal 40 px) gilt fuer Tabelle und Plan gemeinsam. Zeilen aendern ihre Hoehe nie; was nicht passt, steht im Tooltip.
• Der Zustand je Geraet folgt derselben Einstufung wie die Liste: online, wacklig (online, aber bereits verfehlte Pings) und offline.

Network plan — chain view #

In the Network Devices view the Network plan tab shows the site as a chain: Onsite → switch → port → device, an indented list with a fixed row height. Every level can be collapsed, and clicking a device row opens the same detail window as the table. Network selection, filters and search apply to both tabs; every figure in the footer refers to the current selection. The drawn map is still available under network plan in full screen.

Where the port assignment comes from

The assignment "which device is plugged into which switch port" is collected separately from the network scan: via LLDP (switch and device announce each other — precise) and via the switch's MAC table (it learned the address on that port). The Assignment column names both: source and age; the tooltip carries the exact timestamp. An entry that has not been confirmed for 72 hours counts as stale and is dimmed — it stays, because the last known socket is valuable, but it admits its age.

Uplinks — and why they are not sockets

A port carrying another switch is an uplink. The plan draws it as its own row naming the far end, but with no devices underneath.

Why this matters: at Theater Uri the MAC table of the UniFi 10.20.1.99 returns 43 entries — all on port 21, the uplink to the second UniFi. Taking that table at face value would claim "attached to port 21" for 43 devices. That is not a tree, it is a pile. Behind an uplink no reachable switch reports which socket a device really uses — so the plan does not claim one.

The "No port assignment" branch

Devices that no switch reports on an access port neither disappear nor get a dash. They sit in their own named branch — together with the reason: which ports were classified as uplinks and how many addresses were learned behind them, and which switch did not answer at all. If no collection has run for the site yet, that is exactly what it says; nothing is estimated.

Per-switch header: capacity and networks

Each switch header shows used X / Y on the right — occupied access ports out of the ports this switch reported (not the number of sockets on the front panel). Without a port list it says "port usage not collected". The same honesty applies to power: as long as the site delivers no PoE readings it says "PoE not collected" instead of a guess.

On the left the header states which network the switch is managed in and which networks it carries. That is not decoration: at Theater Uri both UniFi switches hold their management address in the AV network (10.20.1.98/.99) while carrying devices of the office LAN. Without this, one network would appear to have no switch at all. The same physical switch under two addresses (identical MAC) appears as one branch listing both addresses.

Free ports, density, states

• Free ports reveals unused ports — but only where the collection actually returned a port list and the ports are plain numbers. A switch that names its ports "0/3" gets no invented numbers.
• Collapse / expand all folds the whole chain; individual levels toggle by clicking their header row. The state is remembered per site and browser.
• Row density (compact 32 px / normal 40 px) applies to table and plan alike. Rows never change height; anything that does not fit is in the tooltip.
• Device state follows the same classification as the list: online, flaky (online but already missing pings) and offline.

Trust-Layer / Zero-Trust #

Der Trust-Layer ist die Sicherheitsschicht zwischen UI und Geraeten. Nach dem Zero-Trust-Prinzip wird jede Steueraktion serverseitig gegen Rolle und Lizenz geprueft — nie nur im Browser.

Kill-Switch

Der Kill-Switch trennt im Notfall sofort alle aktiven Remote-/Steuer-Sessions eines Standorts. Danach ist nur noch Lesen moeglich, bis ein berechtigter Nutzer wieder freigibt.

Audit

Alle sicherheitsrelevanten Aktionen werden protokolliert (Audit-Log) und sind in der Platform einsehbar/exportierbar.

Remote Desktop #

Remote Desktop erlaubt — nur in der Rolle Full und ueber den abgesicherten Tunnel — den Bildschirmzugriff auf einen vor Ort erkannten Rechner (Windows/Mac).

• Verbindung laeuft ueber den Trust-Layer; jede Session ist auditiert.
• Der Remote-Helper muss auf dem Zielrechner installiert sein (siehe Remote-Helper-Installation).
• Der Kill-Switch beendet laufende Sessions sofort.

Clipboard-Sync

Der Clipboard-Knopf synchronisiert die Zwischenablage zwischen deinem Buero-Rechner und dem Ziel — Text laesst sich so in beide Richtungen kopieren, ohne ihn abzutippen.

Datei-Transfer

Ueber Dateien ziehst du Dateien per Drag&Drop ins Ziel (Ablage in ~/Downloads) oder zurueck zum Buero-Rechner.

Monitor-Wahl & Multi-Monitor-Hinweis

Hat der Ziel-Rechner mehrere Bildschirme, waehlst du oben im Viewer ueber Monitor den anzuzeigenden aus. Ein gelber Hinweis erscheint, solange nicht alle Monitore gleichzeitig sichtbar sind — so uebersiehst du keinen zweiten Screen.

Monitor schwarz (Privatsphaere)

Mit Monitor schwarz wird der physische Bildschirm am Ziel-Rechner waehrend der Sitzung dunkel geschaltet — Personen vor Ort sehen nicht mit.

15-Minuten-Limit

Inaktive Remote-Sessions werden nach 15 Minuten automatisch getrennt (Sicherheit). Im Viewer erscheint dann ein Hinweis mit Neu verbinden.

Eine Kachel pro Geraet & Verbindungsweg-Wahl

Ist derselbe Rechner ueber mehrere Wege erreichbar (direkt uebers Mesh und ueber das Onsite-Relay), zeigt die Uebersicht trotzdem nur eine Kachel. Beim Verbinden fragt ein Dialog, welcher Weg genutzt werden soll — der gerade beste Weg ist als (empfohlen) markiert (Mesh direkt, wenn verbunden; sonst das Onsite-Relay). Die Kachel gilt als online, solange mindestens ein Weg erreichbar ist.

Software-Install-Presets #

Im Computer-Panel (Geilomat) lassen sich vordefinierte Installer per Klick auf dem Zielrechner ausrollen — z.B. der Remote-Helper selbst oder Standard-Tools.

• Presets sind nach OS gefiltert (Windows / macOS) und erscheinen nur, wenn der Helper das OS meldet.
• Presets verwalten (nur Rolle Full): Name, OS, Installer-Datei, Silent-Args/SHA256 anlegen oder loeschen.
• Installieren ist nur bei Rolle Service/Full und erreichbarem Helper aktiv; der Fortschritt wird gepollt.

Geraete-Detail (Modal) #

Ein Klick auf ein Geraet in der Liste oeffnet das Detail-Modal mit allen bekannten Feldern: Identitaet (Name, Hersteller, OS), Netzwerk (IP/MAC/Mesh), Status/Heartbeat, PoE/Switch, offene Dienste/Ports sowie einer editierbaren Notiz. Leere Felder werden ehrlich als „—" gezeigt, nichts wird erfunden.

Web-UI oeffnen

Sieht der Scan an einem Geraet einen Web-Port (80/8080/443/8443 oder einen http/https-Dienst), zeigt der Modal-Kopf den Knopf „Web-UI öffnen": in der Platform oeffnet er die Geraete-Oberflaeche getunnelt ueber den Onsite-Relay des Standorts (ab Rolle Service, auditiert — funktioniert damit auch aus der Ferne und fuer HTTPS-Geraete), in der lokalen OnSite-App als direkter LAN-Link. Geraete ohne erkannte Web-Oberflaeche bekommen ehrlich keinen Knopf.

Seit dem 29.07.2026 sind diese getunnelten Geraeteseiten wirklich benutzbar (vorher lieferten sie fast immer eine leere Seite). Wie der Tunnel arbeitet, was das braune Hinweisband bedeutet und welche drei Grenzen bekannt sind, steht unter Geraete-Weboberflaechen ueber den Tunnel (English).

Origin: Lokal vs. Platform

Ein Badge zeigt, wie der Zugriff laeuft: Direkte Verbindung ueber LAN/Mesh (niedrige Latenz) oder Relay ueber die Platform (VPS-Tunnel), wenn keine direkte Route zum Geraet besteht.

Labels / Etiketten #

Das Label-System erzeugt massgenaue Etiketten fuer Geraete, Kabel und freie Beschriftungen — vom WYSIWYG-Editor bis zum P-touch-Druckbogen. Zugang: in einer Anlage der Tab Labels, dort der Knopf Label-Editor bzw. der Modus-Umschalter Geräte | Freie Etiketten. Lesen und Drucken genuegt die Rolle View; Designs bearbeiten und Vorlagen speichern erfordert Service-/Admin-Rechte.

Gerätelabels (WYSIWYG-Editor)

Elemente (Text, Linie, Logo, QR) frei auf dem Etikett platzieren — mm-genau, mit Raster-Snap, Hilfslinien und einer Ueberlauf-Warnung, wenn ein Element ueber den Bandrand ragt. Text-Elemente lassen sich an Geraetefelder binden (Name, Typ, IP, MAC, Hostname) oder mit festem Text fuellen; die Live-Vorschau zeigt Beispiel-Geraetedaten.

• Mehrfachauswahl (Shift-Klick / Rechteck), Ausrichten, Verteilen, Ebenen (nach vorn/hinten), Sperren.
• Kopieren/Einfuegen, Duplizieren, Pfeiltasten-Nudge, Zoom (50–300 %) und Fit-to-Screen.
• Pro Geraet druckt der Bogen das gespeicherte Design; per Ausnahme (Stift-Symbol) laesst sich der gebundene Text fuer ein einzelnes Geraet ueberschreiben.

Kabellabels (Wickel-Falt)

Der Modus-Umschalter Geräte | Kabel erzeugt spiegelsymmetrische Wickel-Etiketten: Text links, feine Falzlinie mittig, identischer Text rechts — ums Kabel gefaltet ist die Beschriftung von beiden Seiten lesbar. Optionen: Auto-Textgroesse mit Lesbarkeits-Warnung, Fett, Falzlinie, QR mittig (Signalpfad-Scan), 180°-Flagge und ein Kabeldurchmesser-Hinweis fuer die Wickelhilfe. Die Serien-Nummerierung (Praefix + Start + Anzahl + Schritt + Nullen-Auffuellung) erzeugt „Mischpult Input 1..N" mit Live-Vorschau aller Texte.

Kabelliste (Excel-Grid)

Der Tab Kabelliste ist ein Tabellen-Grid mit den Spalten Von-Geraet, Von-Anschluss, Zu-Geraet, Zu-Anschluss, Kabel-Nr. und Kabeltyp. Geraetenamen werden aus dem Scan per Autocomplete vorgeschlagen; Excel-Copy&Paste, Autospeichern und ein Rechtsklick-Kontextmenue (Zeilen einfuegen/duplizieren/tauschen/durchnummerieren) beschleunigen die Erfassung. Doppelte Kabel-Nummern werden rot markiert. Der Massendruck erzeugt je Zeile ein Etikett (optional beide Kabelenden, Kabel-Nr. voranstellen).

Freie Etiketten (Vorlagen + Seriendruck)

Der Modus-Umschalter Geräte | Freie Etiketten im Labels-Tab erzeugt Etiketten ganz ohne Geraetebezug — Regal, Case, Inventar, Pruefplakette. Acht eingebaute Vorlagen (Freitext, Nummern-Serie, Patchpanel/Ports, Netzwerkdose, Inventar+QR, Case/Kiste, Pruefplakette, Geraet/IP+QR) fuellen das Formular nur vor; danach bleibt alles frei aenderbar: Band 6–36 mm, Laenge, bis zu 4 Zeilen mit Fett-Schalter, optional QR-Code und Firmen-Logo. Das Logo darf breit oder hoch sein — das Etikett passt sich dem Seitenverhaeltnis an (es wird nie verzerrt) und der Text rueckt entsprechend. Hochgeladen wird es als PNG/JPG im Admin-Cockpit (siehe White-Label).

• Platzhalter in Text und QR: {n} laufende Nummer (mit Start, Schritt und fuehrenden Nullen), {A}/{a} Buchstaben-Serie (A…Z, AA…), {i} Druckposition, {datum}, {anlage}, {firma}. Unbekannte Platzhalter bleiben woertlich stehen; die Chips unter dem Formular fuegen Platzhalter direkt an der Cursor-Position ein.
• Serie „Anzahl": Anzahl, Start, Schritt, fuehrende Nullen (3 → 001, 002 …) — z. B. „Port {n}" fuer ein 24er-Patchfeld.
• Serie „Liste": eine Textzeile = ein Etikett. Spalten mit ; oder Tab trennen und per {1}…{9} einsetzen; {text} ist die ganze Zeile — z. B. „Case 1;XLR-Kabel" → Zeile 1 {1}, Zeile 2 {2}.
• Live-Vorschau rendert das Etikett mm-genau und blaettert mit den Pfeilen durch die ganze Serie; der Druck-Knopf nennt die Etikettenzahl (Kappung bei 500 je Bogen wird ehrlich angezeigt).
• Eigene Vorlagen (ab Rolle Service) speichern das komplette Formular samt Serie firmenweit: „Als Vorlage speichern", laden ueber die Auswahlliste.

Vorlagen und Druck

Eingebaute Vorlagen (Geraet Standard/kompakt/gross/mit Logo, Patchfeld, 19"-Rack, Steckdose, Netzdose, Case, Funkmik, DMX, Kabel Standard/schmal/QR/Buehne/Strom) dienen als Startpunkt; eigene Designs lassen sich firmenweit oder nur fuer diese Anlage speichern und je Modus als Firmen-Standard markieren. Gedruckt wird ueber den Systemdialog; fuer massgenaue Etiketten liefert jedes Label ein PNG in exakter mm-Groesse (300 dpi) fuer den Brother P-touch Editor bzw. iPrint&Label.

Direktdruck-Setup (Windows, Chrome/Edge): Brother-P-touch-Treiber installieren, im Druckdialog Papierformat = Bandbreite (Endlosband), Skalierung 100 %, Raender auf „Standard" lassen (die Druckseite bringt ihre Null-Raender selbst mit — die Einstellung „Keine" schaltet die exakte Etikettengroesse gerade ab!) und Kopf-/Fusszeilen aus. Etiketten-Laenge und Auto-Cut stellt man einmalig in den Windows-Druckeinstellungen des Treibers; der Bogen schickt alle Etiketten als einen Druckjob, der Bandvorlauf (~25 mm) faellt nur beim ersten Etikett an. Unterstuetzte Baender: 6–36 mm (36 mm nur PT-P9xx). Modell-Hinweise: der P-touch Cube PT-P300BT kann nicht vom PC drucken (nur Smartphone-App); der PT-P710BT braucht USB und einen ausgeschalteten Editor-Lite-Modus. In Safari/iOS haelt der Browser-Druck die Etikettengroesse oft nicht ein — dort den PNG-Weg nutzen.

UpNrun-Printer-App (Windows) — Direktdruck ohne Dialog: Die kleine App laeuft im Hintergrund und nimmt der Druckseite den Druckdialog ab. Ihr einziger, aber entscheidender Vorteil: sie schickt dem Treiber Etikettenlaenge und Bandbreite pro Auftrag mit — genau das, was der Browser nicht kann. Damit muss niemand mehr die Laenge in den Windows-Druckeinstellungen setzen, und eine ganze Serie druckt auf einen Klick. Herunterladen unter Etiketten → „App holen" bzw. /downloads/upnrun-printer: starten, P-touch per USB anschliessen (Editor-Lite aus), den angezeigten Token beim ersten Direktdruck einmal eintippen — fertig. Wichtig: die App ist kein Ersatz fuer den Brother-Treiber, sie druckt durch ihn hindurch — der Treiber (aus P-touch Editor / iPrint&Label) muss also installiert bleiben. Ist der Drucker offline oder hat einen Fehler, lehnt die App den Auftrag sofort ab (kein Job bleibt haengen, kein leeres Band). Nur Windows; am Mac weiterhin der PNG-Weg. Die App laeuft neben dem normalen Druck — ohne App aendert sich nichts.

DYMO LabelWriter statt P-touch: Der Druckweg ist derselbe — der LabelWriter wird mit seinem normalen Windows-Treiber installiert und erscheint danach als gewoehnlicher Drucker im Browser-Druckdialog; eine Hersteller-Software ist dafuer nicht noetig. Unterschied: DYMO druckt auf Einzeletiketten in festen Groessen (z. B. 30252 Adressetikett, 28 × 89 mm) statt auf Endlosband — die Etikettensorte wird in den Windows-Druckeinstellungen des Treibers gewaehlt. Weil die Groesse fest vorgegeben ist, muessen Bandbreite und Laenge im Labels-Modul zur gewaehlten Sorte passen, sonst wird beschnitten oder skaliert. Es gelten dieselben Chrome-Regeln wie beim P-touch: Skalierung 100 %, Raender auf „Standard", Kopf- und Fusszeilen aus. Der PNG-Export in exakter Millimetergroesse laesst sich alternativ in die DYMO-Software einfuegen.

KNX / Q-SYS #

KNX

Ueber das KNX-Plugin (ABB IPS u.a.) liest und steuert UpNrun KNX/IP-Gateways: Gruppenadressen, Bus-Monitor und definierte Schaltbefehle. Der KNX-Monitor kann Telegramme mitschneiden (CSV-Export).

Q-SYS

Q-SYS Cores werden ueber Status- und Tunnel-Plugins eingebunden: Core-Status (CPU/Design/ Redundanz) lesen und — per Tunnel — das native Q-SYS-Designer-Web erreichen.

OnSite-Pi (Pairing / Update) #

Der OnSite-Pi ist eine Raspberry-Pi-Sonde am Standort. Sie scannt das lokale Netz und meldet sich bei der Platform.

Pairing

Beim Pairing wird der Pi ueber einen QR-Code/Token einem Standort (Site) zugeordnet. Danach erscheint der Standort in der Platform und liefert Live-Daten.

Update

Der Pi aktualisiert sich ferngesteuert (Remote-Update) — neue App-/Plugin-Versionen werden ohne Vor-Ort-Besuch ausgerollt.

Devices — gekoppelte Geräte #

Der Site-Menüpunkt Devices (vormals „Onsite Device") zeigt alle an die Anlage gekoppelten Geräte in einer Tabelle: die Main-Instanz — die per QR-Code gekoppelte UpNrun-Instanz auf Pi, PC oder Mac — und alle Direkt-Helfer (per „Rechner koppeln" verbundene Rechner). Von hier aus erreichst du die Einstellungen jedes Geräts, ohne durch Untermenüs zu klettern.

Die Tabelle

Jede Zeile zeigt: Gerät (Hostname mit Betriebssystem-Icon), Typ (Main-Instanz — mit Plan in Klammern — oder Helper mit OS), Status (Online/Offline-Pille), Version, IP/NetBird (Mesh-Adresse des Helfers), Gekoppelt seit und ganz rechts einen Settings-Button. Der Knopf „Aktualisieren" oben rechts lädt die Liste neu.

Status-Logik — ehrlich statt geschönt

• Direkt-Helfer: gilt als Online, wenn sein letzter Heartbeat jünger als 15 Minuten ist (Helfer melden sich alle 5 Minuten).
• Main-Instanz: Online = Status „aktiv" und der Heartbeat ist nicht überfällig; bleibt er zu lange aus, kippt die Anzeige auf Offline.
• Alte Helfer-Releases ohne Heartbeat-Funktion zeigen ehrlich Offline bzw. „unbekannt" — niemals ein erfundener Wert. Nach dem nächsten Helfer-Update erscheinen echte Live-Werte.

Settings pro Zeile

Der Settings-Button der Main-Instanz öffnet das Onsite-Settings-Modal (Geräte-Info, QR, Basis, Management, Ports, WiFi, OnSite-Update). Der Settings-Button eines Direkt-Helfers öffnet ein kompaktes, rein lesendes Info-Fenster: Name, Betriebssystem, Status, Version, IP/NetBird, letzter Kontakt, gekoppelt seit und Modus.

Zahnrad in der Geräteliste

Rechner, deren IP zu einem gekoppelten Gerät gehört, bekommen zusätzlich direkt in der Haupt-Geräteliste (Network-Tab) ein Zahnrad in der Aktions-Spalte. Es öffnet dasselbe Settings- bzw. Helfer-Fenster — du musst die Devices-Seite dafür nicht besuchen.

Zugriff ab Rolle Service; ein aktiver Kill-Switch sperrt die Seite.

Devices — coupled devices #

The site menu item Devices (formerly "Onsite Device") lists every device coupled to the site in one table: the main instance — the UpNrun instance coupled via QR code, running on a Pi, PC or Mac — and all direct helpers (computers connected via "Couple computer"). From here you reach each device's settings without digging through submenus.

The table

Each row shows: Device (hostname with an operating-system icon), Type (main instance — with its plan in brackets — or helper with its OS), Status (online/offline pill), Version, IP/NetBird (the helper's mesh address), Coupled since, and a Settings button on the far right. The "Refresh" button at the top right reloads the list.

Status logic — honest, not embellished

• Direct helpers: count as online when their last heartbeat is younger than 15 minutes (helpers report every 5 minutes).
• Main instance: online = status "active" and its heartbeat is not overdue; if it stays silent too long, the display flips to offline.
• Old helper releases without the heartbeat feature honestly show offline or "unknown" — never a fabricated value. After the next helper update, real live values appear.

Settings per row

The main instance settings button opens the onsite settings modal (device info, QR, basics, management, ports, WiFi, OnSite update). A direct helper's settings button opens a compact read-only info window: name, operating system, status, version, IP/NetBird, last contact, coupled since and mode.

Gear icon in the device list

Computers whose IP belongs to a coupled device additionally get a gear icon in the actions column of the main device list (Network tab). It opens the same settings or helper window — no need to visit the Devices page first.

Requires role Service or higher; an active kill switch locks the page.

Onsite-Settings — das Einstellungs-Modal #

Der Settings-Button der Main-Instanz (unter Devices) öffnet das Onsite-Settings-Modal. Kopfzeile: „Status laden" holt Einstellungen und Live-Status frisch vom Gerät, „Speichern" sichert den Entwurf, „OnSite-Update" öffnet das Update-Fenster. Die Live-Pille zeigt „bereit" bzw. „online".

Karte: Geräte-Info

Auf einen Blick: gekoppelte Site (mit Firma), Plan-Badge, Uptime, Datum des letzten Neustarts und der Internet-Status — Online/Offline, über welchen Port das Gerät ins Netz geht und welches Gateway es nutzt.

Karte: Onboarding-QR

• Link-QR — kodiert die Management-URL des Geräts. Scannen öffnet die Weboberfläche direkt: ideal als Aufkleber am Rack.
• WiFi-QR — bringt Handy oder Laptop direkt ins WLAN des Pi (SSID + Passwort im QR). Erst scannen, im Pi-WLAN landen, dann arbeiten — Onboarding ohne Tippen.

Die beiden Buttons neben dem Bild schalten zwischen den QR-Varianten um.

Karte: Basis

• Hostname — Name des Geräts im Netz (Standard upnrun-onsite).
• WAN/Internet aktiv — orange gefärbter Risiko-Schalter. Verbindungsrisiko bedeutet: die Änderung konfiguriert den Uplink-Port um und kann dir die eigene Verbindung zum Gerät kappen. Deshalb greift hier das Bestätigungs-Sicherheitsnetz.
• NAT aktiv — das Gerät übersetzt zwischen seinen Netzen (Router-Betrieb).

Karte: Management

Die virtuelle Verwaltungs-IP (Management IP/CIDR, Standard 10.10.10.1/24) ist die feste Hintertür des Pi: unter dieser Adresse bleibt er aus dem gebundenen Netz erreichbar — unabhängig davon, wie das Projektnetz gerade aussieht. Auch sie ist als Verbindungsrisiko markiert. Dazu die Management-URL (z. B. http://upnrun-onsite.local:7878/run) und der Link „Aktuell erreichbar", der die live gemeldete Adresse öffnet.

Karte: Netzwerk-Ports

Die Tabelle zeigt nur echte Ports — also nur, was der Live-Status des Geräts wirklich meldet. Ein Pi mit zwei Ethernet-Buchsen zeigt zwei Zeilen; ein physisch gemeldeter, aber unkonfigurierter Port erscheint read-only. Spalten: Port (mit Linux-Interface), Netzwerk (Name + Typ-Badge), Live-IP, Link (Kabel steckt / steckt nicht) und Status.

Port-Fenster: Zeile anklicken

Ein Klick auf eine Port-Zeile öffnet ein kleines Port-Fenster. Oben stehen die Fakten (read-only): Linux-Interface, Hardware-Port, Live-IP, Link, Status. Darunter die Konfiguration: Name, Rolle (WAN/LAN/Management/Aus), Netzwerk-Zuordnung, IPv4-Modus (DHCP/Static/Aus), statische IP/CIDR, Gateway, DNS und optional ein DHCP-Server mit Adressbereich.

Wichtig: Die Netzwerk-Zuordnung änderst du ausschließlich hier — und immer mit ausdrücklicher Warnung: Geräte in dem Netzwerk sind danach unter Umständen nicht mehr erreichbar, Scans und Bindungen ändern sich. Ohne Bestätigung springt die Auswahl zurück. „Übernehmen" schreibt nur in den Entwurf — ans Gerät geht noch nichts.

Netzwerk anwenden — mit Auto-Rückbau

Der Weg ans Gerät ist immer zweistufig: erst Speichern, dann „Netzwerk anwenden". Bei riskanten Änderungen (Management-IP, Port-Rolle oder -Netzwerk, WiFi-Modus, WAN) fragt UpNrun vorher nach — und nach dem Anwenden erscheint ein Countdown-Banner: „Änderung bestätigen, sonst Auto-Rückbau in X s". Bestätigst du nicht rechtzeitig (etwa weil du dich ausgesperrt hast), stellt das Gerät den alten Zustand automatisch wieder her. Du kannst dich also nicht dauerhaft aussperren.

Meldet eine Funktion „nicht verfügbar (HTTP 501)", ist die Pi-Software zu alt — zuerst ein OnSite-Update ausführen.

Onsite settings — the settings modal #

The main instance's settings button (under Devices) opens the onsite settings modal. Header row: "Load status" fetches settings and live status fresh from the device, "Save" stores the draft, "OnSite update" opens the update window. The live pill shows "ready" or "online".

Card: Device info

At a glance: coupled site (with company), plan badge, uptime, date of the last reboot, and the internet status — online/offline, which port the device uses to reach the internet, and which gateway it talks to.

Card: Onboarding QR

• Link QR — encodes the device's management URL. Scanning opens the web interface directly: ideal as a sticker on the rack.
• WiFi QR — takes a phone or laptop straight into the Pi's WiFi (SSID + password inside the QR). Scan first, land in the Pi's WiFi, then work — onboarding without typing.

The two buttons next to the image switch between the QR variants.

Card: Basics

• Hostname — the device's name on the network (default upnrun-onsite).
• WAN/internet active — an orange-tinted risk switch. Connection risk means: the change reconfigures the uplink port and may cut your own connection to the device. That is why the confirmation safety net applies here.
• NAT active — the device translates between its networks (router mode).

Card: Management

The virtual management IP (management IP/CIDR, default 10.10.10.1/24) is the Pi's fixed back door: it stays reachable at this address from the bound network — no matter what the project network currently looks like. It is also flagged as a connection risk. Below it: the management URL (e.g. http://upnrun-onsite.local:7878/run) and the "Currently reachable" link, which opens the live-reported address.

Card: Network ports

The table shows real ports only — only what the device's live status actually reports. A Pi with two Ethernet jacks shows two rows; a physically reported but unconfigured port appears read-only. Columns: port (with Linux interface), network (name + type badge), live IP, link (cable plugged / not plugged) and status.

Port window: click a row

Clicking a port row opens a small port window. At the top are the facts (read-only): Linux interface, hardware port, live IP, link, status. Below is the configuration: name, role (WAN/LAN/management/off), network assignment, IPv4 mode (DHCP/static/off), static IP/CIDR, gateway, DNS and an optional DHCP server with an address range.

Important: the network assignment is changed exclusively here — and always with an explicit warning: devices on that network may no longer be reachable afterwards, scans and bindings change. Without confirmation the selection snaps back. "Apply" only writes to the draft — nothing reaches the device yet.

Apply network — with automatic rollback

Changes always reach the device in two steps: first Save, then "Apply network". For risky changes (management IP, port role or network, WiFi mode, WAN) UpNrun asks first — and after applying, a countdown banner appears: "Confirm the change, otherwise automatic rollback in X s". If you do not confirm in time (for example because you locked yourself out), the device automatically restores the previous state. You cannot permanently lock yourself out.

If a function reports "not available (HTTP 501)", the Pi software is too old — run an OnSite update first.

WiFi-Betriebsarten #

Die WiFi-Karte im Onsite-Settings-Modal steuert die Funkbetriebsart des Pi über ein Auswahlfeld: Access Point, Client, Bridge, Bridge + DHCP oder Aus. Das WLAN-Interface (z. B. wlan0) meldet das Gerät selbst — es ist reine Anzeige.

Access Point — eigenes WLAN aufspannen

Der Pi spannt ein eigenes WLAN auf: SSID, Passwort, Band (2.4/5 GHz), Kanal und AP-CIDR (Standard 10.42.0.1/24) sind frei wählbar. Optional verteilt ein eigener DHCP-Server Adressen im angegebenen Bereich (Start/Ende). Typischer Einsatz: Servicenetz am Rack — zusammen mit dem WiFi-QR ist ein Techniker in Sekunden drin.

Client — mit bestehendem WLAN verbinden

Der Pi hängt sich als Client in ein vorhandenes WLAN (SSID, Passwort, „Automatisch verbinden").

„Netze suchen" — der Scan

Der Button „Netze suchen" scannt die Umgebung und listet bis zu 12 Netze, sortiert nach Signalstärke: stark (besser als −60 dBm), mittel (besser als −75 dBm), sonst schwach — jeweils mit Sicherheitsangabe (WPA2 & Co.). Ein Klick auf ein Netz übernimmt die SSID ins Feld und stellt den Cursor direkt ins Passwortfeld. Versteckte Netze erscheinen als „(versteckt)" und sind nicht klickbar. Ein erneuter Scan ersetzt die Liste.

Bridge — WLAN transparent auf Ethernet

Die Bridge verbindet das Pi-WLAN transparent mit einem Ethernet-Port: Wer sich mit dem WLAN des Pi verbindet, landet direkt im Zielnetz — als hätte er sein Kabel in den gewählten Port gesteckt. Du wählst nur das Ziel-Interface (angeboten werden die erkannten Ethernet-Ports). Klassischer Fall: Der Techniker steht mit dem Laptop in der Halle und will ins kabelgebundene AV-Netz — Pi-WLAN verbinden, fertig.

Bridge + DHCP — für AV-Netze ohne DHCP-Server

Wie Bridge — aber zusätzlich verteilt ein Mini-DHCP die letzten N Adressen des Ziel-Subnetzes (N = 1–20, Standard 5). Gedacht für AV-Netze, in denen alles statisch vergeben ist und kein DHCP-Server existiert: Das Notebook bekommt automatisch eine passende Adresse vom Ende des Bereichs (bei 192.168.10.0/24 und N=5 also .250–.254), ohne den fest adressierten Gerätebestand zu gefährden.

Aus

WLAN komplett deaktiviert — kein Access Point, kein Client, keine Bridge.

Sicherheitsnetz beim Anwenden

„WiFi anwenden" prüft die Konfiguration vor dem Übertragen; schlägt die Umschaltung fehl, rollt das Gerät selbstständig zurück. Ein Moduswechsel gilt als Verbindungsrisiko: Es gibt eine Rückfrage, und die Verbindung kann während der Umschaltung kurz wackeln — das ist normal. Danach Status neu laden.

WiFi operating modes #

The WiFi card in the onsite settings modal controls the Pi's radio mode via a select field: Access Point, Client, Bridge, Bridge + DHCP or Off. The WiFi interface (e.g. wlan0) is reported by the device itself — display only.

Access Point — spin up your own WiFi

The Pi spins up its own WiFi: SSID, password, band (2.4/5 GHz), channel and AP CIDR (default 10.42.0.1/24) are freely configurable. An optional built-in DHCP server hands out addresses in the given range (start/end). Typical use: a service network at the rack — combined with the WiFi QR, a technician is connected in seconds.

Client — join an existing WiFi

The Pi joins an existing WiFi network as a client (SSID, password, "connect automatically").

"Search networks" — the scan

The "Search networks" button scans the area and lists up to 12 networks, sorted by signal strength: strong (better than −60 dBm), medium (better than −75 dBm), otherwise weak — each with its security type (WPA2 etc.). Clicking a network copies its SSID into the field and places the cursor straight into the password field. Hidden networks appear as "(hidden)" and are not clickable. A new scan replaces the list.

Bridge — WiFi transparently onto Ethernet

The bridge connects the Pi's WiFi transparently to an Ethernet port: anyone joining the Pi's WiFi lands directly in the target network — as if they had plugged their cable into the chosen port. You only pick the target interface (detected Ethernet ports are offered). Classic case: a technician stands in the venue with a laptop and needs the wired AV network — join the Pi WiFi, done.

Bridge + DHCP — for AV networks without a DHCP server

Like bridge — but additionally a mini DHCP hands out the last N addresses of the target subnet (N = 1–20, default 5). Made for AV networks where everything is statically addressed and no DHCP server exists: the laptop automatically gets a fitting address from the end of the range (with 192.168.10.0/24 and N=5 that is .250–.254) without endangering the statically addressed device fleet.

Off

WiFi completely disabled — no access point, no client, no bridge.

Safety net when applying

"Apply WiFi" validates the configuration before transferring it; if the switch-over fails, the device rolls back on its own. A mode change counts as a connection risk: there is a confirmation prompt, and the connection may wobble briefly during the switch — that is normal. Reload the status afterwards.

OnSite-Update #

Der Button „OnSite-Update" in der Kopfzeile des Onsite-Settings-Modals öffnet das Update-Fenster der Main-Instanz. Es zeigt Installiert und Verfügbar (Versionsnummern), dazu ein Badge: orange „Update verfügbar" oder grün „Aktuell".

Was beim Update passiert

1. „Update jetzt" fragt zuerst nach — mit dem realen Stand: Gibt es kein neueres Update, fragt UpNrun ehrlich, ob die gleiche Version neu installiert werden soll.
2. Das signierte Update wird geladen und die Signatur geprüft — nur Original-Pakete werden installiert.
3. Installation als A/B-Wechsel: die neue Version startet neben der alten.
4. Ein Health-Check prüft, ob die neue Version sauber läuft.
5. Schlägt er fehl, kehrt das Gerät automatisch zur vorherigen Version zurück — die Anlage bleibt nie mit kaputter Software liegen.

Status-Anzeigen

Während des Laufs zeigt die Live-Pille „Update läuft…" und die Status-Zeile „Update läuft — wird geladen und installiert …". Nach Abschluss meldet das Fenster „Update fertig — Version X installiert." Der Status aktualisiert sich alle 15 Sekunden von selbst, solange das Fenster offen ist (und pausiert, wenn der Browser-Tab im Hintergrund liegt). Fehler werden ehrlich benannt: „Gerät nicht erreichbar", „Sitzung abgelaufen", Zeitüberschreitung.

Voraussetzungen & Timing

• Die Main-Instanz muss gekoppelt und erreichbar sein (Relay/Mesh online).
• Während des Laufs kann die Verbindung kurz wackeln — das Update also nicht mitten in einer laufenden Vorstellung starten.
• Ein versehentlicher Klick startet nichts: ohne Bestätigung kein Update-Lauf.

OnSite update #

The "OnSite update" button in the header of the onsite settings modal opens the main instance's update window. It shows Installed and Available (version numbers), plus a badge: orange "Update available" or green "Up to date".

What happens during an update

1. "Update now" asks first — with the real facts: if there is no newer update, UpNrun honestly asks whether the same version should be reinstalled.
2. The signed update is downloaded and its signature verified — only genuine packages get installed.
3. Installation as an A/B swap: the new version starts alongside the old one.
4. A health check verifies that the new version runs cleanly.
5. If it fails, the device automatically falls back to the previous version — the installation is never left with broken software.

Status displays

While running, the live pill shows "Update running…" and the status line "Update running — downloading and installing …". When finished, the window reports "Update done — version X installed." The status refreshes itself every 15 seconds while the window is open (and pauses when the browser tab is in the background). Errors are named honestly: "device not reachable", "session expired", timeout.

Prerequisites & timing

• The main instance must be coupled and reachable (relay/mesh online).
• During the run the connection may wobble briefly — so do not start the update in the middle of a live show.
• An accidental click starts nothing: no update run without confirmation.

Netzwerk-Typen — ein Kanon für App und Platform #

Projektnetzwerke tragen einen Typ aus einem festen Kanon — derselbe in der Main-App, im Projektfile und in der Platform. So erkennt jeder sofort, welche Rolle ein Netz in der Anlage spielt.

Der Kanon

Typ zuweisen — in der Main-App

In der Main-Instanz wählst du das Netzwerk aus und setzt den Typ im Typ-Auswahlfeld neben der Netzwerk-Auswahl. Der Typ wandert ins Projektfile (.upnrun) und erscheint als Badge im Netzwerk-Dropdown und in der Geräteliste. Alte Projekte ohne Typ laufen automatisch als „Sonstiges" weiter — nichts bricht.

Wichtig: Boot-Projekt setzen! Die Platform sieht die Netzwerke des Boot-Projekts — also des Projekts, das die Instanz beim Start lädt. Ohne gesetztes Boot-Projekt liefert die Instanz keine Projektnetzwerke an die Platform, und die Ports-Tabelle fällt auf generische Namen zurück.

Typ-Badges in der Platform

Die Ports-Tabelle im Onsite-Settings-Modal und die Geräte-Infoseite des Pi zeigen zu jedem Port den Netzwerk-Namen plus ein farbiges Typ-Badge; der Tooltip nennt das volle Label und — wenn bekannt — das CIDR. WAN zählt semantisch als Internet/Uplink. Eine ältere Pi-Version ohne Typ-Unterstützung degradiert sauber: Badge „kein Netzwerk" bzw. generische Namen.

Network types — one canon for app and platform #

Project networks carry a type from a fixed canon — the same one in the main app, in the project file and on the platform. That way everyone instantly recognises which role a network plays in the installation.

The canon

Assigning a type — in the main app

In the main instance, select the network and set its type in the type select field next to the network selector. The type is stored in the project file (.upnrun) and appears as a badge in the network dropdown and in the device list. Old projects without a type simply continue as "Other" — nothing breaks.

Important: set the boot project! The platform sees the networks of the boot project — the project the instance loads at startup. Without a boot project, the instance delivers no project networks to the platform and the ports table falls back to generic names.

Type badges on the platform

The ports table in the onsite settings modal and the Pi's device info page show each port's network name plus a coloured type badge; the tooltip gives the full label and — when known — the CIDR. WAN semantically counts as internet/uplink. An older Pi version without type support degrades cleanly: badge "no network" or generic names.

Kiosk-Display — der Info-Button am Pi #

Hat der OnSite-Pi ein Touchdisplay, läuft darauf das Kiosk-Display mit einer Touch-Leiste am unteren Rand. Der Info-Button öffnet den Dialog „Geräte-Info" — die Sofort-Diagnose direkt am Gerät, ganz ohne Login:

• Gekoppelte Site — Site-ID und Firma, oder ehrlich „nicht gekoppelt".
• Plan — der aktive Lizenz-Plan der Instanz.
• Uptime — Laufzeit seit dem letzten Start (z. B. „3 T 4 h 12 min").
• Letzter Neustart — Datum und Uhrzeit.
• Internet — Ja/Nein, dazu über welchen Port das Gerät online ist und welches Gateway es nutzt.

Der Dialog ersetzt den früheren WiFi-Scan hinter dem Info-Button. Typischer Einsatz: Vor Ort in Sekunden klären, ob die Sonde gekoppelt und online ist — bevor überhaupt jemand einen Laptop aufklappt.

Kiosk display — the info button on the Pi #

If the OnSite Pi has a touch display, it runs the kiosk display with a touch bar along the bottom edge. The Info button opens the "Device info" dialog — instant diagnostics right at the device, no login required:

• Coupled site — site ID and company, or honestly "not coupled".
• Plan — the instance's active licence plan.
• Uptime — running time since the last start (e.g. "3 d 4 h 12 min").
• Last reboot — date and time.
• Internet — yes/no, plus through which port the device is online and which gateway it uses.

The dialog replaces the former WiFi scan behind the info button. Typical use: clarify on-site within seconds whether the probe is coupled and online — before anyone even opens a laptop.

Geräte-Infoseite des Pi #

Klickst du in der Geräteliste den Pi selbst an (die eigene UpNrun-Instanz) — oder scannst du seinen QR-Sticker — öffnet sich seine Geräte-Infoseite: login-geschützt, rein lesend und fürs Handy gebaut.

Die Onsite-Status-Karte

Nur beim eigenen Onsite-Pi erscheint zusätzlich die Karte „Onsite Device" mit den wichtigsten Live-Stati:

• Kopplung — gekoppelt (Site, Firma, Plan) oder „nicht gekoppelt".
• App-Version, Uptime (mit „seit"-Zeitpunkt).
• Internet — Online/Offline, Interface, Gateway.
• WiFi-Modus — Aus, AP aktiv, Client oder „Bridge auf ethX (+DHCP)".
• Ports-Mini-Tabelle — Port · Netzwerk-Name mit Typ-Badge · IP · Link. Wie überall gilt: nur echte, live gemeldete Ports.

Die Karte ist reine Anzeige — keine Eingabefelder, keine Apply-Buttons. Einstellungen macht die Site-Seite (Site → Devices), dorthin verweist die Zeile unter der Karte. Geladen wird einmalig beim Öffnen, ohne Dauer-Polling — das schont Pi-Relay und Mobilfunkverbindung.

Details-Aufklapper

Unter der Karte liegt der Aufklapper „Details anzeigen (Live-Systemdaten · Identität · Netzwerk · Services)": die lange Metrikliste, Identitäts- und Adapter-Details sowie die Roh-Port-Chips — erreichbar, aber nicht mehr dominant.

Ehrliche Zustände auch hier: Ist das Gerät offline, das Mesh gestört oder fehlt die Berechtigung (ab Service-Rolle), steht dort genau das — statt leerer Felder.

The Pi's device info page #

If you click the Pi itself in the device list (the UpNrun instance) — or scan its QR sticker — its device info page opens: login-protected, strictly read-only and built for the phone.

The onsite status card

Only for the site's own OnSite Pi, an additional "Onsite Device" card shows the most important live states:

• Coupling — coupled (site, company, plan) or "not coupled".
• App version, uptime (with a "since" timestamp).
• Internet — online/offline, interface, gateway.
• WiFi mode — off, AP active, client, or "bridge onto ethX (+DHCP)".
• Ports mini table — port · network name with type badge · IP · link. As everywhere: only real, live-reported ports.

The card is display only — no input fields, no apply buttons. Settings live on the site page (Site → Devices); the line below the card links there. It loads once when opened, with no continuous polling — easy on the Pi relay and on mobile connections.

Details expander

Below the card sits the expander "Show details (live system data · identity · network · services)": the long metrics list, identity and adapter details plus the raw port chips — reachable, but no longer dominant.

Honest states here too: if the device is offline, the mesh is disrupted or permission is missing (Service role or higher required), the page says exactly that — instead of empty fields.

Instanz / QR-Kopplung — das Onboarding #

Der Site-Tab Instanz ist der zentrale Onboarding-Flow: hier wird die Main-Instanz — die UpNrun-App auf einem Pi, PC oder Mac — per QR-Code oder Kopplungs-Code fest an eine Anlage (Site) gebunden. Erst danach liefert die Anlage Live-Daten, und die Instanz erscheint in der Devices-Tabelle.

Instanz koppeln: Code und QR

1. „Instanz koppeln" erzeugt einen 6-stelligen Kopplungs-Code plus QR-Bild. Das Code-Alphabet lässt verwechselbare Zeichen (0/O, 1/I) bewusst weg — der Code lässt sich fehlerfrei abtippen.
2. Der Code gilt 10 Minuten (Countdown unter dem QR) und ist einmalig — nach Gebrauch oder Ablauf ist er wertlos.
3. In der Main-Instanz den QR scannen oder den Code eintippen: die Instanz meldet sich mit ihrem Geräte-Fingerprint bei der Plattform und ist damit gekoppelt.

Ist die Site bereits gekoppelt, ersetzt ein neuer Code die bestehende Instanz nur, wenn beim Erzeugen „ersetzen erlauben" angehakt war — sonst lehnt die Plattform mit „Site besetzt" ab. Ein Ersatz (Takeover) wird in der Historie festgehalten. Fehlversuche mit falschen Codes werden ratenbegrenzt; jeder Schritt landet im Audit-Log.

RT1-Laufzeit-Token: was „gekoppelt" technisch bedeutet

Beim Koppeln stellt die Plattform der Instanz ein signiertes Laufzeit-Token (Format RT1) aus. Darin stecken Site, Geräte-Fingerprint und der Plan der Anlage — der Site-Plan ist die Plattform-Wahrheit für dieses Token. Das Token gilt 14 Tage und wird von der Instanz selbstständig erneuert; zusätzlich meldet sie sich per Heartbeat alle 6 Stunden. Bleibt der Heartbeat zu lange aus, zeigt die Karte ehrlich „zuletzt gesehen vor …" statt eines erfundenen Online.

Die Karte „Gekoppelte Instanz"

• Fingerprint und Boot-ID (gekürzt) — identifizieren die Instanz.
• Gekoppelt / Zuletzt gesehen — Zeitstempel aus Kopplung und Heartbeat.
• „Duplikat vermutet" — erkennt die Plattform zwei parallel laufende Instanzen mit demselben Token (Klassiker: geklonte SD-Karte), warnt die Karte und nennt die beteiligten Boot-IDs.
• Plan — der aktive Plan der Instanz.

Plan wählen

Im Auswahlfeld wird der Plan der Anlage gesetzt (free, local_pro, remote_site, remote_pro, business, enterprise) und mit „Plan speichern" übernommen. Der Plan fließt in das nächste RT1-Token ein; unbekannte oder leere Werte fallen fail-safe auf free zurück.

Main-Instanz entkoppeln

„Entkoppeln" löst die Instanz von der Site (Status „decoupled", die Historie bleibt erhalten). Die Site ist danach frei für eine neue Kopplung; die Instanz vor Ort läuft weiter.

Seit dem 29.07.2026 merkt die Box das von selbst. Vorher hing ihr Kopplungszustand allein daran, dass die Token-Datei lokal existierte — niemand prüfte je, ob das Token noch gilt. Die Box meldete weiter „gekoppelt", der Kiosk zeigte keinen QR-Code, und jede Neukopplung im Feld hätte SSH gebraucht. Jetzt fragt die Box selbst bei der Plattform nach: beim Start als kurze Serie und danach an jedem Heartbeat — kein zweiter Zeitgeber. Ist sie entkoppelt, räumt sie ihr Token weg (mit Sicherungskopie und Protokollzeile) und fordert sofort eine neue Kopplungs-Sitzung an. Der Kiosk zieht den Wechsel ohne Neuladen nach und zeigt wieder den Kopplungs-QR — am Gerät mit Screenshot belegt.

Schweigen zählt nicht. Das ist die wichtigere Hälfte:

• Als ausdrückliche Ablehnung gilt nur, was beides mitbringt: einen HTTP-Status 401/403/404/409 und einen Fehlercode, den nur die Instanz-Registry der Plattform erzeugt.
• Alles andere ist Schweigen und ändert nichts: Zeitüberschreitung, totes DNS, abgewiesene Verbindung, HTTP 5xx, HTTP 429, unlesbare Antwort — und ausdrücklich auch 401/403 ohne bekannten Fehlercode (das ist typischerweise ein Captive Portal im Gäste-WLAN).
• Entkoppelt wird erst nach drei Ablehnungen in Folge. Grund: eine einzelne Lesestörung auf der Plattform würde sonst die halbe Flotte entkoppeln. Kommt zwischen zwei Ablehnungen ein Schweigen, bleibt der Zähler stehen.

Am Pi gegen die echte Plattform durchgespielt: gültiges Token bei erreichbarer Plattform → bleibt gekoppelt, kein QR. Entzogenes Token → nach drei Ablehnungen (etwa eine Minute) entkoppelt, QR erscheint. Verbindung abgewiesen, Zeitüberschreitung, 502, 503, 429 oder ein fremdes 401 → bleibt jedes Mal gekoppelt.

Für die Fehlersuche vor Ort: die Adresse, die geprüft wird, steht in der Token-Datei — eine Umgebungsvariable steuert sie nicht. Und eine entkoppelte Box ohne Internet zeigt trotzdem etwas an, statt vor einem leeren Bildschirm stehen zu lassen.

Direkt-Helfer koppeln („Rechner koppeln")

Neben der Main-Instanz lassen sich einzelne Rechner direkt koppeln — ganz ohne Pi dazwischen. Der Ablauf ist bewusst zweiseitig:

1. Im Remote-Helper auf dem Rechner „Rechner koppeln" wählen — der Helfer zeigt einen 6-stelligen Code (plus QR) und wartet.
2. Ein eingeloggter Admin bestätigt in der Plattform: QR scannen (öffnet die Seite „Rechner koppeln", Login erforderlich) oder den Code im Formular eintippen und die Ziel-Site wählen.
3. Die Plattform erzeugt einen NetBird-Setup-Key; der Helfer tritt dem verschlüsselten Mesh direkt in der isolierten Zone seiner Anlage bei (Gruppe site-<id> — Anlagen sehen einander im Mesh nicht) und erscheint sofort in der Devices-Tabelle der Site.

Ab dann sendet der Helfer alle 5 Minuten einen Heartbeat (Version, Mesh-IP, Hostname, OS) — daraus speist sich der Online-Status (Online-Fenster 15 Minuten). Auch der Helfer-Kopplungs-Code gilt 10 Minuten und ist einmalig.

Direkt-Helfer entkoppeln

In der Helfer-Verwaltung (Devices → Settings beim Helfer) gibt es den Knopf „Entkoppeln" (ab Rolle Full, mit Warn-Rückfrage): der Helfer-Eintrag wird entfernt, der Rechner verschwindet aus Devices und kann nicht mehr ferngesteuert werden — der Gratis-Platz (Seat) wird sofort frei. Der Rechner selbst läuft unverändert weiter und kann jederzeit neu gekoppelt werden.

Seat-Gate: gratis = 1 Site, 1 Helfer

Ohne Lizenz gilt: genau eine Site mit genau einem Direkt-Helfer. Eine zweite Site oder ein zweiter Helfer in derselben Site verlangt eine Lizenz — der Kopplungs-Versuch antwortet dann ehrlich mit „Lizenz erforderlich" (fail-closed: im Zweifel wird abgelehnt statt still durchgewunken). Entkoppeln gibt den Platz wieder frei — tote oder verwaiste Helfer-Einträge blockieren das Gate also nicht dauerhaft.

Instance / QR coupling — onboarding #

The site tab Instance is the central onboarding flow: it binds the main instance — the UpNrun app on a Pi, PC or Mac — permanently to a site via QR code or coupling code. Only then does the site deliver live data, and the instance appears in the Devices table.

Coupling an instance: code and QR

1. "Couple instance" generates a 6-character coupling code plus a QR image. The code alphabet deliberately omits confusable characters (0/O, 1/I) — the code can be typed without errors.
2. The code is valid for 10 minutes (countdown below the QR) and is single-use — after use or expiry it is worthless.
3. Scan the QR or type the code in the main instance: the instance reports to the platform with its device fingerprint and is coupled.

If the site is already coupled, a new code only replaces the existing instance when "allow replacement" was checked while generating — otherwise the platform refuses with "site occupied". A replacement (takeover) is recorded in the history. Failed attempts with wrong codes are rate-limited; every step lands in the audit log.

RT1 runtime token: what "coupled" means technically

On coupling, the platform issues the instance a signed runtime token (format RT1). It carries the site, the device fingerprint and the site's plan — the site plan is the platform's single source of truth for this token. The token is valid for 14 days and is renewed by the instance itself; in addition, the instance sends a heartbeat every 6 hours. If the heartbeat stays silent for too long, the card honestly shows "last seen … ago" instead of a fabricated online state.

The "coupled instance" card

• Fingerprint and boot ID (shortened) — identify the instance.
• Coupled / last seen — timestamps from coupling and heartbeat.
• "Duplicate suspected" — if the platform detects two instances running in parallel with the same token (classic case: a cloned SD card), the card warns and lists the boot IDs involved.
• Plan — the instance's active plan.

Choosing a plan

The select field sets the site's plan (free, local_pro, remote_site, remote_pro, business, enterprise); "Save plan" applies it. The plan flows into the next RT1 token; unknown or empty values fall back fail-safe to free.

Decoupling the main instance

"Decouple" releases the instance from the site (status "decoupled", the history is kept). The site is then free for a new coupling; the on-site instance keeps running.

Since 29 July 2026 the box notices this by itself. Previously its coupling state depended solely on the token file existing locally — nobody ever checked whether the token was still valid. The box kept reporting “coupled”, the kiosk showed no QR code, and any re-coupling in the field would have required SSH. Now the box asks the platform itself: a short series at startup and then on every heartbeat — no second timer. If it has been decoupled it files its token away (with a backup copy and a log line) and immediately requests a new coupling session. The kiosk follows the change without a reload and shows the coupling QR again — proven on the device with a screenshot.

Silence does not count. That is the more important half:

• An explicit rejection requires both: an HTTP status of 401/403/404/409 and an error code that only the platform's instance registry produces.
• Everything else is silence and changes nothing: timeout, dead DNS, refused connection, HTTP 5xx, HTTP 429, an unreadable answer — and explicitly 401/403 without a known error code as well (typically a captive portal on guest Wi-Fi).
• Decoupling only happens after three rejections in a row. The reason: a single read fault on the platform would otherwise decouple half the fleet. If silence comes between two rejections, the counter holds.

Played through on a Pi against the real platform: valid token with the platform reachable → stays coupled, no QR. Revoked token → decoupled after three rejections (about a minute), QR appears. Refused connection, timeout, 502, 503, 429 or a foreign 401 → stays coupled every time.

For troubleshooting on site: the address being checked comes from the token file — an environment variable does not control it. And a decoupled box without internet still shows something instead of leaving you in front of a blank screen.

Coupling a direct helper ("Couple computer")

Besides the main instance, individual computers can be coupled directly — without a Pi in between. The flow is deliberately two-sided:

1. In the remote helper on the computer, choose "Couple computer" — the helper shows a 6-character code (plus QR) and waits.
2. A logged-in admin confirms on the platform: scan the QR (opens the "Couple computer" page, login required) or type the code into the form and pick the target site.
3. The platform creates a NetBird setup key; the helper joins the encrypted mesh directly in its site's isolated zone (group site-<id> — sites cannot see each other on the mesh) and immediately appears in the site's Devices table.

From then on the helper sends a heartbeat every 5 minutes (version, mesh IP, hostname, OS) — this feeds the online status (15-minute online window). The helper coupling code is also valid for 10 minutes and single-use.

Uncoupling a direct helper

The helper management view (Devices → Settings on the helper) has an "Uncouple" button (role Full required, with a warning prompt): the helper record is removed, the computer disappears from Devices and can no longer be remote-controlled — the free seat becomes available immediately. The computer itself keeps running and can be re-coupled at any time.

Seat gate: free = 1 site, 1 helper

Without a licence the rule is: exactly one site with exactly one direct helper. A second site, or a second helper on the same site, requires a licence — the coupling attempt then honestly answers "licence required" (fail-closed: when in doubt it refuses instead of silently waving things through). Uncoupling frees the seat again — dead or orphaned helper records never block the gate permanently.

Direkt-Helfer-Fernverwaltung #

Der Settings-Knopf eines Direkt-Helfers — unter Devices oder über das Zahnrad in der Geräteliste — öffnet die Verwaltungs-Ansicht des Rechners: Live-Systemdaten, Freigabe-Schalter, Werkzeuge und ein Software-Center. Die Plattform spricht dabei über das verschlüsselte NetBird-Mesh direkt mit dem Helfer, ohne Pi-Umweg.

Die Kopf-Karte „Helfer" zeigt Status (Online/Offline), Betriebssystem, Helper-Version, NetBird-IP, letzten Kontakt und „gekoppelt seit"; „Aktualisieren" lädt alles frisch.

Voraussetzungen

• Helper ab Version 1.9 — erst ab 1.9 meldet der Heartbeat die Mesh-IP, über die die Plattform den Rechner erreicht. Ohne gemeldete Mesh-IP sagt die Ansicht das ehrlich, statt ins Leere zu laufen.
• NetBird verbunden — der Helfer muss im Mesh sein.
• Online-Fenster: als online gilt ein Helfer mit Heartbeat in den letzten 15 Minuten (Helfer melden sich alle 5 Minuten). Offline-Helfer lassen sich nicht steuern — die Ansicht nennt die üblichen Ursachen (Rechner aus? Helper läuft? NetBird verbunden?).

System — live

CPU-, RAM-, Disk- und Netzwerk-Karten kommen live vom Helfer — es sind dieselben server-gerenderten Karten mit derselben Ampel-/Schwellen-Logik wie im Computer-Panel und im Pi-Widget. Fehlen Daten, erscheint ein ehrlicher Hinweis statt leerer Kacheln.

Freigaben — Schalter mit Wirkung am Gerät

Vier Schalter steuern, was die Plattform an diesem Helfer überhaupt darf — gesetzt in der Plattform, durchgesetzt lokal vom Helfer:

• Screenshot erlauben
• Software-Installation erlauben
• Prozessliste erheben
• Netzwerk-Traffic erheben

Ein älterer Helfer ohne Freigabe-Schalter meldet das ehrlich — dann zuerst ein Helper-Update fahren.

Werkzeuge

• Screenshot — holt ein aktuelles Bildschirmfoto des Rechners (ab Rolle Service; braucht Helper 2.0, sonst „Helper-Update nötig").
• Sharing-Dateien — listet die vom Helfer freigegebenen Dateien und lädt sie herunter; „Ordner am Rechner öffnen" öffnet den Sharing-Ordner direkt am Zielrechner.
• Neustart — startet den Rechner ferngesteuert neu (mit Rückfrage).
• Entkoppeln — löst die Kopplung, der Gratis-Seat wird frei (nur Rolle Full; Details im Kapitel Instanz / QR-Kopplung).

Software-Center

„Katalog laden" zeigt den Software-Katalog mit Suchfeld; „Installiertes neu scannen" gleicht ab, was auf dem Rechner schon vorhanden ist. Installationen (nur Rolle Full) laufen ausschließlich über den serverseitig gebauten Auftrag: der Browser wählt nur einen Katalog-Eintrag — niemals eine URL oder ein Kommando. So kann auch ein kompromittierter Browser keine Fremd-Software unterschieben.

„Helper-Update nötig" — was der Hinweis bedeutet

Meldet eine Funktion „Helper-Update nötig", fehlt dem installierten Helfer der passende Endpunkt (HTTP 501/404): Screenshot und Neustart brauchen Helper 2.0, der Software-Katalog eine neuere Version, Heartbeat/Mesh-IP mindestens 1.9. Nach dem In-App-Update des Helfers erscheinen die Funktionen von selbst — es wird nie ein Wert erfunden.

Sicherheit

• Pfad-Whitelist: die Plattform reicht nur eine feste Liste von Helfer-Endpunkten durch — kein offener Proxy.
• SSRF-Guard: Ziel ist ausschließlich die im Heartbeat gemeldete Mesh-/LAN-IP — nie eine Adresse aus dem Browser-Request, nie eine öffentliche IP.
• Rollen: Ansehen ab View, Steuern (Screenshot, Dateien, Neustart, Freigaben) ab Service, Installieren und Entkoppeln ab Full.
• Kill-Switch der Site sperrt den kompletten Helfer-Zugriff; steuernde Aufrufe werden im Audit-Log protokolliert.

Direct helper remote management #

A direct helper's Settings button — under Devices or via the gear icon in the device list — opens the computer's management view: live system data, permission switches, tools and a software center. The platform talks to the helper directly over the encrypted NetBird mesh, with no Pi in between.

The "Helper" header card shows status (online/offline), operating system, helper version, NetBird IP, last contact and "coupled since"; "Refresh" reloads everything.

Prerequisites

• Helper version 1.9 or newer — only from 1.9 does the heartbeat report the mesh IP through which the platform reaches the computer. Without a reported mesh IP the view says so honestly instead of running into the void.
• NetBird connected — the helper must be in the mesh.
• Online window: a helper counts as online with a heartbeat within the last 15 minutes (helpers report every 5 minutes). Offline helpers cannot be controlled — the view lists the usual causes (computer off? helper running? NetBird connected?).

System — live

CPU, RAM, disk and network cards come live from the helper — they are the same server-rendered cards with the same traffic-light/threshold logic as the computer panel and the Pi widget. If data is missing, an honest hint appears instead of empty tiles.

Permissions — switches enforced on the device

Four switches control what the platform may do on this helper at all — set on the platform, enforced locally by the helper:

• Allow screenshot
• Allow software installation
• Collect process list
• Collect network traffic

An older helper without permission switches reports that honestly — run a helper update first.

Tools

• Screenshot — fetches a current screenshot of the computer (role Service or higher; needs helper 2.0, otherwise "helper update required").
• Sharing files — lists the files shared by the helper and downloads them; "Open folder on the computer" opens the sharing folder directly on the target machine.
• Reboot — restarts the computer remotely (with confirmation).
• Uncouple — releases the coupling, the free seat becomes available (role Full only; details in Instance / QR coupling).

Software center

"Load catalog" shows the software catalog with a search field; "Rescan installed" checks what is already present on the computer. Installations (role Full only) run exclusively through the server-built job: the browser only picks a catalog entry — never a URL or a command. Even a compromised browser cannot sneak in foreign software.

"Helper update required" — what the hint means

If a function reports "helper update required", the installed helper lacks the matching endpoint (HTTP 501/404): screenshot and reboot need helper 2.0, the software catalog a newer version, heartbeat/mesh IP at least 1.9. After the helper's in-app update the functions appear by themselves — no value is ever fabricated.

Security

• Path whitelist: the platform forwards only a fixed list of helper endpoints — no open proxy.
• SSRF guard: the target is exclusively the mesh/LAN IP reported in the heartbeat — never an address from the browser request, never a public IP.
• Roles: viewing from View, controlling (screenshot, files, reboot, permissions) from Service, installing and uncoupling from Full.
• The site's kill switch blocks all helper access; controlling calls are recorded in the audit log.

Bitfocus Companion #

Das Sidebar-Modul Bitfocus Companion (Bereich Remote/Technik) verwaltet Companion-Instanzen einer Anlage — egal ob Companion in einer Proxmox-LXC dieser Box läuft oder auf einem beliebigen Rechner im Kundennetz.

Instanzen finden

„Companion im Netz suchen" prüft die Kandidaten aus dem letzten LAN-Scan der Anlage gegen Companions Web-Port (8000) — es wird nichts automatisch hinzugefügt, jeder Treffer muss einzeln bestätigt werden. Findet der Scan eine Instanz nicht (anderes Subnetz/VLAN, WLAN-Client-Isolation), hilft nur die manuelle IP-Eingabe.

Seit dem 29.07.2026 geht das auch ohne Firewall. Vorher hing die gesamte Companion-Erkennung am Firewall-Agenten einer Anlage. Anlagen ohne Firewall — nach heutiger Einschätzung rund 80 % — bekamen darum die irreführende Antwort „kein Onsite-Agent konfiguriert", obwohl Companion lief und aus der Onsite heraus sauber antwortete. Jetzt gilt eine Kette: Firewall-Agent, sonst die Proxmox-Verwaltung des Standorts, sonst der Scan-Cache. Geprüft wird über den generischen Onsite-Durchlass — denselben Weg, den Companion-GUI und Emulator-Auswahl ohnehin nehmen. Wo ein Firewall-Agent vorhanden ist, gewinnt er weiterhin; es gibt keinen Rückschritt.

Vier Befunde statt einer Sammelmeldung. Die Oberfläche unterscheidet jetzt: „auf <IP>:8000 antwortet nichts (die Onsite selbst ist erreichbar)", „Onsite antwortet nicht", „erreichbar, aber kein Companion auf Port 8000" und „Adresse ausserhalb ihrer Netze". Der Statusabruf antwortet dabei mit einem regulären Ergebnis samt Grund statt mit einem Fehler.

Instanz manuell hinzufügen

IP-Adresse (Pflicht), Port (Standard 8000), Label, optionales Lock-Passwort (falls Companions „Enable Locking" aktiv ist, verschlüsselt gespeichert) sowie optional Proxmox-Node/VMID — nur wenn gesetzt, erscheint der echte Update-Knopf.

Version, Konfig-Name, Erreichbarkeit

Version und API-Version kommen aus dem Satellite-Handshake (TCP-Connect auf Port 16622, liefert die Banner-Zeile BEGIN CompanionVersion=… ApiVersion=… ohne Auth). Der Konfig-Name ist Companions „Installation Name" (erscheint im Browser-Titel der Web-Admin). Diese Prüfungen laufen nie direkt von der Plattform aus — Companion hängt fast immer im privaten Kundennetz, ein Direkt-Connect würde praktisch immer „nicht erreichbar" liefern, selbst wenn die Instanz läuft.

Ohne Firewall-Agent kommt die Version auf einem anderen Weg. Der Satellite-Banner ist rohes TCP, das der Onsite-Durchlass nicht trägt; und Companion hat für die Version keinen eigenen HTTP-Endpunkt (die naheliegenden Adressen antworten mit 404 oder liefern nur die Oberfläche). UpNrun fragt darum Companions eigene interne Schnittstelle auf Port 8000 ab — sie liefert dieselbe Auskunft und geht durch den Durchlass. Am Standort belegt: Container gefunden, Durchlass liefert die Companion-Signatur, Version 5.0.0.

Nebenbei behoben: Companion 5 setzt seine Banner-Werte in Anführungszeichen; die Version kam dadurch mit Anführungszeichen an, und der Vergleich meldete immer ein verfügbares Update.

„IP-Konflikt prüfen": zeigen Version/Konfig-Name unerklärlich wechselnde Werte, kann das an einer doppelt vergebenen IP im Kundennetz liegen (zwei Geräte beanspruchen dieselbe Adresse). Der normale Scan kann das strukturell NICHT erkennen — er liest nur den passiven ARP-Cache des Betriebssystems, der immer nur eine MAC-Adresse pro IP zeigt. Der Knopf stößt stattdessen eine aktive Mehrfach-Probe an (mehrere Pings mit kurzem Abstand, ARP-Tabelle jeweils neu gelesen) und meldet einen Konflikt, sobald mehr als eine MAC-Adresse für dieselbe IP beobachtet wird.

Companion-GUI öffnen

Tunnelt die echte Companion-Web-Admin-Oberfläche in den Browser (gleicher Mechanismus wie der Q-SYS-Core-Manager-Tunnel) — für die automatisch erkannte Onsite-Instanz und für jede manuell hinzugefügte Instanz einzeln.

Was weiterhin einen Firewall-Agenten braucht

Der Konfigurations-Upload bleibt an den Firewall-Agenten gebunden — er ist ein mehrstufiger, überschreibender Vorgang und wird nicht über den allgemeinen Durchlass geführt. Die Oberfläche sagt das jetzt klar, statt „nicht konfiguriert" zu melden.

Update ausführen

Stößt das offizielle companionpi-Update (Branch stable, fest im Code hinterlegt — niemals aus Nutzereingabe) per SSH/pct exec auf dem Proxmox-Host an. Erscheint nur, wenn die Instanz einem Proxmox-Node/VMID zugeordnet ist. Root-Aktion auf Kunden-Infrastruktur — gleicher Zugriffsriegel wie VM-Power (Rolle Service, Kill-Switch), jeder Aufruf auditiert.

Satellite-Tunnel

Echtes 1-Klick, kein manueller NetBird-Client: Voraussetzung ist ein gekoppelter UpNrun-Inside-Helfer auf dem eigenen Rechner (Geräte → Rechner koppeln — derselbe Helfer, der auch für Remote-Desktop genutzt wird). Ein Klick auf „Satellite-Tunnel starten" gibt diesem bereits verbundenen Helfer-Peer kurzzeitig Zugriff auf die Companion-Instanz der Anlage (NetBird-Gruppenmitgliedschaft, kein neues Gerät, kein Setup-Key). Die Companion-Satellite-App (lokal auf demselben Rechner) auf die angezeigte Companion-IP:16622 zeigen lassen — das Stream Deck verhält sich danach, als hinge es direkt an der Kunden-Instanz. Zeitlich begrenzt (30 Min., verlängerbar durch erneuten Klick), jede Sitzung auditiert; „Tunnel beenden" entfernt den Helfer sofort wieder aus der Standort-Gruppe (er bleibt dabei regulär im Mesh, verliert nur den Zugriff auf diese eine Anlage). Ohne gekoppelten Helfer erscheint eine klare Fehlermeldung mit Verweis auf die Kopplung.

VPN — voller AV-Netz-Zugang #

Der Site-Tab VPN routet ein ganzes Netz der Anlage (z. B. 192.168.1.0/24) über das verschlüsselte UpNrun-Mesh zu dir: der OnSite-Pi wird Routing-Peer (Subnet-Route), und du erreichst danach jedes Gerät in diesem Netz — Touchpanels, Kameras, I/O, Switches — direkt über seine LAN-IP, als wärst du vor Ort. Ideal für Peripherie-Verwaltung, Firmware-Updates und Geräte-Discovery. Der Tab erscheint nur bei Anlagen mit gekoppeltem Pi.

Abgrenzung: Designer-Tunnel vs. VPN

Für den Q-SYS Core allein reicht der Designer-Tunnel im Q-SYS-Tab (Connect-by-IP) — er öffnet genau eine Verbindung zu einem Gerät. Der VPN-Modus öffnet dagegen das ganze Netz. Deshalb ist er strenger gegated.

Aktivieren — 1-Click mit Rückfrage

1. Netz wählen: das Dropdown bietet die benannten und erkannten Netze der Anlage an; alternativ ein Subnetz manuell als CIDR eingeben (z. B. 192.168.1.0/24).
2. LAN-Interface am Pi angeben (Standard eth0) — der Port, an dem das Zielnetz hängt.
3. „VPN-Zugang aktivieren" fragt ausdrücklich nach und nennt dabei das Netz und die Tragweite. Die Aktivierung ist idempotent — ein zweiter Klick richtet nichts doppelt ein.

Status

„Status laden" zeigt, ob das IP-Forwarding auf dem Pi an oder aus ist, und die Mesh-IP des Pi. Fehlerzustände werden ehrlich benannt: Sitzung abgelaufen, Rolle reicht nicht, Pi über das Mesh nicht erreichbar, Zeitüberschreitung.

Sicherheit und Risiken — bewusst einsetzen

• Nur Admin (Rolle Full) darf aktivieren; der Status ist ab Rolle Service einsehbar. Ein aktiver Kill-Switch sperrt den Zugriff (423).
• Jeder Zugriff wird auditiert — Aktivierung und Statusabfragen landen im Audit-Log.
• Volle Reichweite: nach der Aktivierung ist jedes Gerät des Netzes erreichbar — auch ungeschützte Management-Oberflächen alter AV-Geräte. Die Route deshalb wie einen Generalschlüssel behandeln: nur aktivieren, wenn sie gebraucht wird, und das gewählte Netz so eng wie möglich schneiden.
• Kein Dauerzustand als Default: die Pane bietet bewusst Status und Aktivierung — wer den Zugang nicht mehr braucht, sollte ihn auf dem Pi wieder abbauen lassen, statt ihn dauerhaft offen zu lassen.

VPN — full AV network access #

The site tab VPN routes an entire network of the installation (e.g. 192.168.1.0/24) to you over the encrypted UpNrun mesh: the OnSite Pi becomes a routing peer (subnet route), and you can then reach every device in that network — touch panels, cameras, I/O, switches — directly via its LAN IP, as if you were on site. Ideal for peripheral management, firmware updates and device discovery. The tab only appears for sites with a coupled Pi.

Scope: designer tunnel vs. VPN

For the Q-SYS core alone, the designer tunnel in the Q-SYS tab (connect-by-IP) is enough — it opens exactly one connection to one device. The VPN mode opens the whole network, which is why it is gated more strictly.

Enabling — one click with confirmation

1. Pick a network: the dropdown offers the site's named and detected networks; alternatively enter a subnet manually as CIDR (e.g. 192.168.1.0/24).
2. Specify the LAN interface on the Pi (default eth0) — the port the target network is attached to.
3. "Enable VPN access" asks explicitly, naming the network and the consequences. Activation is idempotent — a second click does not set anything up twice.

Status

"Load status" shows whether IP forwarding on the Pi is on or off, plus the Pi's mesh IP. Error states are named honestly: session expired, insufficient role, Pi not reachable over the mesh, timeout.

Security and risks — use deliberately

• Only admins (role Full) may enable it; the status is visible from role Service. An active kill switch blocks access (423).
• Every access is audited — activation and status queries land in the audit log.
• Full reach: once enabled, every device on the network is reachable — including unprotected management interfaces of older AV gear. Treat the route like a master key: enable it only when needed and cut the chosen network as narrowly as possible.
• Not a permanent default: the pane deliberately offers status and activation — when access is no longer needed, have the route removed on the Pi instead of leaving it open permanently.

Remote-Helper-Installation #

Der Remote-Helper ist eine kleine Anwendung auf einem Zielrechner, die Remote Desktop und tiefere Steuerung ermoeglicht.

• Installer (Windows .exe / macOS) wird aus der App/Platform bereitgestellt.
• Nach der Installation meldet sich der Helper am Standort an und wird in der Geraeteliste sichtbar.
• Zugriff bleibt rollen- und trust-gebunden.

Mesh-Beitritt & Admin-Freigabe (UAC)

Fuer die Fernwartung tritt der Helper dem UpNrun-Mesh bei. Unter Windows braucht das einmalig eine Admin-Freigabe (UAC), weil dabei der Netzwerk-Dienst registriert wird — der Installer erledigt das bereits waehrend der Installation.

Bei aelteren/portablen Installationen holt der Helper den Beitritt selbst nach: Ist der Rechner gekoppelt, aber nicht im Mesh, meldet sich der Helper beim Start von selbst in den Vordergrund und stoesst den Beitritt an — die Person am Rechner bestaetigt den UAC-Dialog mit Ja. Wichtig: Fernwartungs-Sitzungen sehen den UAC-Dialog nicht (Windows Secure Desktop), der Klick muss vor Ort passieren. Als Fallback gibt es im Reiter Verbindung den Button Mesh-Verbindung reparieren (Admin). Nach der einmaligen Freigabe haelt die automatische Selbstheilung die Verbindung dauerhaft — ohne weitere Nachfragen.

Alarme / Monitoring #

UpNrun ueberwacht Geraete kontinuierlich und meldet Abweichungen.

Seit dem 29.07.2026 entstehen Alarme auf der Onsite-Box und werden per Heartbeat an die Plattform gemeldet; die Plattform pollt eine meldende Anlage nicht mehr selbst. Gesehen, quittiert und abonniert werden sie unveraendert hier. Wie das im Uebergang wirkt und welche Monitorpunkte dabei entfernt wurden — insbesondere „PoE-Ueberlast" — steht unter Alarme entstehen am Standort (English).

Alarm-Zentrum

Das globale Alarm-Zentrum buendelt alle aktiven Alarme (offline, Schwellwerte, Sicherheits-Events) ueber alle Standorte. Von hier aus quittieren oder ins betroffene Geraet springen.

Benachrichtigungen

Alarme koennen per Telegram ausgeliefert werden (in den Settings konfigurierbar).

Kundenreport / Wochenbericht #

Der Kundenreport fasst alle Standorte und ihre Geraete in einem eigenstaendigen, gebrandeten HTML-Dokument zusammen — ideal zum Weitergeben an den Endkunden oder zum Archivieren. Produktname und Akzentfarbe des White-Label-Brandings praegen das Dokument.

Was der Report enthaelt

• Kopf mit Kennzahlen — aggregierte Uebersichts-Kacheln ueber alle Standorte (Geraete gesamt, online/offline, nicht erreichbare Standorte).
• Standorte nach Handlungsbedarf sortiert — nicht erreichbare Anlagen zuoberst, dann die mit den meisten Offline-Geraeten, damit Probleme sofort ins Auge fallen.
• Pro Standort — Online-Quote (»X von Y Geraeten online (Z%)«), Fortschrittsbalken, Pi-Adresse, Daten-Stand des zuletzt abgeschlossenen Scans (mit »(veraltet)«-Marker bei altem Scan) sowie eine Geraetetabelle mit Status, IP, Hostname, MAC und Notiz/Tags.

Der Report wird beim Aufruf unter der Adresse /app/report (Login erforderlich) live erzeugt — die Plattform fragt jeden Standort frisch ab. Der Download kommt als HTML-Datei (<Marke>_Kundenreport_JJJJMMTT.html): ein in sich geschlossenes Dokument ohne externe Abhaengigkeiten, das sich direkt im Browser oeffnen oder als PDF drucken laesst.

Automatischer Wochenbericht (E-Mail-Report)

Denselben Report kann die Plattform woechentlich automatisch per E-Mail versenden. Konfiguriert wird das unter Einstellungen → E-Mail-Report (nur fuer Administratoren):

• Aktiviert — schaltet den woechentlichen Versand ein.
• SMTP-Server — Host, Port (Standard 587 / STARTTLS), Benutzer und Passwort des Postausgangs.
• Absender & Empfaenger — Von-Adresse, kommagetrennte Empfaenger und ein optionales Betreff-Praefix (z.B. [UpNrun]).
• Versandzeitpunkt — Wochentag und Uhrzeit (Stunde).
• Jetzt senden (Test) — verschickt den Bericht sofort als Testmail, um SMTP-Zugang und Empfaenger zu pruefen.

Der Mail-Bericht nutzt exakt dieselbe Aufbereitung wie der manuelle Kundenreport — Inhalt und Optik bleiben identisch.

Info-Seiten / QR-Codes / White-Label #

Jedes Geraet kann eine oeffentliche, login-freie Info-Seite erhalten, deren Adresse ein opaker QR-Code ist (/info/<token>) — ohne Standort, IP, Hostname oder MAC im Link. Der QR-Code wird auf das Geraete-Etikett gedruckt (siehe Labels / Etiketten); wer ihn vor Ort scannt, sieht Status, Kurzmanual und hinterlegte Dokumente — mit dem Logo und der Marke des Integrators statt der UpNrun-Marke.

Was der Scan zeigt (die oeffentliche Info-Seite)

• Geraete-Eckdaten — Name, Typ, Hersteller/Modell und Kategorie (alles bewusst neutral, kein Netz-Leak: nie Standort, IP, Hostname oder MAC).
• Neutraler Status — online/offline als Ampel, live per Poller aktualisiert.
• Info-/Kurzmanual — ein frei hinterlegbarer Text (bis 6000 Zeichen) mit »Stand: TT.MM.JJJJ«-Datum, damit der Techniker sieht, wie aktuell die Angaben sind.
• Datei-Downloads — hinterlegte PDFs/Handbuecher zum direkten Oeffnen oder Herunterladen.
• Neutraler Rechts-Footer — Impressum/Datenschutz/Nutzungsbedingungen/Barrierefreiheit unter der Integrator-Marke.

Ein anonymer Scan sieht die Seite nur lesend. Ein eingeloggter Service-Nutzer bekommt zusaetzlich ein Bearbeiten-Feld (Kurzmanual pflegen, Dateien hochladen/loeschen — rollen-gated und auditiert). Die Seite traegt noindex und ist gegen Massenaufrufe ratenbegrenzt.

Info-Seiten verwalten

Ueber »Info-Seiten verwalten« beim Standort (Adresse /app/site/<id>/info-pages) werden die Seiten pro Geraet verwaltet. Info-Seiten entstehen nur auf Wunsch — ein deaktivierter Link ist sofort tot.

• Info-Seite generieren — legt fuer ein Geraet Seite und Token an; danach stehen Link kopieren, Etikett drucken (QR-Etikettenbogen), QR herunterladen (SVG) und Deaktivieren zur Verfuegung.
• Aktivieren/Deaktivieren — schaltet den oeffentlichen Link scharf bzw. sofort tot, ohne die Seite zu loeschen.
• Filter & Suche — Chips Alle / Mit Seite / Aktiv / Ohne Seite und Volltextsuche nach Name, IP, MAC oder Typ.
• CSV-Export und Drucken / Als PDF — die sichtbare Liste als Info-Seiten-Verzeichnis (Geraet, Status, oeffentlicher Link) sichern.

White-Label / Marke einstellen

Die White-Label-Einstellungen liegen im Admin-Cockpit (/app/admckpt, nur fuer Administratoren). Sie gelten global (fuer alle Anlagen ohne eigene Konfiguration) oder pro Enterprise-Kunde (nur fuer dessen Anlagen; leere Felder fallen auf global zurueck):

• Oeffentliche Domain — der Host, mit dem die aufgedruckten Info-/QR-Links erscheinen (z.B. die eigene Integrator-Domain).
• Helpdesk-Domain — Ziel des Helpdesk-Ticket-QR (/t/new/<token>). Leer lassen = der Helpdesk-QR wird nicht gedruckt (kein toter Code).
• Marke / Produktname — erscheint im Browser-Titel, in der Link-Vorschau (Messenger) und im Footer der Info-Seite; nur pro Enterprise-Kunde ueberschreibbar, max. 80 Zeichen.
• Integrator-Logo — als Bild hochladen (PNG/JPG/WebP): waehlen oder per Drag&Drop ablegen, im eingebauten Editor zuschneiden (ziehen zum Verschieben, Regler zum Zoomen), fertig. Das Bild wird serverseitig verkleinert und von Metadaten bereinigt. Logos duerfen breit oder hoch sein — Info-Seite und Etiketten passen sich an. Erscheint auf der Info-Seite und auf den Etiketten anstelle des UpNrun-Logos. (Fuer Vektorlogos gibt es weiterhin das SVG-Textfeld unter „Fortgeschritten".)

Eine Live-Vorschau zeigt schon vor dem Speichern, wie Info-Link, Helpdesk-Link und Titel/Link-Vorschau mit den eingetragenen Werten aussehen.

Helpdesk / Support / Tickets #

UpNrun bindet einen externen Helpdesk an und buendelt dessen Tickets direkt in der Plattform. Das Anlegen und Bearbeiten der Vorgaenge bleibt im Helpdesk selbst; die Plattform zeigt sie rein lesend an und verlinkt jeweils auf den vollstaendigen Vorgang. Faellt der Helpdesk aus oder ist er noch nicht angebunden, laeuft alles fail-soft weiter — es erscheint ein freundlicher Hinweis statt eines Fehlers.

Support-Uebersicht (alle Tickets)

Unter der Adresse /app/support (Login erforderlich) liegt die plattformweite Helpdesk-Uebersicht:

• Kennzahlen-Kacheln — Offen (neu / in Arbeit), Ausstehend (wartet auf den Melder), Geloest (geschlossen) und Gesamt ueber alle Tickets.
• Ticket-Tabelle — Referenz, Status- und Prioritaets-Badge, Betreff, Melder, Standort, Zugewiesen und Erstell-Datum. Die Referenz verlinkt direkt in den Helpdesk-Posteingang.
• Im Helpdesk oeffnen — fuer den Master-Administrator ein SSO-Link (kein zweites Passwort), fuer alle anderen der normale Helpdesk-Login.

Support-Tab pro Anlage

Jede Anlage hat im Site-View den Tab »Support« — sichtbar fuer jeden mit Zugriff auf die Anlage. Er zeigt die Tickets dieser Anlage, gebuendelt und rein lesend:

• Suche & Filter — Volltextsuche (Referenz / Betreff / Melder), Status-Filter (Offen / Ausstehend / Geloest) und Prioritaets-Filter (Dringend / Hoch / Normal / Niedrig) sowie anklickbare Status- und Prioritaets-Schnellfilter.
• Sortierbare Tabelle — die 7 Spalten (Ref, Status, Prioritaet, Betreff, Melder, Zugewiesen, Datum) lassen sich per Spaltenkopf sortieren; am Handy scrollt die Tabelle horizontal statt zu quetschen.
• Neues Ticket — oeffnet den Helpdesk mit vorbefuelltem Anlagen-Betreff. Aus ueberfaelligen Wartungen laesst sich mit einem Klick ein passendes Ticket anstossen.
• CSV / Drucken — die aktuelle (gefilterte) Ticket-Ansicht als CSV exportieren oder als PDF drucken.

Ticket-QR pro Anlage

Oben im Support-Tab liegt der Ticket-QR dieser Anlage zum Aufkleben oder Ausdrucken. Ein Scan oeffnet ein vorausgefuelltes Ticket-Formular fuer genau diese Anlage. Der Link ist neutral (kein Standort, keine IP sichtbar, Form /t/new/<token>) und nutzt die White-Label-Helpdesk-Domain, falls hinterlegt (siehe Info-Seiten / QR-Codes / White-Label).

• Formular oeffnen, Link kopieren, QR herunterladen (SVG) und Drucken stehen direkt an der QR-Karte bereit.
• Aktivieren / Deaktivieren — schaltet den Helpdesk-QR dieser Anlage scharf bzw. aus. Deaktiviert fuehren bereits aufgeklebte Codes zu keinem Ticket mehr (kein toter Aufkleber, der ins Leere laeuft).

Ist keine Helpdesk-Domain konfiguriert, waere der QR-Link nur ein nackter Pfad und beim Scannen wertlos — in dem Fall blendet die Plattform die QR-Karte bewusst aus, statt einen kaputten Code zu drucken.

Die folgenden Abschnitte dokumentieren die Funktionen, die im Helpdesk selbst (nach »Im Helpdesk oeffnen«, siehe oben) zur Verfuegung stehen — die Plattform zeigt Tickets nur lesend an, bearbeitet werden sie im Helpdesk.

Tags & gespeicherte Ansichten

Im Helpdesk selbst lassen sich Tickets mit frei benannten Tags versehen (Eingabefeld im Ticket-Kopf, Enter oder »+«). Vergebene Tags erscheinen als kleine Pills unter dem Betreff, ein Klick auf einen Tag setzt sofort den passenden Filter in der Inbox. Zusaetzlich laesst sich die aktuelle Filterkombination aus Status, Prioritaet, Suchtext und Tag als benannte gespeicherte Ansicht sichern — pro Mitarbeiter individuell, mit einem Klick wieder abrufbar.

Beteiligte (CC)

Neben Melder und Bearbeiter lassen sich weitere Beteiligte auf ein Ticket setzen: ein Team-Follower ist ein Kollege aus der Firma des Tickets und bekommt bei Kundenantwort oder Statuswechsel eine interne Benachrichtigung; ein CC ist eine freie externe E-Mail-Adresse und bekommt dieselbe oeffentliche Antwort-Mail wie der Melder mit. Beide erscheinen als entfernbare Pills im Ticket-Kopf.

Bulk-Makro & Export

In der Inbox lassen sich mehrere Tickets ankreuzen und in einem Schritt bearbeiten: Status aendern, Prioritaet aendern oder ein Makro anwenden — wahlweise als interne Notiz oder als oeffentliche Antwort an alle angehakten Melder gleichzeitig. Makros werden zentral gepflegt und stehen firmenuebergreifend zur Verfuegung. Ein CSV-Export liefert genau die aktuell gefilterte Ticket-Ansicht (bis 5000 Zeilen), praktisch fuer Reports ausserhalb des Helpdesks.

Zusammenfuehren, Abspalten & Duplikat-Vorschlaege

Zwei Tickets desselben Melders lassen sich dauerhaft zusammenfuehren; alle weiteren Nachrichten laufen dann im Ziel-Ticket zusammen. Umgekehrt laesst sich eine einzelne Nachricht in ein neues, eigenstaendiges Ticket abspalten — etwa wenn der Melder in einem Thread ein zweites, unabhaengiges Problem anspricht. Zusaetzlich schlaegt der Helpdesk automatisch moegliche Duplikate vor (gleicher Melder oder aehnlicher Betreff), jeweils mit direktem Zusammenfuehren-Knopf.

KI-Zusammenfassung

Ist im Helpdesk ein Anthropic-Key hinterlegt, erscheint im Ticket-Detail eine Karte »KI-Zusammenfassung«: ein Klick fasst den gesamten bisherigen Verlauf (Antworten, interne Notizen, Statuswechsel) automatisch in wenigen Saetzen zusammen — praktisch, um sich schnell in ein langes, aelteres Ticket einzulesen. Das Ergebnis wird gespeichert und laesst sich jederzeit erneut anstossen. Ohne konfigurierten Key bleibt das Feature komplett unsichtbar.

Geschaeftszeiten-SLA

Pro Firma laesst sich im Helpdesk festlegen, in welchem Zeitfenster die SLA-Uhr ueberhaupt laeuft: Zeitzone, Start-/Endzeit und Arbeitstage. Ist die Funktion aktiv, pausiert die Frist ausserhalb dieser Zeiten (nachts, am Wochenende) — ein Ticket, das freitagabends eingeht, »altert« uebers Wochenende nicht. Deaktiviert laeuft die Frist rund um die Uhr weiter.

Wiederkehrende Tickets

Aus Vorlagen lassen sich automatisch echte Tickets erzeugen — z.B. ein monatlicher Wartungs-Check fuer eine bestimmte Anlage. Jede Vorlage hat Titel, Beschreibung, Prioritaet, optional eine Site sowie ein Intervall in Tagen und ein Startdatum; ein stuendlicher Hintergrund-Job prueft faellige Vorlagen und legt bei Faelligkeit automatisch ein neues Ticket an. Vorlagen lassen sich jederzeit pausieren oder loeschen.

Ticket-Formulare / Custom-Fields

Pro Firma lassen sich Zusatzfelder definieren, die auf dem oeffentlichen Ticket-Formular der Kunden erscheinen (z.B. Vertragsnummer, Abteilung als Auswahlliste). Jedes Feld hat Label, Typ, eine Pflicht-Markierung und eine Reihenfolge. Ausgefuellte Werte erscheinen im Ticket-Detail als eigener Block »Formularangaben«; ohne Zusatzangaben bleibt der Block ausgeblendet.

Wissensbasis & KB-Feedback

Jede Firma pflegt eigene oeffentliche Hilfe-Artikel (Titel, Kategorie, Inhalt, veroeffentlicht/Entwurf), die in der Volltextsuche des oeffentlichen Ticket-Formulars vorgeschlagen werden — im Idealfall findet der Kunde die Antwort, bevor er ueberhaupt ein Ticket eroeffnet. Jeder Artikel zeigt am Ende die Frage »War das hilfreich?«; das gesammelte KB-Feedback wird in der Verwaltungsliste als Bilanz je Artikel angezeigt, damit schwache Artikel auffallen.

Einstellungen-Tabs

Der Einstellungen-Bereich des Helpdesks ist in Tabs gegliedert; admin und company_admin sehen dieselben Firmen-Tabs, nur admin zusaetzlich die globale Gruppe »Verwaltung«. Neben Geschaeftszeiten, Wiederkehrend und Formularfeldern (siehe oben) liegen hier: E-Mail-Versand (SMTP-Zugangsdaten fuer ausgehende Antworten), E-Mail-Vorlage (Branding von Kopf-/Fusszeile mit Live-Vorschau), Sites (mit der Plattform synchronisiert oder manuell gepflegt), Team & Einladungen (Zugriff, Rolle, Site-Einschraenkung), FAQ (kurze Frage/Antwort-Paare im oeffentlichen Formular) und Automatisierung (Regeln, die beim Anlegen eines Tickets automatisch Prioritaet oder Zuweisung setzen).

Embed / White-Label

Das Embed-Studio (nur admin) erzeugt pro Firma ein White-Label-Token mit eigenem Branding (Anzeigename, Akzentfarbe, Logo, optionaler Origin-Lock). Daraus entstehen zwei fertige Einbettungs-Schnipsel fuer die Website des Kunden: eine Script-Einbettung, die das Ticket-Formular direkt in die Kundenseite rendert, und eine iframe-Einbettung fuer Baukasten-Systeme ohne Skript-Unterstuetzung. Tokens lassen sich jederzeit widerrufen, ohne dass der eingebettete Code auf der Kundenseite geaendert werden muesste. Fuer die eigentliche Helpdesk-Domain (fuer Ticket-QR und oeffentliche Formulare) siehe Info-Seiten / QR-Codes / White-Label.

Kanban / Aufgabenboard #

Jede Anlage hat im Site-View den Tab »Kanban« — ein Aufgabenboard, das die Arbeit an dieser Anlage von Bau ueber Inbetriebnahme bis Betrieb / Wartung begleitet. Aufgaben werden als Karten auf Spalten verteilt und per Drag & Drop weitergeschoben; alles wird sofort gespeichert. Lesen darf jeder mit Zugriff auf die Anlage, Bearbeiten ab der Service-Rolle, Loeschen ab der naechsthoeheren Rolle.

Spalten & Board

Ab Werk gibt es fuenf Spalten — Backlog, Bau, Inbetriebnahme, Betrieb / Wartung und Erledigt. Jede Spalte zeigt oben ihre Kartenanzahl. Ueber »Spalten« (Zahnrad) lassen sich Spalten umbenennen, per ▲▼ neu anordnen, hinzufuegen oder loeschen — Karten aus einer geloeschten Spalte wandern automatisch in die erste, gehen also nie verloren. Optional laesst sich pro Spalte ein WIP-Limit (maximale Kartenzahl) setzen; wird es ueberschritten, faerbt sich die Spalte zur Warnung. Das WIP-Limit gilt lokal je Browser.

Karten anlegen & bearbeiten

Ueber die Leiste oben legst du eine Karte an: Titel, Ziel-Spalte, freier Tag, Faelligkeit (Datum), Zuweisung an einen Mitarbeiter und eine Farbe (sechs Farben zur Auswahl). Ein Klick auf eine Karte oeffnet den Bearbeiten-Dialog mit zusaetzlich:

• Beschreibung — mehrzeiliger Notiztext zur Aufgabe.
• Fortschritt — Regler von 0 bis 100 %, als Balken auf der Karte sichtbar.
• Kommentare / Aktivitaet — Verlauf mit Autor und Text; neue Kommentare per Knopf oder Strg/Cmd+Enter.

Faelligkeit, »nur meine« & Sortierung

Karten mit gesetzter Faelligkeit, die noch nicht in der letzten Spalte liegen und deren Termin ueberschritten ist, werden als ueberfaellig hervorgehoben (rote Faelligkeit, roter Spaltenzaehler). Der Filter »nur meine« blendet auf die dir zugewiesenen Karten ein, und »nach Faelligkeit sortieren« ordnet die Karten innerhalb jeder Spalte nach Termin.

Export & Kalender-Abo

Das Board laesst sich als A4-PDF drucken/speichern oder als CSV (Excel/Tabelle) exportieren — beides rein lokal. Ueber »Kalender abonnieren« liefert die Plattform einen token-geschuetzten ICS-Feed (webcal), sodass die Aufgaben mit Faelligkeit in Outlook, Apple Kalender oder Google Kalender laufend erscheinen. Der Abo-Link laesst sich kopieren und der Token bei Bedarf neu erzeugen (macht das alte Abo ungueltig).

Wartungsplan / Wartung #

Jede Anlage hat im Site-View den Tab »Wartung« — einen Wartungsplan fuer wiederkehrende Service-Termine (z. B. Quartalswartung, Filterwechsel, Firmware-Check). Statt an Termine zu denken, legst du Intervalle fest; die Plattform berechnet die naechste Faelligkeit selbst und schiebt ueberfaellige Punkte nach oben. Lesen darf jeder mit Zugriff auf die Anlage, Bearbeiten ab der Service-Rolle, Loeschen ab der Rolle Full.

Termin anlegen

Ueber das Formular oben (nur ab Service-Rolle sichtbar) legst du einen Wartungs-Termin an:

• Was — kurzer Titel der Taetigkeit, z. B. »Quartalswartung Q-SYS Core«.
• Geraet (optional) — auf welches Geraet sich die Wartung bezieht.
• Intervall — eine ganze Zahl (1 bis 9999) plus Einheit Tage, Wochen, Monate oder Jahre.
• Start / Basis — ab welchem Datum gerechnet wird (Basis fuer die erste Faelligkeit).
• Notizen / Checkliste (optional) — mehrzeiliger Text mit Arbeitsschritten.

Zu lange Eingaben werden bereits vor dem Speichern gemeldet (Titel bis 160, Geraet bis 120, Notiz bis 2000 Zeichen), damit nichts still gekuerzt wird.

Faelligkeits-Ampel & Uebersicht

Die naechste Faelligkeit ergibt sich automatisch aus letzter Erledigung (oder dem Start-Datum) plus Intervall — kein Hintergrund-Job noetig, die Berechnung erfolgt bei jedem Aufruf. Jeder Termin traegt eine farbige Ampel:

• ueberfaellig (rot) — der Termin liegt in der Vergangenheit.
• bald faellig (gelb) — faellig innerhalb der naechsten 7 Tage.
• geplant (gruen) — Faelligkeit liegt weiter in der Zukunft.
• pausiert (grau) — Termin ist voruebergehend deaktiviert und wird nicht gezaehlt.

Ueber der Liste zaehlen drei Uebersicht-Chips, wie viele Termine ueberfaellig, bald faellig bzw. geplant sind. Die Liste ist so sortiert, dass ueberfaellige zuerst stehen, danach nach Faelligkeit; pausierte und Termine ohne Datum wandern ans Ende.

Erledigt quittieren & Bruecke zum Service-Tagebuch

Ein Klick auf »Erledigt« quittiert den Termin: die letzte Erledigung wird auf heute gesetzt und das Intervall rollt automatisch weiter zur naechsten Faelligkeit. Dabei kannst du eine optionale Notiz eingeben (bis 1500 Zeichen) — diese wird als Eintrag direkt ins Service-Tagebuch geschrieben, sodass eine lueckenlose Historie entsteht. Laesst du die Notiz leer, wird die Wartung nur quittiert.

Bearbeiten, pausieren, loeschen

Je Termin gibt es (ab Service-Rolle) die Aktionen Bearbeiten (Titel, Geraet, Intervall, Start und Notizen aendern), Pause / Aktiv (Termin voruebergehend stilllegen, ohne ihn zu verlieren) und — ab Rolle Full — Loeschen. Der Loesch-Dialog nennt den Titel des Termins, damit bei mehreren aehnlichen Eintraegen nicht der falsche geloescht wird.

Erinnerungen & Kalender-Feed

Ueberfaellige und bald faellige Wartungen erscheinen automatisch in der Benachrichtigungs-Glocke oben in der Topbar — gebuendelt ueber alle Standorte, auf die du Zugriff hast. Zusaetzlich fliessen die Faelligkeiten in den token-geschuetzten ICS-Kalender-Feed ein, sodass sie in Outlook, Apple Kalender oder Google Kalender neben den Kanban-Terminen laufend sichtbar sind.

Service-Tagebuch #

Jede Anlage hat im Site-View den Tab »Service-Tagebuch« — eine lueckenlose Wartungs- und Einsatz-Historie: wer war wann dran, was wurde gemacht, welche Teile oder Einstellungen wurden geaendert. Eintraege werden nur angehaengt und bleiben dauerhaft erhalten (fuer Uebergabe, Reklamation und wiederkehrende Wartung). Lesen darf jeder mit Zugriff auf die Anlage, Schreiben (Eintrag anlegen, Foto anhaengen) ab der Service-Rolle, Loeschen ab der Rolle Full.

Eintrag anlegen

Ueber das Formular oben legst du einen neuen Eintrag an. Der Autor (eingeloggter Nutzer) und der Zeitstempel werden automatisch vom Server gesetzt; neue Eintraege erscheinen sofort oben in der Liste (neueste zuerst):

• Art — eine von vier Kategorien mit eigener Farbe und Symbol: Wartung (blau, Schraubenschluessel), Stoerung (rot, Warndreieck), Aenderung (gelb, Stift) oder Notiz (grau, Vorgabe).
• Geraet (optional) — auf welches Geraet sich der Eintrag bezieht (bis 120 Zeichen).
• Text — was gemacht wurde, mehrzeilig (bis 4000 Zeichen). Cmd/Strg+Enter speichert direkt aus dem Textfeld.

Zu lange Eingaben werden bereits vor dem Speichern gemeldet, damit nichts still gekuerzt wird.

Fotos und PDF anhaengen

Jeder Eintrag hat einen »Foto«-Button, ueber den sich Bilder oder PDF anhaengen lassen — ideal fuer Vorher/Nachher-Fotos, Typenschilder oder Messprotokolle direkt vom Handy. Erlaubt sind jpg, png, gif, webp, heic und PDF, bis 15 MB pro Datei und maximal 12 Anhaenge pro Eintrag. Bilder erscheinen als Vorschau-Kacheln, andere Dateien als Datei-Symbol; ein Klick oeffnet das Original. Die Dateien liegen getrennt auf dem Server (nie im Code-Repo), der Eintrag traegt nur die Metadaten. Anhaenge einzeln entfernen darf die Rolle Full.

Durchsuchen und filtern

Ueber der Liste kannst du den Verlauf eingrenzen: Volltext-Suche (durchsucht Text, Autor und Geraet), Filter nach Art sowie ein Zeitraum von/bis (Datumsfelder, jeweils inklusiv; »Zeitraum« setzt ihn zurueck). Ein Zaehler zeigt, wie viele der gesamten Eintraege gerade angezeigt werden.

Export: CSV und PDF

Die aktuell gefilterte Ansicht laesst sich als CSV (Excel-tauglich, UTF-8, Spalten Datum / Art / Geraet / Autor / Text) oder als PDF zum Drucken exportieren — beides rein im Browser, es verlaesst kein Byte den Rechner ungefragt. Der Loesch-Dialog nennt Datum und Textanfang des Eintrags, damit bei mehreren aehnlichen Eintraegen nicht der falsche geloescht wird.

Bruecken zu Wartung, Geraet und Audit

Das Tagebuch ist mit anderen Bereichen verzahnt: Beim Erledigt-Quittieren im Wartungsplan wird eine optionale Notiz direkt als Eintrag hier abgelegt. In der Geraeteliste bzw. im Geraete-Detail oeffnet der »Verlauf«-Button die auf dieses Geraet gefilterte Historie (mit Badge = Anzahl der Eintraege). Anlegen, Loeschen und Anhaengen werden zudem im Audit-Log protokolliert.

Stammdaten & Kontakte #

Jede Anlage hat im Site-View den Tab »Stammdaten« — das Objekt-Stammblatt mit allem, was ein Servicetechniker vor Ort griffbereit braucht: Adresse, Zugang/Schluessel, Notdienst, Vertrag/Garantie, Notizen und die wichtigsten Ansprechpartner. Diese Angaben stehen an einem Ort statt in verstreuten Excel-Tabellen. Lesen darf jeder mit Zugriff auf die Anlage; der Button »Bearbeiten« erscheint erst ab der Service-Rolle (auch das Speichern ist serverseitig auf diese Rolle beschraenkt).

Objekt-Felder

Die Karte zeigt nur ausgefuellte Felder an; im Bearbeiten-Modus stehen alle zur Verfuegung (mehrzeilig, ausser dem Objekt-Titel):

• Objekt / Gebäude — kurze Bezeichnung der Anlage, z. B. »Kurtheater Baden — Buehnenturm« (bis 200 Zeichen).
• Adresse — Strasse und Ort, mehrzeilig (bis 600 Zeichen).
• Zugang / Schlüssel — Schluessel-Nr., Zugangscode, Anmeldung beim Hauswart (bis 2000 Zeichen).
• Notdienst / Bereitschaft — Notfall-Telefon und Bereitschaftszeiten (bis 600 Zeichen).
• Vertrag / Garantie — Vertragsnummer, Laufzeit, Garantie-Ende, Anbieter (bis 1000 Zeichen).
• Notizen — sonstige wichtige Hinweise zur Anlage (bis 3000 Zeichen).

Zu lange Eingaben werden bereits vor dem Speichern gemeldet (mit Feld-Name und Zeichenzahl), damit nichts still vom Server gekuerzt wird — du kuerzt selbst, statt einen abgeschnittenen Eintrag zu bekommen.

Ansprechpartner

Unter den Objekt-Feldern pflegst du beliebige Ansprechpartner (bis 50 je Anlage). Jede Zeile hat Name, Rolle/Funktion, Telefon, E-Mail und eine Notiz; mit »Kontakt« fuegst du eine Zeile hinzu, das X entfernt sie wieder. Komplett leere Zeilen werden beim Speichern verworfen. In der Lese-Ansicht erscheint jeder Kontakt als Kachel — die Telefonnummer ist als Anruf-Link (tel:) und die E-Mail als Mail-Link (mailto:) hinterlegt, ideal fuer den direkten Griff zum Handy vor Ort.

Das E-Mail-Feld gibt sofort beim Tippen Rueckmeldung: es faerbt sich gruen bei gueltiger und rot bei ungueltiger Adresse (dieselbe Pruefung wie beim Speichern). So siehst du den Fehler direkt an der Zeile, statt erst eine Sammelmeldung zu bekommen.

Bearbeiten und Speichern

Ein Klick auf »Bearbeiten« oeffnet die Maske; »Abbrechen« verwirft die Aenderungen. Cmd/Strg+Enter speichert direkt aus jedem Feld (blankes Enter bleibt in den mehrzeiligen Feldern ein Zeilenumbruch). Nach dem Speichern zeigt die Karte unten »Zuletzt aktualisiert« mit Benutzer und Zeitstempel. Laedt die Seite mit abgelaufener Sitzung, kommt eine ehrliche Meldung (»Sitzung abgelaufen — bitte neu anmelden«) statt einer leeren Karte, die so aussaehe, als waere nie etwas erfasst.

Die Stammdaten liegen im Plattform-Store der Anlage (kein Scan-Pfad, keine Geraete-Kopplung); jedes Speichern wird im Audit-Log protokolliert.

Auswertung / Zeitreihen #

Der Site-View-Tab »Auswertung« zeigt den Zeitreihen-Verlauf einer Anlage in einem zoom- und pan-baren Chart im TradingView-Look (Crosshair, Legende zum Ein-/Ausblenden einzelner Kurven). Die Daten sind echt mitgeschrieben: der Plattform-Poll-Loop legt rund alle 2 Minuten einen Messpunkt ab. Lesen genuegt hier die Anlagen-Sicht — jeder mit Zugriff auf die Anlage kann die Auswertung oeffnen.

Was aufgezeichnet wird

Zwei echte Quellen speisen den Chart. Erstens die Geraete-History dieser Anlage:

• Online-Geräte — Zahl der erreichbaren Geraete ueber Zeit (gruen, standardmaessig sichtbar).
• Offline-Geräte — Zahl der nicht erreichbaren Geraete (rot, standardmaessig ausgeblendet, da meist 0 — bei Bedarf ueber die Legende einschaltbar).
• Geräte gesamt — Gesamtzahl der bekannten Geraete (blau).
• Online-Quote (%) — abgeleitet aus Online / Gesamt×100, also die Verfuegbarkeit der Anlage. Sie liegt auf einer eigenen 0–100 %-Achse rechts (gelb, standardmaessig sichtbar).

Zweitens — sobald ein Rechner-Helper erreichbar ist — dessen System-Last je Computer: CPU-, RAM- und Disk-Belegung (%) auf der Prozent-Achse rechts sowie der Netz-Durchsatz (Netz I/O, Empfang + Senden) auf einer eigenen Byte/s-Achse (menschenlesbar als B/s · KB/s · MB/s). Jeder Rechner behaelt eine feste Farbe, seine Kennzahlen unterscheiden sich per Linienstil (CPU durchgezogen, RAM gestrichelt, Disk gepunktet, Netz Strich-Punkt). Standardmaessig sichtbar ist pro Rechner nur die CPU; RAM, Disk und Netz schaltest du bei Bedarf in der Legende zu, damit das Chart nicht sofort ueberladen ist.

Das Chart zeigt maximal 10 Kurven gleichzeitig. Schneidet dieses Limit weitere Helfer-Mess-Serien ab (Standort mit mehreren Rechnern), meldet die Statuszeile das ehrlich (»N weitere Helper-Mess-Serien wegen Chart-Limit ausgeblendet«) statt sie stillschweigend wegzulassen.

Zeitbereich, Aufloesung und Frische

Ueber die Buttons oben waehlst du das Zeitfenster: 1 h (feine Aufloesung zum Live-Mitschauen waehrend einer Vorstellung), 24 h, 7 Tage (Standard) oder 30 Tage. Die Wahl wird pro Anlage gemerkt, sodass sie beim naechsten Oeffnen erhalten bleibt. Die Aufloesung passt sich automatisch an (Ziel ~600 Stuetzstellen); die Statuszeile nennt die tatsaechlichen Werte: Messpunkte · Aufloesung ~X s · Zeitfenster · aktualisiert HH:MM.

»Aktualisieren« laedt die Daten von Hand neu — der Knopf dreht sich und ist waehrend des Ladens gesperrt, damit sich keine Requests stapeln. Der »Live«-Knopf laedt automatisch alle 30 Sekunden nach, sodass neue Messpunkte wie in einem Live-Chart erscheinen. Live pausiert von selbst, wenn der Tab im Hintergrund liegt oder die Pane nicht offen ist. Ein aktiver Live-Modus pulsiert rot; scheitert ein Live-Tick (Netzwerk-Aussetzer mitten in der Vorstellung), wechselt der Knopf in eine ruhige bernsteinfarbene Warn-Optik ohne Puls — so wirkt ein eingefrorener Chart nie faelschlich »live«.

CSV-Export und Legende

»CSV« exportiert den aktuell geladenen Zeitreihen-Verlauf als Tabelle (oeffnet in Excel/Numbers): je eine Spalte fuer ISO-Zeit und lokale Zeit (mit UTC-Offset im Kopf), dann eine Spalte je Serie. Der Dateiname enthaelt Anlagenname, Zeitfenster und Datum. In der Legende ein- oder ausgeblendete Kurven bleiben ueber »Aktualisieren« und Zeitbereich-Wechsel hinweg erhalten (pro Anlage gemerkt), sodass deine Ansicht beim Nachladen nicht zuruecksetzt.

Ehrliche Leerzustaende

Hat eine Anlage noch keine passenden Messpunkte, sagt die Pane genau, warum: »Keine Messpunkte in diesem Zeitfenster« (mit Hinweis, einen groesseren Bereich zu waehlen) wenn anderswo bereits Daten liegen; »Noch keine Zeitreihen-Daten« wenn ueberhaupt noch nichts aufgezeichnet wurde (der Poll sammelt ab jetzt); und »Zeitreihen-Aufzeichnung nicht verfuegbar« wenn die Logging-Engine auf diesem Server nicht aktiv ist — dann bringt auch spaeteres Nachschauen nichts. So wartet niemand auf Daten, die nie kommen.

Anlagen-Akte / Steckbrief #

Der Site-View-Tab »Akte« stellt aus den Live-Daten einer Anlage einen druckfertigen Steckbrief zusammen — Geraete, Wartungsplan, offene Aufgaben, Service-Tagebuch und Q-SYS-Status auf einen Blick, als sauberes A4-Dokument zum Ausdrucken oder als PDF. Die Akte ist rein lesend: sie aggregiert im Browser die bereits vorhandenen, rollen-geprueften Datenquellen (Geraete-Scan, Wartung, Kanban, Service-Tagebuch, Q-SYS) zu einem Querschnitt. Es wird kein neuer Server-Weg beschritten und beim Drucken verlaesst kein einziges Byte den Rechner — das Dokument entsteht lokal im Browser (window.print).

Was im Dokument steht

Der Kopf nennt Anlagenname, den Untertitel »Anlagen-Steckbrief · Service-Akte«, (falls bekannt) das Subnetz sowie rechts den Stand (Erzeugungs-Zeitpunkt) und den Produktnamen. Darunter eine Kennzahlen-Leiste: Geräte gesamt, online (gruen), offline (rot, wenn > 0), offene Aufgaben, überfällige Wartung (rot, wenn > 0) und Zahl der Tagebuch-Einträge. Es folgen fuenf Abschnitte:

• Geräte — Tabelle Gerät / IP / Typ / Status, online zuerst und dann nach Name sortiert. Sehr grosse Anlagen werden bei 250 Zeilen gekappt (mit ehrlichem »… und N weitere Geräte«-Hinweis, vollstaendig in der Geräteliste).
• Wartungsplan — Wartung / nächste Fälligkeit / Status mit Ampel-Badge (überfällig rot, bald fällig gelb, geplant gruen, pausiert grau) und Restzeit in Klartext (»heute«, »morgen«, »in N Tg.«, »seit gestern«).
• Offene Aufgaben — die noch nicht erledigten Kanban-Karten (Aufgabe / Phase / Zuständig / fällig / Fortschritt), nach Faelligkeit sortiert.
• Q-SYS · KNX — die konfigurierten Q-SYS-Core-Eckdaten (Modell, Design, Status, Rolle, Firmware, Core-IP), sofern ein Core hinterlegt und erreichbar ist. KNX-Telegramme sind bewusst nicht als eingefrorener Snapshot enthalten — sie laufen live im Bus-Monitor des OnSite-Tabs.
• Service-Tagebuch — die neuesten 15 Einträge als Karten mit Art-Badge (Wartung / Störung / Änderung / Notiz), Geraet, Zeitstempel, Autor und (auf 200 Zeichen gekuerztem) Text; der Rest bleibt vollstaendig im Service-Tab.

Aktualisieren, Drucken und Excel-Mappe

»Aktualisieren« laedt den Steckbrief neu aus den Live-Daten. »Drucken / als PDF speichern« oeffnet das Dokument in einem eigenen Fenster und ruft den Druckdialog auf — dort waehlst du den Drucker oder »Als PDF sichern«. Bitte Pop-ups fuer diese Seite erlauben, sonst kann sich das Druckfenster nicht oeffnen (die Akte sagt das dann ehrlich).

Steht auf dem Server die Excel-Unterstuetzung bereit, erscheint zusaetzlich »Alles als Excel«: ein Download der kompletten Anlagen-Doku als native .xlsx-Mappe mit einem Tabellenblatt je Register. Ab der Service-Rolle gibt es das Gegenstueck »Alles importieren« — eine komplette Mappe wieder einspielen, wobei jedes Blatt per Name seinem Register zugeordnet wird; das destruktive Ueberschreiben ist serverseitig zusaetzlich auf die Full-Rolle beschraenkt.

Lazy laden und ehrliche Zustaende

Die Akte wird erst geladen, wenn du den Tab oeffnest (nicht bei jedem Anlagen-Aufruf), damit sie nicht unnoetig einen Scan und die Q-SYS-Abfrage ausloest. Ist die Sitzung abgelaufen, meldet die Pane das offen (»Sitzung abgelaufen — bitte neu anmelden«) statt eine faelschlich leere Akte mit lauter Nullen zu zeigen, die aussieht, als waere die Anlage leer. Ist der Geräte-Scan gerade nicht verfuegbar (Anlage offline oder Mesh getrennt), sagt der Geräte-Abschnitt genau das — jeder Abschnitt hat seinen eigenen ehrlichen Leerzustand.

Kamera / optisches Monitoring #

Der Site-View-Tab »Kamera« zeigt das Live-Bild einer USB-Kamera oder eines HDMI-Grabbers (Monitor-Eingang) am OnSite-Pi der Anlage. Damit prueft man aus der Ferne die Buehne, den Saal oder — ueber einen HDMI-Grabber — was auf einem angeschlossenen Bildschirm/Mediaplayer laeuft. Das Bild kommt on-demand ueber die Plattform (Proxy zum Pi-Kameradienst): Es wird kein Dauerstream aufgebaut — der Browser holt nur einzelne JPEG-Frames, und zwar nur solange dieses Fenster offen und sichtbar ist. Schliesst du den Tab oder wechselst weg, stoppt die Kamera. Eine niedrige Bildrate schont das Netz.

Der Kamera-Tab erscheint nur bei Anlagen mit einem gekoppelten Pi. Das Auflisten der Kameras und das Abrufen von Bildern setzt mindestens die Service-Rolle voraus; ein per Kill-Switch stillgelegter Standort liefert weder Kameraliste noch Bilder (der Not-Aus greift vor dem Rollencheck).

Quelle, Auflösung und Bildrate wählen

• Kamera — Auswahl der Quelle. Pi-interne ISP-/Codec-Knoten werden ausgeblendet, sodass nur echte Aufnahmequellen erscheinen; ein HDMI-Grabber wird eindeutig als solcher beschriftet.
• Auflösung — 640×480, 1280×720 (Standard) oder 1920×1080.
• Bildrate — »nur Snapshot« (kein Auto-Abruf), 0,5 / s, 1 / s (Standard), 2 / s oder 5 / s. Das ist die Abruf-Kadenz des Browsers; bei UVC-Grabbern wird daraus zusaetzlich ein Aufnahme-Hinweis an den Pi abgeleitet.
• Drehung (0°/90°/180°/270°) und »Spiegeln« — rein im Browser, ohne Last fuer Pi oder Netz. Praktisch bei kopfueber montierten Kameras oder ueber Prompter/Spiegel abgegriffenen Signalen.

Geraet, Auflösung, Bildrate, Drehung, Spiegelung und der Zeitstempel-Schalter werden pro Anlage gemerkt, sodass die gewohnte Einstellung beim naechsten Oeffnen wieder da ist.

Snapshot, Standbild, Speichern und Vollbild

• Snapshot — holt sofort ein frisches Einzelbild.
• Pause / Live — friert das aktuelle Bild ein (Standbild), um z. B. einen Wert auf dem per HDMI erfassten Bildschirm in Ruhe abzulesen; erneut klicken setzt den Live-Abruf fort.
• Speichern — laedt das aktuelle Bild als JPEG herunter. Der Download ist WYSIWYG: Drehung und Spiegelung werden mitgerechnet, das gesicherte Bild sieht also aus wie das, was du siehst. Der Dateiname nennt Quelle (Kamera/HDMI-Grabber), Geraet, Auflösung und Zeitpunkt.
• Zeitstempel — brennt den Aufnahmezeitpunkt (Datum + Uhrzeit) unten ins gespeicherte JPEG, fuer Doku/Uebergabe. Wirkt nur auf die gesicherte Datei, nicht auf das Live-Bild.
• Vollbild — zeigt das Kamerabild randlos. Auch im Vollbild bleiben touch-grosse Schaltflaechen zum Beenden sowie fuer Snapshot/Speichern eingeblendet, und bei einem HDMI-Grabber benennt eine Kennung am Bild die Quelle.

Solange das Live-Bild laeuft, wird — sofern der Browser es unterstuetzt — der Bildschirm wachgehalten, damit beim Zuschauen kein Bildschirmschoner das Monitorbild unterbricht. Kommt gerade kein Bild (Verbinden, keine Kamera gefunden, Anlage offline oder Sitzung/Berechtigung fehlt), zeigt die Flaeche ein ehrliches Kamera-aus-Symbol mit Klartext statt eines irrefuehrend leeren schwarzen Kastens. Aus Datenschutz- und Log-Gruenden wird nicht jedes Frame protokolliert — das Oeffnen des Kamera-Zugriffs genuegt fuer das Audit-Log.

Live-Stream direkt uebers Mesh (ohne VPS-Last)

Neben dem Einzelbild-Abruf gibt es den Knopf »Live«: einen echten MJPEG-Stream (~15 / s) — deutlich fluessiger als der Einzelbild-Poll. Entscheidend ist der Weg, den das Video nimmt: Es laeuft direkt ueber das NetBird-Mesh von der Onsite-Box zu deinem Rechner und nie ueber den VPS. Ein Dauerstream durch den Server wuerde sonst dauerhaft Bandbreite kosten; genau das wird hier vermieden.

Damit das eingebettet im Kamera-Fenster funktioniert, braucht es den UpNrun-Helfer auf genau dem Rechner, an dem du sitzt. Der Grund ist eine Browser-Sicherheitsregel: Eine per https geladene Seite darf keine http-Inhalte einbetten (»Mixed Content«) — und die Onsite-Kamera ist im Mesh nur per http erreichbar. Die einzige Ausnahme, die Browser erlauben, ist 127.0.0.1. Der lokale Helfer ist selbst Mesh-Teilnehmer und reicht den Stream daher lokal ueber 127.0.0.1 durch. Ergebnis: Browser → lokaler Helfer → Mesh → Onsite-Kamera.

• Mit lokalem Helfer — der Stream laeuft inline im Kamera-Fenster. Die Statuszeile meldet »live · direkt im Mesh«.
• Ohne lokalen Helfer — der Browser kann das Mesh-Bild nicht einbetten; der Stream oeffnet sich stattdessen in einem neuen Tab. Das funktioniert nur, wenn dein Rechner den Mesh selbst erreicht.
• Alternative ohne Helfer — das Snapshot-Intervall (siehe unten) auf ~200 ms stellen. Das wirkt fast wie Video und erzeugt trotzdem keinen Dauerstream.

Sicherheitshinweis: Der lokale Helfer ist kein offener Zugang zum Mesh. Er akzeptiert einen Stream nur mit einem von der Plattform signierten, kurzlebigen Ticket, das an genau diese Kamera und dieses Ziel gebunden ist; zusaetzlich sind nur Mesh-/lokale Adressen als Ziel erlaubt. Ohne gueltige Kopplung verweigert er den Dienst. Der Live-Knopf setzt wie alles im Kamera-Tab mindestens die Service-Rolle voraus und respektiert den Kill-Switch.

Kameraeinstellungen: Bildregler, Intervall und Bewegungsbereich

Ueber das Zahnrad → »Kameraeinstellungen« oeffnet sich ein Fenster mit Reglern, die direkt auf der Onsite-Box wirken — sie erzeugen keine zusaetzliche VPS-Last.

• Bildregler — Helligkeit, Kontrast, Saettigung, Farbton, Gamma, Schaerfe, Weissabgleich und Gegenlichtkorrektur, soweit die Kamera sie meldet. Es werden nur die Regler angezeigt, die das Geraet tatsaechlich unterstuetzt. Die Werte werden pro Kamera dauerhaft gespeichert und vor jedem Bild erneut gesetzt — sonst gingen sie verloren, weil jede Aufnahme das Geraet neu oeffnet. »Zuruecksetzen« stellt die Werkseinstellungen der Kamera wieder her.
• Snapshot-Intervall (200–5000 ms) — wie oft dieses Fenster ein neues Bild abruft. Kleiner Wert = fluessiger, aber mehr Abrufe. Auch dieser Wert wird pro Kamera gemerkt.
• Bewegungsbereich — ein Rechteck, das du mit der Maus ueber das Bild ziehst. Die Bewegungserkennung wertet dann nur diesen Ausschnitt aus. Praktisch, um z. B. nur den Eingang zu ueberwachen und einen Baum im Wind draussen zu ignorieren. »Ganzes Bild« setzt auf die volle Flaeche zurueck.

Bewegungsereignisse mit Bildfolge

Ist die Bewegungserkennung fuer eine Kamera aktiv, vergleicht die Onsite-Box laufend Standbilder — das passiert komplett auf der Box, ohne Dauerstream und ohne VPS-Last. Zu jedem erkannten Ereignis speichert sie zusaetzlich eine kurze Bildfolge: ein Bild davor, eines im Moment des Ereignisses und mehrere danach im Sekundenabstand. Ueber das Bilder-Symbol am Ereignis oeffnest du die Folge und siehst, was tatsaechlich passiert ist — statt nur einer Zeile in einer Liste. Die Bilder liegen auf der Onsite-Box und sind in der Anzahl begrenzt: aeltere Ereignisse werden automatisch aufgeraeumt, damit der Speicher nicht volllaeuft.

Wissensbasis / Runbooks #

Der Site-View-Tab »Wissen« ist die durchsuchbare Wissensbasis einer Anlage: Schritt-fuer-Schritt-Anleitungen, Fehlerbehebungs-Runbooks, FAQ, Konfigurations-Hinweise und Notfall-Prozeduren bleiben so an der Anlage statt im Kopf eines einzelnen Technikers. Er ergaenzt das Service-Tagebuch (was passiert ist) und das Files-Modul (Cloud-Quellen und Ablage) um das Wie-macht-man-es. Jeder Artikel wird als Klartext gespeichert und angezeigt (kein HTML-/Markdown-Render) — das ist bewusst so und schuetzt vor eingeschleustem Code.

Wer die Anlage sehen darf, kann alle Artikel lesen. Anlegen und Bearbeiten setzt mindestens die Service-Rolle voraus (ohne sie ist der Knopf »Artikel« ausgeblendet), Loeschen die Full-Rolle. Jede Aenderung landet im Audit-Log. Es ist ein reiner Plattform-Store — die Wissensbasis fasst kein Geraet an.

Artikel: Kategorien, Tags und Anheften

• Titel (Pflicht) und optional Kategorie, Gerät / Bezug, Tags (Komma-getrennt) und der eigentliche Inhalt / Schritte.
• Kategorien — vorgeschlagen werden Anleitung, Fehlerbehebung, FAQ, Konfiguration, Inbetriebnahme, Notfall und Sonstiges; eigene Kategorien sind moeglich (freies Textfeld mit Vorschlagsliste).
• Anheften — wichtige Standard- oder Notfall-Runbooks werden oben festgepinnt, damit sie im Ernstfall sofort greifbar sind. Sortiert wird angeheftet zuerst, dann zuletzt geaendert oben.
• Beim Speichern gilt ⌘/Strg+Enter. Zu lange Eingaben werden schon im Browser gemeldet (Titel max. 200, Kategorie 80, Gerät 160, Tags 240, Inhalt 20 000 Zeichen), damit nichts still abgeschnitten wird.

Finden, Lesen und Exportieren

• Kennzahlen-Leiste — Anzahl Artikel, Kategorien, angeheftete Artikel und wie viele Tags tragen.
• Suche ueber Titel, Tag, Gerät und Inhalt, kombinierbar mit dem Kategorie-Filter und »nur angeheftet«. Die Spalten Artikel / Kategorie / Aktualisiert sind sortierbar. Findet ein Filter nichts, nennt das Leerfeld die aktiven Filter samt Gesamtzahl und bietet einen Filter-zuruecksetzen-Knopf.
• Lesen — ein Klick auf den Titel oeffnet den Artikel in einem Lese-Fenster mit voll erhaltenen Zeilenumbruechen; von dort geht es (ab Service-Rolle) direkt in den Bearbeiten-Modus.
• CSV und Drucken / Als PDF exportieren jeweils die gerade gefilterte Ansicht — die CSV mit Excel-sicherer Formel-Entschaerfung, das Druck-Verzeichnis als eigenstaendiges, hell gestyltes Dokument.

Files (Cloud-Quellen und Ablage) #

Der Site-Menuepunkt Files (vormals „Dokumente", Gruppe Dokumentation) buendelt die Unterlagen einer Anlage an einem Ort: oben werden bestehende Cloud-Ordner verknuepft, die Systemintegratoren fuer eine Anlage ohnehin schon pflegen (Google Drive, Dropbox, Synology, SharePoint/Teams ...), darunter steht die lokale Ablage direkt am UpNrun-Server fuer Dateien ohne festen Cloud-Platz — inzwischen mit Ordnern, Sichtbarkeits-Stufen je Datei, oeffentlichen Freigabe-Links und einem Papierkorb, kein flaches Einzel-Verzeichnis mehr. Sind an der Anlage Direkt-Helfer gekoppelt, kommt ein dritter Block dazu: Helper-Freigaben, die Sharing-Ordner dieser Helfer. Er ergaenzt die Wissensbasis (intern verfasstes Wie-macht-man-es) und das Backups-Register (Sicherungs-Status) um die eigentlichen Unterlagen.

Cloud-Quellen: Sharing-Links verknuepfen

„+ Quelle" hinterlegt einen Sharing-Link eines Cloud-Dienstes samt Titel, URL und optionaler Notiz. Der Anbieter wird automatisch am Link erkannt, eine manuelle Auswahl entfaellt. Pro Anlage sind bis zu 100 Quellen moeglich, Datei-Tabellen werden 5 Minuten zwischengespeichert.

Keine Kunden-Zugangsdaten sind noetig oder werden gespeichert — drei Stufen greifen je nach Anbieter und Freigabe: Links oeffnen zunaechst im Browser, der Login regelt sich ueber den Cloud-Dienst selbst; fuer eine echte Datei-Tabelle nutzt der UpNrun-Server eigene Plattform-Keys (lesbar sind dabei nur oeffentlich freigegebene Inhalte); eine OAuth-Anbindung fuer private SharePoint-Ordner folgt spaeter (v2).

Datei-Tabellen lassen sich nach Name, Groesse und Datum sortieren und tragen ein eigenes Suchfeld. Enthaelt ein Link ein Passwort im Klartext, erscheint ein Warn-Badge. Anlegen und Aendern einer Quelle setzt mindestens die Service-Rolle voraus, Loeschen die Full-Rolle.

Ablage: lokale Dateien am UpNrun-Server

Die Ablage nimmt Dateien direkt entgegen — per Upload-Knopf oder Drag-and-drop. Erlaubt sind u. a. PDF, Bilder (JPG/PNG/GIF/WebP/HEIC), Office-Formate (DOCX/XLSX/PPTX), TXT/CSV/MD, JSON und ZIP, je Datei bis 100 MB. Ein Vorschau-Auge zeigt PDF, Bilder und Textdateien direkt im Browser in einer Lightbox; andere Formate stehen als Download bereit.

„Link kopieren" erzeugt je Datei einen internen Link — er laesst sich z. B. als Ablageort ins Backups-Register einkleben, dort erscheint er anklickbar als „In Ablage oeffnen". Ansehen und Herunterladen darf jeder mit Zugriff auf die Anlage, Hochladen setzt mindestens die Service-Rolle voraus, Loeschen die Full-Rolle (landet zunaechst im Papierkorb, nicht sofort unwiderruflich).

Speicherkontingent (Quota)

Das Kontingent gilt gepoolt fuer die ganze Firma — alle Anlagen einer Firma teilen sich einen gemeinsamen Speicher. Anlagen ohne Firma haben ein eigenes Kontingent nach Site-Plan. Eine schlanke einzeilige Anzeige (Festplatten-Symbol, „belegt / Kontingent", duenner Balken) zeigt den Stand, rechtsbuendig ueber der Upload-Flaeche; der Balken faerbt sich ab 90 Prozent rot. Ist das Kontingent voll, werden neue Uploads abgelehnt — Loeschen und Herunterladen gehen immer. Dateien im Papierkorb zaehlen waehrend ihrer 30 Tage weiter zum Kontingent.

Wichtig: Dateien liegen unverschluesselt auf dem UpNrun-Server. Keine Passwoerter, Schluessel/Lizenzen oder hochsensible Daten in der Ablage speichern.

Ordner: anlegen, verschieben, loeschen

„+ Ordner" (im Breadcrumb ueber der Liste) legt einen Unterordner an, ein Klick im Breadcrumb navigiert zurueck. Dateien und ganze Ordner lassen sich per Drag-and-drop direkt auf einen Ordner oder ein Breadcrumb-Segment ziehen, um sie dorthin zu verschieben. Anlegen und Umbenennen setzt mindestens die Service-Rolle voraus. Ein leerer Ordner laesst sich ebenfalls ab Service-Rolle loeschen; enthaelt er noch Dateien oder Unterordner, ist dafuer die Full-Rolle noetig — der Inhalt wandert dabei rekursiv in den Papierkorb, nichts wird sofort unwiderruflich geloescht. Bis zu 500 Ordner je Anlage.

Sichtbarkeit pro Datei (Zugriffsstufen)

Jede Datei traegt eine eigene Sichtbarkeits-Stufe, einstellbar im Eigenschaften-Dialog (nur Full-Rolle):

Die Stufe greift ueberall gleich — Liste, Vorschau, Download, Suche und ZIP-Download: fuer die aktive Rolle unsichtbare Dateien tauchen dort schlicht nicht auf.

Freigabe-Links: eine Datei ohne Login teilen

Rechtsklick (Kontextmenue) auf eine hochgeladene Datei -> „Link freigeben…" erzeugt einen oeffentlichen, login-freien Download-Link ueber /files/s/<Token> — praktisch, um einem Kunden ohne eigenen Account eine einzelne Unterlage zu schicken. Beim Erstellen laesst sich die Gueltigkeit waehlen (1 Tag, 7 Tage, 30 Tage oder unbegrenzt); ein zweites „Erstellen" ersetzt einen bestehenden Link automatisch. Jede Datei traegt hoechstens einen aktiven Freigabe-Link, jederzeit ueber „Widerrufen" wieder zu entziehen. Der Token ist der Schutz — er steht in keiner Liste und laesst sich nicht erraten; wer den Link hat, kommt ohne Login an die Datei, bis er widerrufen wird oder die Gueltigkeit ablaeuft. Erzeugen und Widerrufen setzt mindestens die Service-Rolle voraus, nur fuer bereits hochgeladene Dateien (keine reinen Link-Referenzen).

Papierkorb (30 Tage)

Geloeschte Dateien und Ordner landen zunaechst im Papierkorb (Symbol oben rechts im Breadcrumb, mit Anzahl-Badge) statt sofort zu verschwinden. Von dort lassen sie sich wiederherstellen (ab Service-Rolle) oder endgueltig loeschen (ab Full-Rolle; „Papierkorb leeren" raeumt alles auf einmal). Nach 30 Tagen werden Eintraege automatisch endgueltig entfernt. Wichtig: Dateien im Papierkorb zaehlen waehrend dieser Zeit weiter zum Speicherkontingent — „geloescht" schafft also nicht sofort Platz.

Helper-Freigaben: Sharing-Ordner gekoppelter Direkt-Helfer

Traegt die Anlage gekoppelte Direkt-Helfer, erscheint ein eigener Block „Helper-Freigaben" mit je einer aufklappbaren Karte pro Helfer — sie zeigt den Sharing-Ordner des Helfer-Rechners (Standard ~/UpNrunShared, per Umgebungsvariable umstellbar), nicht den ganzen Rechner. Innerhalb einer Karte:

• Ansehen und Herunterladen der dort liegenden Dateien, direkt aus der Kachel.
• „In die Ablage uebernehmen" kopiert eine Helfer-Datei in die lokale Ablage dieser Anlage.
• Dateien hinschicken — auf die Kachel ziehen oder in die gestrichelte Flaeche unter der Dateiliste klicken; der Upload landet immer in der Sharing-Wurzel des Helfers, ein Zielordner laesst sich nicht waehlen.
• Helfer-zu-Helfer direkt — eine Datei von einer Helfer-Kachel auf eine andere ziehen kopiert sie ohne Umweg ueber die Platform: laufen beide im selben LAN, per LAN-Abkuerzung direkt, sonst ueber das Mesh. Setzt Helfer ab Version 2.2.6 voraus (aeltere zeigen einen Update-Hinweis).
• Unterordner lassen sich ab Helfer-Version 2.2.7 oeffnen; bei aelteren Helfern bleibt nur die Wurzel-Ansicht, Ordnerzeilen zeigen einen Update-Hinweis statt zu oeffnen.
• Eine dezente Fusszeile zeigt die Groesse des Sharing-Ordners sowie freien/gesamten Plattenplatz des Helfer-Rechners — sofern der Helfer diese Werte mitliefert (aeltere Helfer-Versionen liefern sie noch nicht, die Fusszeile bleibt dann einfach leer).

Der Files-Reiter im Helfer selbst (Outbox)

Auch die Helfer-App hat einen eigenen Bereich »Files« (Windows ab 2.2.6; Mac ab 2.2.10, in der nativen Oberflaeche ab 2.2.11) — fuer den Techniker vor Ort am Helfer-Rechner, ohne Browser-Login:

• »Dateien an Platform senden« laedt gewaehlte Dateien direkt in die Ablage der gekoppelten Anlage hoch (Kategorie »Vom Helfer«, max. 100 MB; der Helfer authentisiert sich mit seinem Kopplungs-Geheimnis).
• Outbox-Ordner: liegt unter ~/UpNrunShared/Outbox. Ist die Ueberwachung eingeschaltet, wird jede dort abgelegte Datei automatisch hochgeladen und danach nach Outbox/Gesendet verschoben — Dateien einfach per Explorer/Finder hineinziehen genuegt.
• Dazu die Sharing-Ordner-Liste, »Ordner oeffnen« und die empfangenen Dateien (Inbox) an einem Ort.

Mehrfachauswahl und ZIP-Download

Strg/Cmd-Klick togglet einzelne Dateien, Shift-Klick waehlt einen Bereich — eine Aktionsleiste erscheint mit der Trefferzahl und darunter Verschieben nach… (ab Service-Rolle), An Helfer senden… und Loeschen (ab Full-Rolle; landet im Papierkorb, nicht sofort endgueltig). Ein ganzer Ordner laesst sich ueber das ZIP-Symbol im Breadcrumb oder das Kontextmenue als eine gepackte ZIP-Datei herunterladen (rekursiv mit allen Unterordnern, Summe bis 500 MB); enthalten sind dabei nur Dateien, die fuer die eigene Rolle laut Sichtbarkeit auch sichtbar sind.

Checklisten & Abnahmeprotokolle #

Der Site-View-Tab »Checklisten« haelt abhakbare Prueflisten je Anlage fest — Inbetriebnahme, Abnahme, Wartung und Inspektion werden Punkt fuer Punkt nachgewiesen. Jede Liste laesst sich als A4-Abnahmeprotokoll drucken (mit Unterschriftszeilen fuer Techniker und Kunde). Er ergaenzt das Service-Tagebuch (was ist passiert) und den Wartungsplan (wann faellig) um den lueckenlosen Erledigungs-Nachweis. Es ist ein reiner Plattform-Store — die Checklisten fassen kein Geraet an.

Wer die Anlage sehen darf, kann alle Listen lesen und als Protokoll drucken. Anlegen, Bearbeiten und Abhaken setzt mindestens die Service-Rolle voraus (ohne sie ist der Knopf »Neue Checkliste« ausgeblendet und die Haken sind gesperrt), Loeschen die Full-Rolle. Jede Aenderung — Anlegen, Aendern, Abhaken, Loeschen — landet im Audit-Log.

Listen anlegen: Vorlagen, Kategorien und Punkte

• Vorlagen — beim Anlegen fuellt eine Vorlage die Punkteliste vor: Inbetriebnahme AV, Abnahmeprotokoll, Jahreswartung und Sicherheits-Check. Die Punkte lassen sich danach frei ergaenzen, streichen und umformulieren; der Titel wird aus der Vorlage uebernommen, wenn er noch leer ist.
• Felder — Titel (Pflicht) sowie optional Kategorie und Notiz. Vorgeschlagene Kategorien sind Inbetriebnahme, Abnahme, Wartung, Inspektion, Sicherheit und Sonstiges — eigene sind moeglich (freies Textfeld mit Vorschlagsliste).
• Pruefpunkte werden als dynamische Zeilen eingegeben; einzelne Punkte lassen sich hinzufuegen und entfernen. Leere Zeilen werden beim Speichern verworfen. Beim Bearbeiten bleibt der Abhak-Zustand bestehender Punkte anhand ihres Textes erhalten.
• Speichern mit ⌘/Strg+Enter. Zu lange Eingaben werden schon im Browser gemeldet (Titel max. 200, Kategorie 80, Notiz 2000, jeder Pruefpunkt 600 Zeichen), damit nichts still abgeschnitten wird. Pro Anlage sind bis zu 2000 Listen mit je bis zu 300 Punkten moeglich.

Abarbeiten, Filtern und als Protokoll drucken

• Kennzahlen-Leiste — Anzahl Checklisten, abgeschlossen, in Arbeit und die Summe der noch offenen Punkte ueber alle Listen.
• Abhaken — ein Klick auf das Kaestchen setzt einen Punkt sofort erledigt (ab Service-Rolle); der Fortschrittsbalken je Liste zeigt erledigt / gesamt und Prozent. Eine vollstaendig erledigte Liste wird mit gruenem Rahmen und Haken markiert.
• Suche ueber Titel, Pruefpunkt und Kategorie, kombinierbar mit dem Kategorie-Filter und »nur offene«. Findet ein Filter nichts, nennt das Leerfeld die aktiven Filter samt Gesamtzahl und bietet einen Filter-zuruecksetzen-Knopf — ein 0-Treffer-Filter sieht so nicht wie eine Anlage ganz ohne Checklisten aus.
• Drucken / Als PDF erzeugt je Liste ein eigenstaendiges, hell gestyltes A4-Abnahmeprotokoll: Kopf mit Titel, Anlage, Kategorie und Datum, Status-Zeile (erledigt / gesamt / Prozent), die Notiz, eine Punkte-Tabelle mit druck-sicheren Haken-Symbolen sowie Unterschriftszeilen fuer Techniker und Kunde. (Ist der Pop-up-Blocker aktiv, weist ein Hinweis darauf hin.)

IP-Plan — das Adress-Register als Excel-Grid #

Der Site-Tab „IP-Plan" ist das IP-Adress-Register der Anlage — und zugleich das Vorbild aller Doku-Register: statt Einzel-Formularen ein eingebettetes Excel-Grid (jspreadsheet CE, MIT-Lizenz, lokal ausgeliefert — kein CDN). Editiert wird direkt in den Zellen, wie in Excel.

Arbeiten im Grid

• Filter-Trichter in jeder Spaltenkopfzeile, Sortierung per Klick und ein Suchfeld grenzen große Pläne ein.
• Copy & Paste mehrerer Zeilen aus und nach Excel funktioniert direkt über die Zwischenablage; „Zeile" fügt eine leere Zeile an.
• Das Grid nutzt die volle Bildschirmhöhe; doppelte IPv4-Adressen werden rot markiert, damit Konflikte sofort auffallen.
• „Drucken / PDF" druckt den sichtbaren Plan (Werkzeugleiste und Meldungen werden dabei ausgeblendet).

Spalten

„Aus Scan übernehmen"

Der Knopf schlägt die Geräte aus dem letzten Netzwerk-Scan als neue Zeilen vor — aber nur IPs, die noch nicht im Plan stehen. Stehen alle Scan-IPs schon drin, sagt die Meldung genau das. Die Vorschläge landen erst im Grid; übernommen wird erst mit „Speichern".

Speichern und Rollen

„Speichern" überträgt den kompletten sichtbaren Stand als Bulk-Save an die Plattform (bis 5000 Einträge je Anlage). Lesen darf jeder mit Zugriff auf die Anlage; ohne Schreibrecht ist das Grid Nur-Lese und der Hinweis „Speichern ist deaktiviert" erscheint.

IP plan — the address register as an Excel grid #

The site tab "IP plan" is the installation's IP address register — and at the same time the blueprint for all documentation registers: instead of individual forms, an embedded Excel grid (jspreadsheet CE, MIT licence, served locally — no CDN). You edit directly in the cells, just like in Excel.

Working in the grid

• Filter funnels in every column header, click-to-sort and a search field narrow down large plans.
• Copy & paste of multiple rows from and to Excel works directly via the clipboard; "Row" appends an empty row.
• The grid uses the full screen height; duplicate IPv4 addresses are highlighted in red so conflicts stand out immediately.
• "Print / PDF" prints the visible plan (toolbar and messages are hidden for printing).

Columns

"Take over from scan"

The button suggests the devices from the last network scan as new rows — but only IPs that are not yet in the plan. If all scan IPs are already there, the message says exactly that. Suggestions only land in the grid; nothing is committed until "Save".

Saving and roles

"Save" transfers the complete visible state to the platform as a bulk save (up to 5000 entries per site). Anyone with access to the site may read; without write permission the grid is read-only and the hint "saving is disabled" appears.

Backups — Konfigurations-Backup-Register #

Der Site-Tab „Backups" beantwortet die Frage, die kein Netzwerk-Scan beantworten kann: WO liegen die Konfigurations- und Programmier-Sicherungen der Anlage, und WANN wurde zuletzt gesichert? Q-SYS-Design, KNX-Projekt, Switch-/Router-Config, Projektor-Presets, Steuerungs-Programme, Server-Images — der Live-Scan sieht nur die Erreichbarkeit, nicht den Sicherungsstand.

Eintrag anlegen

• Bezeichnung (Pflicht) plus optional Kategorie (Vorschläge: Q-SYS Design, KNX-Projekt, Switch/Router-Config, Steuerung/Control, Projektor/Display, Audio-DSP, Server/PC-Image, Firmware, Sonstiges — freie Eingabe erlaubt), Gerät, Speicherort (Server-Pfad, NAS, Cloud-Link …), Version und Notiz.
• Zuletzt gesichert — Datum der letzten Sicherung (leer = ehrlich „noch keine Sicherung").
• Intervall (Tage) — die empfohlene Sicherungsfrequenz (0 = ohne Plan, dann zählt nur das letzte Datum; maximal 10 Jahre).

Die Aktualitäts-Ampel

Aus „zuletzt gesichert" + Intervall errechnet sich die Fälligkeit — direkt im Browser gegen „heute", ganz ohne Hintergrund-Job:

• aktuell — die letzte Sicherung liegt innerhalb des Intervalls.
• bald fällig — die nächste Sicherung rückt heran.
• überfällig — das Intervall ist überschritten.
• kein Backup — noch nie gesichert; solche Einträge stehen in der Liste zuoberst, denn sie sind am dringendsten.

Überblick, Filter und Export

Kennzahlen-Kacheln fassen den Stand zusammen; Volltextsuche (Bezeichnung, Gerät, Speicherort, Notiz), Kategorie-Filter und der Haken „nur kritisch" (überfällig / kein Backup) grenzen ein. CSV und Drucken / Als PDF exportieren die sichtbare Liste. Lesen darf jeder mit Zugriff auf die Anlage, Bearbeiten ab Service-, Löschen ab Full-Rolle; bis 3000 Einträge je Anlage.

Backups — configuration backup register #

The site tab "Backups" answers the question no network scan can answer: WHERE are the installation's configuration and programming backups, and WHEN was the last backup taken? Q-SYS design, KNX project, switch/router config, projector presets, control programs, server images — the live scan only sees reachability, not the backup state.

Creating an entry

• Title (required) plus optional category (suggestions: Q-SYS design, KNX project, switch/router config, control, projector/display, audio DSP, server/PC image, firmware, other — free input allowed), device, storage location (server path, NAS, cloud link …), version and note.
• Last backup — date of the most recent backup (empty = honestly "no backup yet").
• Interval (days) — the recommended backup frequency (0 = no schedule, only the last date counts; 10 years maximum).

The freshness traffic light

The due date is calculated from "last backup" + interval — directly in the browser against "today", with no background job:

• current — the last backup is within the interval.
• due soon — the next backup is approaching.
• overdue — the interval has been exceeded.
• no backup — never backed up; these entries sit at the top of the list because they are the most urgent.

Overview, filters and export

KPI tiles summarise the state; full-text search (title, device, location, note), a category filter and the "critical only" checkbox (overdue / no backup) narrow the list. CSV and Print / as PDF export the visible list. Anyone with site access may read, editing needs Service, deleting needs Full; up to 3000 entries per site.

Firmware — Versions- und Update-Register #

Der Site-Tab „Firmware" hält je Komponente fest, welcher Firmware-/Software-Stand läuft (IST) und welche Version das Ziel ist (SOLL) — der Versions- und Patch-Überblick, den der Live-Scan (nur Erreichbarkeit) nicht liefern kann. Typische Einträge: Q-SYS Core, Netzwerk-Switch, Projektor/Display, Medien-Steuerung, Audio-DSP, Server/NUC, Pi/Mini-PC, Kamera, Software/App.

Eintrag anlegen

• Komponente (Pflicht) plus optional Kategorie, Hersteller, Modell, verantwortlich und Notiz.
• IST-Version und SOLL-/Ziel-Version — nebeneinander dargestellt, die Ziel-Version farblich hervorgehoben.
• Zuletzt geprüft — wann der Stand zuletzt verifiziert wurde; das Alter („vor X Tg. geprüft") rechnet der Browser gegen „heute" und hebt veraltete Prüfstände hervor.

Status-Ampel und Sortierung

Jeder Eintrag trägt einen von fünf Status-Werten: aktuell, Update verfügbar, kritisch, EOL (End of Life) oder unbekannt. Die Liste sortiert nach Handlungsdruck: kritisch zuerst, dann EOL, Update verfügbar, unbekannt und zuletzt aktuell — was Aufmerksamkeit braucht, steht oben, kritische Zeilen sind zusätzlich eingefärbt.

Überblick, Filter und Export

Kennzahlen-Kacheln zählen den Stand; Volltextsuche, Kategorie- und Status-Filter sowie der Haken „nur handlungsbedürftig" grenzen ein; die Spalten sind sortierbar. CSV und Drucken / Als PDF exportieren die sichtbare Liste. Lesen darf jeder mit Zugriff auf die Anlage, Bearbeiten ab Service-, Löschen ab Full-Rolle; bis 3000 Einträge je Anlage.

Firmware — version and update register #

The site tab "Firmware" records, per component, which firmware/software version is running (actual) and which version is the goal (target) — the version and patch overview the live scan (reachability only) cannot deliver. Typical entries: Q-SYS core, network switch, projector/display, media control, audio DSP, server/NUC, Pi/mini PC, camera, software/app.

Creating an entry

• Component (required) plus optional category, vendor, model, responsible and note.
• Actual version and target version — shown side by side, the target version highlighted in colour.
• Last checked — when the state was last verified; the age ("checked X days ago") is calculated in the browser against "today" and stale checks are highlighted.

Status traffic light and sorting

Every entry carries one of five status values: current, update available, critical, EOL (end of life) or unknown. The list sorts by urgency: critical first, then EOL, update available, unknown and finally current — whatever needs attention sits on top, and critical rows are additionally tinted.

Overview, filters and export

KPI tiles count the state; full-text search, category and status filters plus the "action needed only" checkbox narrow the list; columns are sortable. CSV and Print / as PDF export the visible list. Anyone with site access may read, editing needs Service, deleting needs Full; up to 3000 entries per site.

2FA / Sicherheit #

Die Zwei-Faktor-Authentifizierung (2FA) sichert den Platform-Login mit einem zeitbasierten Einmalcode (TOTP, z.B. aus einer Authenticator-App) zusaetzlich zum Passwort.

• Einrichtung ueber die Sicherheits-Settings (QR-Code scannen, Code bestaetigen).
• Empfohlen fuer alle Service-/Full-Konten.
• Zusammen mit dem Trust-Layer und Audit-Log bildet 2FA die Sicherheits-Basis.

Audit-Log / Protokoll #

Das Audit-Log protokolliert sicherheitsrelevante Ereignisse chronologisch und lueckenlos — wer sich wann angemeldet hat, welche Standorte geoeffnet wurden, wann ein Scan lief. Aufrufbar ueber den Menuepunkt Audit-Log in der Hauptnavigation.

Was protokolliert wird

Jede Zeile ist ein Ereignis mit den Spalten Zeit, Aktion, Benutzer, Ziel, Status (Erfolg/Fehler) und IP. Erfasst werden u. a.:

• Login und Login-Lockout (nach zu vielen Fehlversuchen)
• Logout
• Scan — ein Netz-Scan einer Anlage
• Site geoeffnet — Zugriff auf einen Standort
• Remote-Desktop-Zugriffe, Screenshots und Audit-Exporte

Erfolg/Fehler-Streifen

Ueber der Tabelle zeigt ein Kennzahlen-Streifen die Gesamtzahl der erfolgreichen und fehlgeschlagenen Ereignisse. Ein Klick auf eine Kennzahl filtert die Liste sofort auf diesen Status — praktisch, um fehlgeschlagene Anmeldeversuche isoliert zu pruefen.

Filtern und Zeitraum

Die Liste laesst sich eingrenzen ueber Freitextsuche (Aktion, Benutzer, IP), einen Zeitraum (Von/Bis) mit Schnellknoepfen 24 h, 7 Tage, 30 Tage, Alles sowie Auswahllisten fuer Aktion, Benutzer und Status. Die Spaltenkoepfe sind sortierbar (auf-/absteigend), Aktualisieren laedt die neuesten Ereignisse nach.

Export

Der aktuelle (gefilterte) Zeitraum laesst sich als CSV oder JSON herunterladen — fuer Archiv, Auswertung oder Nachweis. Der Export ist der Rolle Full vorbehalten.

System-Health / Live-Status #

Die Seite System-Health zeigt auf einen Blick, ob die UpNrun-Plattform selbst und alle angebundenen Agenten gesund sind — der Server (VPS), der Datenspeicher, der Platform-Dienst sowie pro Standort die Pi-Sonde und der Windows-Helfer. Aufrufbar ueber den Menuepunkt System-Health in der Hauptnavigation.

Ganz oben fasst eine Gesamt-Ampel den schlechtesten Einzelwert zusammen (gruen = alles ok, gelb = Warnung, rot = Stoerung). Die Seite aktualisiert sich automatisch alle 30 Sekunden und nennt den Zeitpunkt der letzten Pruefung; der Knopf Aktualisieren holt sofort frische Werte.

Server- und Dienst-Kacheln

Vier Kacheln zeigen die Kernwerte der Plattform:

• Platform-Service — Status des Dienstes und der aktive Base Path.
• VPS Disk — Festplatten-Belegung als Balken mit belegt/gesamt und freiem Platz.
• VPS RAM — Arbeitsspeicher-Belegung als Balken mit belegt/gesamt und verfuegbarem Speicher.
• Datenspeicher — die einzelnen Datendateien mit eigener Ampel und Dateigroesse (fehlende Dateien werden als fehlt markiert).

Disk und RAM werden nach Auslastung eingefaerbt: unter 85 % gruen, ab 85 % gelb, ab 95 % rot.

Sites & Agenten

Die Tabelle darunter listet jeden Standort mit einer Ampel und drei Erreichbarkeits-Proben:

• Pi Mesh-Ping — erreicht die Plattform die OnSite-Pi ueber das NetBird-Mesh (mit Host und Antwortzeit)?
• Monitor-Agent :8766 — antwortet der Ueberwachungs-Agent auf der Pi?
• Win-Helper :8765 — antwortet der Windows-Helfer, oder ist er nicht konfiguriert?

Jede Probe zeigt ihre eigene Ampel samt HTTP-Status und Latenz, sodass sich eine Stoerung sofort dem richtigen Standort und Dienst zuordnen laesst.

Schonendes Live-Polling

Die Health-Abfrage faechert ueber alle Standorte aus und ist damit die aufwendigste Aggregation der Plattform. Damit sie im Hintergrund niemanden belastet, laeuft der 30-Sekunden-Takt nur, solange der Browser-Tab sichtbar ist; bei Rueckkehr wird sofort einmal frisch geladen. Haengt eine Abfrage laenger als 25 Sekunden, wird sie abgebrochen und ehrlich als Zeitueberschreitung gemeldet, statt still auf Altdaten stehen zu bleiben.

Fleet Push / OTA-Updates #

Die Seite Fleet Push verteilt Software-Updates zentral an die OnSite-Pi aller Standorte (Over-the-Air, OTA). Sie ist ausschliesslich fuer Administratoren zugaenglich; ohne Admin-Rechte antwortet die Seite mit 403 – Admin-Zugang erforderlich. Aufrufbar ueber den Menuepunkt Fleet Push in der Hauptnavigation.

Oben nennt ein Hinweis die aktuelle Manifest-Version, die der zentrale Update-Server bereitstellt – das ist die Version, die per Push ausgerollt wird. Die Tabelle listet jeden Standort, der eine OnSite-Pi konfiguriert hat; Standorte ohne Pi erscheinen nicht.

Die Standort-Tabelle

Pro Standort zeigt eine Zeile:

• Site – Name und technische Kennung des Standorts.
• Installiert – die aktuell auf der Pi laufende Software-Version.
• Verfuegbar – die vom Update-Server angebotene Version. Weicht sie von der installierten ab, wird sie als verfuegbares Update hervorgehoben; ein Fehler der Pi wird als kurzer roter Hinweis unter der Version angezeigt.
• Service-Status – eine farbige Statusmarke des Update-Dienstes auf der Pi: gruen fuer aktiv/fertig, orange waehrend Download/Anwendung, rot bei Fehler, grau wenn die Pi nicht erreichbar ist.
• Aktion – der Knopf Update stoesst das Update fuer genau diesen Standort an.

Ausrollen: Alle, Canary, einzeln

Fuer den Roll-out gibt es drei Wege:

• Alle Sites aktualisieren – stoesst das Update auf allen Standorten gleichzeitig an. Danach meldet die Statuszeile, wie viele Standorte erfolgreich getriggert wurden und wie viele fehlschlugen.
• Canary (1 Site zuerst) – das empfohlene, vorsichtige Vorgehen: es wird zunaechst nur ein Standort aktualisiert. Ist dieser nach Pruefung stabil, rollt der Knopf Rest jetzt pushen das Update auf die verbleibenden Standorte aus; Abbrechen stoppt den Vorgang.
• Update pro Zeile – aktualisiert gezielt einen einzelnen Standort.

Damit ein versehentlicher Doppelklick keine Update-Welle ausloest, gilt pro Standort eine kurze Sperre von 30 Sekunden; ein zu frueher zweiter Push wird abgewiesen. Jeder Aufruf der Seite und jeder Push wird im Audit-Log protokolliert.

Rollback und Sicherheit

Ein manueller Rollback-Knopf ist bewusst deaktiviert: Die OnSite-Pi verwendet ein A/B-Verfahren mit automatischem Rollback. Schlaegt der Gesundheits-Check nach einem Update fehl, kehrt die Pi selbsttaetig zur vorherigen, funktionierenden Version zurueck – ohne manuellen Eingriff.

Schonendes Live-Polling

Die Status-Abfrage faechert ueber alle Standorte samt ihrer Pi-Sonden aus und aktualisiert sich automatisch alle 15 Sekunden – jedoch nur, solange der Browser-Tab sichtbar ist, um die Pi-Anlagen im Hintergrund nicht unnoetig zu belasten. Bei Rueckkehr wird sofort einmal frisch geladen. Haengt eine Abfrage laenger als 20 Sekunden (etwa weil eine Pi nicht antwortet), wird sie abgebrochen und ehrlich als Zeitueberschreitung gemeldet, statt still auf Altdaten stehen zu bleiben.

Einstellungen #

Das Settings-Menue buendelt alle Optionen aufgeraeumt in einer zwei-spaltigen Glas-Ansicht: links die gruppierte Navigation, rechts das jeweilige Panel. Jede Einstellung hat einen Info-Button, der direkt hierher ins Handbuch verlinkt.

Erscheinungsbild (Theme & Akzent)

Steuert die Optik der gesamten Oberflaeche und bleibt lokal im Browser gespeichert (kein Server-State):

• Look-Preset — Studio (klar & fokussiert), Aurora (mehrfarbige Glows) oder Mono (dezent).
• Hintergrund / Matrix-BG — schlicht, dezentes Tech-Raster oder optionaler Matrix-Code-Regen.
• Akzentfarbe — Primaerfarbe der Oberflaeche; Standard ist UpNrun-Cyan, eigene Farbe waehlbar.
• Transparenz — Panels leicht durchscheinend (Glas-Effekt).
• Bewegung — Animationen/Matrix-Regen erlauben; respektiert prefers-reduced-motion.

Plugins

Schaltet die Geraete-Plugins pro Standort ein und aus. Ausgeschaltet heisst: nicht gescannt, kein Panel, keine Alarme. Der Lizenz-Status je Zeile zeigt, ob das Plugin im aktuellen Tarif freigeschaltet ist. Die vollstaendige Liste aller Plugins mit Beschreibung steht unter Plugins.

Sprache

Schaltet die Oberflaeche zwischen Deutsch und Englisch um. Die Wahl wird in einem Cookie gespeichert; Schnellumschaltung gibt es zusaetzlich oben rechts in der Topbar.

Info / Ueber

Zeigt Produktname, den angemeldeten Benutzer und den Transport (NetBird-Mesh, Ende-zu-Ende verschluesselt) sowie einen Link auf dieses Online-Handbuch.

Tiefensuche & Bestandsvergleich #

Der gewoehnliche Scan pingt das eigene Subnetz durch. Das genuegt fuer alles, was per DHCP eine Adresse aus dem Hausnetz bekommen hat — aber nicht fuer Lichttechnik. Art-Net-Geraete stehen ab Werk auf 2.x.x.x mit Maske 255.0.0.0 und sind aus einem 10er- oder 192er-Netz strukturell unsichtbar, egal wie lange man sucht.

Die Tiefensuche schaltet darum zusaetzlich die aktive Suche ein:

• Art-Net ArtPoll (UDP 6454) — jede Node antwortet mit Name, Firmware und ihren DMX-Ports.
• sACN / E1.31 (Multicast) — findet Geraete, die nur diesen Standard sprechen.
• ARP-Sweep — arbeitet auf Ebene 2 und ignoriert Subnetzgrenzen komplett.

Broadcast und Multicast kuemmern sich nicht um IP-Subnetze: sie erreichen alles am selben Kabelstrang. Genau so taucht eine Node mit 2.0.0.1 in einer Anlage auf, deren Management-Netz 10.0.1.0/24 ist.

Warum nur auf Knopfdruck

Die Tiefensuche laeuft nicht im Dauerbetrieb mit. Aktive Suche kostet Zeit und erzeugt Verkehr auf dem Lichtnetz; kleine Netzwerkstacks in Nodes reagieren darauf empfindlich. Wer waehrend einer Vorstellung sucht, waehlt das Profil showsafe — dann bleibt Art-Net aussen vor.

Persistenter Bestand statt Momentaufnahme

Was ein Suchlauf findet, wird dauerhaft gespeichert und ueberlebt Neustarts. Dieser Bestand ist die Geraeteliste der Anlage. Ein erneuter Suchlauf aktualisiert ihn und zeigt den Unterschied: was neu ist, was verschwunden ist, was sich geaendert hat.

Im Normalbetrieb wird danach nur noch im eingestellten Takt geprueft, ob die bekannten Geraete antworten. Faellt eines aus oder haengt es, laeuft das ins Alarm-Zentrum. Das ist der ganze Ablauf: einmal suchen, Bestand bilden, ueberwachen — bis jemand wieder sucht.

Deep search & inventory comparison #

The ordinary scan pings your own subnet. That is enough for anything that received an address from the house network via DHCP — but not for lighting gear. Art-Net devices ship on 2.x.x.x with mask 255.0.0.0 and are structurally invisible from a 10.x or 192.168.x network, no matter how long you look.

Deep search therefore additionally enables active discovery:

• Art-Net ArtPoll (UDP 6454) — every node replies with its name, firmware and DMX ports.
• sACN / E1.31 (multicast) — finds devices that only speak this standard.
• ARP sweep — works at layer 2 and ignores subnet boundaries entirely.

Broadcast and multicast do not care about IP subnets: they reach everything on the same cable run. That is exactly how a node on 2.0.0.1 shows up in a site whose management network is 10.0.1.0/24.

Why it only runs on demand

Deep search does not run continuously. Active discovery costs time and puts traffic on the lighting network; the small network stacks inside nodes are sensitive to it. If you need to search during a performance, pick the showsafe profile, which leaves Art-Net alone.

A persistent inventory, not a snapshot

Whatever a run finds is stored persistently and survives restarts. This inventory is the site's device list. A further run updates it and shows the difference: what is new, what disappeared, what changed.

In normal operation UpNrun then only polls at the configured interval whether the known devices still answer. If one fails or hangs, it goes to the alarm centre. That is the whole cycle: search once, build the inventory, monitor — until someone searches again.

Switch-Plugin — Ports, PoE, Beschriftung #

Jedes Plugin der Sparte Switch ist gleich aufgebaut — UniFi, EdgeSwitch, NETGEAR AV Line, Luminex GigaCore. Es unterscheidet sich nur, wie mit dem Geraet gesprochen wird; die Tabelle sieht ueberall identisch aus:

Portname und Geraetename gehoeren UpNrun

Beide Spalten sind bewusst nicht im Switch gespeichert. Ein Switch kennt weder euren Sprachgebrauch noch die Namen aus der Geraeteliste — er meldet MAC-Adressen und allenfalls eine LLDP-Kennung. Weil die Beschriftung bei UpNrun liegt, uebersteht sie einen Geraetetausch oder ein Zuruecksetzen des Switches und braucht keine Schreibrechte auf der Hardware. Der Geraetename wird ueber die MAC zugeordnet; bleibt die Spalte leer, wurde am Port nichts erkannt. Aendern darf die Beschriftung ab der Rolle service, jede Aenderung wird protokolliert.

Locate — das richtige Kabel finden

Zwei Stufen, beide rein optisch: der Datenverkehr laeuft unveraendert weiter, du kannst sie also auch waehrend einer Vorstellung benutzen.

• Geraete-Locate (Knopf unter „Aktionen") laesst alle Port-LEDs im Sekundentakt pulsen — damit findest du den richtigen Switch im Rack.
• Port-Locate (Knopf in der Portzeile) laesst nur diese eine LED blinken — damit findest du das richtige Kabel, ohne einen Stecker zu ziehen.

Beides hoert von allein wieder auf (Geraet: 5 Minuten, Port: 20 Sekunden); ein zweiter Druck stoppt sofort. Die Blinkschleife laeuft auf dem Switch selbst und stellt am Ende das normale Bild wieder her — auch wenn die Verbindung zwischendurch abreisst. So bleibt nie eine LED im Testzustand haengen.

Die Knoepfe erscheinen nur bei Geraeten, die es koennen. Aeltere Modelle steuern einzelne Port-LEDs nicht an und bekommen darum gar keinen Port-Locate-Knopf.

Stand 29.07.2026, ehrlich aufgeschluesselt:

• UniFi Pro Max — freigeschaltet. Das Geraete-Locate (alle Port-LEDs pulsen) ist am Geraet gesehen worden. Der Weg dafuer war schon Tage vorher gebaut und funktionierte — nur war die Freigabemarke nie gesetzt, darum konnte der Knopf gar nicht erscheinen. Merke: eine Faehigkeit ist erst geliefert, wenn sie in der Oberflaeche steht. Ein funktionierender Weg im Hintergrund ist fuer dich nicht vorhanden.
• Ubiquiti EdgeSwitch — gesperrt. Der Web-Weg antwortet sauber (Start meldet „laeuft", auch nach 10 Sekunden noch, Stopp meldet „laeuft nicht"), aber die LED hat niemand gesehen. Eine Selbstauskunft des Geraets ist kein Beweis. Der Knopf bleibt darum gesperrt, siehe Schreibpfade & Verifikation.

Nebenbefund aus derselben Messung: der SNMP-Weg, den die Herstellerdokumentation fuer EdgeSwitch-Locate nennt, existiert auf dieser Firmware nicht — die zustaendige Kennung antwortet mit „kein solches Objekt", und ein Schreibversuch wird abgelehnt. Es ist also nicht „gelesen 0, also vermutlich schreibbar", sondern: die Funktion fehlt.

Wenn SSH aus ist — UpNrun zeigt dir den Weg

Manche Geraete kommen ab Werk ohne eingeschaltetes SSH — bei NETGEAR M4250/M4350 und Biamp Tesira steht das so im Handbuch des Herstellers, es ist dort also der Normalfall und kein Defekt. UpNrun braucht den Zugang aber, um Ports, PoE und Nachbarn auszulesen. Das ist ein Henne-Ei-Problem: ohne SSH kommt UpNrun nicht heran, um SSH einzuschalten.

Umgekehrt gilt der oft gehoerte Satz „bei einem EdgeSwitch ist SSH ab Werk aus“ nicht: an einem ES-8-150W mit Firmware 1.12.2-lite war SSH offen, ohne dass jemand etwas eingeschaltet hatte (nachgemessen am 29.07.2026). UpNrun behauptet darum nirgends, SSH sei ab Werk aus, sondern schreibt „falls SSH deaktiviert ist …“.

Darum sagt das Panel im Block Management-Zugang zuerst, woran man ist:

• SSH an — alles in Ordnung.
• SSH aus — das Geraet lebt (es antwortet auf seiner Weboberflaeche), nur der Zugang ist abgeschaltet.
• Geraet nicht erreichbar — gar keine Antwort. Dann zuerst Strom, Kabel und IP-Adresse pruefen; eine Anleitung zum Einschalten waere hier irrefuehrend.

Geprueft wird das mit einem einfachen Verbindungsversuch auf die Management-Ports — ohne Anmeldung, unabhaengig davon, ob Zugangsdaten hinterlegt sind.

Ist SSH aus, steht darunter eine Kurzanleitung fuer genau dieses Fabrikat, wo der Schalter in der Weboberflaeche des Geraets sitzt, samt Verweis auf ebendiese Oberflaeche. Der Verweis erscheint nur, wenn das Geraet dort wirklich antwortet. Fuer Geraete, deren Menuepfad noch nicht ueberprueft ist, steht ein allgemeiner Text — lieber ehrlich allgemein als falsch konkret.

Ubiquiti EdgeSwitch (am Geraet geprueft, ES-8-150W, Firmware 1.12.2-lite): Weboberflaeche oeffnen und anmelden (Werkszugang ubnt / ubnt) → links Settings → Abschnitt Services → Haken bei SSH → Save.

⚠ Die Falle, die einen halben Tag kostet: Bei vielen Herstellern oeffnet ein und dasselbe Konto die Weboberflaeche und SSH. Der EdgeSwitch zwingt beim ersten Aufruf der Weboberflaeche in einen Einrichtungsassistenten (eigenes Konto anlegen, Lizenzbedingungen bestaetigen) — SSH verlangt das nicht. Wer dabei ein neues Passwort vergibt, aendert damit auch das SSH-Passwort. Das Plugin arbeitet danach mit den alten Werksdaten weiter und bricht ab; es sieht aus, als haette das Einschalten von SSH das Geraet zerschossen. Deshalb: neues Passwort sofort in UpNrun eintragen. Dasselbe gilt bei NETGEAR, AMX, Crestron, Extron und Biamp; bei UniFi ersetzt die Adoption durch den Controller die Werksdaten.

Kurzanleitungen hinterlegt sind fuer Ubiquiti EdgeSwitch, Ubiquiti UniFi, NETGEAR M4250/M4350, Luminex GigaCore, Biamp Tesira, Extron, AMX NetLinx NX, Crestron, QSC Q-SYS Core sowie Mac und Windows. Zwei davon sagen bewusst, dass es nichts einzuschalten gibt: Luminex GigaCore und Q-SYS Core bieten Nutzern ueberhaupt keinen SSH-Zugang an. Das ist eine Information, kein Mangel — ein Knopf dafuer waere eine Luege.

Bei Geraeten, bei denen UpNrun einen belegten Weg ohne SSH hat, gibt es zusaetzlich den Knopf „SSH am Geraet einschalten“ (ab Rolle service); UpNrun erledigt es dann selbst ueber die Weboberflaeche des Geraets. Wo es diesen Weg nicht gibt, gibt es auch keinen Knopf, sondern einen Satz, der sagt warum — ein UniFi-Switch etwa hat im Werkszustand ueberhaupt keine Weboberflaeche.

SSH ausschalten ist die gefaehrliche Richtung und steht darum ganz unten, rot und mit Rueckfrage: danach kann UpNrun diesen Switch nicht mehr auslesen, und das Wiedereinschalten geht nur noch ueber die Weboberflaeche des Geraets. Auch das verlangt die Rolle service und wird protokolliert.

PoE schalten — Fernstart ohne Anfahrt

Haengt ein Geraet, laesst es sich ueber seinen Switchport stromlos machen und wieder starten. Das ersetzt die Fahrt ins Haus. Der Knopf greift sofort: das Geraet verliert augenblicklich den Strom, der Neustart dauert je nach Modell Sekunden bis Minuten.

Waehrend einer laufenden Show nicht benutzen. Ports ohne Verbraucher zeigen „Kein PoE“ und bieten keinen Schalter an.

Switch plugin — ports, PoE, labelling #

Every plugin in the Switch category is built the same way — UniFi, EdgeSwitch, NETGEAR AV Line, Luminex GigaCore. Only the way the device is talked to differs; the table looks identical everywhere:

Port name and device name belong to UpNrun

Both columns are deliberately not stored in the switch. A switch knows neither your wording nor the names from the device list — it reports MAC addresses and at best an LLDP identity. Because the labelling lives in UpNrun, it survives a device swap or a factory reset of the switch and needs no write access on the hardware. The device name is matched via MAC; an empty cell means nothing was detected on that port. Editing requires at least the service role, and every change is audited.

Locate — finding the right cable

Two levels, both purely visual: traffic is unaffected, so you can use them during a performance.

• Device locate (button under “Actions”) pulses all port LEDs once a second — for finding the right switch in the rack.
• Port locate (button in the port row) blinks only that one LED — for finding the right cable without unplugging anything.

Both stop by themselves (device: 5 minutes, port: 20 seconds); pressing again stops them at once. The blinking loop runs on the switch itself and restores the normal picture when it ends — even if the connection drops in between. No LED is ever left in test state.

The buttons only appear on devices that support it. Older models cannot drive individual port LEDs and therefore get no port locate button.

State as of 29 July 2026, broken down honestly:

• UniFi Pro Max — unlocked. Device locate (all port LEDs pulsing) has been seen on the device. The path had been built days earlier and worked — only the release marker was never set, so the button could not appear at all. Remember: a capability is only delivered once it is in the interface. A working path in the background does not exist for you.
• Ubiquiti EdgeSwitch — locked. The web path answers cleanly (start reports “running”, still after 10 seconds, stop reports “not running”), but nobody has seen the LED. A device's own claim is not proof. The button therefore stays locked, see Write paths & verification.

A side finding from the same measurement: the SNMP path the vendor documentation names for EdgeSwitch locate does not exist on this firmware — the responsible identifier answers “no such object”, and a write attempt is refused. So it is not “read 0, therefore probably writable”, it is: the feature is absent.

When SSH is off — UpNrun shows you the way

Some devices ship with SSH disabled — for NETGEAR M4250/M4350 and Biamp Tesira the vendor manual says so, and there it is the normal state, not a fault. But UpNrun needs that access to read ports, PoE and neighbours. That is a chicken-and-egg problem: without SSH, UpNrun cannot get in to turn SSH on.

The often-repeated claim “on an EdgeSwitch SSH is off from the factory” does not hold: on an ES-8-150W running firmware 1.12.2-lite, SSH was open without anyone having enabled it (measured 29 July 2026). UpNrun therefore never claims SSH is off from the factory; it says “if SSH is disabled …” instead.

So the Management access block tells you where you stand first:

• SSH on — all good.
• SSH off — the device is alive (its web interface answers), only the access is switched off.
• Device unreachable — no answer at all. Check power, cabling and IP address first; a guide to enabling SSH would be misleading here.

The check is a plain connection attempt to the management ports — no login, independent of whether credentials are stored.

If SSH is off, a short guide for that specific make follows, showing where the switch sits in the device's own web interface, together with a link to that interface. The link only appears if the device actually answers there. For devices whose menu path has not been verified yet, a generic text is shown — honestly generic beats wrongly specific.

Ubiquiti EdgeSwitch (verified on the device, ES-8-150W, firmware 1.12.2-lite): open the web interface and sign in (factory login ubnt / ubnt) → Settings in the left menu → Services section → tick SSH → Save.

⚠ The trap that costs you half a day: on many vendors one and the same account opens both the web interface and SSH. On first access the EdgeSwitch forces you through a setup wizard (create your own account, accept the licence terms) — SSH does not require that. If you set a new password there, you change the SSH password too. The plugin keeps using the old factory credentials and fails, and it looks as if enabling SSH had broken the device. So: enter the new password in UpNrun straight away. The same applies to NETGEAR, AMX, Crestron, Extron and Biamp; on UniFi it is adoption by the controller that replaces the factory credentials.

Short guides are stored for Ubiquiti EdgeSwitch, Ubiquiti UniFi, NETGEAR M4250/M4350, Luminex GigaCore, Biamp Tesira, Extron, AMX NetLinx NX, Crestron, QSC Q-SYS Core plus Mac and Windows. Two of them deliberately say there is nothing to enable: Luminex GigaCore and Q-SYS Core offer users no SSH access at all. That is information, not a shortcoming — a button for it would be a lie.

On devices where UpNrun has a proven path that does not need SSH, there is an extra button “Enable SSH on the device” (role service and above); UpNrun then does it for you through the device's web interface. Where no such path exists there is no button, but a sentence explaining why — a UniFi switch in factory state, for instance, has no web interface at all.

Turning SSH off is the dangerous direction and therefore sits at the very bottom, in red and behind a confirmation: afterwards UpNrun can no longer read this switch, and re-enabling it is only possible through the device's own web interface. It too requires the service role and is audited.

Switching PoE — remote restart without a site visit

If a device hangs, you can cut power at its switch port and bring it back. That replaces the drive to the venue. The button takes effect immediately: the device loses power at once, and rebooting takes seconds to minutes depending on the model.

Do not use during a running show. Ports with no consumer show “no PoE” and offer no switch.

Schreibpfade & Verifikation #

UpNrun schreibt nicht blind auf Geraete. Ein Knopf, der etwas veraendert, wird erst freigegeben, wenn genau dieser Weg an echter Hardware durchgespielt wurde: ausloesen, die Wirkung am Geraet messen, den Ausgangszustand wiederherstellen. Eine erfolgreiche Antwort des Geraets genuegt nicht — viele Protokolle quittieren einen Befehl, ohne ihn ausgefuehrt zu haben, und Art-Net quittiert ueberhaupt nie.

Ist ein Weg noch nicht belegt, bleibt der Knopf sichtbar, aber gesperrt, mit dem Hinweis „Write unverifiziert“. Das ist Absicht: ein gesperrter Knopf mit ehrlicher Begruendung ist besser als einer, der vielleicht funktioniert.

Die Bewertung gilt pro Aktion

Ein Plugin hat fast immer mehrere Schreibwege mit sehr unterschiedlicher Beweislage. Beim UniFi-Switch ist das PoE-Schalten an echter Hardware gemessen; das LED-Blinken der Locate-Funktion dagegen kann niemand aus der Ferne pruefen — dafuer muss jemand vor dem Geraet stehen. Darum haengt die Bewertung an der einzelnen Aktion und nicht am ganzen Plugin: der eine Knopf ist scharf, der andere bleibt gesperrt.

Gegenlesen nach jedem Schreiben

Nach einer Aenderung wird der Ist-Zustand neu gelesen und mit dem Soll verglichen. Weicht er ab, nennt das Panel die konkrete Abweichung statt eines pauschalen „gespeichert“. Antwortet das Geraet gar nicht, wird erst gar nicht geschrieben — lieber keine Aenderung als eine blinde.

Write paths & verification #

UpNrun does not write to devices blindly. A button that changes something is only unlocked once that exact path has been exercised on real hardware: trigger it, measure the effect on the device, restore the original state. A successful response from the device is not enough — many protocols acknowledge a command without having carried it out, and Art-Net never acknowledges at all.

While a path is unproven the button stays visible but locked, labelled “write unverified”. That is deliberate: a locked button with an honest reason beats one that might work.

The assessment is per action

A plugin almost always has several write paths with very different evidence behind them. On the UniFi switch, PoE switching has been measured on real hardware; the LED blink of the locate function, by contrast, cannot be checked remotely — someone has to stand in front of the device. The assessment therefore belongs to the individual action, not to the whole plugin: one button is live while another stays locked.

Read-back after every write

After a change the current state is read again and compared with the intended one. On a mismatch the panel names the concrete difference instead of a blanket “saved”. If the device does not answer at all, nothing is written — better no change than a blind one.

Geräte-Weboberflächen über den Tunnel #

Sieht der Scan an einem Gerät einen Web-Port, zeigt das Geräte-Detail den Knopf „Web-UI öffnen“. In der Plattform öffnet er die Oberfläche des Geräts getunnelt über den Onsite-Relay des Standorts — ohne VPN, ohne Anfahrt. In der lokalen OnSite-App ist derselbe Knopf ein direkter LAN-Link.

Was sich am 29.07.2026 geändert hat

Der Knopf gab es vorher schon, nur führte er fast immer auf eine leere Seite. Gemessen an Theater Uri: von 59 Geräten antworteten 5 über den Tunnel überhaupt mit HTTP 200 — benutzbar war keines. Das HTML kam an, aber alles darin zeigte wurzel-absolut (/index.css). Der Browser löste das gegen die Plattform-Wurzel auf, wo unbekannte Pfade mit einer leeren 200 beantwortet werden: jede Datei kam mit 0 Bytes und ohne Fehlermeldung. Genau deshalb ist der Fehler jahrelang niemandem aufgefallen — es sah aus wie eine kaputte Geräteseite, nicht wie ein kaputter Tunnel.

Stand danach: 14 von 17 auffindbaren Weboberflächen sind benutzbar. Die eine Seite, die vorher „ging“, war eine nginx-Platzhalterseite ohne eigene Dateien.

Wie es funktioniert

Zwei Stufen greifen ineinander, beide arbeiten fehlertolerant — keine von beiden darf je der Grund sein, dass eine Seite langsamer lädt oder gar nicht kommt:

• Umschreiber auf dem Server: ersetzt in der Antwort des Geräts href, src, action, formaction, poster, srcset-Listen, url(/…) in CSS, das vom Gerät gelieferte <base> und absolute Selbstverweise auf die eigene LAN-Adresse. Der Zeichensatz wird nicht geraten, sondern aus Content-Type, @charset und <meta charset> gelesen — an einer echten ISO-8859-1-Seite belegt, deren Rumpf byte-identisch zurückkommt.
• Kleiner Helfer im Browser: fängt, was erst zur Laufzeit entsteht — fetch, XHR, History-Navigation, img.src, link.href, script.src, iframe.src, form.action, setAttribute, srcset, das style-Attribut und absolute Adressen auf die eigene Herkunft.

Weitere Fallen, die nebenbei behoben wurden: Cookies des Geräts mit Path=/ streuten vorher über alle Gerätetunnel derselben Herkunft und werden jetzt auf den eigenen Tunnelpfad eingegrenzt; ein Domain=<LAN-IP> wird entfernt, weil der Browser solche Cookies komplett verwarf und der Geräte-Login dann endlos im Kreis lief. Und Schreibaktionen gehen jetzt: PUT, PATCH, DELETE und OPTIONS sind freigegeben — vorher scheiterte jede Änderung an einem Gerät mit HTTP 405.

Das braune Band — gemessen, nicht geraten

Was ein Gerät seine Adressen erst im Browser zusammenbauen lässt (Zeichenketten über mehrere Funktionen, Worker, CSS aus JavaScript), entkommt beiden Stufen. Solche Anfragen scheitern lautlos. Darum misst die Seite mit: sie liest die Liste der tatsächlich geladenen Ressourcen und meldet jede, die am Tunnel vorbeigelaufen ist.

Erst dann erscheint oben ein braunes Band mit der Anzahl und einem Knopf Details, der die betroffenen Pfade namentlich nennt. Es erscheint nur, wenn wirklich etwas vorbeigelaufen ist — eine Warnung auf jeder Seite wäre Rauschen und damit wertlos. Steht das Band da, fehlt auf der Seite etwas, und es liegt am Gerät, nicht an der Verbindung.

Was der Tunnel nicht kann

Diese drei Grenzen sind bekannt und gemessen. Sie stehen hier, damit niemand danach sucht:

• WebSockets gehen nicht. Dafür fehlt die Route. Geräteoberflächen, die Live-Werte über eine WebSocket-Verbindung nachladen, zeigen diese Werte im Tunnel nicht.
• HTTPS nach IP-Adresse geht nicht. Der vorgelagerte Webserver lehnt eine TLS-Verbindung ab, die statt eines Namens eine IP-Adresse trägt (SNI per IP).
• Drei Geräte sprechen auf Port 80 gar kein HTTP. Sie haben einen offenen Port, aber kein Web dahinter. Kein Tunnel der Welt ändert daran etwas.

Nebenwirkung, die man kennen muss: jede geladene Datei erzeugt einen eigenen Eintrag im Audit-Log. Eine einzige geöffnete EdgeSwitch-Seite schreibt dadurch Dutzende Zeilen statt einer. Das ist gewollt (jeder Zugriff auf Kundeninfrastruktur wird protokolliert), macht das Protokoll bei viel Tunnelbetrieb aber deutlich länger.

Sicherheitsriegel

Der Tunnel ist kein offener Proxy. Es gelten alle Riegel gleichzeitig:

• Rolle: ab Service. Der Kill-Switch der Anlage sperrt ihn sofort.
• Nur Ziele aus dem Bestand: eine Adresse, die im Gerätebestand der Anlage nicht vorkommt, wird abgewiesen. Quelle ist der persistente Bestand der Onsite, vereinigt mit dem Scan-Cache — vorher zählte nur der zuletzt gelaufene Scan-Job, weshalb ein Switch im AV-Netz abgelehnt wurde, obwohl er sauber im Bestand stand.
• Nur private oder eigene Netze: zulässig sind RFC-1918-Adressen und Netze, die die Onsite nachweislich selbst führt. Das ist nötig, weil Lichttechnik ab Werk auf 2.x.x.x steht. Ausdrücklich nicht zulässig: das UpNrun-Mesh (sonst wären die Boxen anderer Kunden antunnelbar), Loopback, Link-Local, Multicast und jedes Netz, das gröber als /16 geschnitten ist.
• Nur Web-Ports: Dienst-Ports wie SSH sind gesperrt.

Live gegen die Produktion gegengeprüft, alle mit 403 abgewiesen: eine öffentliche Adresse, eine fremde Mesh-Adresse, die eigene Mesh-Adresse, eine Adresse, die nicht im Bestand steht, ein Dienst-Port und die Cloud-Metadaten-Adresse. Positivprobe: ein Gerät aus dem Bestand mit 200.

Device web interfaces through the tunnel #

When the scan sees a web port on a device, the device detail shows the “Open Web UI” button. On the platform it opens the device's own interface tunnelled through the site's onsite relay — no VPN, no site visit. In the local OnSite app the same button is a direct LAN link.

What changed on 29 July 2026

The button existed before, but it almost always led to a blank page. Measured at Theater Uri: of 59 devices, 5 answered through the tunnel with HTTP 200 at all — none was usable. The HTML arrived, but everything inside it pointed at the root (/index.css). The browser resolved that against the platform root, where unknown paths are answered with an empty 200: every file arrived with 0 bytes and no error. That is exactly why the fault went unnoticed for years — it looked like a broken device page, not a broken tunnel.

State afterwards: 14 of 17 discoverable web interfaces are usable. The one page that “worked” before was an nginx placeholder page with no assets of its own.

How it works

Two stages interlock, both fail-soft — neither may ever be the reason a page loads slower or not at all:

• Rewriter on the server: in the device's response it rewrites href, src, action, formaction, poster, srcset lists, url(/…) in CSS, the <base> the device supplies, and absolute self-references to its own LAN address. The character set is not guessed but read from Content-Type, @charset and <meta charset> — proven on a real ISO-8859-1 page whose body comes back byte-identical.
• Small helper in the browser: catches what is only assembled at runtime — fetch, XHR, history navigation, img.src, link.href, script.src, iframe.src, form.action, setAttribute, srcset, the style attribute and absolute URLs on the page's own origin.

Traps fixed along the way: device cookies with Path=/ used to spill across all device tunnels of the same origin and are now confined to their own tunnel path; a Domain=<LAN IP> is stripped, because browsers discarded such cookies entirely and the device login then bounced forever. And write actions work now: PUT, PATCH, DELETE and OPTIONS are allowed — previously every change on a device failed with HTTP 405.

The brown banner — measured, not guessed

Whatever a device assembles only inside the browser (strings built across several functions, Worker, CSS generated from JavaScript) escapes both stages. Such requests fail silently. So the page measures: it reads the list of resources actually loaded and reports every one that bypassed the tunnel.

Only then does a brown banner appear at the top, with the count and a Details button naming the affected paths. It appears only if something really bypassed the tunnel — a warning on every page would be noise and therefore worthless. If the banner is there, something on the page is missing, and it is the device's doing, not the connection's.

What the tunnel cannot do

These three limits are known and measured. They are listed here so nobody hunts for them:

• WebSockets do not work. The route for them is missing. Device interfaces that pull live values over a WebSocket connection will not show those values in the tunnel.
• HTTPS by IP address does not work. The upstream web server rejects a TLS connection that carries an IP address instead of a name (SNI by IP).
• Three devices speak no HTTP at all on port 80. They have an open port but no web behind it. No tunnel can change that.

A side effect you should know about: every loaded file produces its own entry in the audit log. A single opened EdgeSwitch page therefore writes dozens of lines instead of one. That is intentional (every access to customer infrastructure is recorded), but it makes the log considerably longer under heavy tunnel use.

Security guards

The tunnel is not an open proxy. All guards apply at once:

• Role: Service and above. The site's kill switch blocks it immediately.
• Only targets from the inventory: an address that does not appear in the site's device inventory is refused. The source is the onsite's persistent inventory merged with the scan cache — previously only the last scan job counted, which is why a switch in the AV network was rejected although it was cleanly in the inventory.
• Only private or own networks: RFC 1918 addresses and networks the onsite demonstrably carries itself are allowed. This is necessary because lighting equipment ships on 2.x.x.x. Explicitly not allowed: the UpNrun mesh (otherwise other customers' boxes could be tunnelled to), loopback, link-local, multicast, and any network cut coarser than /16.
• Only web ports: service ports such as SSH are blocked.

Cross-checked live against production, all refused with 403: a public address, a foreign mesh address, our own mesh address, an address not in the inventory, a service port, and the cloud metadata address. Positive control: a device from the inventory with 200.

Alarme entstehen am Standort #

Seit dem 29.07.2026 erkennt die Onsite-Box die Alarme ihrer Anlage selbst und meldet sie an die Plattform. Gesehen, quittiert und abonniert werden sie unverändert im Alarm-Zentrum der Plattform — nur das Erkennen ist umgezogen.

Warum

Vorher lief auf der Plattform ein Hintergrund-Durchlauf, der im Minutentakt jede Anlage über das Mesh nach ihrem Status fragte. Gemessen am 29.07. auf dem Server: 7 Anlagen, 0,75 / 0,75 / 2,91 Sekunden je Durchlauf, 1440 Durchläufe am Tag — 10 080 Mesh-Abfragen täglich für 163 Gerätedatensätze pro Runde. Bei hundert Anlagen dieselbe Rechnung mal vierzehn, und das für Daten, die auf jeder Box ohnehin bei jedem Scan entstehen.

Der zweite, wichtigere Grund: riss die Verbindung zur Plattform, hörte die Überwachung auf — obwohl die Box direkt neben den Geräten steht und sie weiterhin sieht.

Wie es jetzt läuft

• Die Box prüft ihre Geräte im 60-Sekunden-Takt. Die Live-Abfrage der Switches läuft in einem eigenen, langsameren Takt (300 Sekunden), weil sie je Switch 2–6 Sekunden kostet.
• Gemeldet wird über den bestehenden Heartbeat — kein zweiter Kanal, kein zweites Anmeldeverfahren.
• Die Plattform pollt eine Anlage mit frischem Bericht nicht mehr. Mit dem echten Bericht aus Theater Uri gemessen: gepollte Anlagen 8 → 7, und die 14 Alarme der Anlage stehen trotzdem im Alarm-Zentrum.
• Ohne Plattform zeigt die Box ihre Lage weiterhin selbst an.

Der Übergang — keine Anlage wird stumm

Das ist der Teil, der im Feld zählt:

• Eine Box mit altem Stand meldet nichts → ihre Anlage wird unverändert weiter gepollt.
• Eine Box, die verstummt, veraltet ihren Bericht (nach 300 Sekunden) → die Anlage geht zurück in den Poll. Scheitert der, entsteht wie bisher „Site nicht erreichbar“.
• Eine aktualisierte Box an einer alten Plattform ist harmlos — die Plattform nimmt den Heartbeat mit dem neuen Feld an und ignoriert es.

Die Monitorpunkte: 8 tote wurden einzeln entschieden

„Tot“ heisst: der Punkt stand im Bedienfeld und versprach einen Alarm, konnte aber nie auslösen. Statt sie pauschal mitzunehmen, wurde jeder einzeln geprüft:

Wer den Alarm „PoE-Überlast“ sucht, sucht vergeblich. Er ist ersatzlos entfernt, und das ist Absicht: ein Alarm, der nie auslösen kann, ist eine Lüge im Bedienfeld. Sollte eine Switch-Familie später ein echtes Budget liefern, kommt er zurück — die Begründung und der Weg zurück stehen im Quelltext.

link_down hat jetzt eine ehrliche Bedeutung: ein Port, der in der Vorrunde eine Verbindung hatte, hat jetzt keine mehr. Nicht „irgendein Port ist unten“ — das wäre an einem 48-Port-Switch ein Dauer-Alarm. Ohne Vorrunde gibt es kein Urteil; es wird keine Historie erfunden.

Zusätzlich abgesichert: ein Monitorpunkt, dessen Wert in den gelesenen Daten fehlt, wird gar nicht erst ausgewertet. Vorher hätte ein fehlender Wert einen Alarm aus dem Nichts erzeugen können.

Alarms are raised on site #

Since 29 July 2026 the onsite box detects its site's alarms itself and reports them to the platform. They are still seen, acknowledged and subscribed to in the platform's alarm centre — only the detection moved.

Why

Previously a background sweep on the platform asked every site for its status over the mesh once a minute. Measured on 29 July on the server: 7 sites, 0.75 / 0.75 / 2.91 seconds per round, 1440 rounds a day — 10,080 mesh round trips daily for 163 device records per round. With a hundred sites, the same arithmetic times fourteen — for data that is produced on every box during every scan anyway.

The second and more important reason: when the link to the platform broke, monitoring stopped — although the box stands right next to the devices and still sees them.

How it works now

• The box checks its devices every 60 seconds. The live query of the switches runs on its own, slower cycle (300 seconds), because it costs 2–6 seconds per switch.
• Reporting happens over the existing heartbeat — no second channel, no second authentication model.
• The platform no longer polls a site with a fresh report. Measured with the real report from Theater Uri: polled sites 8 → 7, and the site's 14 alarms still appear in the alarm centre.
• Without the platform the box still shows its own situation.

The transition — no site goes silent

• A box on an old build reports nothing → its site keeps being polled unchanged.
• A box that falls silent lets its report go stale (after 300 seconds) → the site returns to polling. If that fails, “site unreachable” is raised as before.
• An updated box on an old platform is harmless — the platform accepts the heartbeat carrying the new field and ignores it.

Monitor points: eight dead ones, decided individually

“Dead” means the point sat in the panel promising an alarm but could never fire. Instead of migrating them wholesale, each was examined:

Looking for the “PoE overload” alarm is pointless. It has been removed without replacement, deliberately: an alarm that can never fire is a lie in the control panel. Should a switch family later report a real budget, it comes back — the reasoning and the way back are recorded in the source.

link_down now has an honest meaning: a port that had a link in the previous round has none now. Not “some port is down” — on a 48-port switch that would be a permanent alarm. Without a previous round there is no verdict; no history is invented.

Additionally guarded: a monitor point whose value is missing from the data read is not evaluated at all. Previously a missing value could have produced an alarm out of nothing.

Gerätetyp aus Evidenz #

Der Typ in der Geräteliste ist eine Schlussfolgerung, keine Tatsache. Seit dem 29.07.2026 sagt UpNrun dazu, worauf die Schlussfolgerung beruht — und schweigt, wo sie nicht trägt.

Der Anlass

Ein Ubiquiti EdgeSwitch stand in der Geräteliste als Access Point. Alles, was über ihn bekannt war: der Hersteller aus der MAC-Adresse und zwei offene Web-Ports — und „Ubiquiti“ stand in der Access-Point-Herstellerliste. Vier Ursachen lagen übereinander, alle behoben.

Ein Hersteller allein sagt nichts über den Typ

Ubiquiti, Cisco, Aruba und Meraki bauen Switches und Access Points und Router. Wo nur der Hersteller bekannt ist, steht jetzt „Network Device“ — Hersteller belegt, Typ unbestimmt. Ein falsches Etikett ist schlimmer als ein unbestimmtes.

Die Regel steht bewusst am Ende der Erkennung: jeder echte Hinweis davor gewinnt weiter — Hostname, Windows-Dienste, Helper-Port. An Theater Uri hängen 13 Proxmox-VMs, deren MAC-Präfix in der Herstellerdatenbank als „Cisco“ geführt wird und die bis dahin alle als „Router/Gateway“ in der Liste standen; eine davon heisst DESKTOP-B00UB0N-2 und ist jetzt korrekt ein Windows-Rechner.

Zwei Quellen, die vorher gar nicht sprachen

• SNMP lief strukturell nie. Zwei Fehler übereinander sorgten dafür, dass kein einziges der 66 Geräte je eine Systembeschreibung hatte — obwohl der Switch auf SNMP in 2,1 Millisekunden sauber antwortet.
• Geräte in Zusatznetzen bekamen überhaupt keine Anreicherung, weder SNMP noch Betriebssystem- oder Firmware-Abfrage. Beides steckte nur im Hauptnetz-Zweig. Der fragliche Switch steht im AV-Netz — dort hat nie jemand gefragt.
• Neu: Ubiquiti-Discovery. Eine kurze Anfrage auf UDP-Port 10001 liefert Plattform und Modell direkt vom Gerät (gemessen: ES-8-150W / „EdgeSwitch 8 150W“ in 5,1 ms; U7PG2 / „UAP-AC-Pro-Gen2“ in 2,6 ms) — genau die Unterscheidung, die die MAC-Adresse nicht hergibt.

Beide Runden kosten feste Wanduhrzeit (je 0,905 s), unabhängig davon, wie viele Geräte im Netz stehen. Jeder Fehler dabei ist still — nichts davon kann einen Scan abbrechen.

Firmware-Angaben verfallen jetzt

Der Zwischenspeicher für Betriebssystem und Firmware wurde früher einmal gefüllt und nie wieder. Ein Switch führte dadurch monatelang „lighttpd“ als Firmware — das war sein Webserver, gelesen aus einem alten Lauf unter seiner damaligen Adresse. Der Wert verfällt jetzt nach 6 Stunden. Läuft die Abfrage ins Leere, bleibt der bisherige Wert stehen, statt gelöscht zu werden.

Ergebnis am echten Bestand

Auf der Onsite von Theater Uri gemessen: der EdgeSwitch ist jetzt ein Switch (Modell „EdgeSwitch 8 150W“), der echte Access Point bleibt ein Access Point (Modell „UAP-AC-Pro-Gen2“). Geräte, deren Typ allein aus dem Hersteller stammte: 34 von 66 → 29. Als „Access Point“ geführte Geräte: 2 → 1 — nur noch der echte.

Device type from evidence #

The type in the device list is a conclusion, not a fact. Since 29 July 2026 UpNrun says what the conclusion rests on — and stays silent where it does not hold.

The trigger

A Ubiquiti EdgeSwitch was listed as an Access Point. All that was known about it: the vendor from its MAC address and two open web ports — and “Ubiquiti” appeared in the access-point vendor list. Four causes sat on top of each other, all fixed.

A vendor alone says nothing about the type

Ubiquiti, Cisco, Aruba and Meraki build switches and access points and routers. Where only the vendor is known, the entry now reads “Network Device” — vendor proven, type undetermined. A wrong label is worse than an undetermined one.

The rule deliberately sits at the end of the detection chain: every real hint before it still wins — hostname, Windows services, helper port. At Theater Uri there are 13 Proxmox VMs whose MAC prefix the vendor database lists as “Cisco” and which had all been shown as “Router/Gateway”; one of them is called DESKTOP-B00UB0N-2 and is now correctly a Windows machine.

Two sources that never spoke before

• SNMP structurally never ran. Two faults on top of each other meant that not one of the 66 devices ever had a system description — although the switch answers SNMP cleanly in 2.1 milliseconds.
• Devices in additional networks got no enrichment at all, neither SNMP nor operating-system or firmware queries. Both lived only in the main-network branch. The switch in question sits in the AV network — where nobody ever asked.
• New: Ubiquiti discovery. A short request on UDP port 10001 returns platform and model straight from the device (measured: ES-8-150W / “EdgeSwitch 8 150W” in 5.1 ms; U7PG2 / “UAP-AC-Pro-Gen2” in 2.6 ms) — exactly the distinction the MAC address cannot provide.

Both rounds cost fixed wall-clock time (0.905 s each), regardless of how many devices are on the network. Every error in them is silent — none of it can abort a scan.

Firmware readings now expire

The cache for operating system and firmware used to be filled once and never again. One switch therefore carried “lighttpd” as its firmware for months — that was its web server, read during an old run under its then address. The value now expires after 6 hours. If the query comes back empty, the previous value stays rather than being deleted.

Result on the real inventory

Measured on the onsite box at Theater Uri: the EdgeSwitch is now a Switch (model “EdgeSwitch 8 150W”), the real access point stays an Access Point (model “UAP-AC-Pro-Gen2”). Devices whose type came from the vendor alone: 34 of 66 → 29. Devices listed as “Access Point”: 2 → 1 — only the real one.

Plugin-Sparten (für Entwickler) #

Dieser Abschnitt richtet sich an alle, die Plugins bauen oder pflegen. Für die tägliche Arbeit an einer Anlage braucht man ihn nicht.

Jedes Plugin gehört zu einer Sparte (family). Bis zum 28.07.2026 war das ein Freitextfeld: gemessen standen 126 Plugins in 108 „Sparten“, die meisten mit genau einem Mitglied. Seit dem 29.07.2026 gibt es ein geschlossenes Vokabular mit 24 Sparten.

Die Zuschnitt-Regel

Geschnitten wird nach Bedienoberfläche, nicht nach Marketing: zwei Geräte gehören in dieselbe Sparte, wenn ein Techniker im Panel dieselben Felder und Knöpfe erwartet. Ein Luminex GigaCore heisst beim Hersteller „AV Switch“, zeigt aber dieselbe Porttabelle wie jeder andere Switch — also gehört er in die Sparte Switch. Lieber wenige grosse Sparten als viele kleine; eine Sparte mit einem einzigen Mitglied ist ein Warnzeichen, kein Ziel.

Zwei Stufen, ehrlich benannt

• geräteführend — das Panel hat eine Sparten-Tabelle, Aktionen und/oder Konfiguration. Hier gilt der volle Vertrag: derselbe Renderer, Pflichtfelder, ein verdrahteter Live-Abfrageweg. Ausformuliert sind bisher genau zwei: Switch und Lighting Node.
• lesend — das Panel ist ein Steckbrief: erreichbar, ein paar Banner- und Versionsfelder, ein Aktualisieren. Network Service ist der Sammelfall.

Ein fehlender Vertragsschlüssel heisst nicht „egal“, sondern „für diese Sparte noch nicht festgeschrieben“. Der Test macht diese Lücken sichtbar, statt sie zu erfinden.

Die 24 Sparten

Netzwerk und Licht: Switch · Lighting Node · Lighting Console · Lighting Network
Audio: Audio DSP · Mixer · Amplifier · Wireless Microphone · AV Network
Video und Medien: Projector · Display · Video Switcher · Video Router · Media Server · Media Player · Recorder · Camera
Steuerung und Gebäude: Control System · Show Control · Collaboration · Building Automation · Intercom · Computer
Dienste: Network Service

Der Test lässt den Bestand stehen, deckelt ihn aber

Die Umstellung ist rein additiv: kein Deskriptor wurde automatisch umgezogen. Der Test führt die noch abweichenden Altbestände als namentlich benannte Altlast, deckelt ihre Zahl und fällt bei jeder neuen Abweichung. Wer ein Plugin mit einer eigenen Sparte anlegt, merkt es sofort.

Das Vokabular fand am ersten Tag drei echte Lücken — unter anderem, dass der Luminex GigaCore in der Registry der Live-Abfragen fehlte. Genau das war die Ursache seiner toten Monitorpunkte.

Noch offen: das Feld family erscheint heute als Untertitel im Panel (IP · Sparte). Sobald aus „Datenbank (PostgreSQL)“ die Sparte Network Service wird, verliert dieser Untertitel seine Aussage — der beschreibende Text muss dann aus dem Protokollfeld kommen.

Plugin categories (for developers) #

This section is for anyone building or maintaining plugins. It is not needed for day-to-day work on a site.

Every plugin belongs to a category (family). Until 28 July 2026 this was a free-text field: measured, 126 plugins sat in 108 “categories”, most of them with exactly one member. Since 29 July 2026 there is a closed vocabulary of 24 categories.

The cutting rule

Categories are cut by operating surface, not by marketing: two devices belong to the same category if a technician expects the same fields and buttons in the panel. A Luminex GigaCore is called an “AV switch” by its vendor but shows the same port table as any other switch — so it belongs to Switch. Prefer few large categories over many small ones; a category with a single member is a warning sign, not a goal.

Two levels, honestly named

• device-leading — the panel has a category table, actions and/or configuration. The full contract applies: the same renderer, mandatory fields, a wired live query path. Exactly two are spelled out so far: Switch and Lighting Node.
• read-only — the panel is a profile: reachable, a few banner and version fields, a refresh. Network Service is the catch-all.

A missing contract key does not mean “anything goes”, it means “not yet pinned down for this category”. The test makes those gaps visible instead of inventing them.

The 24 categories

Network and lighting: Switch · Lighting Node · Lighting Console · Lighting Network
Audio: Audio DSP · Mixer · Amplifier · Wireless Microphone · AV Network
Video and media: Projector · Display · Video Switcher · Video Router · Media Server · Media Player · Recorder · Camera
Control and building: Control System · Show Control · Collaboration · Building Automation · Intercom · Computer
Services: Network Service

The test leaves the legacy stock in place but caps it

The change is purely additive: no descriptor was migrated automatically. The test carries the remaining deviations as named legacy, caps their number and fails on every new deviation. Anyone creating a plugin with a category of their own notices immediately.

On its first day the vocabulary found three real gaps — among them that the Luminex GigaCore was missing from the live-query registry. That was precisely the cause of its dead monitor points.

Still open: the family field is currently shown as the panel subtitle (IP · category). Once “Database (PostgreSQL)” becomes the category Network Service, that subtitle loses its meaning — the descriptive text will then have to come from the protocol field.

OnSite-Pi: Startzeit #

Ein OnSite-Pi startet in 55,4 Sekunden. Am 29.07.2026 wurde gemessen, wohin die Zeit geht — und ein zweites, schnell startendes Abbild gebaut.

Die Messung

Die Aufteilung sah nach 33 Sekunden Kernel und 22 Sekunden Systemstart aus. Die 33 Sekunden sind keine Kernel-Zeit: der Kernel übergibt bereits nach 1,1 Sekunden, und die Wurzel wird erst nach 32,5 Sekunden eingehängt. Dazwischen liegen 31,4 Sekunden mit genau einer Logzeile.

Der Zwischenstart (initramfs) tut auf dieser Box nachweislich nichts: er enthält 0 Module, die benötigten Dateisysteme sind fest im Kernel, die Partition ist bereits nach 1,0 Sekunden da, und alle vier Arbeitsskripte steigen sofort wieder aus. Übrig bleibt ein Wartelauf mit 30 Sekunden Vorgabe, dessen Verzeichnis nicht einmal existiert.

Widerlegt statt geglaubt — das gehört zur Messung dazu: die Dateisystemprüfung kostet 3,7 Sekunden warm / 5,4 kalt und ist nicht die Ursache; die Startreihenfolge nimmt die SD-Karte zuerst; es liegen keine Wiederherstellungsdateien auf der Boot-Partition; die Auflösung der Partitionskennung dauert 0,046 Sekunden; und das System ist das richtige Raspberry Pi OS mit dem Pi-eigenen Kernel. Es ist Konfiguration, nicht das falsche Betriebssystem.

Das Schnellstart-Abbild

Ein Skript baut aus einem vorhandenen Golden Image ein zweites, schnell startendes Abbild. Das Quell-Abbild wird nur gelesen. Alle Änderungen liegen auf der Boot-Partition und sind auf der gebrannten Karte mit einem Texteditor rückgängig zu machen (die Originaldateien liegen mit der Endung .vor-schnellstart daneben). Geändert wird: der Zwischenstart wird abgeschaltet, die verlorengegangenen Ruhig-Startoptionen kommen zurück, und zwei Dienste werden stillgelegt, die auf dieser Box nichts tun (4,4 bzw. 3,8 Sekunden).

Bewusst nicht abgeschaltet: mDNS (das ist die Onsite-Erkennung), das Warten auf das Netz (sechs Dienste hängen daran), die Erstinstallation und die Kopplung. An diesen vier wird vor einem Kundeneinsatz nicht gedreht.

Noch nicht am Gerät belegt

Niemand hat von diesem Abbild gebootet. Es stand weder eine zweite SD-Karte noch ein freier Pi bereit; der laufende Pi wurde nur lesend gemessen. Die 31,4 Sekunden Leerlauf sind belegt, die Wirkung der Änderung ist es nicht.

Was keine Konfiguration löst: die verbaute SD-Karte stammt von 2015 und läuft im High-Speed-Modus mit gemessenen 22,3 MB/s — exakt der Deckel dieses Modus. Der Controller im Pi könnte mehr. Eine neuere Karte ist der zweitgrösste Hebel, und den kann keine Datei ersetzen.

OnSite Pi: boot time #

An OnSite Pi boots in 55.4 seconds. On 29 July 2026 we measured where the time goes — and built a second, fast-booting image.

The measurement

The split looked like 33 seconds of kernel and 22 seconds of system start. Those 33 seconds are not kernel time: the kernel hands over after 1.1 seconds, and the root filesystem is only mounted after 32.5 seconds. In between lie 31.4 seconds with exactly one log line.

The intermediate boot stage (initramfs) demonstrably does nothing on this box: it contains 0 modules, the required filesystems are built into the kernel, the partition already exists after 1.0 seconds, and all four worker scripts exit immediately. What remains is a wait loop with a 30-second default whose directory does not even exist.

Disproven rather than believed — that is part of the measurement: the filesystem check costs 3.7 seconds warm / 5.4 cold and is not the cause; the boot order takes the SD card first; there are no recovery files on the boot partition; resolving the partition identifier takes 0.046 seconds; and the system is the correct Raspberry Pi OS with the Pi's own kernel. It is configuration, not the wrong operating system.

The fast-boot image

A script builds a second, fast-booting image from an existing golden image. The source image is only read. All changes live on the boot partition and can be undone on the burnt card with a text editor (the originals sit next to them with a .vor-schnellstart suffix). Changed are: the intermediate boot stage is disabled, the lost quiet-boot options are restored, and two services are masked that do nothing on this box (4.4 and 3.8 seconds).

Deliberately not disabled: mDNS (that is onsite discovery), waiting for the network (six services depend on it), the first-boot installation, and coupling. Those four are not touched before a customer deployment.

Not yet proven on the device

Nobody has booted from this image. Neither a second SD card nor a spare Pi was available; the running Pi was measured read-only. The 31.4 seconds of idling are proven, the effect of the change is not.

What no configuration solves: the fitted SD card dates from 2015 and runs in high-speed mode at a measured 22.3 MB/s — exactly the ceiling of that mode. The controller in the Pi could do more. A newer card is the second-biggest lever, and no file can replace it.

Gerätepasswörter und Export #

UpNrun speichert Zugangsdaten für Geräte, um Switches, Endstufen und Steuerungen auslesen zu können. Verlassen Einstellungen die App — als Export oder in einer Projektdatei (.upnrun) — werden gespeicherte Passwörter durch einen Platzhalter ersetzt.

Die Lücke vom 29.07.2026

Vier Gerätefamilien speichern Zugangsdaten. In der Liste, nach der die Bereinigung arbeitet, standen nur zwei. Die beiden anderen kamen im Klartext heraus, während die ersten beiden sauber als Platzhalter erschienen. Es brauchte keinen Angriff — es genügte, die Einstellungen auszulesen. Besonders betroffen war der Projekt-Export, der sich genau auf diese Bereinigung verlässt. Behoben.

Warum ein Gerätepasswort kein kleines Passwort ist

Mit einem Switch-Passwort lassen sich VLANs ändern, Ports abschalten und PoE kappen. In einem Theater während einer Vorstellung reicht das, um das Licht auszuschalten. Und eine Plattform, die die Zugangsdaten hunderter Anlagen bündelt, ist ein deutlich lohnenderes Ziel als ein einzelner Switch.

Der Riegel

Ein Test leitet die Liste der speichernden Gerätefamilien aus dem Quelltext ab und schlägt fehl, sobald jemand eine neue Familie anlegt, ohne sie in die Bereinigung einzutragen. Zusätzlich wird die tatsächliche Wirkung geprüft, nicht nur die Liste — und es wird geprüft, dass keine Karteileichen darin stehen.

Was du trotzdem tun solltest: eine exportierte Projektdatei ist kein Geheimnisträger, aber sie enthält den vollständigen Gerätebestand einer Anlage mit Adressen, Hostnamen und offenen Diensten. Sie gehört behandelt wie eine Netzdokumentation, nicht wie ein Screenshot.

Device passwords and export #

UpNrun stores device credentials so it can read switches, amplifiers and control systems. When settings leave the app — as an export or inside a project file (.upnrun) — stored passwords are replaced with a placeholder.

The gap found on 29 July 2026

Four device families store credentials. The list the sanitiser works from contained only two. The other two came out in clear text while the first two appeared cleanly as placeholders. No attack was needed — reading the settings was enough. The project export, which relies on exactly this sanitising step, was particularly affected. Fixed.

Why a device password is not a small password

A switch password allows VLANs to be changed, ports to be shut down and PoE to be cut. In a theatre during a performance that is enough to turn off the lights. And a platform that bundles the credentials of hundreds of sites is a far more rewarding target than a single switch.

The guard

A test derives the list of credential-storing families from the source and fails as soon as someone adds a new family without registering it with the sanitiser. It additionally checks the actual effect, not just the list — and that no dead entries remain in it.

What you should still do: an exported project file holds no secrets, but it does contain a site's complete device inventory with addresses, hostnames and open services. Treat it like network documentation, not like a screenshot.