← StageSense · Handbuch zu Version 1.3.5 (Build 215), der aktuellen Version zum Download

StageSense Handbuch

Der sechste Sinn für die Show. Veranstaltungs-Monitoring für Strom, Licht und Netzwerk.

Stand: 31.10.2026 · Version 1.3.5 (Build 215) für macOS · © 2026 Robin Riese (RieseVT)

StageSense überwacht Strom, Licht und Netzwerk einer Produktion an einem Ort – vom Messgerät in der Dimmer City bis zum Switch-Port am FOH.

Überblick

StageSense liest die Geräte einer Produktion mit, fasst ihren Zustand in einer gemeinsamen Problemliste zusammen und meldet Auffälligkeiten aufs Handy. Es arbeitet im Show-Netz, sendet nie ins MA-Net und DMX bzw. sACN nur beim DMX-Test, den du startest. Zur Überwachung fragt es vor allem per Ping, SNMP und ArtPoll ab – vollständig unter Was StageSense im Netz sendet.

Alles lässt sich zusätzlich Standorten zuordnen – FOH, Dimmer Cities, Bühnen-Racks – mit eigenem Dashboard je Standort und einem Hallenplan.

Nach einer Störung sichert die Blackbox die Minuten davor und danach aus allen Bereichen auf einer gemeinsamen Zeitachse – siehe Nach einer Störung – Blackbox.

Lizenz-Hinweis: Ohne Lizenz läuft StageSense als Demo und verbindet sich nur mit den eingebauten Simulatoren.

Installation, Lizenz und Updates

StageSense braucht macOS 14 oder neuer und wird als DMG geliefert; eine Windows-Version (aktuell 1.0.4) gibt es separat mit Installer.

Installieren

1. DMG öffnen und StageSense auf „Programme“ ziehen.
2. Beim ersten Start meldet macOS einen nicht überprüften Entwickler: Systemeinstellungen → Datenschutz & Sicherheit → „Dennoch öffnen“.
3. Die Frage nach dem lokalen Netzwerk mit „Erlauben“ beantworten – ohne diese Freigabe findet StageSense keine Geräte. macOS stellt die Frage nach jedem Update erneut.
4. Die Geräte-Suche startest du von Hand: Werkzeuge → Geräte-Suche → „Jetzt suchen“. Bei jedem Start sucht StageSense nur, wenn unter Einstellungen → Allgemein „Beim Start nach Geräten suchen“ an ist – ab Werk ist das aus, damit das Show-Netz geschont wird. Überwacht und durchsucht werden automatisch nur angeschlossene Kabel-Adapter – WLAN, Thunderbolt-Brücke, iPhone-USB, Bluetooth und VPN nie. Soll ein solcher Adapter doch dabei sein, im Adapter-Fenster (oben „x Adapter“) ausdrücklich anhaken. Nach der Suche läuft die Überwachung weiter. Automatisch überwacht werden nur eindeutig erkannte Geräte – solche, die per SNMP antworten, oder die sich über MA-Net, Art-Net, sACN, StageSmarts oder Modbus zu erkennen geben. Reine Ping-/ARP-Funde (Handys, iPads, Laptops, unbekannte Adressen) stehen nur in der Ergebnisliste und lassen sich dort von Hand übernehmen; früher automatisch angelegte solche Einträge entfernt die Suche wieder. Ändert sich an einem Adapter IP-Adresse oder Teilnetzmaske, baut StageSense den Empfang neu auf; die Multicast-Gruppen (MA-Net, sACN) meldet es alle 15 s neu an, und verstummt MA-Net plötzlich, obwohl es eben noch lief, startet StageSense den Licht-Empfang selbst neu (Hinweis im Ereignisprotokoll). Automatisch angelegte Einträge, die damals noch nicht geantwortet haben, bekommen bei der nächsten Suche Name (SNMP), Typ (Switch, USV) und SNMP nachgetragen; selbst vergebene Namen bleiben. Während der Geräte-Suche zählen ausbleibende Ping-Antworten nicht als Paketverlust, und die Suche verteilt ihre Pings (je 32 Adressen kurz versetzt). Die Ping-Suche fasst bei stummen Adressen zweimal nach – managed Switche (z. B. Cisco SG300) beantworten Pings über ihren Prozessor und verlieren bei der Suche über ein ganzes Netz gelegentlich eine Antwort. USVs werden an der Standard-USV-Kennung (UPS-MIB) oder der APC-Kennung erkannt – auch bei Geräten nach SNMPv1-Art wie Delta, die eine Anfrage komplett ablehnen, sobald ein abgefragter Wert fehlt (StageSense fragt dann ohne diesen Wert erneut). Netzwerkkarte: Baum mit Abstand, Verbindungen rechtwinklig durch die freien Zwischenräume (nie über einer Karte), Port-Beschriftung an den Kartenrändern; zusätzliche Verbindungen eines Rings gestrichelt. Verbindungen nur zwischen direkten Nachbarn (LLDP, sonst aus den MAC-Tabellen: kein dritter Switch dazwischen). Dasselbe Gerät unter zwei Adressen (z. B. ein Router mit einer IP je VLAN: gleicher SNMP-Name, gemeinsame MAC-Adressen) erscheint in der Karte nur einmal; ein Luminex-Gerät unter zwei Adressen meldet Alarme und Ereignisse nur einmal (gleiche Seriennummer). Backbone-Auslastung: je Switch der Port zum übergeordneten Switch – auch gebündelte Ports (Port-Channel/LAG) –, gemessen an dessen Kapazität (Summe der Mitglieder), als Balken auf der Karte, farbig an der Verbindung und in der Web-App. Die Cisco SG300 haben keinen Temperaturfühler; StageSense zeigt dort Firmware, Hardware-Revision und Seriennummer. SNMP schont die Switche: vollständige Abfrage alle 5 Minuten, dazwischen alle 15 s nur Link aller Ports sowie Zähler, Fehler und Geschwindigkeit der Ports mit Link (Multicast-Zähler jede Minute, MAC-Tabelle und LLDP alle 5 Minuten); Tabellen, die ein Gerät nicht hat, werden 30 Minuten lang nicht erneut gesucht. Ein Cisco SG300 braucht so pro Runde 0,3–0,9 s statt 7 s – sein Verwaltungsprozessor beantwortet auch Ping, die Antwortzeiten waren vorher durch StageSense selbst bis 190 ms verfälscht. Angezeigt wird bei Switchen der Median der letzten 10 Pings. Bei Switchen meldet StageSense keine Antwortzeit- und Jitter-Probleme – sie beantworten Ping mit ihrem Verwaltungsprozessor, dessen schwankende Antwortzeit nichts über den Datenverkehr sagt; Ausfall und Paketverlust werden weiter überwacht. Cisco-SG300-Switche: Temperatur nur, wenn das Gerät einen Fühler hat (die lüfterlosen SG300-28 haben keinen), Lüfterzustand bei den SG300-52.

Umstieg von Versionen vor 1.2: Die alte Version vorher beenden. Beim ersten Start übernimmt StageSense Einstellungen, Lizenz, Geräte und den Datenordner automatisch (~/Library/Application Support/StageSense); das Ereignisprotokoll meldet die Übernahme. Die Freigabe „lokales Netzwerk“ und Mitteilungen fragt macOS einmal neu ab. Angemeldete Web-App-Geräte melden sich einmal neu an.

Lizenz

Die Lizenz wird unter Einstellungen (⌘,) → Lizenz eingetragen und einmal online aktiviert; sie ist dann an diesen Rechner gebunden und läuft offline weiter. Alle 60 Tage bestätigt StageSense die Lizenz kurz online, sonst erinnert es daran.

Meldung „Lizenz“: Vor dem Ablauf einer befristeten Lizenz – bei Monatslizenzen 3 Tage, sonst 14 Tage vorher – bzw. 7 Tage bevor die Online-Bestätigung fällig ist, kommt das Problem „Lizenz“ mit Push – Mittel, am letzten Tag Hoch; läuft die Gnadenfrist, Hoch. Ist die Lizenz nicht mehr gültig (abgelaufen, widerrufen, nicht bestätigt, Update-Zeitraum vorbei), kommt ein Alarm „keine gültige Lizenz – echte Geräte werden nicht mehr überwacht (…)“; die Vorwarnungen gehen darin auf. Das Ende melden „verlängert“, „Online-Bestätigung erneuert“ bzw. „wieder gültig – Überwachung läuft“. Ohne Lizenzschlüssel (Demo) gibt es diese Meldungen nicht; im Client-Modus kommen sie vom Server. Läuft die Lizenz während des Showmodus ab, überwacht StageSense bis zum Ende des Showmodus weiter, höchstens 24 Stunden über den Ablauf hinaus; danach gibt es keine Live-Daten mehr, Berichte, Verlauf und Export bleiben.

Weitere Bridges lassen sich dazukaufen; jede Bridge wird am Lizenzserver aktiviert. Jeder Mac braucht einen eigenen Lizenzschlüssel – auch im Client-Modus: Der Server gibt seine Freischaltung nicht an gekoppelte Macs weiter. Ein Mac ohne eigenen Schlüssel zeigt „Lizenzschlüssel eingeben“ und bekommt keine Live-Daten; Berichte, Verlauf und Export bleiben. Tageslizenzen gibt es nicht mehr. Bridges laufen auch an der reinen Mac-App.

Zurücksetzen löscht den Lizenzschlüssel nicht – nur die ausdrückliche Option „auch Lizenz entfernen“ oder „Deaktivieren“ in der Lizenz-Ansicht.

Kundenkonto auf license.stagesense.de

Unter https://license.stagesense.de/konto sehen Kunden ihre Lizenzen und Geräte, geben Plätze frei und fragen neue Lizenzen an. Das Kundenkonto dient nur der Lizenzverwaltung.

1. Konto anlegen: „Konto anlegen“ mit der E-Mail-Adresse, an die die Lizenz ging, und einem Passwort mit mindestens 12 Zeichen.
2. Adresse bestätigen: Der Link in der Mail gilt 24 Stunden und nur einmal; zum Bestätigen noch einmal das Passwort eingeben. Keine Mail? Im Spam-Ordner nachsehen – erneut registrieren schickt einen neuen Link.
3. Zwei-Faktor-Anmeldung (Pflicht): Den QR-Code mit einer Authenticator-App scannen (z. B. Apple Passwörter, 1Password, Google/Microsoft Authenticator) und den 6-stelligen Code eingeben. Danach zeigt das Konto 10 Wiederherstellungscodes – nur dieses eine Mal, also sicher aufbewahren; jeder gilt einmal, falls das Handy mit der App fehlt. Bleibt die Einrichtung unvollständig, schickt die nächste Anmeldung einen neuen Link dafür an die Adresse.

Anmelden: E-Mail und Passwort, dann der Code aus der App, ein Wiederherstellungscode oder „Mit Passkey bestätigen“. Eine Sitzung endet nach 30 Minuten ohne Aktivität, spätestens nach 12 Stunden. Oben stehen die Reiter Lizenzen, Sicherheit, Sitzungen und Protokoll.

• Lizenzen: Adresse und Kundennummer, dann je Lizenz Name, Produkt, der verdeckte Schlüssel, belegte Plätze („x von N Plätzen“), „Updates bis“ und gegebenenfalls „gesperrt“; darunter die aktivierten Geräte mit Plattform, Version und wann sie sich zuletzt gemeldet haben. Eine Lizenz erscheint, wenn ihre Lizenz-E-Mail zum Konto passt; sonst genügt eine kurze Mail an info@riesevt.de, dann wird sie zugeordnet. Das Konto zeigt je Lizenz Produkt, Ablauf und Bridges; den Schlüssel zeigt „Schlüssel anzeigen“ erst nach einer frischen Bestätigung mit dem zweiten Faktor. Vor dem Ablauf kommt eine Erinnerung per Mail (Jahr 14, Monat 3 Tage vorher).
• Platz freigeben: „Freigeben“ neben einem Gerät (mit Rückfrage) – das Gerät verliert die Lizenz beim nächsten Auffrischen, der Platz ist wieder frei.
• Neue Lizenz anfragen: kurz beschreiben, was gebraucht wird (z. B. „2 weitere Plätze“, „Sensor-Lizenz für DC 3“); die Antwort kommt per E-Mail.
• Sicherheit: neue Wiederherstellungscodes (die bisherigen gelten dann nicht mehr), andere Authenticator-App, Passkeys hinzufügen und entfernen – ein Passkey (Touch ID, Face ID, Windows Hello, Sicherheitsschlüssel) ersetzt den Code aus der App –, Passwort ändern (meldet alle anderen Sitzungen ab). Änderungen verlangen eine frische Bestätigung mit dem zweiten Faktor (5 Minuten gültig); über Passwort-, Code- und Zwei-Faktor-Änderungen kommt eine Mail.
• Sitzungen: alle angemeldeten Browser mit IP-Adresse, Anmeldezeit und letzter Aktivität; einzeln abmelden oder „Alle anderen abmelden“. Unter Bekannte Browser stehen die Browser, mit denen man sich angemeldet hat – sie haben eine eigene Grenze für Fehlversuche, Fremde können sie nicht aussperren. „Vergessen“ entfernt einen; Abmelden vergisst den Browser ebenfalls.
• Protokoll: Anmeldungen, Fehlversuche und Änderungen am Konto (z. B. Gerät freigegeben, Lizenz angefragt, Passwort geändert, Passkey hinzugefügt) mit Zeit und IP-Adresse.

Passwort vergessen: Auf der Anmeldeseite „Passwort vergessen?“ – der Link gilt 30 Minuten und nur einmal. Danach sind alle Sitzungen beendet; die Zwei-Faktor-Anmeldung bleibt aktiv.

Anmeldung gesperrt: Nach zu vielen Fehlversuchen ist die Anmeldung vorübergehend gesperrt. „Entsperr-Link per Mail anfordern“ schickt einen Link (1 Stunde gültig), der den Browser freigibt, in dem er geöffnet wird; auch „Passwort zurücksetzen“ hebt die Sperre auf.

Updates

Unter Einstellungen → Updates prüft StageSense auf neue Versionen. Updates sind signiert; Beta-Lizenzen erhalten zusätzlich Beta-Versionen.

Dieses Handbuch

Hilfe → StageSense Handbuch (⌘?) oder Einstellungen → Allgemein öffnet das Handbuch in der App; mit ⌘P lässt es sich drucken oder als PDF sichern. Es liegt auch dem DMG bei und wird mit jeder Version aktualisiert.

Die Oberfläche

Das Hauptfenster besteht aus der Seitenleiste links und dem jeweiligen Bereich rechts; jede Zeile der Seitenleiste zeigt eine Kurzinfo und die Zahl offener Probleme.

Seitenleiste

Tabellen sortieren: Jede Tabelle in StageSense (Geräte, Universen, Patch, RDM, Adressen, Geräte-Suche, PTP, Alarmregeln, Import-Vorschau …) lässt sich per Klick auf einen Spaltenkopf sortieren, erneuter Klick dreht die Reihenfolge um.

Übersicht (Startseite)

Die Übersicht ist die Gesamtseite im Stil der DC-Seiten (Standorte → Dashboard je Standort) – dieselbe Seite zeigt die Web-App als erste Seite „Gesamt“ unter /dc bzw. unter /uebersicht. Von oben nach unten, leere Bereiche entfallen:

• Kopf mit Ampel, „Gesamt“, Zahl der Standorte, MA-Session und Showmodus; rechts Wartung, Showmodus, Aufnahme, der Schalter „Überwachung starten/stoppen“ für Netzwerk und Licht und „Probleme ansehen“.
• Kennzahlen-Band mit sieben großen Zahlen über alle Standorte, jeweils mit Ort: Leistung gesamt (kW, darunter die kleinste Reserve bis zur Absicherung), max. Phasenlast (Phase · Anschluss · Standort), höchste Temperatur (Gerät · Standort), Geräte online (x/y, dazu wo welche fehlen; Farbe wie die schlechteste Standortseite), höchster Uplink, Universen (live/gesamt, z. B. „138/157“, sind alle live nur die Zahl; „live“ heißt Daten auf allen Wegen und keine Störung. Gestörte – Konflikt, sACN-Befund oder ausgefallener Zusatzweg – färben die Kennzahl; Universen „ohne Daten“ (z. B. Ausgänge ohne Sender) stehen getrennt in der Notiz und färben nicht; „alle live“ steht nur, wenn es stimmt. Jedes Universum zählt einmal, auch über mehrere Wege oder Standorte), offene Probleme (rot/orange; zählt wie die Seitenleiste nur unbestätigte Probleme, auffällige Werte ohne eigenes Problem als Zusatz „· 2 Werte auffällig“).
• Probleme aller Standorte als Chips mit Standort-Plakette (z. B. „DC 1“; ohne Plakette = keinem Standort zugeordnet), rot zuerst; dieselben auffälligen Werte wie auf den DC-Seiten. Ohne Probleme ein grüner Balken. Klick springt zur Ursache, „Bestätigen …“ wie bisher.
• Standortkarten – FOH, DC 1 … und „Ohne Standort“ für nicht zugeordnete Geräte: Ampel-Rahmen, Leistung, Mini-Balken L1/L2/L3 (höchste Last gegen die Absicherung), Geräte online (in der Farbe der Kennzahl der Standortseite), höchste Temperatur, Uplink, Universen. Klick öffnet die DC-Seite des Standorts.
• Strom gesamt: Leistung der letzten Stunde als gestapelte Fläche je Standort (Standortfarben), Spannung/Frequenz/cos φ/Sternpunkt/FI über alle Anschlüsse mit Toleranzband, Reserve und Energie seit Showbeginn; darunter alle Verteiler in einer Tabelle (L1/L2/L3 in % der Absicherung mit Balken, N mit „gem.“/„ber.“, cos φ; höchste Last zuerst).
• Netzwerk gesamt: die Uplinks aller Standorte (Trunk zum übergeordneten Switch) mit dickem Auslastungsbalken und Verlauf, darunter die Switche als kleine Matrix (online, Uplink, Fehler/min, Temperatur, PoE; auffälligste zuerst), dazu kurz NDI, DHCP und Zeit.
• Licht gesamt: alle Universen als Raster, nach Standort gruppiert (grün live, orange Prio-Befund, rot Konflikt, grau ruhig), Nodes online, Prio-Konflikte und -Befunde, MA-Stationen, MA-Session mit Master und Timecode. Die Zusammenfassung zählt jedes Universum einmal – auch an mehreren Standorten oder über MA-Net2 und sACN –, also dieselbe Zahl wie die Kennzahl „Universen“.
• Top-Schwachstellen über alle Standorte (höchster Wert je Gerätetyp mit Standort, wackelige Geräte).
• Strom, Netzwerk, Licht und Schwachstellen ordnen sich wie auf den DC-Seiten nach Inhalt und Auffälligkeit (rot/orange zuerst, nach 60 s anhaltender Auffälligkeit; zurück nach 5 Minuten ohne), die Breite folgt dem Inhalt, gestapelt ohne Leerflächen.
• Aktualisierung: Die Überwachung selbst läuft unverändert weiter (Ping jede Sekunde; Alarme, Web-App und Push arbeiten immer mit dem neuesten Stand). Die Mac-Oberfläche zeichnet sichtbare Änderungen sofort neu – Gerät online/offline, Gerät kommt oder verschwindet, neues Problem, Störung an einem StageSmarts-Verteiler; mehrere kurz hintereinander (z. B. SNMP-Antworten vieler Geräte) in einem Durchgang. Reine Messwerte wie Antwortzeiten, Zähler und Raten erscheinen höchstens alle 5 s, StageSmarts-Ströme aller Verteiler zusammen höchstens einmal pro Sekunde; Messgeräte (Janitza) bleiben live. Das spart am Laptop Akku: StageSense braucht so etwa ein Viertel der Rechenzeit.

Probleme

Eine gemeinsame Liste für Strom, Licht, Netzwerk und Dienste, filterbar nach Bereich. „Bestätigen“ einzeln oder „Alle bestätigen“, jeweils mit Notiz; Doppelklick öffnet die Ursache. Details im Kapitel Probleme und Alarmierung.

Schnellsuche (⌘K)

Findet Netzwerkgeräte, IP-Adressen, Messgeräte, Universen („1“ oder „0:0:1“), Lampen (Name, ID oder „1.132“), Switch-Ports nach Beschreibung oder LLDP-Nachbar, MA-Stationen und NDI-Quellen. Pfeiltasten wählen, Enter springt hin; Geräte und Ports öffnen direkt ihre Karte.

Großbild

Über das Großbild-Menü in der Werkzeugleiste öffnet sich ein dunkles Vollbild-Fenster mit großer Schrift – gesamt (Zustand, Uhr, vier Bereiche, Timecode, Standorte, Probleme) oder für einen Standort (Leistung, L1–L3, Anschluss-Auslastung, Netzwerk, Probleme). Mehrere Fenster gleichzeitig sind möglich, etwa ein Monitor pro Dimmer City.

Einstellungen (⌘,)

Standorte und Hallenplan

Ein Standort bündelt alle Geräte an einem Ort – FOH, eine Dimmer City, ein Bühnen-Rack – mit eigenem Dashboard, eigenen Problemen und einer Position im Hallenplan.

Standorte einrichten

1. Seitenleiste → Alle Standorte → „FOH + 6 Dimmer Cities anlegen“ (oder „+ Standort“ einzeln: Name, Art, Farbe, Notiz).
2. „Nach Namen zuordnen“: Geräte, deren Name einen Standort enthält („Switch DC3“, „UMG DC-3“, „GigaCore FOH“), landen automatisch dort. „DC10“ wird nicht „DC 1“ zugeordnet; bereits zugeordnete Geräte bleiben.
3. Im Dashboard des Standorts → Zuordnen: Messgeräte, StageSmarts-Verteiler, Netzwerkgeräte (inkl. Switche und USV), Art-Net-Nodes und MA-Stationen abhaken. Ein Gerät gehört immer genau zu einem Standort; Anhaken verschiebt es.

Gesamtüberblick

Je Standort ein Widget mit Problemzähler, Leistung (oder Strom), Phasenbalken L1–L3, Anschluss-Auslastung mit Reserve (Ampere bis zur Absicherung auf der höchsten Phase), Netzwerk online, Nodes und MA-Geräten. Auffällige Netzwerte (Spannung, Frequenz, FI, Schieflast) erscheinen farbig darunter. Phasenbalken: Ist für jeden Anschluss des Standorts eine Absicherung eingetragen (Strom → Anschlüsse), beziehen sich die Balken auf deren Summe und zeigen A und % (ab 80 % orange, ab 100 % rot); sonst wie bisher auf 32 A bzw. die höchste Phase. Je USV des Standorts eine Zeile – auch in den kleinen Kacheln der Übersicht: Netz/AKKU/Bypass/Alarm, Ladung, Restlaufzeit, Last und Temperatur (Temperatur orange ab 35 °C, rot ab 40 °C; Zeile rot im Akkubetrieb oder unter der Restlaufzeit-Grenze, orange bei Alarm, Bypass oder fehlgeschlagenem Selbsttest; Tooltip mit Modell, Batteriezustand, Selbsttest, Temperatur, Akkutausch und Alarmen). Ein Standort ohne USV zeigt „keine USV“. Sortierbar nach Reihenfolge, Name, Zustand, Leistung oder Art; Rechtsklick öffnet das Großbild oder löscht den Standort.

Matrix

„Alle Standorte“ → Matrix (Web-App: Netzwerk → Matrix) zeigt Tabellen mit Ampelzellen – jede Zelle hat ihre eigene Ampel, Zeilen bzw. Spalten ohne Datenquelle fallen weg; ein Klick (Tipp) öffnet den Standort bzw. die Gerätekarte:

Am Handy hochkant erscheint jede Matrix als Liste (eine Karte je Standort bzw. Gerät), quer als Tabelle.

Universen in der Matrix „Standorte“: gezählt wie die Kennzahl der Gesamtseite – je Universum einmal (MA-Net2 und sACN gleicher Nummer zusammen, Art-Net eigen). Live heißt: alle Wege mit Daten, kein Konflikt, kein Prio-Befund; gestört: Konflikt, Prio-Befund oder ein Weg ohne Daten, während ein anderer läuft; Universen ganz ohne Daten sind weder noch. Die Zelle zeigt „live/gesamt“ und färbt nur bei gestörten Universen (Konflikt rot, Befund oder toter Weg orange, Notiz „n gestört“); „ohne Daten“ bleibt grün.

Schwachstellen

Seitenleiste → Standorte → Schwachstellen (Web-App: Netzwerk → Schwachstellen) zeigt, wo es zuerst eng wird. Oben wählbar: Alle Geräte, Je Standort (eine Kachel je Standort in der Reihenfolge der Standorte – FOH zählt wie ein DC – mit Ampel, höchster Temperatur und Auslastung je Gerätetyp und den wackeligen Geräten; nicht zugeordnete Geräte unter „Ohne Standort“) oder ein Standort (alle vier Teile nur mit dessen Geräten, Verteilern, Server/Sensoren und Uplinks). Dieselbe Auswahl hat die Web-App als Knöpfe „Alle · Je Standort · FOH · DC 1 …“; jede DC-Seite (unten) zeigt ihre Schwachstellen ebenfalls.

• Höchste Temperatur je Gerätetyp (Switch, Pult, PU, Node, USV, Server, Sensor) mit Gerätename und Sensor; der Balken reicht bis zur roten Grenze dieser Quelle.
• Höchste Auslastung je Gerätetyp mit Ampelfarbe: Verteiler-Phase (gegen die Absicherung, 80/100 %), PoE-Budget (85/95 %), USV-Last (Grenze aus der USV-Einstellung), Switch-Port (70/90 %), Node-, Pult-, PU- und Pi-CPU (75/90 %). Was keine Datenquelle hat, fehlt.
• Uplink-Traffic je Standort, letzte Stunde: eine Linie je Standort (stärkster Uplink); die zwei auffälligsten (höchste Spitze bezogen auf die Port-Geschwindigkeit) sind farbig, der Rest grau.
• Wackelige Geräte, letzte Stunde: Neustarts, Ausfälle (nicht erreichbar), Link-Wechsel an Ports, Paketverlust und steigende Port-Fehlerzähler, gewichtet (Neustart 10, Ausfall 5, Link-Wechsel 2, Paketverlust 0,5 je %, Fehler 2 + 1 je Zehnerpotenz) – schlimmste zuerst; ein Klick öffnet die Geräteseite. Gezählt wird im Speicher ab dem Start des Programms.

Ampel je Standort

Die Ampel eines Standorts ist am Mac (Kacheln, Seitenleiste, Hallenplan, Großbild) und in der Web-App dieselbe: der schlechteste Wert aus offenen Problemen (bestätigte zählen nicht), Strom (Auslastung, Spannung, Frequenz, FI, Schieflast, N-Strom, Sternpunkt), USV (rot im Akkubetrieb, bei schwachem Akku oder nicht erreichbar; orange auf Bypass, mit Alarm, fehlgeschlagenem Selbsttest oder unter der Restlaufzeit-Grenze), höchster Temperatur, Uplinks und sACN-Befunden. Ein Standort kann daher orange sein, ohne dass ein Problem offen ist (Kopf: „Werte auffällig“) – etwa bei Schieflast oder einem warmen Switch. Probleme von Server und Sensor (Temperatur, Unterspannung, Drosselung, Platte) erscheinen bei dem Standort, dem sie zugeordnet sind.

Grenzwerte

Ab welchem Wert etwas orange oder rot wird, steht an einer Stelle. DC-Seiten, Gesamtseite, Matrix, Standort-Ampel und Web-App nutzen dieselben Zahlen, ebenso die Vorlagen der Alarmregeln und die Auslöser der Blackbox. Ab Werk gelten die bisherigen Werte: Wer nichts ändert, sieht dieselben Ampeln wie bisher.

Einstellen: Einstellungen (⌘,) → Grenzwerte. Die Seite hat zwei Teile:

• Nennwerte: Nennspannung L-N (230 V), Nennfrequenz (50 Hz) und FI-Auslösestrom (30 mA) – der Bezug für Spannung, Frequenz und Differenzstrom.
• Strom: je Zeile „orange ab/über …“ und „rot ab/über …“ – Phasenlast (in % der Absicherung, höchste Phase), Spannung und Frequenz als Abweichung vom Nennwert (Spannung in %), Phasenausfall (unter 100 V; muss unter der Nennspannung liegen), Differenzstrom (in % des FI-Auslösestroms), Schieflast, „N über Außenleiter“ (1 A), Sternpunkt U0 und cos φ.

Oben steht, wofür die Grenzen gelten – „diesen Mac und seine Web-App“, im Client-Modus „den Server (alle Clients und die Web-App)“ – und wie viele Werte vom Standard abweichen. Die Grenzen gelten für alle Standorte gleich; eigene Grenzen je Standort kommen mit den Venue-Profilen. Änderungen gelten sofort, und alle Anzeigen ziehen mit: DC-Seite, Matrix, Gesamtseite, Web-App und die Blackbox. Jede Grenze hat einen erlaubten Bereich, und die Grenze für orange muss unter der für rot liegen. Passt eine Eingabe nicht, wird die Zeile rot, und oben steht „Nicht gesichert – es gelten weiter die gesicherten Werte“ mit dem Grund. „Standardwerte …“ setzt nach einer Rückfrage alle Grenzen zurück. Steht in den gespeicherten Einstellungen ein unpassender Wert (z. B. aus einer alten Datei), gilt für dieses Paar der Wert ab Werk, und im Protokoll steht „Grenzwerte: … – dort gilt der Standardwert“.

Die Grenzen für Netzwerk und Server (Uplink, Switch-CPU, PoE, Temperaturen, Server) stehen nicht auf der Seite und gelten wie in der Tabelle. Ping und Temperatur der Netzwerkgeräte stellst du wie bisher unter Einstellungen → Alarme bzw. Netzwerk ein.

Strom-Alarme ab Werk: Auch ohne eigene Alarmregel meldet StageSense je Messgerät Unter- bzw. Überspannung außerhalb von Rot (nach 10 s), eine ausgefallene Phase unter der Grenze für den Phasenausfall (nach 3 s) und eine Frequenz außerhalb von Rot (nach 5 s) – als Alarm, mit Wartung, Bündelung und Push wie alle Probleme (Bereich Strom). Dazu je Einspeisung mit eingetragenem Anschluss die Auslastung der höchsten Phase: ab Orange Mittel, ab Rot Hoch, wenn es 10 s ununterbrochen ansteht. „Behoben“ kommt erst nach 30 s ohne Befund („Spannung wieder normal“, „Phase wieder da“, „Frequenz wieder normal“, „Auslastung wieder normal“). Eine Phase zählt erst, wenn sie einmal im normalen Bereich lag (einphasige Geräte melden sonst „Phase weg“), die Frequenz ebenso (z. B. Aggregat ohne Last). Fällt der Strom ganz aus, bleibt nur „Phase … ausgefallen“ – Spannung, Frequenz und Auslastung gehen darin auf, ohne „wieder normal“. Eine eingeschaltete eigene Alarmregel auf denselben Wert in dieselbe Richtung ersetzt den eingebauten Alarm; eine Unterspannungs-Regel deckt auch „Phase weg“ ab. Trennt man ein Messgerät von Hand oder entfernt es, enden seine Strom-Alarme ohne Meldung; bei einem Verbindungsfehler bleiben sie stehen (der Verbindungsausfall meldet sich selbst).

Schalter: „Strom-Alarme ab Werk“ auf der Seite Grenzwerte (ab Werk an; aus = keine) und je Messgerät unter Messgerät → Alarme (aus = nur noch Info, ohne Mitteilung und Push – wie „Ausfall melden“ bei Netzwerkgeräten). Im Client-Modus gilt der Schalter für den Server.

Alarmregeln haben eigene Grenzen. Die Vorlagen unter Messgerät → Alarme (Über- und Unterspannung, Frequenz, cos φ, Sternpunkt, RCM) übernehmen ihre Zahlen aus den Grenzwerten. Das Vorlagen-Menü zeigt deshalb immer die aktuellen Zahlen, ab Werk z. B. 253/207 V und 50,5/49,5 Hz; es rundet nach außen (obere Grenzen auf, untere ab). Eine angelegte Alarmregel bleibt aber, wie sie angelegt wurde, auch wenn du später die Grenzwerte änderst. Ob eine Alarmregel eine Blackbox-Sicherung auslöst, entscheidet ihr Schweregrad: „Alarm“ ja, „Warnung“ nein.

Dashboard je Standort (DC-Seite)

Jeder Standort – FOH genauso wie DC 1–6, Bühne, Rack – hat dieselbe Seite, am Mac (Seitenleiste → Standort) und in der Web-App unter /dc (siehe unten). Aufbau von oben nach unten, leere Bereiche entfallen:

• Kopf mit Zustand, Leistung und den Knöpfen Zuordnen, Bearbeiten, Großbild. „x nach Namen zuordnen“ erscheint, wenn noch nicht zugeordnete Geräte zum Standort passen: für „DC 1“ z. B. „DC1-1“, „DC1-2“, „Service-DC1“ (aber nicht „DC10“).
• Kennzahlen-Band mit bis zu sechs großen Zahlen und Ampelstreifen: Leistung (kW; Streifen in der Strom-Farbe, orange/rot bei auffälligen Stromwerten), max. Phasenlast (höchste Phase in % der Absicherung mit Phase und Anschluss; ohne Absicherung höchster Phasenstrom in A), höchste Temperatur (mit Gerät), Geräte online (x/y; die Farbe folgt den Ausfällen, siehe „Ausgefallene Geräte und Pulte“ unten), höchster Uplink (% mit Switch), Universen (jedes einmal, auch über mehrere Wege; gestörte = Konflikt, sACN-Befund oder ausgefallener Zusatzweg, z. B. „23/24 · 1 gestört“).
• Probleme als rote/orange Chips: die offenen Probleme des Standorts und auffällige Werte ohne eigenes Problem (Phase ab 80 %, Schieflast, N-Strom, Spannung, Frequenz, Temperatur, Uplink, sACN, USV) – so ist die Ampel immer erklärt. Wert-Chips (cos φ, Spannung, Frequenz, Sternpunkt, FI) nennen den Verteiler mit dem auffälligsten Wert, z. B. „DC 2 UV 2 · cos φ 0,89“; Standort-Plakette und Gerätename werden nie gekürzt, höchstens der Meldungstext. Ein Ausfall ohne eigenes offenes Problem steht ebenfalls als Zeile da („PU5 nicht erreichbar“, „Pult FOH nicht im MA-Net“). Kennzahl, Chips und Ampel stehen immer auf derselben Stufe. Ohne Probleme ein grüner Balken „Alles in Ordnung“. Klick auf ein Problem springt zur Seite des Problems; „Bestätigen …“ wie bisher.
• Einteilung nach Relevanz (Mac und Web gleich): Jeder Standort hat einen Schwerpunkt – am FOH die Pulte, in einer Dimmer City der Strom, sonst das Netzwerk. Er ergibt sich aus der Art des Standorts (Bearbeiten → Art; die Art ist damit die Übersteuerung) und dem Inhalt: ein Standort mit mehreren Pulten und ohne Verteiler gilt als Pult-Standort, einer mit Verteilern als Strom-Standort. Die Bereiche stehen nach Gewicht – Bedeutung für den Schwerpunkt × Inhalt (wie viele Pulte, Verteiler, Uplinks, Universen …) –, Bereiche mit roten bzw. orangen Werten rücken ganz nach oben – erst nach 60 s anhaltender Auffälligkeit und zurück erst nach 5 Minuten ohne, damit die Seite nicht springt –, die Schwachstellen stehen immer am Ende. Die Breite folgt dem Inhalt: ein einzelner Verteiler ist eine schmale Kachel, viele Pulte oder Universen bekommen Platz; leere Bereiche entfallen. Jede Kachel ist nur so groß wie nötig (Mac und Web, beide Ansichten): Breite = Bedarf des Inhalts (längste Zeile bzw. Tabelle, Grenzen je Kacheltyp), Höhe = Inhalt; freie Breite wird nicht aufgebläht, sondern weitere Kacheln rücken nach (gepackt in Reihenfolge der Relevanz). Nur Kacheln, die von Platz echt profitieren, wachsen in frei bleibende Spalten: das Universen-Raster und die Pulte (mehrspaltig). Breite Listen (Pulte, Temperaturen, Schwachstellen, Uplinks) laufen mehrspaltig; Nodes stehen als Chips, „kein Timecode“ klein in der Unterzeile. Im schmalen Fenster bzw. am Handy stehen die Kacheln in derselben Reihenfolge untereinander. Eine Akzentfarbe je Bereich (Strom gelb/orange, Netzwerk blau, Licht violett), Zahlen monospaced.
• Kennzahlen am FOH (Schwerpunkt Pulte): Pulte online, Session, Timecode (läuft/steht, an welchem Pult), System Monitor (verbunden x/y, „aus“), Geräte online, höchste Temperatur und die Leistung klein.
• Strom (siehe unten): je Messgerät bzw. Verteiler drei senkrechte Balken L1/L2/L3 und N gegen die Absicherung mit Strichlinie bei 80 % und roter Linie bei 100 % (Phase orange ab 80 %, rot ab 100 %), Schieflast-Hinweis, Absicherung klein darunter; Spannung, Frequenz, cos φ, Sternpunkt und FI als kleine Werte mit Toleranzband (Marke im grünen, orangen oder roten Bereich), Reserve und Energie; USV-Zeilen; die Leistung der letzten Stunde als Fläche. Klick auf einen Anschluss öffnet das Messgerät.
• Netzwerk: Uplinks mit dickem Auslastungsbalken (blau, ab 70 % orange, ab 90 % rot), ↓/↑, Fehler/min nur wenn vorhanden, Verlauf der letzten Stunde rechts; Switche als kleine Tabelle mit CPU, Temperatur und PoE (orange ab 85 %, rot ab 95 %); alle übrigen Geräte als Status-Chips (Punkt + Name, „3× 1 h“ bei Ausfällen der letzten Stunde, Antwortzeit im Tooltip). Klick öffnet die Geräteseite.
• Licht: Universen als gleich große Kacheln (grün live, orange sACN-Prioritäts-Befund oder ausgefallener Zusatzweg, rot Konflikt mit ⚠, grau ruhig; Tooltip mit Quelle, Priorität und Rate), darunter die Nodes (Art-Net, LumiNode/LumiCore, MA-Nodes) mit aktiven Ausgängen, Ausfällen und Temperatur. Ein Universum über mehrere Wege (z. B. eine grandMA2 gibt 201–218 über MA-Net2 und zusätzlich als sACN aus) steht einmal da: Die Kachel nennt die Wege („MA-Net2 + sACN“), der Zustand ist der des schlechtesten Wegs, der Tooltip zeigt je Weg Rate, Quellen und Priorität. Fällt ein Weg aus, während der andere läuft, wird das Universum orange („sACN ohne Daten – der andere Weg läuft“) und zählt als gestört. Art-Net (Port-Adresse Net:Sub:Uni, zählt ab 0) steht als eigenes Universum „A…“, z. B. „A5“, mit der Port-Adresse im Tooltip. Kennzahl, Gesamtseite und Standort-Matrix zählen jedes Universum einmal.
• Pulte (z. B. am FOH): Session, System Monitor (grandMA2: verbunden/wartet/aus), Timecode groß (läuft violett, steht grau) und wer gerade an der Station arbeitet (👤, aus dem MA-Protokoll; in der Web-App ohne Anmeldung als „•••“); ab vier Pulten zweispaltig; je Pult ein kleines Badge v1/v2 (Hardware-Generation). Der Pultname steht immer ganz da; reicht der Platz nicht, wird das Badge „System Monitor verbunden“ zu „SM ✓“ (Tooltip mit vollem Text). Am FOH darunter das Leaderboard heute (Top 3, antippen öffnet es), sofern die Bedienerdaten sichtbar sind. Bei vielen Universen (über 48, etwa MA-Net am FOH) wird das Universen-Raster kompakt.
• Temperatur: Thermometer-Balken je Sensor mit schraffiertem Grenzbereich ab der Warnschwelle, heißeste zuerst (Details unten).
• Schwachstellen dieses Standorts: höchste Temperatur und Auslastung je Gerätetyp, wackelige Geräte.

Die Werte im Einzelnen (Zahlen ab Werk; die Strom-Grenzen sind unter Grenzwerte einstellbar):

• Strom: es erscheint nur, was ein Messgerät wirklich liefert:
  • Reserve bis zur Absicherung (kleinste über alle Anschlüsse, mit Phase und Anschluss).
  • Schieflast (höchste minus niedrigste Phase, bezogen auf die höchste) – erst ab 25 % der Absicherung bewertet (ohne Absicherung ab 10 A), orange über 30 %.
  • N-Strom: „N gem.“, wo das Messgerät ihn misst (I4, Netzwerk-UMGs mit N-Messeingang), sonst „N ber.“ (aus L1–L3 berechnet, Vektorsumme – z. B. USB-Verteiler ohne I4). „Gemessen“ gilt erst, wenn I4 seit dem Verbinden einmal über 0,05 A lag (das Rauschen eines unbeschalteten Eingangs zählt nicht), und nur, solange I4 plausibel ist: unter Last mindestens 70 % von N ber. minus 2 A. Sonst steht „N ber.“ mit dem Hinweis „I4 unplausibel (… bei N ber. …) – Wandler/Anschluss prüfen“. Bei Oberschwingungen (LED, Netzteile) kann der gemessene N deutlich höher liegen als der berechnete. Die Ampel bewertet immer den höheren der beiden Werte (orange, wenn er über der höchsten Phase liegt) – ein zu kleiner I4 verdeckt keine N-Überlast. Die Verteiler-Tabelle der Gesamtseite zeigt je Zeile „gem.“ bzw. „ber.“.
  • Sternpunkt U0 (orange ab 3 V, rot ab 5 V).
  • cos φ je Anschluss und gewichtet für den Standort (Σ P / Σ S); orange unter 0,9.
  • Spannung jetzt und min/max seit Showbeginn (Showmodus an; sonst seit dem Start des Programms): orange außerhalb ±6 %, rot außerhalb ±10 % von 230 V oder bei Phasenausfall (eine vorher belegte Phase ohne Spannung). Nie belegte Phasen eines einphasigen Geräts zählen nicht.
  • Frequenz jetzt und min/max seit Showbeginn: orange ab 0,2 Hz, rot ab 0,5 Hz Abweichung (Generator).
  • FI (Differenzstrom, RCM): nur, wenn ein Messgerät echte RCM-Werte liefert; orange ab 15 mA, rot ab 21 mA (70 % von 30 mA).
  • Energie in kWh seit Showbeginn und der Verlauf der letzten Stunde (Leistung, alle 30 s ein Punkt). Energie und min/max laufen im Speicher und beginnen nach einem Neustart neu.
  • Getrennte Messgeräte (USB abgezogen, Gerät antwortet nicht, Verbindungsfehler) zählen nirgends mit – weder in Leistung, Reserve, Phasenlast und Verlauf des Standorts noch auf der Gesamtseite (Leistung gesamt, gestapelte Fläche), in der Übersicht oder im Stromplan. Ihr Anschluss steht als Kachel „getrennt seit 15:40“ ohne Balken da, der letzte Wert grau mit „zählt nicht in die Summe“; das Kennzahlen-Band nennt „1 ohne Werte“ und wird orange. Live-Ansicht, Dashboard und Messwerte am Mac zeigen die letzten Werte grau mit „getrennt seit …“, die Web-App ebenso (Strom, Gerätekarte und Gerätedetails).
  • Dieselben Kennzahlen zeigt die Web-App im Standort (Übersicht → Standort antippen) und auf der Standort-Kachel der Übersicht (Phasenbalken, Reserve, auffällige Werte).
• Temperatur: alle Temperaturen der Geräte des Standorts, heißeste zuerst, mit Gerät, Sensor und Gerätetyp – SNMP-Sensoren von Switchen, Pulten, PUs und Nodes (Grenzen wie bei den Problemen: allgemein ab 70 °C, Rechner-CPU ab 85 °C, SSD ab 75 °C), USV-Akku (orange ab 35 °C, rot ab 40 °C), StageSense-Server und Sensor (CPU orange ab 80 °C, rot ab 85 °C; NVMe ab 70 °C). Die Kachel zeigt die höchste Temperatur mit Quelle. Server und Sensoren (Pi 5, Pi 4) lassen sich unter Zuordnen → „Server und Sensoren“ einem Standort zuordnen, z. B. der Sensor der DC, in der er steht.
• Uplinks (oben in der Netzwerk-Kachel): je Switch des Standorts der Port zum übergeordneten Switch (aus der Netzwerkkarte, LLDP/MAC-Tabellen; ohne Karte der belegte Trunk-Port mit der größten Last, „vermutet“) mit Durchsatz ↓/↑ in Mb/s, Auslastung (höhere Richtung zur Port-Geschwindigkeit), Fehler pro Minute (aus zwei Zählerständen; nach einem Neustart des Switches erst wieder ab dem zweiten) und dem Verlauf der letzten Stunde. Ampel: Uplink unten rot, Auslastung ab 70 % orange und ab 90 % rot, Fehler ab 1/min orange und ab 100/min rot. Ein von STP blockierter Uplink ist der Ersatzweg eines redundanten Paars und zählt nicht als Fehler. Dasselbe zeigt die Web-App im Standort.
• Ausgefallene Geräte und Pulte (Netzwerk-Chips, Switch-Zeilen, Pulte; Mac und Web gleich): Jeder Ausfall bekommt die Stufe seines Problems. Ist das Problem offen, gilt dessen Farbe. Ist es bestätigt, steht beim Gerät „kein Alarm bei Ausfall“ oder ist „Überwachen“ aus, zeigt StageSense einen grauen Ring statt des roten Punkts, den Grund im Tooltip; die Kennzahl zählt den Ausfall mit („Geräte online 27/28 · 1 fehlt · ohne Alarm“ bzw. „· bestätigt“, am FOH ebenso „Pulte online“), färbt aber nicht. Ist der Ausfall die Folge eines anderen, wird er orange („Folge: Switch DC 2 ausgefallen“). Ein Ausfall ganz ohne Problem ist rot und steht als Problemzeile da („… nicht erreichbar“, „Pult … nicht im MA-Net“). Kennzahl, Chips und Ampel stehen immer auf derselben Stufe; die Zeile „online“ der Standortkarten auf der Gesamtseite hat dieselbe Farbe wie die Kennzahl der Standortseite.
• sACN-Prioritäten (Universen-Kacheln, Tooltip; in der Web-App im Standort „sACN-Prioritäten“): je sACN-Universum, das am Standort ankommt (Node-Ausgang, LumiCore-Engine, MA-Node-Port) oder von dort gesendet wird, die aktiven Quellen mit Priorität (höchste zuerst) und über welches Gerät es ankommt. Befunde:
  • Konflikt (rot): mehrere Quellen mit gleicher höchster Priorität (wie bisher; Art-Net: mehrere Sender).
  • Unerwartete Priorität (orange, 10 Minuten lang, auch als Problem „sACN-Priorität“): eine bekannte Quelle sendet plötzlich mit anderer Priorität, oder eine andere Quelle übernimmt das Universum mit höherer Priorität als die bisherige (z. B. Medienserver 150 über dem Pult 100). Ein Wechsel bei gleicher Priorität – etwa das MA-Backup übernimmt – ist kein Befund.
• Probleme über das Universum: Konflikte und sACN-Prioritäts-Probleme erscheinen bei dem Standort, an dem das betroffene Universum ankommt (z. B. beim DC mit dem Node), nicht nur beim sendenden Pult.

Details zu Kennzahl und Kachel: Eine Kennzahl oder Kachel antippen zeigt alles zu ihrem Thema an diesem Standort. Am Tablet quer und am Monitor erscheint das Detail als Seitenleiste rechts, die Seite läuft daneben weiter; am Handy als Vollbild mit „‹ Standort“ – Zurück, Wischen nach unten oder Esc schließen es. Spaltenkopf antippen sortiert, Chips filtern, eine Zeile mit Gerät öffnet die Geräteseite. Themen: Temperatur, Pulte (Spalte Priorität gleich hinter dem Namen), Probleme (ohne IP-Adressen im Text), Strom, USV (auch über die USV-Zeile der Strom-Kachel), Netzwerk (Uplinks mit Richtung, Switches, Geräte mit Antwortzeit und Ausfällen der letzten Stunde), Licht (Universen, Nodes) und Schwachstellen (Temperaturen und Auslastung nahe der Grenze, Wackelkandidaten der letzten Stunde). Den Verlauf zeigt ein Detail nur nach Anmeldung (PIN). Ein Detail hat einen eigenen Link, /dc/<Standort>/<Thema>, z. B. /dc/FOH/pulte als fester Bildschirm. Mit ?auto= schließt ein offenes Detail nach 60 s ohne Bedienung, spätestens nach 5 min.

Pulte-Kachel: ★ = aktueller Master; das Badge zeigt die Master-Priorität (Never grau, schmal als H, N, L bzw. ∅). Darunter steht je Session, wer übernimmt, wenn der Master ausfällt. Ein Wechsel der Master-Priorität erscheint sofort. Ohne PIN steht ein Pult ohne Namen als „unbenannt“, nie mit seiner IP.

Strom-Detail: je Anschluss L1/L2/L3 und N, Absicherung, Auslastung, Reserve, Leistung, Spannung, Frequenz, cos φ, Sternpunkt U0 und FI; getrennte Messgeräte grau mit dem letzten Wert. Dazu Spannung, Frequenz und cos φ min/max, höchster Strom und Energie seit Showbeginn (sonst seit dem Programmstart), die Kennzahlen des Standorts wie auf der Kachel und die StageSmarts-Kanäle. „Max 24 h“ und den Verlauf je Phase gibt es nur mit PIN. Am Ende der Abschnitt Volllast (siehe Stromplan).

Volllast auf der DC-Seite: Eine blaue Marke im Phasenbalken zeigt je Phase, wo der Patch auf voller Leistung läge (Tooltip z. B. „Volllast L1 52,0 A · 41 % der Absicherung (Patch, Planwert)“); unter den Anschlüssen steht eine Zeile wie „Volllast 38,2 kW · L1 52 / L2 48 / L3 50 A · 41 % von 125 A“ (bei einer Absicherung je Anschluss „… % am stärksten Anschluss“). Die Matrix → Standorte hat eine Zeile Volllast, die Gesamtseite die Kennzahl Volllast (Patch) in kW; sie öffnet das Strom-Detail. Die Volllast ist ein Planwert: Sie färbt nie die Ampel, löst keinen Alarm und keinen Push aus.

Am Mac: Kennzahl bzw. Kachelkopf (mit „›“) antippen öffnet dasselbe Detail als Popup über der Seite – auf der Standortseite und in der Übersicht „gesamt“; dasselbe Thema noch einmal antippen schließt es. Ein Gerät darin antippen öffnet seine Geräteseite im selben Popup, oben steht dann „‹ <Thema>“ zum Zurückgehen. Esc, ✕ oder ein Klick daneben schließt die oberste Ebene; ein Wechsel von Bereich oder Standort schließt das Popup. „Link kopieren“ kopiert den Link für die Web-App. Das Popup kürzt keine Zelle: breite Tabellen scrollen waagerecht, lange Texte brechen um.

Hallenplan

Umschalter „Hallenplan“ in Alle Standorte. Mit Bearbeiten:

• Hallengröße in Metern eingeben (Raster alle 5 m).
• Flächen hinzufügen (Bühne, FOH-Platz, Tribüne, Backstage, Fläche), verschieben, an der Ecke vergrößern, umbenennen, löschen.
• Standorte an ihre Position ziehen.
• Grundriss als Bild oder PDF hinterlegen, Deckkraft per Regler.

Ohne Bearbeiten zeigt jeder Marker Farbe, Leistung und Problemzähler; ein Klick öffnet das Dashboard des Standorts.

Strom

Der Bereich Strom zeigt alle Einspeisungen – Janitza-Messgeräte und StageSmarts-Verteiler – in einer einheitlichen Einheit, dazu Anschluss-Auslastung, Stromplan und USV. Reiter: Übersicht, Anschlüsse, Verteiler, Stromplan, USV (Verteiler und USV erscheinen nur, wenn vorhanden).

Einheit: kW oder A

Oben rechts im Strom-Bereich (oder Einstellungen → Allgemein) wählbar; gilt überall, auch in Standorten, Großbild und Web-App.

• kW: Messgeräte liefern ihre gemessene Leistung. Bei StageSmarts rechnet StageSense U × I je Phase (mit cos φ, wenn der Verteiler ihn meldet; sonst als Näherung mit „≈“).
• A: Strom der höchsten Phase.
• Der jeweils andere Wert steht klein daneben.

Messgeräte (Janitza)

Hinzufügen mit „+“ unten in der Seitenleiste: Name, Verbindung (Modbus TCP über Ethernet oder Modbus RTU über RS485), Adresse, Geräteprofil, „Beim Start automatisch verbinden“ (bei neuen Messgeräten standardmäßig an): StageSense verbindet das Messgerät beim Start von selbst – auch dann, wenn die Lizenz erst kurz nach den Messgeräten geprüft ist. Außerdem merkt sich StageSense, ob du ein Messgerät verbunden oder getrennt hast: Verbundene Messgeräte verbinden sich nach einem Neustart oder Update des Servers wieder von selbst, getrennte bleiben getrennt – auch nach „Trennen“ über die Menüleiste. Verbindet sich die Mac-App im Client-Modus mit dem Server, startet sie dessen Messgeräte nicht neu – es gibt dabei keine Lücken in den Messwerten. „Trennen“ in der Mac-App merkt sich StageSense dauerhaft; Mac-App und Server am besten zusammen aktualisieren. Wenn ein Gerät nicht antwortet: StageSense lässt die Modbus-TCP-Verbindung bei einer Zeitüberschreitung offen (eine verspätete Antwort wird an der Transaktionsnummer erkannt und verworfen) und baut sie erst nach drei Zeitüberschreitungen in Folge neu auf; der Abfragetakt verlängert sich nach Fehlern auf 2, 4 und höchstens 5 s und springt mit der ersten Antwort zurück. Sofortiges Neuverbinden im Sekundentakt ließ bei Janitza-Geräten halb offene Verbindungen liegen, bis keine mehr frei war. Tipp: Hängt ein Janitza im Takt von ein bis zwei Minuten (erst keine Modbus-Antworten bei funktionierendem Ping, dann einige Sekunden gar nicht erreichbar), am Switch den Link-Zustand seines Ports prüfen (ifLastChange): Fällt der Link immer wieder ab, liegt es an Kabel, Stecker, Port oder einer Energiesparfunktion des Switch-Ports (EEE/Green Ethernet) – nicht an der Abfrage.

Verteiler mit USB-Buchse (z. B. connex-Verteiler, Buchse „NW“): Darin steckt ein USB-Seriell-Chip (FTDI) direkt am Janitza-Messgerät. Am Mac erscheint er als /dev/cu.usbserial-…. Am einfachsten als Messgerät „connex MRG-Verteiler (USB-Buchse „NW“)“ wählen: Die Vorlage stellt „Modbus RTU“, die erste usbserial-Schnittstelle, 921600 Baud, keine Parität, 1 Stoppbit ein; die Geräteadresse spielt dort keine Rolle. Weil die Verteiler gemietet sind, schreibt StageSense mit dieser Vorlage nie etwas ins Messgerät („Im Gerät löschen …“ fehlt). Per WLAN statt Kabel zum Mac: Die StageSense-USB-Brücke (ESP32-S3, ein Board pro Verteiler, Firmware im Ordner firmware/usb-bridge) steckt an der Buchse „NW“, liest den Janitza und gibt ihn als Modbus TCP weiter – nur Lese-Anfragen. Sie meldet sich per Bonjour; die Geräte-Suche legt sie automatisch mit der Vorlage „StageSense USB-Brücke“ an. Brücke einstellen: Im Geräte-Editor (Vorlage „StageSense USB-Brücke“) gibt es zwei Knöpfe. „Per USB-C einrichten …“ – Brücke mit einem USB-C-Datenkabel an den Mac (Buchse am Display-Board): Name, WLAN, Ersatz-WLAN und feste IP eintragen, „Auf Brücke schreiben“; StageSense wartet, bis die Brücke im WLAN ist, und trägt ihre Adresse ein. Dabei wird die Brücke mit diesem Mac gekoppelt (Schlüssel im Schlüsselbund). „Übers Netz einstellen …“ – dasselbe ohne Kabel, nur für gekoppelte Brücken; jede Änderung ist signiert, eine fremde oder mitgeschnittene Anfrage lehnt die Brücke ab. Ändern sich WLAN oder Adresse und die Brücke kommt damit 90 s lang nicht ins Netz, stellt sie die alten Einstellungen selbst wieder her. Das Ersatz-WLAN nimmt sie nach vier Fehlversuchen im Haupt-WLAN. Ohne Mac geht die Einrichtung weiter über die BOOT-Taste (3 s) und das WLAN der Brücke. Bei der USB-Suche spricht StageSense nur ESP-Boards an (CH340, CP210x, Espressif), nie den FTDI eines Verteilers. Den ESP aus einer Steckdose desselben Verteilers versorgen, damit getrennt gespeiste Verteiler nicht über USB verbunden werden. Über 230400 Baud stellt StageSense die Rate über den macOS-Sonderweg (IOSSIOSPEED) ein. Die Ansicht eines Messgeräts hat diese Reiter:

Werte, die das Messgerät nicht hat: Manche Janitza-Modelle liefern für Kanäle, die sie gar nicht messen, einfach 0 – etwa das UMG 96RM in den USB-Verteilern: I4 (N gemessen) und die Crest-Faktoren U/I stehen dort dauerhaft auf 0, während die Netzwerk-UMGs 19–21 A bzw. 1,4–1,9 zeigen. StageSense erkennt das je Gerät und Kanal: Ist ein solcher Wert seit Verbindungsbeginn 10 Minuten lang exakt 0, obwohl er physikalisch nicht 0 sein kann (Crest-Faktor U bei anliegender Spannung und Last über 1 A, Crest-Faktor I auf einer Phase mit über 1 A, I4, wenn rechnerisch mehr als 1 A N-Strom fließt), zeigt StageSense ihn grau als „vom Messgerät nicht geliefert“ (Übersicht, Tabelle, Sternpunkt, Web-Gerätekarte) und lässt ihn aus Grenzwerten, Alarmen, Min/Max, Verlauf, Schwachstellen und Summen heraus. Lückenlose Messzeit zählt – Pausen ohne Antwort zählen höchstens mit 60 s, ohne Last läuft die Zeit nicht weiter. Kommt ein Wert ≠ 0, gilt er sofort wieder und wird bis zum nächsten Verbinden nicht mehr versteckt. Der Differenzstrom (RCM) bleibt unberührt – 0 ist dort normal. N-Strom: DC-Seiten, Gesamtseite und Web-Karten zeigen „N gem.“, wo das Messgerät I4 plausibel misst (Regeln siehe Standorte → Dashboard je Standort), sonst „N ber.“ (aus L1–L3 berechnet, Vektorsumme, Janitza-Register 19018). Live-Ansicht, Dashboard, Bericht und Aufzeichnung zeigen weiter „N ber.“; ein gemessenes I4 steht dort zusätzlich als „I4 gem.“ (Live-Ansicht, Sternpunkt) bzw. „I4 gemessen“ (Messwerttabelle). Die Alarm-Vorlage „N-Leiterstrom > 20 A“ prüft den berechneten Wert; für den gemessenen eine eigene Regel auf „I4 gemessen“ (Adresse 10085) anlegen.

Typenschild: Bei Janitza-Messgeräten liest StageSense einmal je Verbindung Seriennummer (Register 754) und Software-Release (Register 750) – nur lesend (Funktion 03) – und zeigt sie in der Statusleiste unten und auf der Web-Gerätekarte, z. B. „Janitza UMG 96RM (USB, vermutl. -P/-CBM) · Seriennr. 123456 · Software-Release 105“. Kennt ein Gerät die Register nicht oder liefert es Unplausibles, fehlt die Angabe. Die Bauart in Klammern ist kein Geräteregister, sondern aus der Anbindung geschlossen: Ein USB-Anschluss mit 921,6 kBit/s gibt es bei Janitza nur am UMG 96RM-P/-CBM.

StageSmarts-Verteiler

StageSmarts erscheinen automatisch, sobald die Überwachung läuft (IPv6-Suche im Netz). Je Verteiler: Einspeisung L1–L3 und N, jeder Kanal mit Strom und Fehlerstrom, Schalterstellung und Meldungen (Überlast, Schalter aus, Fehlerstrom, Not-Aus, Unterspannung, Akkubetrieb).

Anschlüsse und Auslastung

Je Einspeisung lässt sich eintragen, an welchem Anschluss sie hängt – über das Menü „Anschluss“ an jeder Karte oder gesammelt unter Strom → Anschlüsse.

Meldet ein StageSmarts seine Anschlussleistung selbst, wird sie vorbelegt. Die Auslastung ist die höchste Phase im Verhältnis zum Anschluss: Balken an den Karten, „Anschluss %“ in Standorten und Großbild. Ab 80 % kommt nach 20 s eine Warnung, ab 100 % nach 10 s ein Alarm (Hoch).

Lastgang & Spitzenlast

Aus den Live-Werten bildet StageSense Minutenmittel je Verteiler (Messgerät oder StageSmarts) und daraus 15-Minuten-Mittel der Wirkleistung – wie ein Lastgangzähler des Netzbetreibers, aber nur aus dem, was StageSense selbst gemessen hat (Abtastung etwa alle 2 s).

• Wo: am Mac in Strom → Übersicht („Lastgang gesamt“) und auf jeder Standortseite („Lastgang DC 1“ …), jeweils Heute/Gestern; in der Web-App unter Strom → Lastgang (Heute, Gestern, 7 Tage; Gesamt, Standorte oder einzelne Verteiler). Auf der Gesamtseite /dc steht die Kennzahl „Spitze 15 min“ (höchste Viertelstunde heute mit Uhrzeit) neben der Leistung gesamt.
• Ohne Anmeldung zeigt die Web-App nur Heute und Gestern; 7 Tage und ältere Zeiträume (bis 62 Tage) gibt es nach der Anmeldung mit PIN bzw. am gekoppelten Mac. In der Internet-Ansicht stehen Heute und Gestern bereit, der CSV-Export nicht. Der Server rechnet den Lastgang im Hintergrund (nie im Takt der Überwachung), höchstens eine Auswertung gleichzeitig, und hebt ein Ergebnis eine Minute lang auf – ein Aufruf nach dem anderen belastet ihn kaum.
• Spitze: die höchste abgeschlossene Viertelstunde ohne Lücke, mit Uhrzeit (z. B. „42,3 kW · 20:15–20:30“). Gibt es noch keine vollständige Viertelstunde, steht die höchste vorhandene da, gekennzeichnet „mit Lücke“.
• Lücken: Ist ein Messgerät getrennt (USB gezogen, antwortet nicht), fehlen seine Minuten. Die Viertelstunde wird nicht mit 0 gefüllt, sondern markiert: am Mac orange bzw. leer, in der Web-App orange bzw. ein grauer Strich. In Standort- und Gesamtsummen steht dazu, welcher Verteiler fehlte; die Summe enthält dann nur die übrigen. Ein Verteiler zählt ab seiner ersten Viertelstunde mit Werten mit.
• Standorte summieren die Verteiler nach der aktuellen Zuordnung; gesamt sind alle Verteiler mit Werten im Zeitraum.
• Im Client-Modus rechnet der Server; der Mac holt die Viertelstunden über die Verbindung zum Server.
• Lese-Schnittstelle: GET /api/lastgang?von=&bis=&ebene=verteiler|standort|gesamt (Zeit als Sekunden seit 1970 oder 2026-10-29/2026-10-29T14:00; ohne Angabe heute, gesamt; höchstens 62 Tage). Die Antwort enthält nur Namen, keine Geräte-IDs.

CSV-Export der Minutenmittel

Minutenmittel von U, I und P je Phase, cos φ je Phase, Frequenz, THD U und THD I je Phase, N-Strom, Unsymmetrie U und dem Energiezähler – je Verteiler, Zeitraum oder Einsatz. Format für Excel (DE): Semikolon, Dezimalkomma, UTF-8 mit BOM, eine Zeile je Minute und Verteiler; die letzte Spalte sagt, aus wie vielen Live-Werten die Minute gemittelt ist.

• Mac: Knopf „CSV …“ an der Lastgang-Karte (Tag), im Verlauf (Zeitraum bis 31 Tage) und in Einsatz & Bericht (je Einsatz).
• Web-App: Strom → Lastgang → CSV-Export – nur nach Anmeldung mit PIN (bzw. für den gekoppelten Client); ohne Anmeldung antwortet /api/export mit „Anmeldung nötig“. Ohne gesetzte PIN gibt es den Export nur in der Mac-App.
• Höchstens 31 Tage bzw. 400 000 Zeilen je Datei.
• Beginnt ein Verteiler- oder Einsatzname mit =, +, -, @ oder einem Tabulator, steht in der CSV ein ' davor – Excel führt den Namen sonst als Formel aus.

Verlauf (Langzeit-Archiv)

„Verlauf …“ an der Lastgang-Karte öffnet den Verlauf mit frei wählbarem Zeitraum: Tag, Woche oder Tour (von–bis), wahlweise Leistung, Spannung (Mittel der Phasen), Strom (höchste Phase) oder THD U je Verteiler. Lücken bleiben offen. Die Werte kommen aus dem Energie-Archiv: Minutenwerte je Messgerät, am Mac im Datenordner, am Server im Datenordner oder auf einer HDD (siehe StageSense-Server → Energie-Archiv). Aufbewahrung Standard 400 Tage; im Datenordner höchstens 2000 MB (am Mac unten im Verlauf einstellbar), immer mindestens 2 GB frei und auf der Systemplatte höchstens 80 % belegt – darüber fallen die ältesten Tage weg. Im Client-Modus holt der Mac den Verlauf vom Server.

Stromplan

Aus dem Patch berechnet: Leistung je Lampe (merkt sich StageSense je Gerätetyp), Verteiler, Plugbox, Steckplatz, Kreis und Phase.

Leistungs-Bibliothek: Patch → „Leistung aus Bibliothek …“ schlägt für jeden Gerätetyp die maximale Leistungsaufnahme laut Hersteller-Datenblatt (230 V / 50 Hz) vor – aus einer mitgelieferten Bibliothek mit rund 900 gängigen Modellen (Movingheads, Washes, Profiles, Beams, LED-Bars, Strobes, Blinder, Verfolger, Nebel- und Hazer, DMX-Ventilatoren, MA-Pulte und -Nodes; u. a. Robe, Martin, GLP, Ayrton, Claypaky, Vari-Lite, Chauvet Professional, Elation, ETC, High End, SGM, JB-Lighting, Cameo, Astera, Showtec, ADJ, Prolights, ACME, Briteq, Robert Juliat, ARRI, De Sisti, Portman, MDG, Look Solutions, Hazebase). Je Eintrag stehen Quelle (Link zum Datenblatt) und Sicherheit (Datenblatt, Händlerangabe, geschätzt), wo angegeben auch typische Leistung, cos φ bzw. VA, Einschaltstrom, Netzteil und Steckverbinder (Tooltip). Die Zuordnung ist unscharf: Modus-Zusätze aus Pult-Bibliotheken („Mode 1“, „M2 - Normal“, „4 channel“) zählen nicht, „Robin …“ ist Robe, Schreibweisen wie „XPAR“/„X-PAR“ oder „W 600“/„W600“ passen zusammen, ein abweichender Hersteller im Patch schließt aus. Je Typ bestätigen (vorausgewählt sind Typen ohne eigenen Wert); übernommen wird nur für Lampen ohne Leistung. Eigene Werte haben Vorrang – ein von Hand eingetragener Wert, das Gedächtnis je Typ und die Angabe aus GDTF-Dateien (PowerConsumption, beim Patchen aus GDTF) werden nie überschrieben. Übernommene Werte merkt sich StageSense je Typ wie eigene. Beim Zuordnen einer GDTF (Show-Import, „GDTF zuordnen …“, „Geräte patchen …“) gilt dieselbe Reihenfolge automatisch: gemerkter Wert des Typs → Leistung aus der GDTF → Wert aus der Bibliothek; der Bibliothekswert füllt dabei nur Lampen ohne eigenen Wert, und die Zuordnung zeigt an, woher die Leistung kommt. Hinweis: Einige Hersteller nennen nur VA oder nur die typische Leistung – dann steht das beim Eintrag; die Bibliothek nimmt in diesem Fall den angegebenen Wert (VA ≥ W, also eher zu hoch als zu niedrig). Gerechnet wird je Gerätetyp einmal – auch große Patches (über 1.000 Lampen) gehen ohne Wartezeit.

• Phasenschema Han 16: Kreis 1 L1, 2 L2, 3 L3, 4 L1, 5 L2, 6 L3. „Automatisch auf Kreise verteilen“ gleicht die Last aus.
• UV-Baum: Hauptverteiler und Unterverteiler mit Bibliothek (z. B. Powerlock 400 A → 4× CEE 125 A, CEE 125 A → 8× Han 16, CEE 63 A → 4× Han 16).
• Messgeräte verknüpfen: Je UV ein Messgerät zuordnen. Steckt in einem Unterverteiler ein eigenes Messgerät, zählt es als Teillast des übergeordneten und wird nicht doppelt addiert.
• Plan und gemessene Werte stehen nebeneinander; Export als CSV.

Volllast je DC: Alle Lampen des Patches auf ihrer Maximalleistung, je Phase gegen die Absicherung des Standorts – ein Planwert, gerechnet mit cos φ 0,95 und Gleichzeitigkeit g = 1. Der Strom kommt aus der Scheinleistung: aus der Leistungs-Bibliothek, sonst Leistung ÷ cos φ des Typs, sonst Leistung ÷ 0,95.

• Phase: von Hand bzw. aus dem Kreis (Phasenschema), sonst aus dem Steckplatz 1–6 (1/4 → L1, 2/5 → L2, 3/6 → L3).
• Verteiler → Standort: Patch-Einstellungen → Verteiler ↔ Standort; „automatisch“ nimmt den Standort des zugeordneten Messgeräts (auch des übergeordneten Verteilers), sonst den Namen („DC 1 › UV3“ → DC 1). Passt ein Name zu zwei Standorten, bleibt der Verteiler offen. Einstellungen → Zurücksetzen → Stromplan setzt auch diese Zuordnung zurück.
• Bezug: die Absicherung je Anschluss, bei mehreren die Summe („auf n Anschlüsse verteilt“), sonst die Einspeisung laut Stromplan.
• Strom-Detail → Volllast: Standort, je Anschluss, je Verteiler und Plugbox-Kanäle. Lücken stehen als Zahl da: Lampen ohne Leistung (die Summe heißt dann „≥ …“), ohne Phase, ungültiger Steckplatz, ohne Verteiler, Verteiler ohne DC. Hinweise nur als Info, z. B. „Volllast über Absicherung: L1 140 A bei 125 A“ oder „Plugbox 3 Kanal 2: 4,1 kW über 16 A“ (Sicherung aus den Patch-Einstellungen).

USV

Netzwerk-USV per SNMP (UPS-MIB, z. B. APC, Delta, Eaton, Riello, Socomec, Generex) und USB-USV am Mac. Gelesen werden Netz- oder Akkubetrieb, Batteriezustand, Ladung, Restlaufzeit, Zeit im Akkubetrieb, Akkuspannung und -temperatur, Ein-/Ausgangsspannung und Frequenz, Ausgangsleistung und Last je Phase, dazu Nennleistung (VA/W), bei Delta das Datum des letzten und des nächsten Akkutauschs (Gerätekarte: Alter des Akkus, orange ab 5 Jahren, rot wenn der Tausch fällig ist), das Ergebnis des letzten Selbsttests und die Alarmtabelle der USV im Klartext (z. B. „Akku defekt – tauschen“, „Lüfter defekt“, „Ladegerät defekt“, „Überlast am Ausgang“). Meldet ein Gerät 0 A Ausgangsstrom trotz Last (manche Delta-Agenten), blendet StageSense den Strom aus. Probleme: Akkubetrieb (Katastrophe), Akku schwach, Batteriefehler, Restlaufzeit unter Grenze, Bypass (Hoch), Last über Grenze (Mittel), Batterietemperatur ab 40 °C (Warnung), Alarme der USV (Hoch, außer Akku-/Bypass-Meldungen, die schon oben erscheinen) Selbsttest fehlgeschlagen (Mittel) und Akkutausch fällig (Warnung, wenn das vom Gerät gespeicherte Datum überschritten ist). Grenzen für Restlaufzeit und Last stehen in den Netzwerk-Einstellungen. Die Übersicht zeigt im Strom-Kasten die Zahl der USVs am Netz und die kürzeste Restlaufzeit.

Licht

Der Bereich Licht liest Art-Net, sACN, MA-Net und RDM mit und zeigt, wer welches Universum sendet, welcher Node es ausgibt und ob es Konflikte gibt. Die Überwachung startet mit „Überwachen“ oben rechts (oder automatisch beim Start). Reiter: Überblick, Universen, DMX, Nodes, MA-Net, RDM – MA-Net und RDM erscheinen erst, wenn es dort etwas gibt.

Überblick und Timecode

Kennzahlen zu Universen, Quellen, Konflikten und Nodes sowie der Art-Net-Timecode (läuft/steht, Bildrate).

Timecode an den MA-Pulten: Ist bei einem grandMA2-Pult der System Monitor angehakt (siehe MA-Protokoll), zeigt StageSense dessen Timecode-Eingänge – LTC (z. B. „LTC 1“) und MIDI-Timecode („MTC (MIDI 2)“) – im Timecode-Kasten, in der FOH-Ansicht, in der Web-App unter Licht und im Reiter MA-Net bei der Station: läuft (eingerastet) oder steht (Lock verloren). Jedes Pult meldet nur seine eigenen Eingänge. Den laufenden Timecode-Wert schickt das Pult dabei nicht: Kennt StageSense ein Sprungziel (das Pult meldet z. B. „Jumped 0 -> 1295933“ beim Einstieg), rechnet es den Stand mit der verstrichenen Zeit hoch und zeigt ihn mit ≈ (geschätzt). Ins Ereignisprotokoll kommen „Timecode … läuft“, „Timecode … gestoppt bei …“ (erst nach 10 s Stillstand – MIDI-Timecode rastet beim Spulen sekündlich ein und aus) und „Timecode … gesprungen 14:29:58 → 12:59:57“ (Warnung). Einen genauen Wert mit Frames liefert nur Art-Net-Timecode im Netz.

Universen

Jedes Universum mit seinen Quellen: Name, IP, Priorität (sACN), Bildrate. Konflikt heißt: zwei Quellen mit gleicher höchster Priorität senden dasselbe Universum. Fällt eine Quelle aus oder hat ein Universum, das lief, keine Daten mehr, erscheint das als Problem (siehe Meldung und Behoben). Konflikte stehen ebenfalls als Problem in der Liste – ein Problem je Sendergruppe (z. B. „Pult A ↔ Pult B auf 10 Universen“), mit Bestätigen am Mac und in der Web-App; benachrichtigt wird nur darüber (nach Schwelle, einmal bis zum Bestätigen). MA-Net2 gilt nie als Konflikt: in einer grandMA2-Session senden alle Pulte und NPUs dieselben Daten, das regelt die Session. sACN-Universen ohne Universe Discovery trägt man in den Netzwerk-Einstellungen nach (z. B. „1-32, 100“).

Art-Net-Empfänger: Pulte senden Art-Net oft per Unicast nur an die Nodes. Mit „Als Art-Net-Empfänger anmelden“ (Netzwerk-Einstellungen) meldet sich der Mac als Visualisierer – das Pult schickt dann auch hierher.

DMX

Die 512 Kanäle eines Universums live. Ein Tipp auf einen Kanal zeigt, zu welcher Lampe er gehört (aus dem Patch), mit allen Kanälen der Lampe – am Mac und in der Web-App.

Nodes

Ein Node je Zeile, alle Buchsen auf einen Blick (ohne seitliches Scrollen), nach Namen sortiert. Jeder Node als Geräteansicht mit seinen Buchsen: welches Universum auf welchem Port liegt, ob er ausgibt, Eingang, Merge (HTP/LTP), sACN-Modus, Konflikt. Modelle werden automatisch erkannt (MA, Luminex, Swisson, ELC, DMXking, ChamSys, Obsidian, ENTTEC, Pathway, Avolites) und mit passendem Gehäuse gezeichnet. MA-Nodes, die nur MA-Net sprechen, erscheinen mit Session und Software. grandMA2-Nodes (MA-Net2) melden ihre Port-Belegung selbst: Jede Buchse zeigt das Universum („U 101“) oder „nicht belegt“ und darunter, wie viele Geräte aus dem Patch auf diesem Universum liegen. Bei grandMA3-Nodes ist die Belegung im MA-Net nicht lesbar. grandMA2: DMX live aus dem MA-Net2 – StageSense liest die DMX-Werte, die die NPUs ins MA-Net2 senden, passiv mit. Sie erscheinen als Universen „MA-Net2“ in der Universen-Liste und im DMX-Monitor. Teilen sich mehrere NPUs ein Universum (jede rechnet ihre Kanäle), fügt StageSense die Teile zu einem Bild zusammen – die Quelle heißt dann z. B. „PU1 + PU3“. Das Pult schickt alle Universen mit, dort steht aber nicht die tatsächliche Ausgabe; seine Daten zählen nur, wenn keine NPU DMX sendet. Node-Buchsen mit Live-Daten leuchten grün und zeigen die Zahl der Kanäle > 0. Gezählt wird nur, was physisch da ist: Ohne NPUs schickt das Pult zwar alle 256 Universen mit, StageSense zeigt davon nur die, die ein Node-Port ausgibt oder die im Patch vorkommen; die zusätzliche Art-Net-Meldung eines MA-Nodes zählt nicht als eigenes Universum. Ebenso zählt die Geräteanzahl jede Hardware einmal – ein MA-Node mit MA-Net- und Art-Net-Adresse ist ein Gerät. Hat ein MA-Node zusätzlich eine Art-Net-Adresse (z. B. 10.x), erscheint er nur einmal – mit beiden Adressen.

MA-Protokoll (grandMA2 System Monitor)

Bei grandMA2-Pulten, NPUs/Processing Units und Nodes kann StageSense den System Monitor mitlesen – per Telnet auf Port 30001, laut MA ein nur lesender Zugang; StageSense sendet dabei keine Befehle (auch keine Telnet-Antworten). An der Konsole einmal Setup → Console → Global Settings → Telnet auf „Login Enabled“ stellen, dann im Reiter MA-Net (Tab Session) bei der Station „System Monitor“ anhaken (bei allen grandMA2-Stationen – Pulte, NPUs, Nodes). Die Zeilen erscheinen mit Uhrzeit im Kasten MA-Protokoll (Filter Speichern, Anmeldung, Fehler, Warnung, Suche); Speichern und Anmeldungen landen zusätzlich im Ereignisprotokoll, und je Konsole entsteht ein Tagesprotokoll im Datenordner (MA-Protokoll/). Welche Meldungen der System Monitor genau liefert (z. B. Befehle anderer Benutzer), hängt von der Konsole ab. grandMA3 bietet diesen Telnet-Zugang laut Handbuch nicht.

Filter: Die Konsole schickt bei jeder Telnet-Verbindung ihren ganzen Puffer erneut – StageSense erkennt solche Zeilen am Laufzeit-Stempel und übernimmt jede nur einmal, auch über Neustarts hinweg. Verworfen werden Zeilen ohne Aussage: Bildschirm-Zeichnen (MainDraw), die Telnet-Verbindung selbst (D-TEL/TCPClient), Bestätigungen und fehlende Gobo-Bilder der Fixture-Library. Ins Ereignisprotokoll kommen Speichern, Anmeldungen, echte Fehler sowie Stations- und Session-Timeouts, Netzwechsel und instabile Ausgabe; MA-Net-Paketwiederholungen höchstens einmal je 5 Minuten und Konsole (mit der Zahl der Pakete).

Paketwiederholungen als Problem: Fehlen einer Station der MA-Net2-Session Pakete, fordert sie diese nach („Receiving n Data NACKS from …“), und der Master schickt sie an alle noch einmal („Received n retransmissions“). Einzelne Wiederholungen sind normal. StageSense meldet: Warnung ab 300 wiederholten Paketen in einer Minute oder bei Wiederholungen in 5 Minuten am Stück (Dauerverlust); Hoch ab 1.000 in einer Minute, bei einem Schub (ab 40) zusammen mit Session-Timeout, verlorener Station oder „Output is now unstable“, oder wenn dieselbe Station in 30 Minuten bei drei getrennten Schüben nachfordert. Die Meldung nennt die Station, die nachfordert (sie erscheint an deren Standort), und den Anlass, z. B. „MA-Net: 319 Pakete wiederholt in 1 min – Service-DC1 fordert nach · kurz nach „Store Cue 26“ (huwi)“. Sie verschwindet nach 5 Minuten ohne neuen Schub. Melden mehrere Pulte dieselben Wiederholungen, zählt das Pult mit den meisten (nicht die Summe). Grundlage ist der System Monitor – ein Pult mit Häkchen reicht, weil der Master die Wiederholungen an alle schickt. Tipp: Kommen die Nachforderungen von einer Station, deren Switch-Port und Netzwerkkarte keine Fehler zeigen, verliert das Pult die Pakete selbst (Last während Store/Update, ältere Rechner) – nicht das Kabel. „Alles“ zeigt alle Zeilen einschließlich der Bedienbefehle (CMD INPUT); „Befehle“ zeigt nur diese. Die Konsole meldet auch Befehle anderer Stationen der Session (z. B. „Paul 10“ = Benutzer Paul mit der Benutzernummer 10 aus dem Benutzerpool – nicht die Station). Liest StageSense mehrere Stationen mit, kommt jeder Befehl mehrfach an; gezählt und angezeigt wird er einmal (gleicher Benutzer, gleicher Text, höchstens 2 s Abstand, je Station einmal – fünfmal Clear an einem Pult bleibt fünfmal). Im Protokoll steht die Zeile dann einmal mit „+21“ hinter dem Stationsnamen; der Tooltip nennt alle Stationen, die sie gemeldet haben. Das gilt auch für gleiche Meldungen anderer Art (z. B. „Page changed from network“).

Alle Stationen: Im Tab Session schaltet „System Monitor an allen grandMA2-Stationen“ alle grandMA2-Pulte ein – auf Wunsch auch die Processing Units/NPUs, nie die Nodes –, auch Pulte, die später im MA-Net auftauchen (alle 10 s). Die Einzel-Häkchen bleiben (über „alle“ eingeschaltete Stationen sind ausgegraut). Je Station eine Telnet-Verbindung, nur lesen, höchstens 40; nach einem Abbruch versucht StageSense es nach 5 s erneut, danach mit wachsendem Abstand bis 5 min. In der Web-App steht der Zustand im Kopf des MA-Protokolls (umschalten nur in der StageSense-App).

Uhrzeit: Maßgeblich ist, wann StageSense die Zeile empfangen hat (Uhr des Servers bzw. dieses Rechners) – danach richten sich Sortierung, Filter, Statistik und Leaderboard. Die Uhr im Pult ist nur Zusatzinfo: Fährt man mit der Maus über die Uhrzeit (Web-App: antippen und halten), steht dort z. B. „Pult-Uhr 20:23:00 (Abweichung +3 min)“. Die Abweichung misst StageSense je Pult laufend aus den live empfangenen Zeilen und zeigt sie im Reiter MA-Net bei der Station („Pult-Uhr +3 min“, orange ab einer Minute) und in der Web-App im Kopf des MA-Protokolls. Zeilen, die ein Pult beim Verbinden aus seinem Puffer nachschickt, tragen die Pult-Uhr minus der gemessenen Abweichung und ein ↻ („nachgeladen“). Hat das Pult seit dem Verbinden noch nichts live geschickt, gleicht StageSense seinen Puffer mit den schon von anderen Stationen gezählten Befehlen ab (derselbe Befehl liegt um die Abweichung daneben) und lernt daraus die Abweichung – solche Zeilen zählen nicht noch einmal. Bis dahin gilt die per SNMP gelesene Abweichung, und zwar nur die Uhrzeit, nicht das Datum (Pulte mit leerer Pufferbatterie gehen um Wochen falsch). Eine Zeit liegt nie nach dem Empfang.

Aufteilung am Mac: Der Reiter MA-Net hat oben Tabs – Session (Sessions, Stationen, Timecode; hier wird der System Monitor je Station eingeschaltet), System Monitor / Log (das MA-Protokoll über die ganze Höhe, Zeiten = Empfang), Leaderboard und – mit Entwicklerlizenz bzw. im Client-Modus – Mitschnitt. Der zuletzt gewählte Tab bleibt gemerkt.

Statistik: Umschalter „Protokoll | Statistik“ im Tab System Monitor / Log. Je Konsole und Benutzer (ohne Beleg für die Station unter „über … gemeldet (Station offen)“): Zahl der Befehle, Clear, Store, Lieblingsbefehle, zuletzt aktiv – dazu Bestwerte wie Clear-Champion, Panik-Clear (die meisten Clear direkt hintereinander), schnellste Finger (Befehle in einer Minute), Speicher-Profi, Gruppen-Jongleur und Nachteule. Gezählt wird ab dem ältesten vorhandenen Tagesprotokoll (einmalig nachgelesen); „Zurücksetzen …“ beginnt neu, die Tagesprotokolle bleiben. Nach einem Neustart von StageSense zeigt der Kasten wieder die letzten Zeilen (je Konsole die zwei neuesten Tagesprotokolle) – zusammen mit dem, was die Konsole beim Verbinden schon geschickt hat; das Tagesprotokoll läuft unter dem zuletzt bekannten Stationsnamen weiter, auch bevor das Pult im MA-Net auftaucht.

Bediener: Wer arbeitet gerade an welcher Konsole? Am Mac oben in der Statistik (Tab System Monitor / Log) der Abschnitt Bediener, in der Web-App im MA-Protokoll der Reiter Bediener. Der System Monitor jeder Station meldet die Befehle der ganzen Session – an welchem Pult jemand sitzt, steht in keiner Befehlszeile. StageSense ordnet einen Benutzer deshalb nur mit Beleg einer Konsole zu: Start (Startbenutzer, den die Konsole beim Hochfahren selbst meldet; PUs melden niemanden), Seitenwechsel (wechselt jemand die Fader- oder Button-Seite, schreiben alle anderen Stationen „… Page changed from network“ – die eine ohne diese Zeile ist seine; dafür braucht es mindestens zwei mitgelesene Stationen), Tasten (das Pult schreibt jeden Tastendruck nur selbst ins Protokoll, z. B. „TA_X6 pressed=1“ – kommt ein Befehl kurz danach und hat nur eine der gelesenen Stationen gedrückt, sitzt der Benutzer dort; das geht auch mit nur einer gelesenen Station) oder Anmeldung („Login …“ eines Benutzers mit bekannter Konsole: der neue Benutzer sitzt dort). „Logout“ beendet die Zuordnung, und an einer Konsole sitzt immer nur einer. Ohne Beleg steht der Benutzer als „über <Pult> gemeldet · Station offen“ da (kursiv) statt bei einer falschen Konsole. Dazu: seit wann, der letzte Befehl, die Befehle und weitere Benutzer der letzten 24 Stunden. Voraussetzung: System Monitor (Telnet) an der Konsole eingeschaltet und in StageSense angehakt – je mehr Stationen mitgelesen werden, desto öfter gibt es einen Beleg.

FOH-Leaderboard: Ranglisten der Licht-Operator mit Augenzwinkern – am Mac im Reiter MA-Net im Tab Leaderboard, in der Web-App im Großformat unter /leaderboard und als letzte Seite der DC-Seiten (/dc, Top 3 auch auf „Gesamt“) (Knopf „Leaderboard“ unter Mehr, Vorschau in der FOH-Ansicht, Knopf im MA-Protokoll). Zeiträume Heute (ab 5 Uhr – eine Show nach Mitternacht zählt noch zum Vortag), Show (ab Einschalten des Showmodus; danach „Letzte Show“) und 7 Tage. Oben das Podium der meisten Befehle (Tasten-Marathon), darunter die Awards mit Platz 1–3: Schnellste Hand (Befehle in der stärksten Minute, ab 5), Store-King, Go-Drücker (Go+, Go-, Goto – Gobo zählt nicht), Update-König (Befehl „Update …“ und Update per Taste – Letzteres steht nicht als Befehl im System Monitor, nur als „Trying to Update a CMD_CUE/CMD_PRESET“ des Pults; es zählt für den Benutzer, der an diesem Pult sitzt bzw. dort gerade mit Tastendruck gearbeitet hat), Oops-Meister (Oops und Undo), Clear-All-Panik, Putzteufel (Clear), Weiterklicker (Next und Previous), Dauerbrenner (längste Schicht ohne 30 min Pause), Kaffeepausen-Profi (längste Pause bis 4 h), Nachteule (Befehle zwischen 0 und 5 Uhr, nur live empfangene) und Früher Vogel (wer an einem Tag als Erster am Pult ist: erster Befehl oder „Login“ nach mindestens 4 h Ruhe; über mehrere Tage, wer am häufigsten Erster war, mit der frühesten Uhrzeit). Dazu alle Operator mit Platz, Lieblingsbefehl und bester Minute. Gezählt wird nur die Befehlsart (z. B. „Store“) – nie der Rest der Zeile, also keine Namen, Werte oder Passwörter; an die Pulte geht nichts. Zeiten nach Empfang auf dem Server, Platz nur mit Beleg (sonst „über … gemeldet“). Der Server rechnet die Ranglisten alle 15 s und hebt die Daten 8 Tage auf; Clients bekommen die fertigen Ranglisten. Einmalig liest er die Tagesprotokolle der letzten 8 Tage nach (nur Zeiten vor den eigenen Zählungen, über alle Pulte ohne Doppelte), damit „7 Tage“ nicht erst mit dem Update beginnt.

Showfile-Sicherungen: StageSense zählt jedes Speichern des Showfiles („The show file was successfully saved.“) je Konsole – mit Zeit, Auslöser (Benutzer bei „SaveShow“, „Setup-Menü“, oder Benutzer „über die Session“, wenn eine andere Station gespeichert hat und die Konsole auf Anforderung mitspeichert) und Dateiname aus „Create backup“. Oben im Kasten MA-Protokoll: „Showfile gesichert: heute n× · gesamt n× · zuletzt …“ (Tooltip mit den letzten 15), in der Statistik die letzten zehn je Konsole. Vorhandene Tagesprotokolle werden einmalig nachgelesen (erneut gesendete Puffer zählen nicht doppelt). „Zurücksetzen …“ der Statistik lässt die Sicherungen stehen.

In der Web-App (Signal → Lichtsteuerung): MA-Sessions mit Name, Session-ID, Master und Zahl der Stationen – antippen zeigt die Mitglieder (★ = Master, orange = meldet sich nicht mehr) mit Master-Priorität, Hardware und „in der Session seit“, darunter „Fällt der Master aus, übernimmt: …“; bei einer Kollision steht „Kollision“ in Rot an beiden Sessions. MA-Protokoll & Statistik öffnet das Protokoll mit denselben Filtern und Suche (aktualisiert sich alle 5 s), die Bediener je Konsole und die Befehls-Statistik mit Bestwerten und allen Benutzern je Konsole – nur ansehen, Zurücksetzen geht nur am Mac. Das FOH-Leaderboard öffnet sich darunter bzw. direkt unter /leaderboard.

MA-Net

Passiv mitgelesen (MA-Net2 und MA-Net3), StageSense sendet nichts ins MA-Net.

• Sessions mit Teilnehmern, Master (grandMA2), Showfile und Version (grandMA3).
• Master-Priorität (nur grandMA2, Tab Session): Jede MA2-Station zeigt ihre Priorität High, Normal, Low oder Never (Never grau, nicht gemeldet leer), eingestellt am Pult unter Setup → Network → Master Priority.
• „Fällt der Master aus, übernimmt: …“ steht unter jeder MA2-Session. Es zählen nur Pulte und onPC, NPUs werden nie Master. Bei gleicher Priorität stehen alle Kandidaten da („A oder B (Normal)“), weil MA selbst entscheidet. Sonderfälle: „keine Station – kein weiteres Pult in der Session“, „keine Station – alle anderen Pulte stehen auf Never“, „noch unbekannt – nicht jedes Pult hat seine Priorität gemeldet“.
• In der zweiten Zeile jeder Station stehen die Hardware (Modell und Generation v1/v2, z. B. „grandMA3 light · v2“; Prozessor, Speicher und Seriennummer im Tooltip) und „in der Session seit 18:52 (1 min)“. „seit mind. 16:44 (Start der Überwachung)“ heißt: Die Station war schon drin, als die Überwachung startete.
• Eine geänderte Priorität steht als Info im Ereignisprotokoll und in der Blackbox („Master-Priorität: FOH Normal → Never“), ohne Push.
• grandMA2: StageSense erkennt die Geräteart aus der Ankündigung – Pult/onPC, NPU oder Node – sowie den Platz in der Session. Nur der Master meldet den Session-Namen, die anderen Teilnehmer melden den Master; StageSense fasst alles zu einer Session zusammen. MA2-Nodes melden keinen Master und werden der MA2-Session im selben Netz zugeordnet.
• Geräte werden automatisch nach ihrem MA-Namen benannt und mit passender Vorlage versehen (grandMA2 Pult, grandMA2 NPU, MA-Node MA-Net2, grandMA3 …). Früher fälschlich als „grandMA2 Pult“ angelegte NPUs und Nodes werden automatisch umgestellt.
• Soll-Rolle im Geräte-Editor: Master oder Backup. Alarme bei „Backup hat übernommen“ (grandMA2), Backup nicht in der Session, Backup sendet nicht, Backup nicht synchron (andere Version oder anderes Showfile).
• Station verlässt die Session → Problem (ist das Gerät selbst aus, nur als Folge seines Ausfalls); ist die ganze Session nicht mehr sichtbar, eine Meldung „nicht mehr sichtbar“ für die Session statt einer je Pult; grandMA2-Master gewechselt → Warnung. Wie die Rückkehr eines Pults gemeldet wird, steht unter Meldung und Behoben. Unterschiedliche Versionen oder Showfiles in einer Session → Warnung. Verglichen wird nur die öffentliche Versionsnummer (höchstens vier Stellen, z. B. 3.9.63.11) aus der Ankündigung der Geräte – keine Build- oder Architekturkennungen.
• MA3-Hardware im grandMA2-Modus: grandMA3-Pulte und -Nodes, auf denen grandMA2 läuft, melden nebenbei MA-Net3 mit der Version ihrer grandMA3-Systemsoftware (z. B. 2.5.1.0). StageSense zeigt sie neben der grandMA2-Version: in der Session-Liste als „MA3 2.5.1.0“, in der Geräteübersicht und Gerätekarte als „3.9.63.11 · MA3 2.5.1.0“, in den Gerätedetails (auch Web-App) als Zeile „MA3-Software“. Nicht jede MA3-Hardware im grandMA2-Modus sendet MA-Net3 (in der Praxis oft nur einzelne Pulte und Nodes). Aus der MA-Net3-Ankündigung (1× pro Sekunde je Gerät an 236.4.1.0) liest StageSense Name, Session-Name (ohne Session „Local“), Session-ID, Systemversion, Showfile, Geräteart (Pult, Processing Unit, Node) und MAC – geprüft an 38 Geräten gegen deren MA-Net2-Meldung. Benutzer, Befehle und die Rolle in der Session (Master/Backup) stehen darin nicht; wer an welchem Pult arbeitet, kommt nur aus dem System Monitor (siehe MA-Protokoll → Bediener). Für die übrigen liest StageSense die Version per SNMP: Die MA-Software legt je installierter Version einen Datenordner an, der in der Mount-Tabelle steht (/home/madata/gma3_2.5.1, für grandMA2 /home/data/V_3.9.63). Angezeigt wird die neueste installierte MA3-Version („MA3 2.5.1“); sind mehrere installiert, nennt die Gerätekarte alle („installiert: 2.5.0, 2.5.1“). Nodes haben diese Ordner nicht – dort, falls kein MA-Net3 kommt, abgeleitet über das gleiche System-Build (Kernel, Build-Nummer, Build-Zeitpunkt) wie ein Gerät, das MA-Net3 meldet: „≈ MA3 2.5.1.0“. Der Tooltip nennt jeweils die Quelle. Tabellen liest StageSense in Blöcken von 12 Einträgen, damit Antworten mit langen Werten unter einem Paket bleiben (größere werden auf manchen VLAN-Strecken verloren). SMART-Werte der Pult-SSDs gibt es übers Netz nicht: Der SNMP-Dienst der MA-Geräte zeigt die NVMe-SSD gar nicht und hat keine Erweiterungen; StageSense erkennt Plattenprobleme im Betrieb nur an den Folgen (Dateisystem „nur lesen“, Platte verschwunden, Neustarts) – SMART liest der Hardware-Test vom Boot-Stick (Pult-Diagnose).
• Gerätenamen: Automatisch angelegte MA-Geräte heißen wie ihre MA-Net-Station. Namen aus Datenquellen – der sACN/Art-Net-Absender einer grandMA („GMA2:3.9.63.11“) oder eine von mehreren NPUs gemeinsam gesendete MA-Net2-Quelle („PU-14 + PU4“) – ersetzt StageSense durch den Stationsnamen; selbst vergebene Namen bleiben. Wie Namen dem Gerät folgen, steht unter Netzwerk → Geräte und Vorlagen.
• Hardware: Tab Hardware – Generation (v1/v2), Arbeitsspeicher, Modell und Seriennummer aller Pulte und PUs; siehe Netzwerk → Hardware der MA-Pulte und PUs.
• MA-Geräte antworten zusätzlich auf Ping und SNMP. StageSense liest automatisch: Modell und Seriennummer (z. B. grandMA3 full-size, grandMA3 8Port Node, grandMA3 onPC 8Port Node), CPU-Last (Durchschnitt aller Kerne – MA-Nodes halten einen Kern dauerhaft voll, das ist normal und löst keinen Alarm aus), Arbeitsspeicher (echter Bedarf ohne Puffer/Cache), bei Pulten Temperaturen mit lesbaren Namen (CPU, CPU (Mainboard-Messung) = derselbe Wert über den Mainboard-Chip (PECI), SSD, Mainboard, Board, Grafikchip – je nach Hardware-Generation des Pults unterschiedlich) und Lüfterdrehzahl (nicht bei jeder Pult-Generation messbar), die Netzwerkanschlüsse (interne Verbindungen ausgeblendet; beim grandMA3 full-size mit drei Anschlüssen als Ethernet 1–3 wie auf der Rückseite, auch ohne Kabel sichtbar) und ob die MA-Software läuft (grandMA2 auf MA3-Hardware: gma2_compat, Nodes: 4port_compat). Antwortet ein MA-Gerät, aber die Software läuft nicht, meldet StageSense ein Problem (hoch). Lüfter-Alarm: Fällt ein Lüfter unter die Grenze aus den Einstellungen (Standard 400 U/min, normal am Pult um 800 U/min), meldet StageSense ein Problem (hoch), steht ein Lüfter, der schon gelaufen ist, einen Notfall – jeweils erst nach 20 s, damit kurze Regelschwankungen nicht stören. MA-Nodes liefern per SNMP keine Temperatur und keine Lüfterwerte. Pulte ohne Lüftermessung (ältere grandMA3-Rechner mit Core i5-7500 melden keine Drehzahl): StageSense lernt die normale CPU- und Grafikchip-Temperatur je CPU-Lastbereich (etwa 20 Abfragen, danach gleitend über rund eine Stunde). Liegt die Temperatur bei ähnlicher Last 12 °C oder mehr über dem Normalwert, meldet StageSense nach 3 Minuten „Kühlung prüfen“ (hoch). Hardware-Generation: Bei Pulten und PUs zeigt die Gerätekarte den eingebauten Rechner (z. B. „Core i5-12500 (Intel 12. Gen) · 32 GB“ oder „Core i5-7500 (Intel 7. Gen) · 16 GB“) und ob eine Lüftermessung vorhanden ist. Beide Generationen melden per SNMP dieselbe Artikelnummer. StageSense merkt sich Seriennummer und Hardware je Gerät; wechselt sie unter derselben Adresse (Pult getauscht), steht das im Ereignisprotokoll. MA-Nodes im MA-Net-Modus gelten als reine MA-Geräte: Ihre zusätzliche Art-Net-Adresse (meist 10.x) wird weder als eigenes Gerät angelegt noch angepingt oder in der DC-Ansicht gezeigt; automatisch angelegte Doppel-Einträge entfernt StageSense selbst (Hinweis im Ereignisprotokoll). Ausnahme: Der Node bekommt tatsächlich Art-Net (Art-Net-Modus) – dann zählt die Art-Net-Adresse als echter Datenweg.
• MA-Sessions: Verlässt ein Pult die Session oder sucht ein Gerät seinen Master neu, meldet es kurz 0.0.0.0 bzw. 255.255.255.255 als Master – das wertet StageSense als „keine Session“ (keine Schein-Session). Die vollständige Meldung eines Geräts setzt seinen Session-Zustand jedes Mal neu. Die Session-ID (wie am Pult unter Setup → Network) steht in jeder Meldung von Pult und NPU/Processing Unit (Byte 0x23, Byte 0x20 = Platz); StageSense gruppiert danach und zeigt sie an („HFS26 (ID 1)“). MA2-Nodes nennen ihre Session nur im Aufnahme-Handschlag beim Hochfahren oder Wiederverbinden – den liest StageSense mit und schreibt ins Ereignisprotokoll, z. B. „FOH-16: in MA-Net2-Session „HFS26“ (ID 1) aufgenommen (Handschlag mit Showlight-Backup, Service-DC1)“. Ohne Handschlag ordnet StageSense Nodes über das Netz der Session zu, immer derselben. Manche grandMA3-Nodes melden nach einem Neustart nebenbei MA-Net3 mit „Local“ (keine Session) – das zählt nicht als eigene Session. Auch grandMA3-Hardware im grandMA2-Modus sendet beide Protokolle: StageSense zeigt jedes Gerät einmal (je IP) mit „MA-Net2 + MA-Net3“ und den Raten getrennt; „Ohne erkannte Session“ steht nur, wer in keinem der beiden Protokolle zu einer Session gehört. Zähler (Dashboard, Traffic, Orte, Suche) zählen Geräte, nicht Protokolle. Session-Kollision (MA2): Der Master einer Session meldet sich selbst als Master. Erklären sich zwei Pulte oder NPUs zum Master derselben Session-ID, führt StageSense beide Sessions getrennt (die größere behält die ID, die zweite erscheint zusätzlich mit derselben ID) und meldet nach 15 s ein Problem „Session-Kollision“ (Hoch) – aber nur, wenn beide Master am selben Adapter ankommen (an zwei getrennten Netzen bzw. VLAN-Adaptern dürfen Sessions dieselbe ID haben) mit beiden Sessions, ihren Mastern und der Zahl der Stationen. Stationen der zweiten Session gelten dabei nicht als „aus der Session gefallen“. Meldet der System Monitor einer Konsole „collision“ oder „conflict“, steht das als Warnung im Ereignisprotokoll.
• MA-Ausgabe (grandMA2 mit System Monitor): Aus der „Output Table“ des Pults zeigt StageSense die DMX-Kanäle der Ausgabe und die Zahl der Geräte – gesamt und je Station. Das sind nicht die Parameter der Lizenz (16-Bit-Attribute zählen als zwei Kanäle); genutzte Parameter zeigt nur das Pult selbst. „Parameter verfügbar“ rechnet StageSense nach der MA-Regel aus den Stationen, die es im MA-Net sieht: das größte Pult (full-size 8.192, light/compact 4.096, onPC 0) plus 4.096 je NPU/Processing Unit (höchstens 15), Obergrenze 65.536 – z. B. full-size + 14 Processing Units = 65.536. Stationen in einem anderen Netz fehlen in der Rechnung. Anzeige in der Gerätekarte des Pults und in der Web-App.
• Luminex LumiCore / LumiNode (Firmware 2.x): Per SNMP geben diese Geräte nur Laufzeit, CPU und Speicher frei. StageSense liest deshalb zusätzlich die Schnittstelle der Weboberfläche – nur lesend (ausschließlich Abfragen; Profil laden, Neustart, Reset, Identify oder RDM-Discovery sind im Leser gar nicht vorhanden). Erkannt wird ein Gerät, wenn Name oder Notiz „Lumi“ enthält, der SNMP-Name mit „LUM“ beginnt oder ein Luminex-Art-Net-Node unter der Adresse antwortet. Abfrage alle 10 s. Die Gerätekarte zeigt Modell, Seriennummer, Firmware (mit Ausweichversion), aktives Profil (orange, wenn geändert und nicht gespeichert), Zahl der gespeicherten Profile, VLAN-Gruppen mit Adressen, ob die Weboberfläche ein Passwort hat, und eine Tabelle Process Engines: Modus, Eingang, aktuelle Quelle mit Priorität, Ausfälle (wie oft die Quelle seit Gerätestart weggefallen ist) und Ausgang. In der DC-Ansicht erscheint der LumiCore mit seinen Universen und ob alle Engines eine Quelle haben. Alarme: Engine ohne aktive Quelle (hoch, nach 5 s). Ereignisprotokoll: Quelle ausgefallen (Zähler steigt), Sender- oder Prioritätswechsel, Firmware- und Profilwechsel, einmalig der Hinweis auf eine Weboberfläche ohne Passwort.

RDM

„Scan“ fragt alle Nodes nach ihren RDM-Geräten. Je Gerät: Hersteller, Modell, Adresse und Footprint (Überschneidungen rot), Modus, Firmware, Betriebs- und Lampenstunden, Temperatur, Statusmeldungen (z. B. Übertemperatur, Lampe zündet nicht, Sicherung ausgelöst, Lüfterfehler, Fluid niedrig). Nach einem Scan liest StageSense alle 5 Minuten gedrosselt nach (nur GET). Schreiben (Adresse, Modus, Label, Identify) nur nach ausdrücklicher Freigabe.

DMX-Test

Reiter DMX-Test im Bereich Licht (früher unter Patch): Lampen gezielt hellmachen oder eine Test-Cue fahren – gibt Art-Net/sACN aus und läuft nur, solange du ihn startest. Welche Universen er bespielt, wählst du in einem umbrechenden Raster (Knöpfe „alle“ und „keine“) – auch bei vielen Universen. „Hell machen“ für ausgewählte Lampen geht weiterhin direkt in der Patch-Tabelle.

Pult-Diagnose

Reiter Pult-Diagnose im Bereich Licht – alles nur lesend, Session und Showfiles werden nicht verändert.

• Pulte: Konsolen-Check übers Netz für alle Pulte und PUs („Alle prüfen“ oder je Pult). Geprüft werden:
  • Ping, SNMP und ob die MA-Software läuft;
  • die Platte (wird sie noch gemeldet, Zustand) und die Datenpartitionen: lesen/schreiben oder nur noch lesbar, Belegung;
  • Laufzeit und Neustarts, Uhr des Pults;
  • Antwortzeit über fünf Abfragen (eine hängende Platte bremst das ganze System), Temperaturen, Lüfter, Speicher.

  Der Bericht lässt sich kopieren oder sichern. SMART-Werte und einen Oberflächentest liefert das Pult nicht per SNMP – dafür gibt es den Hardware-Test.

• Dauerüberwachung: Bei jeder SNMP-Abfrage eines Pults (etwa jede Minute) meldet StageSense als Problem:
  • Dateisystem nur noch lesbar (Linux schaltet bei Plattenfehlern um; Showfile kann nicht gespeichert werden) – beim Pult Katastrophe;
  • Platte nicht mehr gemeldet;
  • unerwarteter Neustart (zwei in 24 h: Hoch) – erkannt an kleinerer SNMP-Laufzeit als bei der vorigen, früheren Abfrage. Wird die Überwachung neu aufgesetzt (Lizenz, MA-Net-Neuaufbau), verwirft StageSense die laufende Abfragerunde; eine ältere Lesung, die nach einer neueren eintrifft, gilt nie als Neustart. Bei Nodes (ohne Platte) heißt der Rat „Netzteil, Kabel und Temperatur prüfen“ statt „Platte prüfen“;
  • Partition über 90 % belegt;
  • Uhr mehr als einen Tag falsch (Pufferbatterie);
  • sehr träge Antworten.
• Showfiles: grandMA2/3-Showfiles, Ordner oder ganze USB-Sticks prüfen (Knopf oder hineinziehen).
  • Beschädigt heißt: Datei leer, genullt oder abgeschnitten; gzip-Prüfsumme falsch (MA2 .show.gz); bei MA3 ist die Datenblock-Kette unterbrochen oder ein Block hat die falsche Größe. Geeicht an über 180 gesunden Showfiles (keine Fehlmeldung) und absichtlich beschädigten Kopien (alle erkannt, auch ein einzelnes gekipptes Bit bei MA3).
  • Plugins: Alle in der Show eingebetteten Lua-Plugins (grandMA2 und grandMA3) werden herausgelöst und auf Syntaxfehler geprüft – wie der Lua-Compiler, ohne den Code auszuführen. Befund z. B. „Plugin ‚X‘: Syntaxfehler – Zeile 12: ‚end‘ erwartet (zu ‚function‘ in Zeile 3)“; Steuerzeichen im Code deuten auf Beschädigung. Geeicht an 301 Showfiles mit 88 Plugins (keine Fehlmeldung). Ob ein Plugin inhaltlich richtig arbeitet, kann keine Prüfung ohne Pult sagen.
  • Patch-Befunde (doppelte Fixture-IDs, doppelte/überlappende DMX-Adressen, fehlende Gerätetypen) erscheinen als Hinweis, weil das Showformat nicht offengelegt ist und nur näherungsweise gelesen wird.
  • Multipatch (dasselbe Gerät mit gleicher Fixture-ID und gleichem Namen auf mehreren DMX-Adressen, z. B. NeonFlex-Stränge oder eine Zusatzadresse in Universum 255) ist gewollt und wird als „Multipatch: n Geräte auf mehreren DMX-Adressen“ genannt – nicht als doppelte Fixture-ID. Als doppelt gilt eine ID nur, wenn verschiedene Geräte unter ihr liegen.
  • Versionen derselben Show (z. B. „shows“ und „backups“ eines Pults) werden verglichen: deutlich kleiner oder viel weniger Geräte als die Version davor → Auffälligkeit.
  • Ungezippte MA2-Shows (.show) haben keine Prüfsumme – dort ist nur der Inhalt prüfbar.
  • Sicherungsordner (Netzwerk → Dienste) werden automatisch geprüft: Ist die neueste Sicherung beschädigt, gibt es ein Problem „Hoch“.
• Hardware-Test: technisches Prüfwerkzeug. Das Pult startet dafür von einem eigenen USB-Stick mit Linux-Live-System (SystemRescue) statt vom MA-System – nur über das einmalige Boot-Menü; die Bootreihenfolge des Pults wird nicht geändert. Der Test stammt nicht von MA Lighting und ist von MA Lighting weder geprüft noch freigegeben. Hinweis vor dem Start (ab Build 218; am Pult, in der App und im LIESMICH auf dem Stick gleich): „Der Boot-Stick startet ein eigenes Prüfsystem. Daten und Software auf dem Pult werden nicht verändert; der Test liest nur. Nutzung auf eigene Verantwortung, nur an eigenen Pulten oder mit Zustimmung des Eigentümers.“ Mit dem Schalter „Laufwerks-Selbsttest und Diagnose-Abbild der SSD“ lautet der zweite Satz: „Daten und Software auf dem Pult werden nicht verändert. Für die Diagnose startet er einen kurzen Laufwerks-Selbsttest und lässt das Laufwerk ein Diagnose-Abbild erstellen; beides wird im Laufwerk selbst vermerkt.“ Bis Build 218 gibt es die beiden Schalter beim Erstellen noch nicht: Dann laufen Selbsttest, Diagnose-Abbild und Ruhetest-Vergleich immer, und „Komplett“ sichert die Showfiles mit.
  • Boot-Stick erstellen (direkt in StageSense):
    1. „SystemRescue laden“ (ca. 1,3 GB von system-rescue.org). Die SHA-256-Prüfsumme wird kontrolliert, sonst wird die Datei verworfen. Alternativ „Andere ISO …“ für eine neuere Version.
    2. USB-Stick wählen. Angezeigt werden nur wechselbare USB-Sticks von 4 bis 256 GB; empfohlen sind 16 GB oder mehr.
    3. Zwei Schalter, beide standardmäßig aus (ab Build 218):
       • „Showfiles und Plugins des Nutzers auf den Stick sichern“ – gesichert wird nur aus gma2/shows, gma2/plugins, gma3_library/shows und gma3_library/plugins, nie der MA-Lieferumfang (z. B. zur Rettung vor einem Plattentausch).
       • „Laufwerks-Selbsttest und Diagnose-Abbild der SSD“ – aus: am Laufwerk nur SMART-Werte und Sensoren lesen; an: zusätzlich ein kurzer Selbsttest im Laufwerk, Ereignisprotokoll und Hersteller-Telemetrie (Diagnose-Abbild) sowie der SSD-Ruhetest-Vergleich (Menü 4) – beides wird im Laufwerk selbst vermerkt.
    4. „Boot-Stick erstellen …“ – die Bestätigung „Stick löschen und Boot-Stick erstellen?“ zeigt den Hinweis und ob Showfiles kopiert werden; mit „Einverstanden – löschen und erstellen“ geht es los – der Stick wird komplett gelöscht.

    Der Stick wird als FAT32 (MBR) mit dem Namen aus der Boot-Konfiguration (z. B. RESCUE1302) eingerichtet. Drauf kommen das Live-System, das Prüfskript, ein Autostart und die deutsche Tastatur. Danach wird jede Datei nachgeprüft und der Stick ausgeworfen. Dauer an einem USB-2-Stick einige Minuten. (macOS kann SystemRescue-ISOs nicht einhängen – StageSense packt sie deshalb direkt mit dem eingebauten tar aus.)

  • Am Pult:
    1. Stick und USB-Tastatur anstecken, Netzwerkkabel am besten abziehen, beim Einschalten F8 drücken (grandMA3: Boot Manager → „EFI USB Device“) – das einmalige Boot-Menü; an der Bootreihenfolge wird nichts geändert.
    2. Der Test startet von selbst und schaltet Netzwerk und Systemmeldungen ab. Zuerst erscheint der Hinweis (ab Build 218) mit dem Satz, ob Showfiles kopiert werden – „Enter = einverstanden und weiter · Pult ausschalten = abbrechen“. Dann fragt er auf leerem Bildschirm die Seriennummer vom Typenschild ab (Vorschlag vom Mainboard mit Enter übernehmen). Danach Bestätigung: Enter = richtig, n = neu eingeben.
    3. Menü – was soll geprüft werden? 1 Komplett (Standard) · 2 Nur Showfiles sichern (plus SMART; ab Build 218 nur mit dem Schalter beim Erstellen) · 3 Schnelltest (ca. 10 min) · 4 SSD-Ruhetest-Vergleich (SSD 5/10/20/40 min ruhen lassen und danach ansprechen – erst ohne, dann mit Stromsparmodus, ca. 2,5 h; ab Build 218 nur mit dem Schalter „Laufwerks-Selbsttest …“, sonst läuft automatisch 5) · 5 SSD-Ruhetest wie im Pult-Betrieb (ca. 75 min) · 6 Komplett mit kurzem RAM-Test. Ohne Eingabe nach 5 min: Komplett. Fällt die SSD nur mit Stromsparmodus aus, wacht sie aus dem Stromsparzustand nicht mehr auf (Firmware-/Stromspar-Problem); fällt sie auch ohne aus, ist sie defekt. Den Stromsparmodus schaltet nur der Linux-Kernel um – auf der SSD wird nichts dauerhaft gespeichert.
    4. Reihenfolge: auf Wunsch zuerst die Showfiles sichern (nur mit dem Schalter beim Erstellen – ab Build 218; bis dahin sichert „Komplett“ die Showfiles mit; nur aus den Nutzer-Ordnern, Platte nur lesend eingehängt, neueste zuerst, dazu die Plugins; Zähler „Show 12/40“, jede Datei mit Zeitgrenze, falls die Platte hängt), dann die SSD-Forensik (Gesundheits- und Fehlerprotokoll der SSD; Ereignisprotokoll und Telemetrie ab Build 218 nur mit dem Schalter „Laufwerks-Selbsttest …“; Firmware-Stand, Stromspar-Einstellungen und die Hersteller-Telemetrie – ein internes Abbild des Controllers, das nur der Hersteller auswerten kann, z. B. für eine Reklamation. Das Abbild erstellt das Laufwerk selbst und vermerkt es; Daten und Software bleiben unverändert. Ordner nvme_<Laufwerk> im Bericht), dann Bestandsaufnahme, Sensoren, Platte (SMART, Selbsttest nur mit Schalter, Lesetest), Dateisysteme, CPU-Test (3 min), zum Schluss der volle RAM-Test (memtester über ca. 70 % des Speichers, alle 18 Prüfmuster, ohne Zeitgrenze – oft 1–3 h). Am Anfang steht die geschätzte Dauer bis zum RAM-Test (meist 25–40 min). Jeder lange Schritt zeigt Fortschritt bzw. Laufzeit, der RAM-Test das laufende Prüfmuster („Muster 9/18“); Taste S überspringt den laufenden Schritt.
    5. Am Ende steht eine Kurzbewertung am Bildschirm; Enter schaltet das Pult aus.
    6. Von Hand (ohne Menü): bash /run/archiso/bootmnt/hardwaretest.sh --nur-shows | --schnell | --ruhetest | --ruhetest-vergleich | --ram-kurz. Kürzer: bash /run/archiso/bootmnt/hardwaretest.sh --ram-kurz (RAM-Test nur 2 GB, höchstens 20 min) oder --schnell (ohne Lesetest der ganzen Platte, ca. 10 min).
  • Ergebnisse liegen auf dem Boot-Stick unter berichte/<Seriennummer>/<Datum_Uhrzeit>/. So lassen sich mehrere Pulte nacheinander mit demselben Stick testen.
  • Geprüft wird:
    • Bestandsaufnahme (Mainboard, BIOS, RAM-Module, interne PCI- und USB-Geräte) und Sensoren in Ruhe und unter Last;
    • CPU unter Volllast mit Prüfung jeder Rechnung, RAM-Test, Kernel-Hardwarefehler (Machine Check, PCIe, SATA, Grafik, USB);
    • Platte: SMART, Selbsttest (ab Build 218 nur mit Schalter), Lesetest der ganzen Platte, Dateisysteme (fsck -n);
    • auf Wunsch werden außerdem die Showfiles auf den Stick gesichert (ab Build 218; bis dahin sichert „Komplett“ die Showfiles mit).

    Die Platte wird vorher auf Kernel-Ebene schreibgeschützt, ab Build 218 auch Swap auf internen Platten abgeschaltet; alle Plattentests lesen nur. Nur mit dem Schalter „Laufwerks-Selbsttest und Diagnose-Abbild der SSD“ startet der Stick im Laufwerk einen kurzen Selbsttest und lässt es ein Diagnose-Abbild erstellen; beides wird im Laufwerk selbst vermerkt.

  • Bericht einlesen: Stick wählen; alle Testläufe erscheinen nach Seriennummer. Ganz oben steht, ob die Showfiles gesichert wurden. Findet der Lesetest unlesbare Blöcke, ermittelt das Skript mit debugfs (nur lesen), welche Dateien darauf liegen – betroffene Showfiles stehen ganz oben im Bericht. Erkannt wird auch ein Ausfall des SSD-Controllers (NVMe antwortet nicht mehr, Kernel schaltet sie ab) mit Zeitpunkt nach dem Start. Aus dem SSD-Protokoll: kritische Warnungen mit Ursache (Ersatzblöcke, Temperatur, Zuverlässigkeit, nur-lesen), Fehlerprotokoll mit Fehlerarten, Zeit über Warn-/kritischer Temperatur, Betriebsstunden, Ein- und harte Abschaltungen, Verschleiß, Firmware; dazu Ereignisprotokoll und Ruhetest-Ergebnis. Je Laufwerk gibt es DEFEKT / AUFFÄLLIG / IN ORDNUNG. „Defekt“ gibt es nur bei harten Belegen: Lesefehler, schwebende/unkorrigierbare Sektoren, fehlgeschlagener Selbsttest, SMART „FAILED“, Kernel-E/A-Fehler. Gerettete Showfiles werden gleich mitgeprüft.
  • Als PDF sichern … erstellt den Bericht als A4-PDF: Ergebnis zuerst, System, Laufwerke mit allen Belegen, CPU/RAM/Mainboard, gerettete und betroffene Showfiles mit Prüfergebnis, Vergleich, Ablaufprotokoll; Vorschlag zum Speichern ist der Berichtsordner auf dem Stick. Konsolen-Check und Showfile-Prüfung lassen sich ebenso als PDF sichern (Menü „Bericht“).
  • Defektbericht für Verleiher … (für Leihpulte) fasst alle Prüfläufe desselben Pults zu einem PDF zusammen – „1511000000-102697“ und „102697“ gelten als dasselbe Pult. Inhalt nur Hardware-Fakten: Ergebnis je Laufwerk mit den harten Belegen je Prüflauf, Gerät (Modell, Seriennummer, Mainboard, BIOS, CPU, RAM-Module), Laufwerk (Modell, Seriennummer, Kapazität, Betriebsstunden), je Prüflauf alle Laufwerks- und Hardware-Befunde, Ablauf mit Uhrzeiten, die vom Laufwerk als unlesbar gemeldeten LBA-Bereiche und ein Auszug der Kernel-Meldungen (Wiederholungen zusammengefasst), dazu das Prüfverfahren. Nicht enthalten: Pultname, Showfiles, Plugins, Dateinamen und Show-Rettung – betroffene Dateien erscheinen nur als Anzahl. Ohne Oberfläche: StageSense --defektbericht-pdf <ziel.pdf> <laufordner> ….
  • Vergleichen mit einem anderen Pult vom selben Stick zeigt Unterschiede bei PCI-/USB-Geräten, RAM und BIOS – fehlt bei einem Pult ein internes Gerät, ist diese Baugruppe verdächtig.
  • Grenzen:
    • SystemRescue startet nicht mit eingeschaltetem Secure Boot.
    • Der Stick startet nur per UEFI – sehr alte Pulte mit reinem BIOS-Start brauchen einen anders erstellten Stick.
    • Der RAM-Test prüft den freien Speicher (ca. 70 %); den vom Live-System belegten Rest prüft nur Memtest86+ aus dem Startmenü des Sticks (falls angeboten).
  • „Nur Prüfskript auf einen Stick …“ schreibt hardwaretest.sh auf einen Stick – auch, um einen schon erstellten Boot-Stick auf den neuesten Stand des Prüfskripts zu bringen (Stick „RESCUE…“ wählen).

Patch

Eigener Bereich Patch in der Seitenleiste.

• Importieren: grandMA2-Show (.show.gz), grandMA2-Layer-XML, grandMA3-Show, MVR, Patchliste als PDF oder CSV. Ein leerer Patch nennt alle Formate.
• Patchliste als PDF oder CSV (z. B. Excel-Export einer Masterliste): StageSense liest die Tabelle – beim PDF über die Kopfzeile (z. B. „Layer · Fix ID · Name · FixtureType · MA-Patch · DP-Patch · Artnet-Patch · Socket“), auf jeder Seite; Zwischenzeilen (z. B. nur „1.LX13a“), wiederholte Köpfe und Fußzeilen fallen weg. Ragt ein langer rechtsbündiger Wert in die Nachbarspalte, wird die Zeile richtig geteilt. Das PDF braucht echten Text (keine eingescannten Seiten). Grenzen: höchstens 300 Seiten, 20 000 Zeilen und 120 s Lesezeit; gelesen wird im Hintergrund, Schließen des Fensters bricht ab (CSV ebenso).
  • Spalten zuordnen wie beim CSV (Vorschlag aus den Spaltennamen). Mehrere Spalten auf „Notiz“ werden mit ihrem Kopf zusammengefasst („DP-Patch 14-15 : 001 · Artnet-Patch D-E : 001“); Adresse darf „223 : 001“ sein. Layer auch als Position und Modus vom Typ abtrennen („Zenit W 300 4 ch“ → Typ „Zenit W 300“, Modus „4 ch“; „M1 - Basic“, „Mode 1“) sind wählbar.
  • Strom-Spalte zerlegen (Feld „Strompfad (zerlegen)“): Einen Standard gibt es nicht – jeder Planer schreibt es anders. StageSense zerlegt den Text an den Trennzeichen (. / - : | , oder Leerzeichen; höchstens 8 je Vorlage), z. B. „1.LX13a / 1“ → [1][LX13a][1], „DC2-SPX4-3“ → [DC2][SPX4][3], „UV3 / Har7 / 2“ → [UV3][Har7][2]. Je Teil wählst du die Bedeutung: Standort / DC, Verteiler, Plugbox / Multicore, Steckplatz, Kreis, Phase oder ignorieren; darunter eine Live-Vorschau an echten Zeilen und die Zählung „passt · ohne Strom · passt nicht“. „/“ allein = ohne Strom. Standort und Verteiler landen im Feld Verteiler (beides: „DC 1 Han › UV3“).
  • Werte → Standort / Verteiler: je Wert (z. B. „1“, „7“) ein Name; vorgeschlagen wird nur, wenn genau ein vorhandener Standort bzw. Verteiler passt („1“ → „DC 1 Han“, nicht „DC 10“). Offene Werte bleiben als Text aus der Liste stehen.
  • Vorlagen: „Als Vorlage speichern …“ mit Name, Autor (Planer) und Firma – gespeichert wird nur das Schema (Spalten, Strom-Spalte, Werte → Standort, Optionen), nie die Lampenliste. Beim nächsten Import schlägt StageSense die passendste Vorlage vor, mit Begründung („passt auf 791/813 Zeilen · Spalten 100 % · zuletzt 29.10. für …“); ab 95 % wird sie gleich übernommen, bleibt aber sichtbar und änderbar („Vorlage“-Menü, „Ohne Vorlage“). Was du beim Importieren korrigierst, lernt die Vorlage mit. Mitgeliefert: „DS · MRG – Patch nach Versatz“ (Socket „‹DC-Nummer›.‹Plugbox› / ‹Steckplatz›“, Standort = Name, der mit „DC ‹Nummer›“ beginnt, Layer → Position und Layer, DP-/Art-Net-Patch als Notiz „DP 14-15:001 · Art-Net D-E:001“). Ungültige Vorlagen (fremde Trennzeichen, zu viele Teile) verwirft StageSense beim Laden, beim Datei-Import und beim Zusammenführen.
  • „Weiter: Gerätetypen & GDTF …“ führt wie beim Show-Import je Gerätetyp zur GDTF-Auswahl (Hersteller wird aus dem Namen erkannt, z. B. „Cameo Zenit W300“); Ort, Strom und Notiz aus der Liste bleiben. „Importieren“ übernimmt ohne GDTF.
  • Gelerntes (Vorlagen und Gerätetyp → GDTF/Modus, auch vom Show-Import – „gemerkt“ im Import-Fenster): unter Einstellungen → Patch-Import ansehen, bearbeiten, löschen und als Datei exportieren/importieren (an andere Rechner oder Kollegen weitergeben); im Client-Modus beim Server mitgespeichert: Der Server führt Vorlagen und gemerkte GDTF aller Clients zusammen (die neuere Änderung gewinnt, Gelöschtes bleibt gelöscht). Leistung je Gerätetyp merkt sich der Patch wie bisher.
• grandMA2-Show: StageSense liest aus der Showdatei Fixture-ID, Channel-ID, Name, Layer, Universum/Adresse und den Gerätetyp (Hersteller, Name, Modus). Alternativ geht der Layer-XML-Export der MA2 (Setup → Export → Layer). Im Import-Fenster steht jeder Gerätetyp der Show in einer Zeile mit GDTF-Vorschlag: StageSense sucht in der GDTF Share den passenden Gerätetyp (Hersteller, Name, Modus, Kanalzahl; Herstellerdateien ✓ bevorzugt) und schlägt Datei und Modus vor. Ampel: grün = sicher, gelb = wahrscheinlich (beide vorausgewählt), orange = unsicher (nicht vorausgewählt), blau = von Hand gewählt bzw. lokale Datei. Jeder Typ hat ein Auswahlmenü – auch ohne Vorschlag: die Vorschläge aus der GDTF Share, passende Dateien der eigenen Bibliothek (samt MA3-Bibliothek ~/MALightingTechnology/gma3_library/fixturetypes), „Suchen …“ (GDTF Share und Bibliothek durchsuchen oder eine GDTF-Datei wählen) und „Ohne GDTF“; daneben der Modus. Beim Importieren werden die gewählten GDTF geladen und liefern Kanalzahl, Hell-Kanäle, Test-Cue-Werte und Leistung. Ohne GDTF übernimmt StageSense Typ und Modus aus der Show; die Kanalzahl kommt dann aus dem Modusnamen („54 channel“) oder wird aus den Adressabständen geschätzt (≈). Für Vorschläge aus der GDTF Share einmal unter „Geräte patchen …“ mit dem GDTF-Share-Konto anmelden; ohne Anmeldung schlägt StageSense Dateien der Bibliothek vor, und Einträge der Share lassen sich nur laden, wenn sie schon in der Bibliothek liegen (Hinweis am Typ).
• GDTF nachträglich zuordnen: in der Patch-Tabelle Lampen markieren → „GDTF zuordnen …“ (Knopf oben, Kontextmenü oder im Bearbeiten-Fenster einer Lampe). GDTF wählen (Vorschlag, GDTF Share, Bibliothek oder Datei) und den Modus – für alle Lampen dieses Typs oder nur die markierten. Übernommen werden Hersteller, Typ, Modus, Kanalzahl, Hell-Kanäle, Kanalbelegung (Test-Cue) und Leistung; Fixture-ID, Name, Adresse, Ort und Strom-Zuordnung bleiben. Wird eine Lampe dadurch länger, zeigt der Patch die Überschneidung orange. „Ohne GDTF“ nimmt Kanalbelegung und Hell-Kanäle wieder weg (Typ und Kanalzahl bleiben). „Gerätetypen …“ listet alle Typen im Patch mit ihrer GDTF (ohne GDTF zuerst) und „GDTF zuordnen …“ je Typ. Kanäle fremder GDTF-Dateien mit einem Offset außerhalb 1…512 übergeht StageSense.
• Geräte patchen: aus GDTF-Dateien (auch GDTF Share), fortlaufend adressiert; Universenumbrüche automatisch, Patchen ohne DMX-Adresse möglich, belegte Adressen überspringen, Vorschau je Universum.
• Mehrere bearbeiten: Klasse, Layer, Position, Namen nummerieren, FIDs neu vergeben, neu adressieren, Adressen entfernen, Leistung.
• GDTF auf USB für MA3 kopiert Gerätetypen in den grandMA3-Ordner eines Sticks; Export als CSV mit Stromplan.

Netzwerk

Der Bereich Netzwerk prüft jedes eingetragene Gerät jede Sekunde per Ping, fragt Switche und andere SNMP-Geräte ab und wertet den Verkehr im Netz aus. Neue Geräte findet die Geräte-Suche (Werkzeuge → Geräte-Suche → „Jetzt suchen“); von selbst sucht StageSense nur, wenn „Beim Start nach Geräten suchen“ an ist (ab Werk aus). Reiter: Übersicht, Verlauf & Auslöser (aktuelle und behobene Netzwerk-Probleme, Wartung, Grenzwerte), Geräte, Infrastruktur, Karte, Dienste, Ereignisse. Die aktuelle Liste aller Bereiche steht unter Probleme in der Seitenleiste.

Wann ein Gerät als ausgefallen gilt: Ein Gerät, das in der letzten Minute auf Ping geantwortet hat, gilt ohne Antwort nur noch 5 s über eigenen Verkehr als erreichbar (bei Art-Net-Nodes, von denen nur Antworten auf ArtPoll kommen, zwei Polls plus 1 s – eine verlorene Antwort reicht nicht); „nicht erreichbar“ kommt dann nach etwa 7 s (Ping alle 1 s, ausgefallen nach 2 Fehlschlägen). Geräte, die Ping nicht beantworten (Ping-Blocker wie grandMA3), behalten 30 s. Ein Ausfall zählt ab dem letzten Lebenszeichen. Endet ein Ausfall von mindestens 6 s, bevor die Meldung rausging, kommen 🔴 und danach ✅ trotzdem; kürzere Ausfälle (z. B. ein 3-s-Hänger eines Switches) stehen als eine 🟠-Zeile im Protokoll, z. B. „Switch 2: kurz nicht erreichbar (3 s)“, ohne Push – statt Alarm und „wieder erreichbar“. Eine Hardware mit mehreren Adressen (z. B. eine MA-Node mit MA-Net- und Art-Net-IP) meldet einen Ausfall nur einmal – erkannt an derselben MAC-Adresse (aus MA-Net, Art-Net bzw. ARP) oder bei MA-Nodes am gleichen Art-Net-Namen; auch „wieder erreichbar“ kommt nur einmal. Das gilt, wenn die Adressen höchstens 90 s nacheinander ausfallen – ist eine davon schon länger tot (z. B. ein alter Art-Net-Eintrag), meldet die andere ihren Ausfall weiter selbst.

Aussetzer (Wackelkontakt): Fehlen bei einem Gerät, das auf Ping antwortet, mindestens 2 Pings am Stück und kommt es danach wieder, ist das ein Aussetzer. Zwei Aussetzer in 60 s geben die Warnung „2 kurze Aussetzer in 60 s (3 s, 3 s) – Kabel/Stecker prüfen (IP)“ (Mittel); weitere ziehen nur den Text nach, „keine Aussetzer mehr seit 5 min (IP)“ kommt 5 min nach dem letzten. Nicht als Aussetzer zählt: wenn die Daten des Geräts weiterliefen (nur Ping fehlte), wenn viele Geräte am selben Adapter zugleich aussetzen – Umstecken am Pi oder Switch gibt so nur eine Meldung –, wenn ein Gerät davor aussetzte, und ein Ausfall (die bisherigen Aussetzer gehen darin auf). Paketverlust geht in einer offenen Aussetzer-Warnung auf. Bei Geräten, die nur per Ping überwacht werden (Switch, Access Point, USV), zählt ein kurzer Ausfall unter 6 s als Aussetzer – ab 2 verpassten Runden, ein einzelner verlorener Ping nicht. Fehlte nur die Ping-Antwort, während das Gerät weiter Daten schickte, zählt das weder als Paketverlust noch als Aussetzer.

Switch-Ports: Link down meldet StageSense an Ports, die etwas bedeuten – mit Beschreibung, LLDP-Nachbar, überwachtem Gerät dahinter oder Verkehr in der letzten Stunde –, nach 15 s als Mittel, am Uplink zu einem Switch als Hoch: „Port gi33 (RoboCam 1): Link down“, Behoben „… Link wieder da“ mit Dauer. Ist das Gerät dahinter selbst nicht erreichbar, ist Link down eine Folge – die Meldung ist dann sein „nicht erreichbar“. Eingangsfehler je Port (Switch, MA-Node, PU) misst StageSense gegen den eigenen Normalwert des Ports: Warnung erst nach 3 Abfragen in Folge über dem Dreifachen des Normalwerts (mindestens 1/s), behoben nach 3 ruhigen Abfragen; das Grundrauschen der MA-8Port-Nodes bleibt still.

Node auffällig: StageSense vergleicht jede MA-Node mit den übrigen – nur aus Daten, die ohnehin ankommen (MA-Net mithören, System Monitor der Pulte, SNMP CPU/Speicher); gesendet wird nichts. „verhält sich auffällig (…) – Neustart prüfen“ (Mittel, mit Push) kommt bei 2 Lücken im MA-Net in 10 min („2× kurz aus dem MA-Net in 10 min“ – über 10 s still, während andere Stationen zu hören sind und die Node per Ping erreichbar war), bei einer Zeitüberschreitung, die ein Pult nur für diese Node meldet („Pult meldet Zeitüberschreitung“), oder wenn ihre CPU seit 30 min mehr als 8 Punkte über den anderen liegt („CPU 34 % statt 12 % wie die anderen“); höherer Speicher steht nur als Begründung dabei. Die Meldung kommt nach 2 min, je Node höchstens ein Push in 6 h (danach als Hinweis). Behoben: „nach Neustart wieder unauffällig“, sonst nach 30 min ohne Signal „wieder unauffällig“. War die Node nicht erreichbar, gilt die Meldung dafür („nicht erreichbar“ bzw. Aussetzer), nicht „Neustart prüfen“. Trifft es mehrere Nodes an verschiedenen Standorten zugleich (ab 3 bzw. 25 %), liegt es an Netz oder Session – dann keine Node-Meldung. Je Standort: Sind an einem Standort mindestens 2 Nodes und mindestens die Hälfte auffällig (Node-Signale oder anhaltende Eingangsfehler an Node bzw. Switch-Port), an anderen höchstens eine, kommt eine Meldung, z. B. „DC 2: 3 von 4 Nodes auffällig (…, an DC2-C300-BTM gi3, 100 Mbit) – Switch-Ports, Patch bzw. Uplink von DC 2 prüfen“, dazu die offenen Probleme der Switches dort (sonst „Switches ohne eigene Fehler“). Mittel mit Push, je Standort höchstens einmal in 6 h; die Node-Meldungen und Eingangsfehler dort sind Folge. Behoben: „Nodes wieder unauffällig“.

Adapter je Protokoll: Im Adapter-Fenster (oben „x Adapter“) hat jeder Licht-Adapter die Häkchen Art-Net, sACN und MA-Net. MA-Net und Art-Net laufen meist in getrennten Netzen – dann MA-Net nur am MA-Adapter und Art-Net nur am Art-Net-Adapter anhaken. StageSense liest und sendet (ArtPoll, DMX-Test, Multicast-Anmeldung) das Protokoll dann nur dort. Sind alle Häkchen gesetzt, gilt keine Einschränkung.

Geräte und Vorlagen

„+ Gerät“ legt ein Gerät an: Vorlage, Name, IP-Adresse, Typ, Überwachen, Ausfall melden, Notiz, „Hängt an“ (Switch, an dem es hängt), Soll-VLAN, bei MA-Geräten die Soll-Rolle, dazu SNMP (Community, Port, eigene Werte als „Name = OID“). Der Testknopf prüft Ping und SNMP sofort.

Namen vom Gerät (Geräte-Editor, „Namen vom Gerät übernehmen“, Standard an): Meldet ein Gerät seinen Namen selbst – als MA-Net-Station (nur der eigene Stationsname, nie der Session-Name), sonst per SNMP (sysName) –, zeigt StageSense diesen Namen überall: Mac und Web, Pulte, FOH, Übersicht, System Monitor und Leaderboard. Ändert sich der Name am Gerät, folgt StageSense; jede Änderung steht im Ereignisprotokoll, z. B. „Name geändert: Oberbeleuchter-Backup → Mediaserver-Main (vom Gerät gemeldet, MA-Net)“.

• Wann: erst, wenn das Gerät denselben Namen mindestens 1 Minute lang meldet, und höchstens einmal je 10 Minuten. MA-Namen gelten nur für MA-Geräte (Pult, Node) mit passender MAC-Adresse; Switche und USVs übernehmen nur ihren eigenen SNMP-Namen. Melden mehrere Ankündigungen für dieselbe IP-Adresse im selben Zeitraum verschiedene Namen, benennt StageSense nicht um und zeigt „Name uneinheitlich – IP-Konflikt?“.
• Nicht übernommen werden Werksnamen wie „localhost“, ein Modellname oder Gerätetyp mit Seriennummer, ein sysName in Hex-Form („44:43:…“) und Namen mit Steuerzeichen; ein Name hat höchstens 64 Zeichen.
• Standorte: Hängt ein Gerät nur über seinen Namen an einem Standort, ordnet StageSense es vor dem Umbenennen fest diesem Standort zu; das Protokoll nennt den Standort.
• Eigener Name: Häkchen aus, dann bleibt der eigene Name; wer im Editor einen eigenen Namen eintippt, schaltet das Häkchen damit aus. Der Editor zeigt darunter „Meldet sich als …“.
• Doppelte Gerätenamen: ein Hinweis je Name, z. B. „Name „WiFi“ zweimal vergeben: 192.168.0.3, 192.168.1.49“ (Info, blauer Punkt; zählt nicht in den Problem-Kacheln). Dieselbe Hardware unter mehreren Adressen – Router mit einer IP je VLAN, Pult mit zwei Ports, Node in zwei Netzen – zählt einmal, erkannt an gemeinsamer MAC-Adresse, SNMP-Seriennummer oder gleichem SNMP-Namen mit gleicher Port-Tabelle.
• Der Name ist eine Anzeige, keine Identität: Kopplung und Signaturen hängen nie am Namen.

Überwachen aus (im Gerät oder per Rechtsklick in der Geräteliste, auch für mehrere markierte Geräte): kein Ping, keine SNMP-Abfrage, keine Meldungen – offene Meldungen des Geräts verschwinden still. Gedacht für Geräte, die kommen und gehen oder egal sind (z. B. WLAN-Access-Points). Das Gerät bleibt grau mit „nicht überwacht“ in der Liste, zählt nicht bei „Geräte online“, und die Geräte-Suche legt es nicht neu an. Auch die Web-App zeigt „nicht überwacht“.

Vorlagen setzen Typ, SNMP, Schwellen und den Schweregrad bei Ausfall – rund 50 Geräte aus Netzwerk (Luminex GigaCore, Netgear AV, Cisco, UniFi Switch/Access Point/Gateway, Yamaha), Licht (grandMA2/3 Pult, onPC, PU, Node, NPU, ChamSys, ETC, Hog, Avolites, LumiNode, Swisson, ELC, RoboSpot), Audio (DiGiCo, Yamaha, A&H, Dante mit 5 ms/1 %, Funkempfänger, Endstufen, Intercom), Video (disguise, Pixera, LED-Prozessor, Projektor, ATEM, NDI) sowie USV und Kettenzüge.

Die Liste zeigt Zustand, IP, Netz, Antwortzeit und Details und lässt sich per Klick auf die Spaltenköpfe nach Zustand, Name, IP, Netz, Version oder Antwortzeit sortieren. Die Spalte Version zeigt bei MA-Geräten die öffentliche Version aus der Ankündigung, sonst die SNMP-Software bzw. Art-Net-Firmware. Ein Gerät, mehrere Adressen: Dieselbe Hardware unter mehreren IPs (gleiche MAC aus MA-Ankündigung, Art-Net oder ARP; bei MA-Node und Art-Net-Node auch gleicher Name) erscheint als eine Zeile mit allen Adressen – typisch für MA-Nodes mit MA-Net-IP und zusätzlicher Art-Net-IP. Hauptadresse ist die MA-Net-Adresse. Unterreiter Adressen (ARP-Tabelle, unbekannte Geräte, IP-Konflikte). IP-Konflikt heißt: dieselbe IP mit verschiedenen MACs innerhalb einer Minute im selben Netz. StageSense liest dafür den VLAN-Tag mit (ein Trunk-Adapter sieht ARP aus allen VLANs); gleiche IP in verschiedenen VLANs ist kein Konflikt. Die Spalte „Netz“ zeigt VLAN bzw. Adapter, die Meldung z. B. „IP-Konflikt: 192.168.0.20 (VLAN 204)“.

Geräteseite und Gerätekarte

Ein Gerät antippen (Übersicht, Standortseite, Probleme, Uplinks, Nodes, Temperaturen, Schwachstellen) öffnet am Mac seine Geräteseite als Popup: mittig über der Seite, bei Fenstern ab 900 pt 70 % breit und höchstens 88 % hoch, es wächst mit dem Inhalt; schmalere Fenster fast ganz. Ein weiteres Gerät ersetzt das angezeigte. In der Web-App öffnet sich dieselbe Geräteseite (eigene Adresse …/geraet/…, Zurück schließt nur das Gerät). Abschnitte ohne Daten fallen weg:

• Kopf: Name, Art und Standort, Zustand „in Ordnung“, „auffällig“ oder „gestört“, „läuft seit …“ (rot bei einem Neustart heute), bei Cisco-Geräten „Baujahr“ (aus der Seriennummer, z. B. „ca. 2015 (KW 33)“ – Fertigungswoche, nicht Kaufdatum); darunter orange Hinweise wie „nicht erreichbar“.
• Instrumente mit kleiner Kurve: CPU, RAM, wärmster Fühler (mit Grenzen), PoE („W von … W“), Akku, Laufzeit, Last, Eingang, USV-Temperatur, Antwortzeit, Verlust, Session-Teilnehmer.
• Umgebung: alle Fühler (bei Pulten Board, CPU, Grafikchip, Mainboard, SSD …) mit Balken und eigenen Grenzmarken, Lüfter mit Drehzahl bzw. Zustand, Netzteile; bei der USV der Akku als Fühler (Grenzen 35/40 °C).
• Prozessor: Last je CPU-Kern als Balken (gelb ab 80 %, rot ab 95 %), darunter die Temperatur je Kern, wenn das Gerät sie liefert – nur Anzeige, keine Alarme.
• Datenträger: je Partition Belegung (gelb ab 85 %, rot ab 95 %) und rot „nur lesbar“.
• Frontpanel bei Switches (siehe Infrastruktur).
• Verlauf: „1 h“, „24 h“ (Standard), „7 Tage“ oder „90 Tage“ – Antwortzeit und Verlust, Temperaturen, CPU/RAM, PoE, Uplink-Port, Eingangsspannung, Last und Akku, mit Ereignismarken (z. B. Neustart) und Grenzlinien. In der Web-App nur mit PIN, in der Internet-Ansicht nicht.
• Ereignisse des Geräts, mit „behoben“ bzw. „quittiert“.
• Technik (eingeklappt): IP, Firmware, Seriennummer, Hersteller, Baujahr und darunter die vollständige Gerätekarte – Erreichbarkeit mit Verfügbarkeit 24 h und 7 Tage, Anschluss (MAC, Switch-Port, VLAN, „hängt an“), System per SNMP (Software, Laufzeit, Speicher, PoE; bei UniFi-Access-Points SSIDs je Funkband mit Kanal und Clients), MA-Net, Art-Net, Universen, Probleme, alle Ports mit Auslastung und die Knöpfe Verlauf, Bearbeiten und Wartung. Wo dieses Handbuch von der Gerätekarte spricht, ist dieser Teil gemeint.

Verlauf 90 Tage: StageSense speichert je Gerät Stundenwerte (Mittel, Minimum, Maximum) für 90 Tage – Antwortzeit, Verlust, jeden Fühler, CPU und jeden Kern, RAM, PoE (auch je Port), Ports, Lüfter und Netzteile, Laufzeit (Neustarts), Datenträger und USV; je Gerät eine Datei im Ordner „Verlauf“, zusammen höchstens 300 MB (ab 80 % steht im Protokoll „Verlauf: … belegt – älteste Geräte werden verworfen“). Strom-Werte haben keinen 90-Tage-Verlauf; dafür gibt es Lastgang und Energie-Archiv. Die letzten 500 Einträge des Netzwerk-Protokolls überstehen einen Neustart (nicht im Client-Modus – dort kommt es vom Server).

Infrastruktur

Je Geräteart ein Reiter: Switche, Pulte, Processing Units, Nodes, Sonstige (Reiter erscheinen, sobald es solche Geräte gibt), dazu Auslastung und VLANs. Die Art kommt zuerst aus dem, was das Gerät im MA-Net selbst meldet (Pult/onPC, NPU/PU, Node), sonst aus Vorlage und Typ. Jeder Reiter zeigt alle Geräte dieser Art mit Zustand und – sobald SNMP antwortet – CPU, Temperaturen, Speicher und Anschlüsse; bei MA-Geräten Session und Version. Die Frontansicht gibt es nur für Switche; bei Pulten, NPUs und anderen Rechnern zeigt StageSense nur benutzte Anschlüsse – interne oder virtuelle Schnittstellen (grandMA-Pulte melden per SNMP z. B. auch ihre internen Anschlüsse) werden ausgeblendet und gezählt.

SNMP automatisch: Licht- und MA-Geräte fragt StageSense ohne Häkchen am Gerät per SNMP ab (Einstellungen → Netzwerk, „SNMP automatisch bei Licht- und MA-Geräten“). Optional „SNMP bei allen Geräten versuchen“. Wer dreimal nicht antwortet, wird nur noch alle 10 Minuten erneut gefragt (mit Häkchen alle 2 Minuten), damit Zeitüberschreitungen die Abfrage nicht ausbremsen. Abgefragt werden bis zu sechs Geräte gleichzeitig; automatisch abgefragte Pulte, NPUs und Nodes nur etwa jede Minute (Switche im eingestellten Takt), MAC- und LLDP-Tabellen nur bei Switches – das schont Konsolen und Netz.

• Frontansicht im Stil von Luminex Araneo: Ports nach VLAN eingefärbt, Link, Geschwindigkeit, PoE, Trunks, STP-blockierte Ports, LLDP-Nachbarn.
• Frontpanel auf der Geräteseite wie am Gerät: Cisco SG300 (-10, -20, -28, -52) mit RJ45 oben 1 bis zur Hälfte, unten der Rest, SFP/Combo als eigene Spalten am Ende (oben die gerade, unten die ungerade Nummer); andere Switches oben ungerade, unten gerade. In der Mac-App stehen die Spalten in Blöcken zu 12, die bei schmalem Popup umbrechen, ebenso die Legende („wenig“, „mittel“, „voll“, „kein Link“, „PoE“, „Fehler/Flattern“). In der Web-App bleibt das Frontpanel am Stück und lässt sich waagrecht scrollen. Die Portnummer ist die Beschriftung am Gerät (SG300: Position 1…52, sonst die Zahl am Ende des Port-Namens), der Uplink steht als „n ↑“. Hat ein Port keine sinnvolle Beschreibung, zeigt er das angeschlossene Gerät (sonst Uplink bzw. LLDP-Nachbar) – nur in StageSense, am Switch wird nichts geschrieben; das Port-Detail sagt dann „Beschreibung: – (angezeigt als „…“)“. Ein überwachtes Gerät im Port-Detail ist ein Link auf seine Geräteseite („(überwacht)“). Port antippen öffnet das Port-Detail.
• Port-Karte: Tipp auf einen Port zeigt Empfang, Senden, Auslastung, Multicast, Fehler, PoE-Watt, VLANs, STP, Nachbarn und angeschlossene Geräte sowie Verläufe live, 24 h und 7 Tage mit allen Ereignissen am Port.
• Auslastung: Durchsatz je Port, meistbelastete Ports, eigene Adapter des Macs (mit Multicast), was im Netz läuft (Art-Net, sACN, MA-Net, PTP, Dante/NDI). Je Switch wählbar, welche Ports erscheinen: alle aktiven, Ports mit Beschreibung am Switch (optional mit Stichwort, z. B. „MON“), Uplinks und Trunks oder eigene Auswahl.
• VLANs: welche Geräte und Ports in welchem VLAN sind; weicht ein Gerät vom Soll-VLAN ab, gibt es ein Problem.

Hardware der MA-Pulte und PUs

Netzwerk → Hardware bzw. Licht → MA-Net → Hardware zeigt alle grandMA-Pulte und Processing Units mit Generation (v1 = Core i5-7500, v2 = Core i5-12500), Arbeitsspeicher, Modell und Seriennummer, dazu Name (und „Gemeldeter Name“, wenn sich das Gerät anders nennt als in der Geräteliste), IP, CPU, Standort und Session; oben die Zählung, z. B. „Pulte: 5× v2, 3× v1 · PUs: 1× v2, 13× v1“. Die Werte kommen per SNMP (nur lesen). Ausgeschaltete Geräte bleiben mit der zuletzt erkannten Hardware in der Liste (blasser). „?“ heißt: anderer Prozessor (er steht daneben), „–“: keine Angabe (z. B. SNMP aus). Nodes und fremde PCs stehen nicht in der Liste.

• Hinweise (keine Alarme): Arbeitsspeicher weicht von der Mehrheit gleicher Geräte ab („PU-12: 8 GB statt 16 GB wie …“, ohne Mehrheit „uneinheitlich“); in einer Session gemischte Generationen bzw. verschiedene Pult-Modelle.
• Filter nach Generation und Modell, Tabelle je Art, Klick öffnet die Geräteseite; CSV-Export (Semikolon).
• Die Pulte-Kachel der DC-Seiten zeigt je Pult ein Badge v1/v2.
• Web-App: „Alle Bereiche“ (/app) → Netzwerk → Hardware mit Filter, Tabelle und CSV. In der Internet-Ansicht ohne CSV und ohne Seriennummern (Spalte S/N „–“); Seriennummern gibt es nur lokal.

Karte

Topologie aus LLDP, MAC-Tabellen der Switche und ARP: welcher Switch an welchem hängt und welche Geräte an welchem Port. Erscheint, sobald ein Switch per SNMP abgefragt wird.

Dienste

Uhren der MA-Geräte

Pulte und PUs haben oft keine Zeitquelle und laufen auseinander – um Minuten, nach der Zeitumstellung um eine Stunde, mit leerer Pufferbatterie um Jahre. Dann passen die Zeitstempel im System Monitor, im Telnet-Mitschnitt und in den Sicherungen nicht mehr zueinander. StageSense liest bei jeder SNMP-Systemabfrage die Uhr jedes MA-Geräts (nur lesen) und vergleicht die am Gerät angezeigte Uhrzeit mit der Ortszeit dieses Rechners. MA-Geräte melden ihre Ortszeit als UTC; die Zeitzone in der Antwort wird darum übergangen.

Die Liste zeigt je Gerät die Abweichung (z. B. „−95 s“, „−1 h“, „−2 J.“) und die Uhrzeit, die das Gerät gerade anzeigt. Weichen Geräte um mehr als 60 s ab (einstellbar unter Einstellungen → Alarme → Zeitserver), kommt eine gesammelte Warnung „Uhren der MA-Geräte“ mit den größten Abweichungen – nicht eine je PU. Nodes melden keine Uhr.

Abhilfe: am Session-Master unter Setup → Console → Date & Time → *NTP info* die IP eines Zeitservers eintragen und *Sync with NTP* auf Enable stellen; im Reiter *Location* Zeitzone +1 und *Daylight Saving* einstellen. Laut MA gleichen sich die übrigen Stationen der Session daran ab – die Liste zeigt danach, ob es bei allen gegriffen hat. Der erste Abgleich ist ein Zeitsprung: nicht während der Show (Agenda).

Zeitserver für das Show-Netz

Gibt es im Show-Netz keinen Zeitserver, kann StageSense einer sein: Schalter *Zeitserver für das Show-Netz* unter Dienste → DHCP & Zeit (voreingestellt aus). StageSense beantwortet dann Zeitanfragen (NTP, UDP-Port 123) mit der Uhr dieses Rechners:

• Nur Antworten – von sich aus wird nichts gesendet, kein Broadcast.
• Nur über die überwachten Adapter – Anfragen aus WLAN oder anderen Netzen bleiben unbeantwortet; je Gerät höchstens eine Antwort pro Sekunde.
• Angezeigt werden die Adressen, die am Pult einzutragen sind, und welche Geräte schon fragen.
• Quelle ist die Uhr dieses Rechners (Stratum 3). macOS stellt sie über das Internet; ohne Internet läuft sie mit ihrer eigenen Genauigkeit weiter.

Nur einen Zeitserver im Show-Netz betreiben – zwei mit unterschiedlicher Zeit sind schlimmer als keiner (StageSense meldet das als „Zeitserver im Netz liegen … auseinander“). Läuft auf demselben Rechner schon ein anderer Zeitserver (z. B. chrony auf dem StageSense-Server), meldet der Schalter „Port 123 nicht verfügbar“ – dann genügt jener.

Ereignisse

Protokoll aller Meldungen mit Uhrzeit und Quelle (Geräte gefunden, ausgefallen, wieder erreichbar, bestätigt, Showmodus …). Beim Beenden des Showmodus steht hier, was der Mac währenddessen ohne Ton und Mitteilung gelassen hat.

Was StageSense im Netz sendet

Überwachen heißt bei StageSense vor allem zuhören. Einiges muss es aber senden: Abfragen an Geräte, Suchanfragen und Anmeldungen am Switch. Hier steht alles, was der StageSense-Server ins Netz schickt, mit Takt, Schalter und Einstellung ab Werk. Der Mac im Eigenständig-Betrieb überwacht auf dieselbe Weise. Ein Mac im Client-Modus sendet nichts ins Show-Netz, das übernimmt allein der Server.

Kurz: Ins MA-Net sendet StageSense keine Pakete. DMX bzw. sACN sendet es nur beim DMX-Test, den du startest. SNMP und Modbus nutzt es zur Überwachung nur lesend. Die Geräte-Suche läuft nur auf Knopfdruck.

Regelmäßig, ohne Zutun

Nur an eingetragene Geräte

Diese Abfragen gehen nur an Geräte, die in StageSense stehen (Geräteliste, Messgeräte, Bridges) oder die StageSense schon gefunden hat. „Überwachen aus“ am Gerät stoppt Ping und SNMP.

Nur von Hand

Nichts davon startet von selbst. Ausgelöst wird es in der StageSense-App bzw. am gekoppelten Mac. Die Web-App schaltet nichts.

Nie

• Ins MA-Net: keine Pakete. StageSense liest MA-Net2 und MA-Net3 nur mit; zum MA-Net geht nur die Multicast-Anmeldung (IGMP) des Betriebssystems.
• DMX bzw. sACN von sich aus: Nur der DMX-Test sendet, und nur solange du ihn laufen lässt.
• SNMP schreiben: StageSense setzt per SNMP nie etwas.
• Modbus schreiben in der Überwachung: nur Lesefunktionen. Geschrieben wird einzig bei „Min/Max löschen“ von Hand.
• RDM ändern von sich aus: nur auf Knopfdruck.
• Blackbox: Sie liest nur, was StageSense ohnehin hat, und sendet nichts ins Show-Netz.

Antwortet nur, wenn gefragt

Ins Internet, nicht ins Show-Netz

Über die Internetverbindung des Servers:

• Lizenz (license.stagesense.de): Prüfung beim Start und stündlich; gesendet wird nur, wenn die letzte Bestätigung älter als 7 Tage ist. Nur bei Online-Lizenz.
• Update-Prüfung (license.stagesense.de): 2 min nach dem Start, dann täglich. Geladen wird nur auf Befehl.
• Internet-Ansicht (live.stagesense.de): ab Werk aus. Eingeschaltet alle 4 s, solange jemand zusieht, sonst jede Minute.
• Push-Mitteilungen: nur mit Abo, über die Dienste von Apple, Google, Mozilla bzw. Microsoft.

Probleme und Alarmierung

Jede Auffälligkeit wird ein Problem mit Schweregrad, Beginn und Ende; gemeldet wird erst, wenn die Bedingung lange genug ansteht, und „behoben“ erst nach einer Erholzeit – so flattert nichts.

Schweregrade

Einstufung nach Auswirkung: Wie schlimm ein Ausfall ist, hängt davon ab, ob er die Show trifft – nicht nur vom Gerätetyp. StageSense merkt sich laufend, welche Geräte gerade Showdaten liefern (DMX-Quelle eines aktiven Universums, MA-Session-Master, Node, der ein Universum mit Daten ausgibt). Fällt so ein Gerät aus – oder ein Switch, hinter dem es hängt –, ist das eine Katastrophe; die Einstufung wird beim Ausfall festgehalten. Ohne Showdaten: Hoch für Show-Geräte und Switche mit Geräten dahinter, Warnung für alles andere (WLAN, Router, Switch ohne bekannte Geräte dahinter). Die Gerätevorlage gibt die Obergrenze vor, „Ausfall melden“ aus macht daraus Info. Ein ausgefallener Switch-Port ist nur dann Hoch, wenn dahinter ein anderer Switch hing; mit anderem Nachbarn Warnung (das Gerät dahinter meldet sich selbst), ohne Nachbarn Info. Lüfter mit zu geringer Drehzahl: Warnung, stehender Lüfter oder ausgefallenes Netzteil: Hoch.

Temperaturen: In Pulten, PUs und PCs gelten feste Grenzen je Sensorart – CPU Warnung ab 85 °C, Hoch ab 95 °C (Intel-CPUs drosseln erst bei 100 °C, unter Last sind 70–80 °C normal); SSD/NVMe Warnung ab 75 °C, Hoch ab 85 °C; Grafikchip 90/100 °C. Gehäuse-/Mainboardfühler und alle Switche: einstellbare Grenze (Standard 70 °C), Hoch 10 °C darüber. Die Grenzen stehen unter Einstellungen → Alarme; Vorlagen setzen bei empfindlichen Geräten (Dante, Intercom) engere Ping-Grenzen. „Melden ab“ legt fest, ab welcher Stufe Mitteilungen und Push kommen (ab Werk ab Mittel). Hoch und Katastrophe kommen als Alarm, Mittel und Warnung als Warnung.

Abhängigkeiten

Fällt ein Switch aus, gibt es eine Meldung für den Switch statt vieler für die Geräte dahinter – mit der Zahl und den Namen der Geräte, die dadurch nicht erreichbar sind („DC4-C300-TOP: nicht erreichbar – 23 Geräte dahinter ebenfalls weg: …“); die Folgeprobleme stehen gedimmt in der Liste. „Hängt an“ wird aus der Netzwerkkarte automatisch erkannt oder im Geräte-Editor gesetzt.

Mac-Adapter weg: Verliert ein überwachter Adapter des Macs Link oder IP-Adresse (Kabel gezogen, USB-Adapter ab, Switch-Port aus), meldet StageSense genau das – „Mac-Adapter … ohne Verbindung (Netz) – Kabel, Adapter oder Switch-Port prüfen; n Geräte darüber nicht erreichbar“ (Hoch). Alle Geräte in diesem Netz gelten als Folge und melden nichts Eigenes; VLANs auf demselben Adapter stehen in derselben Meldung. Geprüft wird jede Sekunde direkt am Adapter. StageSense merkt sich die Netze der überwachten Adapter über Neustarts hinweg; fehlt ein im Adapter-Fenster ausgewählter Adapter schon beim Start, heißt die Meldung „Ausgewählte Adapter nicht verbunden: …“, und alle Geräte ohne verbundenes Netz gelten als Folge davon.

Mitteilungen bündeln: Neue Meldungen werden 10 s gesammelt, bevor Mitteilung und Push rausgehen. Was in dieser Zeit als Folge eines anderen Ausfalls erkannt wird, fällt weg (die Ursache wird manchmal ein paar Sekunden später erkannt als die Geräte dahinter); der Rest geht als eine Mitteilung raus – einzeln wie gewohnt, sonst „n Meldungen“ mit der schlimmsten zuerst. Was in den 10 s schon wieder behoben ist, wird gar nicht gemeldet. „Behoben“-Mitteilungen werden genauso zusammengefasst und kommen vor neuen Meldungen desselben Bündels – kam ein Gerät kurz zurück und fiel gleich wieder aus, steht beides in dieser Reihenfolge; Folgeprobleme schicken kein eigenes „behoben“.

Meldung und Behoben

Jede Meldung geht über dieselben Wege – Mac-Mitteilung, Web-Push und Push-Dienste –, und jedes gemeldete Problem meldet auch sein Ende über denselben Weg. Der Titel nennt Zeichen, Stufe und Gerät, z. B. „🔴 Alarm – DC 3 UV 1“ oder „✅ Behoben – Node U12“; darunter steht der Text.

In der Web-App zeigt jedes Ereignis seine Stufe als Punkt: rot, orange, grün nur für Behobenes, blau für Info. Sammelmeldungen („n Meldungen“) tragen das Zeichen der schlimmsten.

Behoben-Texte: Wo es einen eigenen Text gibt, steht er statt „Behoben: …“. Jede Behoben-Meldung trägt die Dauer wie im Ereignisprotokoll: „… nach 10 s“, ab 2 min „nach 3 min“, ab 1 h „nach 1 h 20 min“.

Licht weg: Ein Problem je Quelle, die zuletzt gesendet hat – ein Pult mit 64 Universen ist eine Meldung, mit dem sendenden Gerät als Titel. Es zählt nur, was mindestens 10 s lief; die Daten müssen 5 s fehlen. Fällt das sendende Gerät selbst aus (oder ein Switch bzw. Mac-Adapter davor) oder ist es gerade erst zurück und sendet noch kein Universum (höchstens 2 Minuten), gilt das als Folge ohne eigene Meldung; bei mehreren eingetragenen Quellen-Geräten erst, wenn alle aus sind. Ein Quellen-Gerät mit „Überwachen aus“ zählt dabei nicht – fehlen seine Universen, werden sie gemeldet. Ein Gerät, das sonst auf Ping antwortet, zählt dafür schon als ausgefallen, sobald es nicht mehr antwortet und seit 5 s nichts mehr sendet – auch bevor „nicht erreichbar“ feststeht. Sendet es danach wieder etwas, ohne dass das Universum zurückkommt, wird das Universum gemeldet. Verstummt ein Ping-Blocker (z. B. grandMA3), wird sein Universum sofort gemeldet; „nicht erreichbar“ folgt später.

MA-Sessions: Während ein Pult aus ist, ist „nicht mehr in der Session“ eine Folge seines Ausfalls. Ist die ganze Session nicht mehr sichtbar (kein Pult und keine PU sendet mehr), gibt es eine Meldung für die Session; die Probleme der Mitglieder gehen darin auf. Wechselt in einer grandMA2-Session der Master, kommt eine Warnung „Master gewechselt: A → B“ (ohne Behoben). Kommt ein Pult zurück, heißt das Behoben z. B. „hatte die <Session> verlassen – nach 3 min 12 s wieder drin (21:13–21:16)“ bzw. „… – nach 3 min 12 s in der <andere Session>“; ist es wieder erreichbar, aber noch nicht drin, „wieder erreichbar (…), aber nicht in der <Session>“. Ist eine ganze Session verschwunden und ein Mitglied anderswo zu sehen: „wieder da als <Session>“; Hinweise zu Version oder Showfile einer verschwundenen Session enden still mit „– Session nicht mehr zu sehen“. Nach einem Neustart von StageSense kommen offene Session-Probleme wieder; ist die Session 5 Minuten lang (ab sichtbarem MA-Net) nicht zu sehen, endet das Problem mit einer ℹ️-Mitteilung „… – Abschluss nach Neustart, Session nicht mehr zu sehen“ statt ✅.

Ausfall statt Paketverlust: Fällt ein Gerät aus, kommt nur „nicht erreichbar“. Paketverlust, Antwortzeit und Jitter dieses Geräts gehen im Ausfall auf (noch nicht verschickte entfallen), und die Fehlschläge rund um den Ausfall zählen danach nicht als Paketverlust.

Kein stilles Ende: Ein gemeldetes Problem endet immer mit einer Meldung. Endet es ohne „wieder normal“, kommt ein Abschluss mit dem Grund, z. B. „… – PTP-Takt … nicht mehr zu sehen“. Geht es in einem größeren Problem auf – Paketverlust oder Aussetzer im Ausfall, die Lizenz-Vorwarnung in der Sperre, Session-Mitglieder in „nicht mehr sichtbar“, Spannung und Frequenz im Phasenausfall –, kommt sein Abschluss erst mit dessen Behoben („… – beendet mit „wieder erreichbar (IP)““); neben dem schlimmeren Alarm steht so kein ✅.

Stufe steigt: Steigt ein offenes Problem über die Meldeschwelle und über die höchste schon gemeldete Stufe (z. B. Anschluss von 80 auf 100 %, Temperatur), kommt es neu – im Protokoll mit „Stufe jetzt Hoch“. Pendelt es danach zurück und wieder hoch, kommt nichts Neues.

Was nur einmal endet: Probleme, deren Ende nur einmal gemeldet wird (DHCP, Zeitserver, Uhren der MA-Geräte, Showfile-Sicherungen, Soll-Rollen), enden nach der Erholzeit auch ohne weitere Prüfung.

Bestätigen

In der Problemliste, auf der Übersicht, im Standort-Dashboard und in der Web-App: „Bestätigen“ mit optionaler Notiz, einzeln oder „Alle bestätigen“. Bestätigte Probleme bleiben grau sichtbar, zählen nicht mehr als offen und alarmieren nicht erneut. Ein bestätigter Geschwindigkeitsabfall übernimmt die neue Geschwindigkeit als Normalfall.

Wartung

Wartungsmodus für Aufbau, Abbau oder Umbau – global oder je Gerät für 1, 2, 4 Stunden oder bis morgen 8 Uhr. Probleme werden weiter erfasst, aber nicht gemeldet.

Showmodus

Während der Show bleibt der Mac still: keine Töne, keine macOS-Mitteilungen – für 2, 4 oder 8 Stunden, verlängerbar (höchstens 24 Stunden je Start), übersteht einen Neustart. Push aufs Handy geht weiter wie sonst (Alarm, Warnung, Behoben): Wer zuständig ist, soll sofort erfahren, was passiert, und handeln können. Angezeigt und erfasst wird alles wie immer. Beim Beenden steht unter Ereignisse eine Zusammenfassung dessen, was der Mac ohne Ton und Mitteilung gelassen hat („Showmodus beendet – n Meldungen ohne Ton und Mitteilung (Push ging sofort raus): …“, bis 10 Meldungen). Ein Mac im Client-Modus bleibt im Showmodus des Servers ebenfalls still. Updates werden im Showmodus nie eingespielt. Schalter auf der Übersicht, in der Problemliste und in der Web-App; dort steht während der Show oben „Showmodus bis 23:30 · 3 Meldungen am Mac still“.

Benachrichtigungen

• macOS-Mitteilung und Ton (Ton je Strom-Alarmregel abschaltbar; alle Töne dieses Macs aus: Einstellungen → Allgemein → „Töne bei Alarmen und Warnungen“ – Mitteilungen, Push und Anzeige bleiben). Im Client-Modus zeigt der Mac die Meldungen des Servers (siehe Was im Client geht).
• Web-Push an die Web-App auf dem Handy (siehe Push aufs Handy).
• Push-Dienste: ntfy, Pushover, Telegram oder ein eigener Webhook, mit Mengenbegrenzung pro Minute (weitere Meldungen kommen gesammelt als „n weitere Meldungen“ mit dem Zeichen der schlimmsten). Der Webhook bekommt JSON mit title, message, text, level (alarm, warning, cleared oder info), time und source.
• Was rausgeht: Alarme immer. „Auch Warnungen (nicht nur Alarme)“ gibt es je Weg – ntfy, Pushover, Telegram, Webhook (Einstellungen → Push) und Web-Push (Einstellungen → Web-App) – und ist ab Werk an. Beim Update von einer älteren Version stellt StageSense die Warnungen einmal auf an und schreibt „Push: Warnungen aufs Handy jetzt an (neuer Standard) – je Weg abschaltbar“ ins Protokoll; wer sie danach ausschaltet, behält das. Der Schalter für „Behoben“-Meldungen gilt für alle Wege gemeinsam. Der Showmodus hält Push nicht zurück.
• Test-Alarm unter Einstellungen → Push prüft alle eingeschalteten Wege auf einmal, unabhängig von den Warnungs-Schaltern („ℹ️ StageSense – Test“).

Push-Pause: Kommt eine Mitteilung auf keinem eingeschalteten Weg an (ntfy, Pushover, Telegram, Webhook – alle Wege gehen gleichzeitig raus), zählt StageSense das; bei zweien in Folge steht am Mac und in der Web-App die Warnung „Push – nicht erreichbar – Meldungen kommen nicht aufs Handy (Grund)“. Eine einzelne Fehlzustellung bleibt still. Sobald wieder eine Mitteilung ankommt (StageSense versucht es alle 60 s), endet die Warnung mit „Push: wieder erreichbar nach …“, und es kommt eine Sammel-Mitteilung „Während der Push-Pause (Dauer): n Meldungen“ mit den Alarmen und Warnungen samt Uhrzeit (höchstens 10); Behobenes und Infos nur gezählt, nach mehr als 6 h nur Zahlen.

Web-App und Fernzugriff

Die Web-App bringt StageSense aufs Handy oder Tablet: im lokalen Netz, über Tailscale oder über eine eigene HTTPS-Adresse. Sie läuft im Browser und lässt sich auf dem iPhone zum Home-Bildschirm hinzufügen.

Einrichten (Einstellungen → Web-App)

1. Der Webserver (Port 8470) startet mit StageSense immer automatisch; der Schalter „Webserver für die Web-App einschalten“ stellt ihn nur bis zum nächsten Start ab.
2. „Im lokalen Netz erreichbar“ für Zugriff über alle Adapter; optional eine externe Adresse (Reverse-Proxy, Cloudflare Tunnel, Firmen-VPN).
3. Mit Tailscale: „HTTPS über tailscale serve“ stellt die Web-App mit gültigem Zertifikat nur für Geräte im eigenen Tailnet bereit.
4. Nur ansehen: Die Web-App zeigt alles an, schaltet aber nichts. Ohne Anmeldung gehen nur Push-Benachrichtigungen abonnieren und Probleme quittieren; Showmodus, Identify, Hellmachen, RDM, DMX-Test, Simulatoren und die Lizenz ändert man in der StageSense-App selbst bzw. von einem gekoppelten Mac oder Windows-Rechner desselben Kunden (siehe Client-Modus). Eine PIN (mindestens 6 Zeichen empfohlen) schützt nur noch das Ansehen: „Auch zum Ansehen PIN verlangen“ – sonst sieht jeder im Netz Geräte, IPs, Patch und Ereignisse (nur lesend). Bedienerdaten – Leaderboard, MA-Protokoll und Befehls-Statistik mit den MA-Benutzern, ihren Befehlen und Zeiten – zeigt die Web-App nur nach der PIN-Anmeldung (gekoppelte Macs immer); ohne Anmeldung steht dort „Bedienerdaten nur nach Anmeldung (PIN) – oder in den Einstellungen freigeben“. Freigeben: „Bedienerdaten ohne Anmeldung zeigen“ (Standard aus) bzw. am Pi sudo stagesense --bedienerdaten on|off. Showfile-Namen in der Pult-Matrix gibt es ebenfalls nur angemeldet; in Problem- und Ereignistexten steht ohne Anmeldung „•••“ statt eines MA-Benutzernamens (die eingebauten Konten wie administrator oder guest bleiben), und der Zusatz „kurz nach „Store Cue 26“ (huwi)“ fehlt.
5. QR-Code mit der iPhone-Kamera scannen, in Safari öffnen → Teilen → „Zum Home-Bildschirm“.

Sicherheit: Anmeldungen gelten 30 Tage (höchstens 50 Geräte), Rateversuche werden je Adresse und insgesamt gebremst. Push-Abos gehen nur an die Push-Dienste von Apple, Google, Mozilla und Microsoft (höchstens 20 Geräte); mit PIN braucht das Abo eine Anmeldung. Der Webserver begrenzt gleichzeitige Verbindungen und trennt Anfragen, die nicht innerhalb von 10 s vollständig sind.

Start: Die Web-App öffnet mit der Gesamtübersicht („Gesamt“, wie die Übersicht am Mac) und blättert von dort durch die Standorte (FOH, DC 1 …) und am Ende zum Leaderboard – siehe DC-Seiten unten. Oben rechts führt „Alle Bereiche“ (am Handy ☰) zur gewohnten App mit den Reitern unten; sie liegt unter der Adresse /app. Links aus Push-Mitteilungen (z. B. „/#events“) öffnen weiterhin direkt den passenden Reiter; ebenso bleiben /foh und /leaderboard.

Reiter der Web-App

Geräteseite (Tipp auf ein Gerät): dieselben Abschnitte wie am Mac (siehe Geräteseite und Gerätekarte) – Kopf, Instrumente, Umgebung, Prozessor, Datenträger, Frontpanel (Legende „Farbe = Auslastung“, „⚡ PoE“, „Rahmen = Fehler“), Verlauf (nur mit PIN), Ereignisse. Unter Technik (eingeklappt) die bisherige Gerätekarte: Erreichbarkeit (Antwortzeit, erreichbar seit, Verfügbarkeit 24 h), System (Hersteller, Modell, Seriennummer, Rechner, Software, Laufzeit, CPU, Speicher, MA-Software), alle Temperaturen mit Verlauf der letzten Stunde, Lüfter und Netzteile, USV-Werte, MA-Net (Session, Version, Slot, Node-Ports mit Universum und DMX live), MA-Parameter, Luminex-Engines, Universen, Anschlüsse mit Datenrate und Fehlern, offene und zuletzt behobene Probleme.

SNMP komplett in der Gerätekarte (unter Technik): alle aufbereiteten Werte (Ports im Detail mit Alias, Geschwindigkeit, Datenrate, Multicast, VLAN/Trunk, Spanning Tree, Fehler, PoE, LLDP-Nachbar bzw. Uplink und angeschlossenen Geräten, VLAN-Liste, WLAN, Netzteile, eigene Werte) und auf Knopfdruck „Alle SNMP-Werte lesen“ – alle Rohwerte des Geräts mit lesbaren Namen (z. B. ifAlias, upsBattery, Cisco SB Umgebung) und Filter; das belastet das Gerät kurz und läuft nur für ein Gerät gleichzeitig (Ergebnis 2 Minuten zwischengespeichert).

Läuft am Mac ein neuer Build, lädt sich die Web-App innerhalb einer Minute selbst neu.

Bestätigen ohne PIN: Probleme lassen sich in der Web-App von jedem bestätigen, auch ohne Anmeldung – in der Notiz steht dann die Adresse des Handys. Schalten und einstellen geht in der Web-App nicht (auch nicht mit PIN); mit „Auch zum Ansehen PIN verlangen“ ist die Web-App ganz geschützt.

Die Adresse mit „/foh“ dahinter zeigt eine Nur-ansehen-Vollbildansicht für einen Bildschirm am FOH.

DC-Seiten (/dc): Die Adresse mit „/dc“ dahinter (Knopf „DC-Seiten“ unter Mehr bzw. unter Netzwerk → Standorte; am Mac im Server-Fenster „DC“) zeigt zuerst die Gesamtseite „Gesamt“ (wie die Übersicht am Mac: alle Standorte, Strom/Netzwerk/Licht gesamt, Kennzahl „Spitze 15 min“ (höchste Viertelstunde heute, siehe Strom → Lastgang), Top-Schwachstellen; Tipp auf eine Standortkarte blättert zu dessen Seite), danach eine Seite je Standort in der Reihenfolge der Standorte – FOH, DC 1, DC 2 … – mit demselben Aufbau wie am Mac (Kennzahlen-Band, Probleme, Strom, Netzwerk, Licht, Pulte, Temperatur, Schwachstellen; siehe Standorte → Dashboard je Standort). Gedacht für Bildschirme und Tablets im Netz, nur ansehen, ohne Tabs:

• Wischen (Handy/Tablet), Pfeiltasten ← → bzw. Bild auf/ab oder die Punkte oben (je Standort mit Ampel) wechseln die Seite; die Seite rastet ein.
• /dc/DC 1 (bzw. /dc/dc1, Groß/klein und Leerzeichen egal) öffnet direkt diesen Standort; beim Blättern zeigt die Adresszeile immer den aktuellen Standort. /uebersicht (Knopf „Gesamtübersicht“ auf der Übersicht und unter Mehr) öffnet die Gesamtseite, ebenso /dc/gesamt.
• Leaderboard als letzte Seite (nach dem letzten Standort): Podium der meisten Befehle, alle Awards und alle Operator, umschaltbar Heute/Show/7 Tage (/dc/Leaderboard); auf „Gesamt“ dazu der Kasten FOH-Leaderboard · Top 3 heute (antippen blättert zur Seite). Beides nur, wenn die Bedienerdaten sichtbar sind (mit PIN angemeldet bzw. „Bedienerdaten ohne Anmeldung zeigen“) und es Operator gibt – sonst fehlen Seite und Kasten ohne Fehlermeldung. Sind die Bedienerdaten gesperrt, fragt die Seite das Leaderboard erst nach einer Anmeldung bzw. beim erneuten Öffnen des Tabs wieder ab.
• /dc?auto=20 blättert alle 20 Sekunden weiter (5 s bis 1 h), einschließlich der Leaderboard-Seite; nach einer Bedienung eine Minute Pause. Ein offenes Detail-Overlay hält das Blättern höchstens 2 Minuten an.
• Aktualisiert sich alle 3 Sekunden.
• DMX-Werte: Ein Universen-Kästchen antippen zeigt seine DMX-Werte mit Senderwahl und Lampen wie unter Licht → Universen; bei zusammengeführten Universen (MA-Net2 + sACN) den aktiven Weg. Das Weiterblättern mit ?auto pausiert dabei. In der Internet-Ansicht lassen sich die Kästchen nicht antippen.
• Ein-Seiten-Ansicht (Standard): Jede Seite füllt genau den Bildschirm, nichts scrollt – auf 1920×1080, 1280×720, 1366×768, 2560×1440 (wie 1080p, nur größer), iPad quer und Handy quer, auch hinter der Internet-Ansicht. Kennzahlen und Probleme stehen immer oben (Probleme auf ein bis zwei Zeilen, der Rest als „+N weitere“). Darunter die Bereiche, gepackt nach Inhalt: der Inhalt bestimmt die Fläche – jede Kachel bekommt, was sie braucht; nur wenn die Seite zu hoch würde, wird auf der höchsten Spalte verdichtet (wichtige Bereiche zuletzt). Gekürzte Kacheln bekommen frei bleibende Fläche zuerst, vollständige bleiben so groß wie ihr Inhalt. Passt ein Bereich nicht, wird er verdichtet statt abgeschnitten: erst kleiner (Verläufe, Legenden und Sparklines weg), dann noch dichter (Phasenbalken flach, Nebenangaben weg), dann Listen auf die wichtigsten Einträge (Auffälliges zuerst) mit „+12 weitere“, bei sehr wenig Platz bis auf „alle N ›“ – erst ganz zuletzt nur eine Zusammenfassung wie „Netzwerk: 71/71 online · höchster Uplink 41 %“. Das Universen-Raster füllt seine Fläche (Spalten × Zeilen so, dass die Zellen möglichst groß werden, höchstens 56 px; Nummer immer lesbar, mindestens 22 px). Die Licht-Kachel wird nur so breit, wie die Seite am niedrigsten bleibt – frei werdende Breite nutzen die anderen Kacheln (z. B. Strom, Netzwerk, Licht 5×6 und Schwachstellen in einer Reihe); reicht das nicht, stehen Gruppen zu 32 als Balken mit Zustandsfarben („U1–32“). Antippen eines verdichteten Bereichs oder von „+N weitere“ zeigt ihn vollständig als Overlay (aktualisiert sich mit). Die Leaderboard-Seite kürzt Awards und Operator-Liste genauso. Handy hochkant scrollt wie bisher (Bereiche untereinander, Kennzahlen zweispaltig) mit dem Hinweis, das Handy quer zu halten. /dc?scroll=1 (bzw. /uebersicht?scroll=1) zeigt die alte Ansicht zum Scrollen; gilt auch zusammen mit ?auto=20. Ältere Browser ohne Container-Abfragen (Safari vor 16, Chrome vor 105) bekommen diese Ansicht automatisch.
• Es gelten dieselben Freigaben wie für die übrige Web-App („Auch zum Ansehen PIN verlangen“ sperrt auch /dc). Die Seiten zeigen nur Namen, Messwerte und Ampeln, keine Geräte-IDs. Adressen in Problemtexten („(10.0.0.5)“, „IP …“, mit Port oder an „↔“) blendet die Seite aus – reine Anzeigepflege, Versionen wie 1.9.7.3 bleiben stehen; vollständige Texte zeigt die übrige Web-App. Alle Bildschirme teilen sich eine Berechnung (alle 2 s).

Internet-Ansicht (live.stagesense.de)

Die Web-App des Servers lässt sich auch unterwegs ansehen – über https://live.stagesense.de/<Ansichts-Kennung>. Der Server (Pi) schickt dafür seinen Stand nur ausgehend an den Server von RieseVT (live.stagesense.de); von außen ist der Pi weiterhin nicht erreichbar.

• Einschalten: in der Mac-App im Client-Modus unter Einstellungen → Server → Internet-Ansicht: erst eine PIN setzen (mindestens 6 Ziffern, keine Reihe wie 123456), dann „Internet-Ansicht einschalten“. Dort stehen Adresse und Ansichts-Kennung, wann der letzte Stand gesendet wurde und ob gerade jemand zusieht. „Alle abmelden“ meldet alle Geräte ab, eine neue PIN ebenso. Am Pi: sudo stagesense --internetansicht on|off|status (die PIN nur am Mac).
• Anmelden: Adresse öffnen, Ansichts-Kennung (8 Zeichen, steht in der Adresse) und PIN eingeben; die Anmeldung gilt 12 Stunden. Nach 5 falschen PINs ist die Anmeldung von diesem Anschluss 15 Minuten gesperrt (danach länger), nach 20 Fehlversuchen in einer Stunde für den Server 15 Minuten – die Mac-App zeigt das unter Internet-Ansicht an.
• Was man sieht: nach der Anmeldung die Gesamtübersicht mit Durchwahl der Standorte und dem Leaderboard (/dc); „Alle Bereiche“ öffnet die übrige Web-App wie nach der PIN-Anmeldung – Strom, Signal & Daten, MA-Protokoll – nur ansehen: nichts schalten, nichts quittieren, keine Push-Benachrichtigungen. Einzelne Detailblätter (Netzgeräte, Universen, Patch) gibt es im Internet nicht.
• Aktualität: Oben steht „Internet-Ansicht · Stand vor 3 s“ (auf der Gesamtübersicht oben links „Internet-Ansicht · vor 3 s“). Kommt länger als 30 s kein neuer Stand (Internet am Server weg, Server aus), steht dort „Server offline seit 12:04 · letzter Stand“.
• Details der DC-Seiten: auch in der Internet-Ansicht, aber nur mit Momentwerten – ohne Verlauf, ohne Sprünge zu anderen Seiten, ohne Showfile, Seriennummern und IP-Adressen, Bediener als „•••“. Sie werden nur gerechnet, solange jemand zusieht, dann alle 12 s neu (die übrige Seite alle 4 s); für „gesamt“ und bis zu 12 Standorte.
• Keine Adressen ins Internet: Es gehen keine IP- und MAC-Adressen, Seriennummern oder internen Geräte-, Standort- und Problem-Kennungen hinaus – auf allen Seiten, auch nicht in Meldungstexten („Name · 10.0.0.5“ wird zu „Name“). Geräte und Standorte haben dort eigene Kennungen, die bei jedem Start des Servers neu vergeben werden. Die Geräteseite zeigt nur Momentwerte, ohne Verlauf und ohne Behobenes; leere Adressfelder blendet die Web-App aus. Versionsnummern wie „1.9.7.3“ bleiben.
• Last und Datenschutz: Solange niemand zusieht, schickt der Server nur einmal pro Minute ein Lebenszeichen, beim Zusehen alle 4 Sekunden und nur Geändertes. Ohne Internet läuft der Server ganz normal weiter. Ausschalten löscht den Stand auf live.stagesense.de; ohne neuen Stand ist er nach 7 Tagen weg.
• Gesperrte Lizenz: Wird eine Lizenz gesperrt oder gelöscht oder der Platz eines Servers freigegeben, schaltet die Internet-Ansicht ihn innerhalb von etwa einer Minute ab: Der Stand auf live.stagesense.de wird gelöscht, angemeldete Betrachter werden abgemeldet, der Server zeigt „Internet-Ansicht: Lizenz bzw. Gerät gesperrt – Internet-Ansicht abgeschaltet“. Nach dem Entsperren bzw. einer neuen Aktivierung geht sie beim nächsten Senden wieder.

Push aufs Handy

1. Web-App über eine HTTPS-Adresse öffnen (Tailscale oder externe Adresse) und vom Home-Bildschirm starten (iOS 16.4 oder neuer).
2. Mehr → Benachrichtigungen → Aktivieren, Mitteilungen erlauben, dann „Test“.
3. Am Mac unter Einstellungen → Web-App „Alarme als Web-Push senden“ eingeschaltet lassen; „Auch Warnungen (nicht nur Alarme)“ ist ab Werk an.

Web-Push kommt auch im Showmodus. Zeigt ein Mac im Client-Modus die Meldungen des Servers schon als Mitteilung, bekommt eine Web-App auf demselben Mac keinen Web-Push dazu (kein Doppel); ein Handy im selben Netz bekommt seinen Push immer, ebenso jeder Test.

Die Web-App meldet sich beim Öffnen selbst neu an, wenn der Mac ihr Abo nicht mehr kennt. Klappt es nicht, zeigt „Mehr → Benachrichtigungen“ eine Diagnose Schritt für Schritt (HTTPS, Home-Bildschirm, Erlaubnis, Service Worker, Abo, Mac kennt das Abo).

Einsatz und Bericht, eigene Dashboards

Einsatz & Bericht

Eine Aufzeichnung sammelt während eines Jobs alle Alarme und Ereignisse sowie jede Minute Leistung, Spannungen, Ströme, Neutralleiter, Frequenz und Sternpunkt je Messgerät und die Erreichbarkeit der Netzwerkgeräte.

1. Werkzeuge → Einsatz & Bericht → Name, Ort, Notizen → „Aufzeichnung starten“.
2. Während des Einsatzes: „Zwischenbericht (PDF)“ jederzeit.
3. „Beenden“ – der Einsatz landet unter „Frühere Einsätze“, von dort als PDF exportierbar. Der Bericht enthält Verläufe, Ereignisse und die Verfügbarkeit je Netzwerkgerät in Prozent.

In derselben Ansicht stehen oben die Sicherungen der Blackbox; bei jedem früheren Einsatz steht, wie viele in seinen Zeitraum fallen – siehe Nach einer Störung – Blackbox.

Energie & Kosten (im PDF): kWh je Verteiler, je Standort und für den ganzen Einsatz aus den Energiezählern der Messgeräte (Ende − Start, Zuwächse summiert). Springt ein Zähler zurück (im Gerät gelöscht oder getauscht), wird nichts abgezogen: StageSense summiert die Abschnitte davor und danach getrennt und vermerkt „Zähler-Rücksprung hh:mm“. Eine Lücke in der Aufzeichnung (Gerät getrennt) ist im Verbrauch enthalten, weil der Zähler im Messgerät weiterläuft, und wird mit Uhrzeit vermerkt. Hat ein Messgerät keinen Zähler, schätzt StageSense aus der Leistung (gekennzeichnet; Lücken dann nicht enthalten). StageSmarts-Verteiler haben keinen Energiezähler und fehlen in der Tabelle. Der Strompreis pro kWh steht oben in Einsatz & Bericht (z. B. 0,35); leer = keine Kosten. Dazu die Lastgang-Grafik des Einsatzes (15-min-Mittel, Spitze rot, Lücken orange).

Netzqualität „angelehnt an EN 50160“ (im PDF): je Messgerät 10-Minuten-Mittel von Spannung, Frequenz, THD U und Unsymmetrie gegen die Grenzen der Norm, je Kriterium mit Ampel und Prozentwert:

Grün = alle Fenster im Band, Orange = gefordert erfüllt, einzelne Fenster außerhalb, Rot = nicht erfüllt, Grau = keine Werte. Ehrlich: StageSense tastet etwa alle 2 s ab – Einbrüche und Unterbrechungen unter 1 s, Flicker und einzelne Oberschwingungen erfasst es nicht, und bewertet wird der Einsatz statt einer Woche. Deshalb „angelehnt an“ und kein Normnachweis. Fenster mit weniger als 5 Minuten Werten zählen nicht. Grundlage sind die Minutenmittel aus dem Archiv; bei älteren Einsätzen ohne Archiv die Minutenpunkte der Aufzeichnung.

CSV: Knopf „CSV“ je Einsatz (bzw. „CSV …“ beim laufenden) – Minutenmittel aller Messgeräte des Einsatzes.

Eigene Dashboards

„Dashboard anlegen“ in der Seitenleiste: Geräte wählen und Bausteine zusammenstellen.

Für Dimmer Cities bieten die Standort-Dashboards (Kapitel Standorte) einen fertigen Aufbau ohne Zusammenstellen. Standortfilter: Netzwerk-Geräte, DMX-Universen und USV lassen sich in den Baustein-Einstellungen auf einen Standort beschränken (Standard „Alle Standorte“) – z. B. ein Dashboard je DC mit nur dessen Geräten, Universen und USV.

Nach einer Störung – Blackbox

Nach einem Ausfall ist oft unklar, was zuerst kam: der Strom, der Switch oder das Pult. Die Blackbox hält dafür laufend die letzten Minuten aller Bereiche im Speicher. Bei einer Störung sichert sie diese Minuten auf die Platte, ab Werk 10 Minuten davor und 2 Minuten danach, und zeigt sie auf einer gemeinsamen Zeitachse. Die Blackbox läuft auf dem StageSense-Server bzw. auf dem Mac im Eigenständig-Betrieb und ist ab Werk eingeschaltet. Ein Mac im Client-Modus zeichnet nicht selbst auf, er zeigt die Sicherungen des Servers.

Ehrlich: Die Blackbox zeigt die Abfolge, nicht die Ursache. Jeder Wert trägt die Zeit, zu der der Server ihn empfangen hat. Was davon Ursache ist und was Folge, musst du selbst deuten.

Was gesichert wird

Licht, MA, Netzwerk und Server liest die Blackbox jede Sekunde, Temperaturen der Netzwerkgeräte alle 10 s. Zustände wie „erreichbar“ oder „verbunden“ hält sie bei jeder Änderung fest und zusätzlich einmal je Minute, damit jede Sicherung den Zustand am Anfang kennt. Werte, die ein Gerät nicht liefert, fehlen in der Sicherung – sie stehen nie als „0“ da. Befehle der Bediener und MA-Pakete nimmt die Blackbox nicht auf (siehe Bedienerdaten und Datenschutz).

Wann gesichert wird

Keine Sicherung lösen aus: Meldungen der Stufen Mittel, Warnung und Info sowie „behoben“. In der Wartung (global oder je Gerät) lösen Geräte, Universen und Nodes nicht aus. Jede Strom-Art löst je Messgerät einmal aus und erst wieder, wenn sich der Wert 10 s lang erholt hat; nie belegte Phasen eines einphasigen Geräts zählen nicht. Spannung und Frequenz lösen also nur beim Wechsel aus „gut“ aus: Was schon beim Start daneben liegt, löst erst aus, nachdem es einmal gut war. Für Spannung und Frequenz gelten dieselben Grenzen wie für die Ampeln (siehe Grenzwerte).

Nach dem Start des Servers bzw. von StageSense im Eigenständig-Betrieb lösen Meldungen der Stufe Alarm 5 Minuten lang keine Sicherung aus; sie stehen trotzdem in der Spur „Ereignisse“. Beim Start meldet StageSense alles neu, was schon vorher so war, z. B. ein Gerät, das schon fehlte – das ist keine neue Störung, und im Speicher stünde noch kaum Vorlauf. Wechsel wie Gerät nicht erreichbar, Universum weg, Node-Neustart und die Strom-Auslöser lösen auch in diesen 5 Minuten aus. Ein Neustart ohne Störung ergibt also keine Sicherung. „Jetzt sichern“ geht immer; eine Sicherung kurz nach dem Start reicht aber nur bis zum Start zurück.

Mehrere Auslöser – eine Sicherung: Was innerhalb von 2 Minuten nach dem ersten Auslöser passiert (Totzeit), landet in derselben Sicherung. Ein Stromausfall in einer DC mit 20 Geräten und 8 Universen ergibt also eine Sicherung, nicht 29. Fertig ist die Sicherung erst nach dem Nachlauf; bis dahin steht in der Liste „Wird gesichert … fertig um 21:14 (Nachlauf)“. Wird der Server beendet (Update, Neustart), schreibt er eine laufende Sicherung vorher noch auf die Platte.

Sicherungen ansehen

• Mac: Werkzeuge → Einsatz & Bericht, Kasten „Blackbox · Sicherungen nach Störungen“. Jede Sicherung steht mit Uhrzeit, Auslöser, Standort und Größe da – roter Punkt nach einer Störung, grüner bei „von Hand“ (mit Herkunft, z. B. „Von Hand gesichert (Mac)“). Antippen öffnet die Zeitachse. Bei den früheren Einsätzen steht, wie viele Sicherungen in ihren Zeitraum fallen („2 Blackbox-Sicherungen“). Im Client-Modus kommt die Liste vom Server, eine Sicherung lädt der Mac beim Öffnen in Stücken.
• Web-App: Reiter Meldungen, oben „Blackbox · Sicherungen nach Störungen“. Ohne Anmeldung zeigt die Liste nur Uhrzeit und Art des Auslösers. Text, Standort und die Zeitachse gibt es erst nach Anmeldung mit PIN („Blackbox nur nach Anmeldung (PIN)“).
• Geräte-Konto des Servers: Karte Blackbox mit „Jetzt sichern“.
• Internet-Ansicht (live.stagesense.de): nur die Liste mit Uhrzeit und Art des Auslösers. Sicherungen öffnen und „Jetzt sichern“ gehen nur in der Web-App des Servers (mit PIN).

Zeitachse (Mac und Web-App gleich): Oben stehen Auslöser, Standort und Zeitraum („12 min (10 davor, 2 danach)“), darunter die Spuren nach Gruppen – Ereignisse, Strom, Licht, MA, Netzwerk, Server – mit einem gemeinsamen Cursor. Der Auslöser ist als rote Linie markiert. Zoom 12 min, 3 min, 1 min und 20 s; die Ansicht öffnet mit 1 Minute um den Auslöser. „Standort“ beschränkt die Spuren auf einen Standort („alle Standorte“ zeigt wieder alles). Der Cursor zeigt die Uhrzeit auf die Zehntelsekunde und den Abstand zum Auslöser, z. B. „+1,5 s“. Darunter steht die Ereignisfolge mit Uhrzeit, der Auslöser rot; weitere Auslöser in der Totzeit stehen dort mit Art und Standort. Dichte Messreihen zeigt die Zeitachse je Bildpunkt als Minimum und Maximum – kurze Spitzen bleiben sichtbar.

• Datei sichern (Web-App) lädt die Sicherung als .json, z. B. für den Support.
• Kurzbericht (PDF) … (Mac, im Fenster der Zeitachse): A4 mit Art des Auslösers, Uhrzeit auf die Millisekunde, Standort, Aufzeichnungszeitraum, Server und Version; darunter die betroffenen Spuren ±60 s um den Auslöser als Grafik (höchstens 10 Zeilen) und die Ereignisfolge als Tabelle, der Auslöser rot. In der Grafik stehen zuerst die Ereignisse, dann das Gerät des Auslösers mit seinem Zustand und höchstens 3 passenden Werten (Spannungseinbruch und Phase weg: U, I, P; Frequenz daneben: f, U, P; Messgerät getrennt: nur der Zustand), danach weitere Geräte, deren Zustand im Ausschnitt nicht „ok“ war. Ist nichts auffällig, z. B. bei „von Hand“, steht statt der Grafik ein Hinweis. Bei vielen Ereignissen folgen weitere Seiten. Der Auslöser steht immer auf Seite 1: Passt er der Reihe nach nicht mehr darauf, zeigt Seite 1 die Meldungen um den Auslöser („Ereignisfolge um den Auslöser · 30 von 120 Meldungen – alle ab Seite 2“), und ab Seite 2 folgt die ganze Ereignisfolge. Der Kurzbericht zeigt die Abfolge, nicht die Ursache.

Jetzt sichern

Nicht jede Störung löst einen Alarm aus – etwa ein kurzes Flackern, das nur das Publikum sieht. Dann „Jetzt sichern“ drücken: am Mac (Einsatz & Bericht), in der Web-App (Meldungen, nur nach Anmeldung mit PIN) oder im Geräte-Konto. Gesichert werden die 10 Minuten davor und die 2 Minuten danach, die Datei ist also erst nach dem Nachlauf fertig. Ein zweiter Druck in der Totzeit legt keine zweite Sicherung an, sondern meldet „Gehört zur laufenden Sicherung – fertig um …“. Über die PIN-Anmeldung der Web-App geht „Jetzt sichern“ höchstens sechsmal je Stunde, damit niemand ältere Sicherungen durch neue verdrängen kann. „Dieser Server kann noch nicht von Hand sichern (Update nötig)“ heißt: Auf dem Server läuft eine ältere Version.

Einstellungen der Blackbox

Einstellungen (⌘,) → Blackbox. Im Client-Modus gilt die Seite für den Server; die Sicherungen entstehen dort.

Änderungen gelten sofort. Passt eine Eingabe nicht, wird das Feld rot, oben steht „Nicht gesichert – es gelten weiter die gesicherten Werte“ mit dem Grund, z. B. „Vorlauf: 0 min – erlaubt 1…60 min“. „Standardwerte …“ setzt nach einer Rückfrage alles auf die Werte ab Werk zurück.

Nicht auf der Seite und fest ab Werk: die Totzeit (2 min), der Speicher für die laufenden Minuten (128 MB), die übrigen Auslöser (alle an; „Standardwerte …“ schaltet auch sie wieder ein) und MA-Pakete (aus, gibt es noch nicht).

Ist die Blackbox aus, entsteht keine Sicherung, auch nicht von Hand („Blackbox ist ausgeschaltet (Einstellungen)“). Ist „„Jetzt sichern“ erlauben“ aus, lösen nur Störungen eine Sicherung aus; „Jetzt sichern“ meldet dann „Der Auslöser „von Hand“ ist abgeschaltet“. Auch der Platz für die Aufbewahrung gilt nur innerhalb der Plattenregel unten.

Ablage und Platz

Die Sicherungen liegen im Datenordner von StageSense im Ordner Blackbox: je Sicherung eine gepackte Datei blackbox-JJJJMMTT-HHMMSS.json.gz und eine kleine Begleitdatei für die Liste. Auf dem Server können nur der Dienst und seine Gruppe Ordner und Dateien lesen.

Es gibt höchstens 50 Sicherungen und zusammen höchstens 2 GB; darüber löscht StageSense die ältesten, die neueste bleibt immer. Außerdem gilt: Die Blackbox lässt immer mindestens 2 GB frei und füllt die Systemplatte (am Pi die SD-Karte) höchstens zu 80 %, andere Platten höchstens zu 90 %. Ist die Platte zu voll, löscht sie ältere Sicherungen – aber nur, wenn das reicht. Sonst legt sie keine neue an und schreibt „Platte zu voll … – Sicherung nicht geschrieben“ ins Protokoll.

Nicht geschrieben: Kann die Blackbox eine Sicherung nicht schreiben (Platte zu voll oder ein anderer Fehler), steht in der Problemliste das Problem „Blackbox“ (Schweregrad Mittel) – am Mac, in der Web-App und in der Internet-Ansicht, dort ohne den Text des Auslösers. Die nächste geschriebene Sicherung nimmt das Problem zurück. Am Linux-Server stehen „Gesichert …“ und „nicht geschrieben“ zusätzlich im Journal (journalctl -u stagesense).

Bedienerdaten und Datenschutz

Eine Sicherung ist ein Protokoll der Anlage. Sie kann aber Angaben zu Personen enthalten, und wer eine Datei oder einen Kurzbericht weitergibt, gibt diese Angaben mit.

• MA-Benutzernamen stehen nur in der Spur „Ereignisse“: Anmeldungen und Abmeldungen an den Pulten und der Zusatz bei Paketwiederholungen („kurz nach „Store Cue 26“ (huwi)“). Ist „Bedienerdaten ohne Anmeldung zeigen“ aus (ab Werk), ersetzt StageSense die Namen schon bei der Aufnahme durch „•••“ und lässt den Zusatz „kurz nach …“ weg. Dann stehen sie in keiner Sicherung. Ist der Schalter an, sichert die Blackbox die Namen so, wie die Konsole sie meldet. Der Schalter wirkt bei der Aufnahme: Sicherungen, die mit Namen entstanden sind, behalten sie.
• Befehle der Bediener (MA-Protokoll, Befehls-Statistik, Leaderboard) nimmt die Blackbox nie auf.
• MA-Pakete gibt es in Sicherungen noch nicht; die Einstellung dafür ist aus.
• Außerdem stehen in einer Sicherung Messwerte, Namen von Geräten und Standorten, IP-Adressen der Netzwerkgeräte und die Texte der Meldungen.

Wer sieht was: Ohne Anmeldung zeigt die Web-App nur Uhrzeit und Art der Sicherungen. Inhalt, Auslösertext und Standort gibt es nur nach Anmeldung mit PIN bzw. für den gekoppelten Mac, am Server selbst nur für den Dienst und seine Gruppe. Eine heruntergeladene Datei und ein Kurzbericht sind Kopien: Gib sie nur abgestimmt weiter, und lösche sie, wenn sie nicht mehr gebraucht werden.

Showprofile

Ein Showprofil speichert eine komplette Produktion und lädt sie mit einem Klick wieder – für wiederkehrende Jobs oder die nächste Tour-Station.

1. Werkzeuge → Showprofile → „Aktuellen Stand speichern“: Name (z. B. „Tour 2026 – Köln“) und Notiz; gleicher Name überschreibt.
2. Laden: ersetzt Geräte, Patch, Standorte, Anschlüsse und Dashboards durch das Profil. Vorher legt StageSense automatisch eine Sicherung an (Einstellungen → Zurücksetzen → Sicherungen).
3. Exportieren / Importieren als Datei (.stageshow) – zum Weitergeben an einen anderen Rechner.

Das geladene Profil steht in der Seitenleiste unter Showprofile. Profile bleiben auch beim Zurücksetzen auf den Werkszustand erhalten.

Simulatoren

Unter Werkzeuge → Simulatoren spielen eingebaute Simulatoren echte Geräte über die echten Protokolle nach – aber nur innerhalb des Macs (127.0.0.x); im Show-Netz ist nichts davon zu sehen. Alles heißt „SIM …“, auch in Alarmen und Push. Beim Neustart sind alle aus; angelegte Simulator-Geräte verschwinden beim Abschalten wieder.

In der Demo (ohne Lizenz) sind die Simulatoren der einzige Weg, StageSense auszuprobieren.

Zurücksetzen und Sicherungen

Unter Einstellungen → Zurücksetzen lässt sich jeder Bereich einzeln leeren oder zurücksetzen; vor jedem Zurücksetzen legt StageSense automatisch eine Sicherung an.

Alles zurücksetzen (Werkszustand) löscht alle Einstellungen und Daten und startet die App neu. Der Lizenzschlüssel bleibt erhalten – außer du wählst ausdrücklich „Alles zurücksetzen und auch Lizenz entfernen“.

Sicherungen stehen unten in derselben Ansicht und lassen sich wiederherstellen; auch dabei bleibt die aktuelle Lizenz, und vorher wird der jetzige Stand selbst gesichert.

Für Server exportieren … (ganz unten in derselben Ansicht) speichert alle Einstellungen in eine .stageconfig-Datei für den StageSense-Server, z. B. einen Raspberry Pi – siehe Kapitel StageSense-Server.

StageSense-Server (Raspberry Pi)

StageSense läuft auch ohne Bildschirm als Server auf einem Raspberry Pi und überwacht dort rund um die Uhr Strom, Licht und Netzwerk – unabhängig davon, ob ein Mac im Show-Netz hängt. Bedient wird der Server über die Web-App (Browser, iPhone) unter http://<IP des Pi>:8470. Eingerichtet wird am Mac; die Einstellungen kommen per Export auf den Pi.

Was der Server kann

Neue Geräte sucht der Server auf Knopfdruck vom gekoppelten Mac (Client-Modus: Werkzeuge → Geräte-Suche → „Jetzt suchen“); beim Hochfahren nur, wenn „Beim Start nach Geräten suchen“ an ist (ab Werk aus; die Einstellung kommt mit dem Mac-Export). Mitteilungen im macOS-Mitteilungszentrum und Alarmtöne gibt es auf dem Server nicht – er meldet per Web-Push und über die Push-Dienste, auch im Showmodus; gekoppelte Macs im Client-Modus zeigen seine Meldungen als Mitteilung.

Hardware

• Raspberry Pi 5 (8 GB) mit NVMe-SSD und offiziellem 27-W-Netzteil; ein Pi 4 mit 64-bit-System geht auch.
• RTC-Batterie (ML-2020, Anschluss „BAT“) unbedingt einsetzen: Ohne sie startet der Pi ohne Internet mit falscher Uhrzeit – dann stimmen Zeitstempel und Alarme nicht, und mit Zeitserver auch die Uhren im ganzen Show-Netz nicht. Nach dem Einsetzen einmal mit Internet starten, damit die Uhr gestellt wird.
• Der eingebaute Netzwerkanschluss kommt an einen Trunk-Port: ungetaggt das Management-Netz, alle anderen Netze als getaggte VLANs.

Ohne Display, Maus und Tastatur

Monitor und Tastatur braucht der Pi nicht – eingerichtet wird alles vom Mac aus:

1. Raspberry Pi Imager → Raspberry Pi OS Lite (64-bit) auf die SD-Karte bzw. NVMe-SSD. In den Einstellungen des Imagers Hostname (z. B. stagesense bzw. stagesense-sensor), Benutzer und Passwort, SSH an und Zeitzone Europe/Berlin setzen; soll der Pi über WLAN ins Netz, dort auch WLAN-Name, Passwort und Land (DE) eintragen.
2. Karte in den Pi, erst das Netzwerkkabel, dann Strom. Der Pi braucht dafür ein Netz mit DHCP – den Switch bzw. Router vor Ort, das WLAN aus Schritt 1 oder am Mac die Internetfreigabe auf den Kabel-Adapter. Nach ein bis zwei Minuten antwortet er unter <Hostname>.local.
3. Vom Mac aus das Paket kopieren und installieren – Server: scp StageSense-Server-*.tar.gz <benutzer>@stagesense.local:, dann ssh <benutzer>@stagesense.local, tar xzf StageSense-Server-*.tar.gz && cd StageSense-Server-*/ und sudo ./install.sh (mit --import <Datei>.stageconfig, wenn die Einstellungen vom Mac mitkommen sollen); Sensor genauso mit StageSense-Bridge-*.tar.gz und sudo ./install-bridge.sh.
4. Danach ist der Pi unter http://<Hostname>.local:8470 erreichbar (Sensor: :8480), per Kabel direkt am Mac immer unter der Fallback-Adresse 169.254.255.1 (Sensor: .2). Lizenz in der Web-App bzw. auf der Statusseite eintragen.

Auf Wunsch liefert RieseVT eine fertig vorbereitete Karte, die sich beim ersten Start selbst einrichtet. Taucht der Pi damit nicht im Netz auf, steht das Ergebnis auf der Karte unter stagesense/ERGEBNIS.txt (Karte in den Mac stecken und nachlesen).

Server einrichten

1. Mit dem Raspberry Pi Imager Raspberry Pi OS Lite (64-bit) auf die NVMe-SSD schreiben; im Imager Hostname (z. B. stagesense), Benutzer und Passwort, SSH und die Zeitzone Europe/Berlin einstellen. Startet der Pi nicht von der NVMe: sudo raspi-config → Advanced Options → Boot Order → NVMe/USB Boot.
2. Je VLAN eine Schnittstelle anlegen, Name immer eth0.<VLAN>, mit eigener freier Adresse und ohne Gateway (das kommt nur über das Management-Netz), z. B. sudo nmcli con add type vlan con-name vlan291 ifname eth0.291 dev eth0 id 291 ipv4.method manual ipv4.addresses 192.168.91.20/24 ipv6.method disabled, dann sudo nmcli con up vlan291.
3. Am Mac unter Einstellungen → Zurücksetzen → Für Server exportieren … die Einstellungen sichern.
4. Paket und .stageconfig auf den Pi kopieren (z. B. per scp), dort entpacken und im Paketordner sudo ./install.sh --import <Datei>.stageconfig aufrufen. Der Pi braucht dabei Internet (Tailscale, Lizenz).
5. Tailscale: Das Skript installiert Tailscale mit (--no-tailscale lässt es weg) und zeigt einen Anmelde-Link – im Browser öffnen und den Pi im eigenen Tailnet bestätigen. Auf die Anmeldung wartet es höchstens 60 s; danach nennt es den Befehl für später (sudo stagesense --tailscale, wartet bis 300 s) und installiert weiter. Am Ende nennt es die Tailscale-Adresse des Pi (z. B. http://100.x.y.z:8470); sie kommt in der Mac-App unter Einstellungen → Server. Für HTTPS (nötig für Web-Push) im Tailscale-Admin unter DNS „HTTPS Certificates“ einschalten – tailscale serve richtet das Skript dann selbst ein.
6. Mit sudo stagesense --check prüfen; danach die Web-App unter http://<IP des Pi>:8470 öffnen – im Show-Netz oder über Tailscale auch von unterwegs – und unter Lizenz den Schlüssel eintragen (siehe unten).

Immer erreichbar – Fallback-Adresse 169.254.255.1: Der Pi hat am Netzwerkanschluss (ungetaggt) zusätzlich immer die feste Adresse 169.254.255.1 – egal ob DHCP fehlt, die VLANs falsch eingerichtet sind oder Tailscale nicht läuft. Sie steht als zusätzliche Adresse im NetworkManager-Profil des Netzwerkanschlusses: DHCP läuft daneben weiter (ohne Zeitlimit), und auch ganz ohne DHCP-Server ist sie sofort da. Der Dienst stagesense-fallback-ip prüft das alle 5 Sekunden, trägt sie nach Änderungen über „Pi-Netzwerk verwalten“ wieder ein und gibt den Anschluss an NetworkManager zurück, falls die Adresse schon außerhalb davon gesetzt war. Was der Dienst an NetworkManager-Profilen ändert: Im Profil, das gerade am Netzwerkanschluss läuft, trägt er die Fallback-Adresse zusätzlich ein; bei DHCP außerdem ipv4.may-fail yes und ipv4.dhcp-timeout infinity, bei „ohne IPv4“ (nur VLANs) wird daraus eine feste Adresse mit nur der Fallback-Adresse und ohne Default-Route. Ein Profil ohne Bindung (z. B. „Wired connection 1“) bindet er beim Zurückholen an den Anschluss – an eine MAC-Adresse oder per „match“ gebundene Profile nie. Profile mit 802.1X aktiviert er nie selbst (Fehlversuche könnten Konten sperren). Hat jemand den Anschluss bewusst getrennt (nmcli device disconnect), aktiviert er ihn nicht wieder; die Adresse setzt er dann wie früher direkt, ebenso ohne NetworkManager (auch wenn er gestoppt oder abgestürzt ist) und bei Profilen, die er nicht anfasst (shared, link-local, Port einer Bridge/eines Bonds). Während „Netzwerk verwalten“ eine Änderung auf Probe hat, setzt er aus. Abschalten: sudo ./install.sh --no-fallback (nimmt die Adresse auch aus den Profilen; may-fail und dhcp-timeout bleiben, sie schaden nicht), wieder an mit --fallback – die Wahl bleibt über Updates. So kommst du immer dran: Mac per Kabel direkt an den Pi (oder in ein Netz ohne DHCP), warten, bis der Mac sich selbst eine Adresse 169.254.x.x gibt, dann http://169.254.255.1:8470 (Web-App), ssh <benutzer>@169.254.255.1 oder im Client-Modus diese Adresse. Hat der Mac-Adapter eine feste Adresse, erreicht er die Fallback-Adresse nicht – dann den Adapter kurz auf DHCP stellen. Die Überwachung sieht diese Adresse nicht (kein Show-Netz); sudo stagesense --check zeigt sie unter „Fallback-Adresse“. Adressen aus 169.254.255.x vergibt kein Gerät selbst – keine Konflikte.

Eigenes WLAN als Notzugang: Hat der Pi 45 Sekunden lang keine echte Netzverbindung – keine Adresse per DHCP, keine feste IP bzw. VLAN, kein bekanntes WLAN –, macht er ein eigenes WLAN auf, auch wenn ein Kabel an einem Port ohne Netz steckt – praktisch, wenn er ohne Bildschirm und Tastatur dasteht. Name und Passwort nennt der Installer am Ende („Eigenes WLAN, wenn kein Netz da ist: StageSense-<Name> / Passwort …“); sie stehen nur für root lesbar in /etc/default/stagesense-hotspot (sudo cat /etc/default/stagesense-hotspot). Handy oder Laptop verbinden, dann http://10.42.0.1:8470 (Web-App) oder ssh <benutzer>@10.42.0.1. Sobald eine echte Verbindung steht (DHCP, feste IP/VLAN), geht das eigene WLAN sofort aus; die Fallback-Adresse 169.254.255.x zählt dabei nicht. Ist niemand verbunden, schaltet es alle 5 Minuten kurz ab, damit sich der Pi mit einem bekannten WLAN verbinden kann. StageSense überwacht das eigene WLAN nie (keine Suche, kein ArtPoll). Abschalten: sudo ./install.sh --no-hotspot (bleibt auch bei Updates aus), wieder einschalten mit --hotspot. sudo stagesense --check zeigt „WLAN-Notzugang: StageSense-<Name> (an/aus)“. Läuft auf demselben Pi auch die Bridge, teilen sich beide dasselbe WLAN. Band: auf dem Pi 5 sendet das eigene WLAN auf 5 GHz (Kanal 36, Land muss gesetzt sein – der Installer setzt DE, wenn keins eingestellt ist), auf anderen Pis auf 2,4 GHz (Kanal 6). Umstellen mit HOTSPOT_BAND=a (5 GHz) bzw. HOTSPOT_BAND=bg (2,4 GHz) in /etc/default/stagesense-hotspot; das gilt beim nächsten Einschalten. Geht 5 GHz nicht an, nimmt der Pi automatisch 2,4 GHz. Nur zur Fehlersuche: HOTSPOT_TXPOWER=2000 begrenzt die Sendeleistung auf 20 dBm.

StageSense läuft danach als Dienst unter einem eigenen Dienstkonto und startet bei jedem Einschalten von selbst. Seine Daten liegen unter /var/lib/stagesense.

Auslastung: Der Server zeigt seine Auslastung und die seiner Sensoren (StageSense Bridge) – CPU gesamt und je Kern mit Last 1/5/15, Arbeitsspeicher und Swap, Platte des Datenordners, CPU- und NVMe-Temperatur, Drosselung und Unterspannung (Raspberry Pi), Takt, Laufzeit, Netz-Durchsatz je Adapter und den Speicher von StageSense. Zu sehen in der Web-App (Übersicht → Auslastung) und im Client-Modus der Mac-App (Übersicht); als JSON unter http://<IP des Pi>:8470/api/system. Sensoren sind die Bridges der Messgeräte mit der Vorlage „StageSense USB-Brücke“ – der Server liest deren Statusseite alle 20 Sekunden (nur lesen). Probleme in der gemeinsamen Liste: CPU ab 80 °C (ab 85 °C Hoch, dort drosselt der Pi), NVMe ab 70 °C, Unterspannung (Hoch; „seit dem Start aufgetreten“ als Warnung), Drosselung, Platte ab 90 % (ab 97 % Hoch), Arbeitsspeicher unter 10 % frei (unter 5 % Hoch). Der eigenständige Mac zeigt keine Auslastung.

Übersicht auf dem Monitor

Hängt am Pi ein Monitor (HDMI), zeigt er statt der Anmeldung eine ruhige Übersicht, alle 3 Sekunden neu:

• Kopf: Name des Servers, Version, Uhrzeit, Lizenz.
• Zugang: Web-App-Adresse im Netz (http://<IP>:8470), die feste Adresse für den Laptop am Kabel (http://169.254.255.1:8470), das eigene WLAN mit Name und Zustand (an: http://10.42.0.1:8470) und die Tailscale-Adresse, dazu Internet – über welchen Adapter es gerade geht (grün, wenn die Internet-Prüfung bestanden ist). Passwörter und PIN zeigt der Bildschirm nie.
• Zustand: Ampel, Zahl der offenen Probleme, Showmodus bzw. Wartung und die wichtigsten Probleme (bis 8, das schwerste zuerst; quittierte nicht).
• Bereiche: Strom (Gesamtleistung, Messgeräte online, Verteiler), Licht, Netzwerk, Dienste – je eine Zeile.
• Pi: CPU, Temperatur, Arbeitsspeicher, Platte und ob er drosselt (Unterspannung, Hitze).

Anmelden: Alt+F2 wechselt zur Anmeldung (tty2), Alt+F1 zurück zur Übersicht – oder per SSH. Ist „Ansehen nur mit PIN“ eingestellt, zeigt der Bildschirm nur Kopf und Zugang. Abschalten: sudo ./install.sh --no-bildschirm (bleibt auch bei Updates aus, dann gibt es auf tty1 wieder die Anmeldung), wieder einschalten mit --bildschirm. Ohne Monitor stört die Übersicht nicht. Zum Ausprobieren im Terminal (z. B. per SSH): sudo stagesense --bildschirm (Ende mit Strg+C).

Lizenz des Servers

Ohne gültige Lizenz läuft auch der Server nur im Demo-Modus und überwacht keine echten Geräte. Die Lizenz wird beim Export bewusst nicht mitgenommen. Am einfachsten in der Web-App: http://<IP des Pi>:8470 (oder http://169.254.255.1:8470) → Lizenz → Schlüssel eintragen → „Aktivieren“. Das geht ohne Anmeldung nur, solange auf dem Pi noch nie eine Lizenz eingetragen war (frisch installiert) – die erste Lizenz legt den Kunden fest. Danach ändert oder entfernt die Lizenz nur noch das Terminal (sudo stagesense --license) oder ein gekoppelter Mac bzw. Windows-Rechner desselben Kunden (Einstellungen → Lizenz) – auch wenn sie abgelaufen ist oder zu lange offline war. Werkszustand und Wiederherstellen ändern daran nichts. Alternativ auf dem Pi: sudo stagesense --license SS-…; ohne Schlüssel versucht er den Freischaltcode (siehe unten) und fragt sonst den Schlüssel ab. Online-Schlüssel werden dabei einmal online aktiviert (der Pi braucht dafür kurz Internet) und an den Pi gebunden; der Pi zählt dann wie ein eigener Rechner. Für den eigenen Pi genügt auch der eigene Schlüssel (Inhaber/NFR).

Server-Lizenz und Freischaltcode

Edition „Server“: Eine Server-Lizenz schaltet einen StageSense-Server (Raspberry Pi) frei und gilt zusätzlich für eine festgelegte Zahl Mac-Clients (z. B. 3; 0 = unbegrenzt). Sind alle Client-Plätze belegt, lehnt der Server das Koppeln eines weiteren Macs ab. Jeder Mac braucht zusätzlich einen eigenen Schlüssel (siehe Lizenz).

Freischalten ohne Abtippen: Am Pi sudo stagesense --license aufrufen, ohne Schlüssel. Der Pi zeigt einen sechsstelligen Freischaltcode (z. B. K7Q4XP) und einen Link (https://license.stagesense.de/c/K7Q4XP). Den Link am Handy oder Mac öffnen, den Lizenzschlüssel eintragen und „Freischalten“ wählen – der Pi holt die Freischaltung nach wenigen Sekunden selbst ab und meldet „Lizenz: gültig – …“.

• Der Freischaltcode gilt 15 Minuten und nur einmal; danach sudo stagesense --license erneut aufrufen. Er hat nichts mit dem Kopplungscode für den Client-Modus zu tun.
• Mit einem Freischaltcode lassen sich Server-, Inhaber- und Beta-Lizenzen freischalten; andere Lizenzen werden direkt in der App eingegeben.
• Der Schlüssel wird nur auf der Lizenzseite geprüft – der Pi erhält eine signierte, an ihn gebundene Freischaltung, nie den Schlüssel selbst.
• Direkt mit Schlüssel geht weiterhin: sudo stagesense --license SS-XXXX-XXXX-XXXX-XXXX.

Server ohne Internet: über Handy, Laptop oder Mac aktivieren

Im Einsatz hat der Pi oft kein Internet. Dann übernimmt das Gerät, mit dem man die Web-App öffnet (Handy, Laptop – es braucht selbst Internet, z. B. über Mobilfunk):

• Erste Lizenz: Web-App → Lizenz → Schlüssel eintragen → „Aktivieren“. Erreicht der Pi den Lizenzserver nicht, schickt die Web-App die vom Pi unterschriebene Anfrage über dieses Gerät und gibt die Freischaltung an den Pi zurück („Lizenz aktiviert ✓ (über dieses Gerät)“).
• Online-Bestätigung (alle 60 Tage): Ist sie fällig (14 Tage vorher), zeigt die Web-App „Online-Bestätigung fällig bis …“ und den Knopf „Über dieses Gerät bestätigen“.
• Macs ohne Internet: Ein gekoppelter Mac, dessen Online-Bestätigung in höchstens 14 Tagen fällig ist, meldet sich beim Server. In der Web-App unter Mehr → Lizenz steht er dann mit Zustand (wartet, angefragt, bereit, fertig); „Über dieses Gerät bestätigen“ auf einem Handy oder Laptop mit Internet holt die Bestätigung. Dabei geht nur die Lizenz-Nummer des Macs an den Lizenzserver, kein Schlüssel; der Mac prüft die Antwort selbst und meldet „Online-Bestätigung über den Server erhalten ✓“.
• Am Mac (Client-Modus): Einstellungen → Lizenz → Lizenz des Servers → „Über diesen Mac aktivieren“ bzw. „Über diesen Mac bestätigen“.
• Sicher, auch über fremde Geräte: Das weiterreichende Gerät kann die Anfrage nicht verändern, und der Pi übernimmt nur eine Freischaltung, die der Lizenzserver für genau diesen Pi ausgestellt hat. Den Schlüssel sieht nur, wer ihn selbst eintippt; zum Bestätigen reicht die Lizenz-Nummer.
• Eine Lizenz ändern oder ersetzen geht auch so nur, solange auf dem Pi noch keine Lizenz war – sonst wie oben über den gekoppelten Mac desselben Kunden oder das Terminal.
• Die Uhr des Pi muss dafür nicht stimmen: Weicht sie ab, nimmt der Pi für die Anfrage die Uhrzeit des Handys bzw. Macs.

Was beim Export mitkommt

Der Server überwacht seine eigenen Kabel-Adapter und VLANs; WLAN, Docker- und VPN-Schnittstellen (z. B. Tailscale) nie automatisch. Beim Import behält der Server nur Adapter, die es bei ihm gibt (die Mac-Namen wie en26 nicht); bleibt keiner übrig, überwacht er seine aktiven Kabel-Adapter mit IP-Adresse – ohne Kabel-Adapter das WLAN – und schreibt das in die Ausgabe des Imports und ins Protokoll („Einstellungen übernommen: …“). Überwacht er gar keinen Adapter, steht im Protokoll, welche es gäbe. Vor jedem Import sichert StageSense den bisherigen Stand des Servers im Ordner „Sicherungen“. Die Exportdatei enthält PIN und Push-Schlüssel der Web-App sowie die Zugangsdaten der Push-Dienste (ntfy, Pushover, Telegram) – nicht weitergeben. Push-Abos gehören zur Adresse der Web-App: Auf dem Handy die Web-App des Pi öffnen und dort unter Mehr → Benachrichtigungen neu aktivieren; für Push braucht auch der Pi eine HTTPS-Adresse – die richtet das Installationsskript über Tailscale ein (tailscale serve; von Hand: sudo tailscale serve --bg http://127.0.0.1:8470).

Gerät → Netzwerk (Web-App, nur lesen): Unter „Mehr“ zeigt die Web-App des Servers alle Netzwerkadapter des Pi – Kabel, USB-LAN, WLAN, VLANs, Tailscale – mit Zustand (verbunden/kein Kabel), IPv4-Adresse und Präfix, Gateway, DHCP oder statisch, MAC-Adresse, beim WLAN Netzname und Signal bzw. den Zustand des eigenen WLANs, dazu die Fallback-Adresse. Passwörter erscheinen nie. Ist „Ansehen nur mit PIN“ eingestellt, gilt das auch hier.

Netzwerk verwalten – Geräte-Konto „admin“ (Web-App): Unter „Mehr → Gerät → Netzwerk → Netzwerk verwalten …“ (eigene Seite /admin.html) lässt sich das Netz des Pi auch ohne Mac einrichten – die einzige Stelle, an der die Web-App etwas ändert, und nur fürs Netz: Gerätename; je Kabel-Adapter (eingebaut und USB) DHCP oder feste Adresse mit Präfix, Gateway und DNS, VLANs anlegen und entfernen; WLAN: Netze suchen, bekannte Netze hinzufügen, entfernen und ihre Priorität ändern (immer ohne PMF – das WLAN des Pi scheitert sonst an WPA2/WPA3-Mischnetzen); eigenes WLAN: Name, Passwort, Band (automatisch, 5 GHz, 2,4 GHz), Modus (automatisch = wenn kein Netz da ist, immer an, aus – „immer an“ belegt den WLAN-Adapter, dann verbindet er sich mit keinem bekannten WLAN); Neustart.

• Erstes Anmelden: Benutzer admin, Passwort admin – das geht nur im eigenen WLAN des Pi (mit ihm verbinden – den Namen zeigt der Monitor am Pi, das Passwort nennt der Installer am Ende; am Pi auch sudo stagesense-hotspot info –, dann http://10.42.0.1:8470/admin.html) oder am Pi selbst (auch per SSH-Tunnel). Per Kabel direkt, aus dem Show-Netz oder über Tailscale wird das Startpasswort abgelehnt. Danach musst du ein eigenes Passwort festlegen und kannst eine Login-E-Mail eintragen. Ab dann meldest du dich mit admin oder der E-Mail und deinem Passwort an – von überall, wo die Web-App erreichbar ist, auch per Kabel.
• Eigenes Passwort: mindestens 10 Zeichen; abgelehnt werden leicht zu erratende wie 1234567890, Tastaturreihen, „Passwort2026!“, „admin“, „stagesense“ oder der Gerätename mit Ziffern dahinter. Am besten mehrere Wörter, z. B. „Kabeltrommel-Nebel-17“.
• Schutz: Nach 5 falschen Passwörtern ist die Adresse 5 Minuten gesperrt; zusätzlich wartet das Konto selbst – egal von welcher Adresse – erst 30 Sekunden, bei jedem weiteren Fehlversuch doppelt so lange bis 15 Minuten. Fehlversuche im eigenen WLAN zählen getrennt von denen aus dem Netz – Fremde im Show-Netz sperren dich im eigenen WLAN also nicht aus; am Pi selbst gilt keine Wartezeit. Nach 30 Minuten ohne Aktivität (spätestens nach 12 Stunden) bist du abgemeldet, ebenso nach einem Neustart des Dienstes; „Abmelden“ beendet die Sitzung sofort. Passwort ändern geht nur mit dem aktuellen Passwort und meldet andere Sitzungen ab. Jede Anmeldung, jeder Fehlversuch und jede Änderung steht im Ereignisprotokoll – Passwörter nie. Ohne HTTPS (Aufruf per IP im lokalen Netz) gehen Passwörter unverschlüsselt durchs Netz; von unterwegs die Tailscale-HTTPS-Adresse nutzen.
• Jede Änderung gilt 2 Minuten auf Probe: Oben erscheint „Änderung auf Probe“ mit Countdown – „Bestätigen“, wenn die Seite danach noch antwortet, sonst „Zurücknehmen“. Ohne Bestätigung stellt der Pi nach 2 Minuten den alten Stand von selbst wieder her, auch wenn die Verbindung abgerissen ist, der Dienst oder der Pi neu startet, kein Internet da ist oder die Uhr des Pi falsch geht. Während eine Änderung offen ist, geht keine zweite. Betrifft eine Änderung den Adapter, über den du gerade verbunden bist, fragt die Web-App vorher nach.
• Internet von jedem Port: Der Pi prüft jede Minute an jedem Adapter mit Gateway, ob er das Internet erreicht (eine kurze Anfrage an license.stagesense.de, ohne Daten des Pi), und nimmt automatisch den Adapter, über den es wirklich geht – Kabel, VLAN, USB-LAN oder WLAN. Adapter ohne Internet rücken nach hinten; wandert das Internet, dreht sich die Reihenfolge von selbst. Haben mehrere Adapter Internet (oder lässt sich nirgends prüfen), gilt: Kabel vor WLAN vor VLAN. Die Karte Internet oben zeigt, über welchen Adapter es gerade geht, jeder Adapter „Internet: ja / nein / Prüfung nicht möglich / nicht geprüft“ und wer die Default-Route hat (dasselbe unter Gerät → Netzwerk und am Monitor). „Prüfung nicht möglich“ heißt: kein Adapter kommt durch – entweder gibt es kein Internet, oder der Prüfserver ist nicht erreichbar bzw. die Uhr des Pi geht stark falsch (HTTPS). Ein VLAN darf deshalb auch per DHCP oder mit fester Adresse und Gateway angelegt werden. Einen Adapter ausschließen: „Internet über diesen Adapter: nie“; eine feste Adresse ohne Gateway liefert ohnehin nie Internet. Achtung: Ändert eine ältere Mac-App (ohne diese Auswahl) die Adresse eines Adapters, gilt danach wieder „automatisch“. VLANs, die von Hand (nmcli) oder mit anderen Werkzeugen angelegt wurden und ein Gateway haben, stehen mit der NetworkManager-Metrik 400 vor dem WLAN – im Geräte-Konto einmal „Übernehmen“ stellt sie hinter das WLAN (700). Die Prüfung ganz abschalten: Installer mit --no-internet-check. Datenmenge: je Prüfung und Adapter rund 6 KB, also etwa 9 MB am Tag bzw. rund 260 MB im Monat je Adapter mit Gateway – bei Internet über LTE mit knappem Volumen einplanen oder die Prüfung mit --no-internet-check abschalten. Das eigene WLAN hängt nicht an dieser Prüfung.
• Tailscale (Fernzugriff): zeigt, ob Tailscale installiert und angemeldet ist (Name, IP). „Tailscale einrichten“ installiert das Paket (braucht Internet), schaltet es ein und holt einen Anmelde-Link – nur hier sichtbar, nie im Protokoll; Link öffnen, Gerät im eigenen Tailnet bestätigen, die Seite merkt die Anmeldung von selbst. Am Pi geht dasselbe mit sudo stagesense --tailscale (Link im Terminal) – etwa wenn bei der Installation kein Internet da war.
• Kopplung ohne Tastatur am Pi: Karte „Kopplung (StageSense-App)“ → „Kopplungscode erzeugen“ zeigt den Code groß an – dasselbe wie sudo stagesense --pair (10 Minuten, einmal gültig; koppeln geht weiter nur mit einer Lizenz desselben Kunden) –, dazu am Mac den Knopf „Mit StageSense koppeln“, einen QR-Code und die Kennung des Servers; auf iPhone oder iPad steht statt des Knopfs ein Hinweis (siehe Client-Modus einrichten). Die Karte Update spielt Updates auch ohne Mac ein (siehe Updates des Servers). Darunter stehen die gekoppelten Clients mit „entkoppeln“. Höchstens 5 Codes in 10 Minuten je Adresse; jeder Code und jedes Entkoppeln steht im Ereignisprotokoll.
• Passwort vergessen: am Pi (Monitor/Tastatur oder SSH) sudo stagesense --admin-reset – danach gilt wieder admin/admin (nur lokal), alle Sitzungen sind beendet.
• Gekoppelte StageSense-Clients (Mac, Windows) desselben Kunden dürfen dieselben Netzwerk-Funktionen ohne Geräte-Konto nutzen; sie signieren jede Anfrage. Die Fallback-Adresse 169.254.255.1 bleibt immer, was auch eingestellt wird.
• Technik: Der StageSense-Dienst hat selbst keine Netzwerk-Rechte. Er legt nur einen Auftrag ab; ein kleiner root-Dienst (stagesense-netadmin) prüft ihn, sichert vorher den alten Stand und stellt den 2-Minuten-Timer, erst dann ändert er. Eine frühere Sonderregel (polkit), die dem Dienst NetworkManager-Rechte gab, entfernt das Update.

MA-Net-Mitschnitt auf der Platte (Pi 5)

Der Server kann den MA-Net-Verkehr über Stunden oder Showtage als pcap-Dateien (Wireshark) auf seine Platte aufzeichnen – sinnvoll mit NVMe oder einer HDD. Aufgezeichnet wird nur, was der Server ohnehin von den MA-Konsolen empfängt: MA-Net3 (UDP 30020) und MA-Net2 (UDP 29998/29999) auf den Adaptern mit der Rolle MA-Net (oder nur auf einem gewählten, z. B. eth0.201). Andere Ports und anderer Verkehr kommen nicht in die Dateien; StageSense sendet dabei nichts ins MA-Net.

• Starten/Anhalten: am Pi sudo stagesense --manet start bzw. stop, Stand mit sudo stagesense --manet status; im Geräte-Konto (Karte „MA-Net-Mitschnitt“); in der Mac-App im Client-Modus unter Signal & Daten → Netzwerk → MA-Net, Tab Mitschnitt, Zeile „Dauer-Mitschnitt am Server“ aufklappen („Starten“, „Einstellen …“). Ein laufender Mitschnitt läuft nach einem Neustart weiter.
• Ordner: Standard /var/lib/stagesense-manet. Für eine HDD den Ordner einmal vorbereiten, z. B. sudo stagesense --manet ordner /mnt/hdd/manet (nur unter /mnt, /media oder /srv). Ist die Platte unter /mnt bzw. /media nicht eingehängt, startet der Mitschnitt nicht („Platte nicht eingehängt“) – er schriebe sonst auf die SD-Karte bzw. Systemplatte. Die Elternordner müssen root gehören und dürfen für andere nicht beschreibbar sein (kein Link, keine ACL); sonst bricht der Befehl ab.
• Grenzen: je Datei höchstens 500 MB (--manet datei MB), die Platte höchstens zu 80 % voll (--manet grenze PROZENT; auf der Systemplatte nie mehr als 80 %), mindestens 2 GB müssen frei bleiben. Der kurze Mitschnitt aus der Mac-App (Tab Mitschnitt) startet am Server nur mit mindestens 2 GB frei. Wird es mehr, fallen die ältesten Mitschnitte weg; reicht das nicht, hält der Mitschnitt an. Adapter: --manet adapter eth0.201 (alle = alle mit Rolle MA-Net).
• Abholen per SSH: Die Dateien heißen manet-JJJJMMTT-HHMMSS.pcap und sind für die Gruppe stagesense-manet lesbar; wer den Server installiert hat (bzw. der erste Benutzer des Pi), ist darin. Am Mac z. B. scp robin@stagesense:/var/lib/stagesense-manet/manet-*.pcap . – weitere Benutzer: sudo usermod -aG stagesense-manet NAME (ab der nächsten Anmeldung).
• Datenschutz: Die Mitschnitte enthalten den Verkehr der MA-Konsolen (Show- und Pultdaten, Adressen der Stationen), keine Daten anderer Geräte. Sie bleiben auf dem Pi, bis sie jemand abholt oder die Plattengrenze sie löscht; vor der Weitergabe an Dritte mit dem Veranstalter bzw. Pultbetreiber abstimmen und danach löschen (sudo rm /var/lib/stagesense-manet/manet-*.pcap).

Energie-Archiv auf der Platte (Pi 5)

Der Server speichert die Minutenwerte je Messgerät dauerhaft (Grundlage für Verlauf, Lastgang über Tage, CSV und Netzqualität): je Tag und Verteiler eine kleine Textdatei (JJJJ-MM-TT/meter_<ID>.txt, etwa 150 KB je Gerät und Tag). Es wird nur abgelegt, was StageSense ohnehin misst – ins Messgerät wird nie geschrieben.

• Ordner: Standard im Datenordner (/var/lib/stagesense/.local/share/StageSense/Archiv) mit Größengrenze 2000 MB (--archiv groesse MB). Für eine HDD den Ordner einmal vorbereiten: sudo stagesense --archiv ordner /mnt/hdd/archiv – gleiche Prüfungen wie beim MA-Net-Mitschnitt: nur unter /mnt, /media oder /srv mit Unterordner, die Platte muss eingehängt sein, Elternordner root-eigen, kein Link, keine ACL. Der Ordner gehört dem Dienstkonto (0750). Zurück in den Datenordner: sudo stagesense --archiv standard.
• Platte fehlt: Ist die HDD nicht eingehängt, schreibt der Server vorübergehend in den Datenordner (mit Größengrenze) und meldet das unter --archiv status; gelesen wird aus beiden.
• Grenzen: Aufbewahrung Standard 400 Tage (--archiv tage N), immer mindestens 2 GB frei, Platte höchstens 80 % voll (--archiv grenze PROZENT; auf der Systemplatte „/“ nie mehr als 80 %). Darüber fallen die ältesten Tage weg; reicht das nicht, hält das Archiv an und läuft weiter, sobald wieder Platz ist.
• Stand: sudo stagesense --archiv status (Ordner, Platte, Tage, Größe, Hinweise); --archiv aus / an. Der Dienst übernimmt Änderungen binnen 10 s. Im Mac-Client steht der Stand unten im Verlauf.
• Geteilte Platte: Teilt sich das Archiv die HDD mit anderen Daten (z. B. dem MA-Net-Mitschnitt), zählt für die 80 % bzw. 2 GB die ganze Platte – füllen andere Daten sie, löscht das Archiv seine eigenen ältesten Tage, im Extremfall bleibt nur der heutige. Für lange Aufbewahrung das Archiv deshalb auf eine eigene Platte oder Partition legen bzw. die MA-Mitschnitte rechtzeitig abholen und löschen.

Befehle auf dem Pi

Ohne Angabe und unbekannte Optionen: sudo stagesense ohne Angabe startet nichts – der Server läuft als Dienst (Zustand: sudo systemctl status stagesense). Eine unbekannte Option oder ein fehlender Wert (z. B. --import ohne Datei) bricht mit „Unbekannte Option oder fehlender Wert“ und der Hilfe ab (Exit-Code 2) und startet keine zweite Überwachung; sudo stagesense --help zeigt alle Befehle. Für stagesense-bridge gilt dasselbe.

MRG-Verteiler per USB am Server: Die USB-Buchse „NW“ eines connex/MRG-Verteilers (FTDI → Janitza UMG 96) kann direkt am Pi stecken – dann braucht es keine Bridge. Im Client unter Messgeräte ein Gerät mit Vorlage „MRG-Verteiler (USB-Buchse „NW“)“ anlegen, Verbindung RS485/USB, Schnittstelle aus der Liste des Servers wählen: Sie zeigt die festen Namen /dev/serial/by-id/usb-FTDI_…_<Seriennummer> – so bleibt nach dem Umstecken der richtige Verteiler gemeint (nicht ttyUSB0/1, die sich beim Umstecken vertauschen). 921600 Baud, 8N1; ans Messgerät gehen nur Lesefunktionen (03/04). Das Dienstkonto ist in der Gruppe dialout.

SNMP-Agent des Servers: Stellt alle Messgeräte des Servers (USB und Netzwerk) nur lesend per SNMP v1/v2c bereit – mit denselben MIBs wie die Bridge (SNMPv2-MIB system, ENTITY-MIB, ENTITY-SENSOR-MIB): je Messgerät ein Gehäuse mit 16 Sensoren (Spannung, Strom inkl. N, Leistung je Phase und Summe, Frequenz, cos φ, Energie) und „Verbindung“. Eine Zabbix-Vorlage passt damit für Server und Bridge. Werte kommen aus den laufenden Messungen, es wird nichts zusätzlich abgefragt; SET wird abgewiesen, eine falsche Community bleibt unbeantwortet. Standard aus. Einschalten im Mac-Client unter Einstellungen → Server → „SNMP-Agent des Servers“ oder am Pi mit sudo stagesense --snmp on (Community --snmp-community, Standort, Kontakt, Port). Läuft auf demselben Pi auch die Bridge mit SNMP, ist UDP 161 belegt – der Server meldet das als Problem; dann SNMP nur an einem der beiden einschalten oder dem Server einen anderen Port geben (z. B. --snmp-port 1161).

Updates des Servers

Vier Wege, alle nur mit signierten Paketen des Lizenzservers, nur auf neuere Versionen und im Rahmen von „Updates bis“ der Lizenz – nie im Showmodus:

• Am Pi mit Internet: Der Server sieht täglich nach und meldet „Update verfügbar“. Einspielen mit sudo stagesense --update oder im Mac-Client unter Einstellungen → Server → „Am Server laden und einspielen“.
• Übers lokale Netz, ohne Internet am Pi (auch über sein eigenes WLAN 10.42.0.1): im Mac-Client unter Einstellungen → Server → „Update des Servers“ entweder „Aus dem Update-Kanal laden …“ (der Mac lädt mit seinem Internet und dem Lizenz-Token des Servers) oder „Paket wählen …“ – das Paket (.tar.gz) mit seiner Signaturdatei (.json) daneben. Der Mac lädt in Stücken hoch, mit Fortschritt; jede Anfrage ist signiert (gekoppelter Client desselben Kunden). Der Server prüft die Update-Signatur, SHA-256, „nur neuer“ und „Updates bis“ (Build-Datum aus dem Paket).
• Im Geräte-Konto, ohne Mac: Web-App → Mehr → Gerät → Netzwerk → „Netzwerk verwalten …“, Karte Update: „Nachsehen“ fragt den Update-Kanal, „x.y einspielen“ lädt und spielt die angebotene Version ein. Ohne Internet am Pi Paket (.tar.gz) und Signaturdatei (.json) wählen – der Browser lädt in Stücken hoch, mit Fortschritt, und wartet danach auf das Ergebnis (der Dienst startet neu; erscheint „abgemeldet“, die Seite neu laden). Die Karte zeigt installierte Version, Angebot, das Ergebnis des letzten Updates (auch einen Rückfall) und Hinweise zu Showmodus, Lizenz und Testpaketen. Nur nach Anmeldung im Geräte-Konto.
• Von Hand: neues Paket entpacken, sudo ./install.sh.
• Testpakete (für Tester): im Mac-Client unter Einstellungen → Server → Update „Testpaket … (Ordner)“ – einen Ordner wählen (z. B. dist/); StageSense nimmt daraus das neueste passende Paket samt Signaturdatei (richtige Plattform, nur neuer als installiert), lädt es hoch und wartet auf das Ergebnis. Testpakete sind an einzelne Geräte gebunden und gelten nur dort, für die sie signiert wurden; jedes andere Gerät lehnt ab („Testpaket nicht für dieses Gerät“). Die Geräte-ID zeigt sudo stagesense --geraete-id; ohne Anmeldung liefert sie auch die Abfrage http://<IP>:8470/api/v2/identity?challenge=<64 Hex-Zeichen> (Feld device; Sensor: Port 8480).

Eingespielt wird in allen Fällen von einem eigenen root-Dienst, der alles noch einmal prüft; startet die neue Version nicht innerhalb von 60 Sekunden stabil, schaltet er auf die vorige (/opt/stagesense.prev) zurück. Nach einem Rückfall liegt in /opt/stagesense.prev die Version vor der wieder aktiven – ein weiterer Fehlschlag fällt also nicht auf eine kaputte Version zurück. Reicht der Platz für die Sicherung der laufenden Version nicht (frei mindestens ihre Größe plus 50 MB), spielt der Dienst nichts ein und meldet „Zu wenig Platz für die Sicherung der laufenden Version … – nichts geändert“. Das Ergebnis steht im Mac-Client und im Protokoll (journalctl -u stagesense-update).

Meldung „Server-Update“: Schlägt ein Update fehl oder schaltet der Server auf die vorige Version zurück, steht das Problem „Server-Update“ (Hoch, mit Push) in der Liste – „Update auf … fehlgeschlagen – …“. Es endet mit dem nächsten gelungenen Update („Update auf … installiert“). Ein gelungenes Update steht sonst nur als Info im Protokoll („Server-Update auf … installiert“).

Was du nach dem Update siehst: Der Dienst startet dabei neu – die Verbindung zum Mac und zur Web-App ist kurz weg. Nach etwa 1–2 Minuten zeigt die Mac-App unter Einstellungen → Server das Ergebnis: „Update auf StageSense … eingespielt“ bzw., wenn die neue Version nicht stabil startete, den Grund mit „vorherige Version wieder aktiv“ (Rückfall). Ein weiterer Neustart ist dafür nicht nötig.

Server-Ansicht am Mac

Unter Einstellungen → Server die Adresse des Servers eintragen (z. B. stagesense.local oder seine Tailscale-Adresse; ohne Angabe gilt Port 8470) und „Verbindung prüfen“ – StageSense zeigt Name, Version und Lizenz des Servers. Ist dort eine PIN gesetzt, mit ihr anmelden: Gemerkt wird nur die Sitzung (30 Tage) im Schlüsselbund, nie die PIN. Server-Ansicht öffnen – oder der Knopf Server in der Werkzeugleiste, sobald eine Adresse eingetragen ist – zeigt die Web-App des Servers in einem eigenen Fenster, oben umschaltbar zwischen Web-App (alle Bereiche), FOH-Ansicht und Gesamtübersicht mit den DC-Seiten. Die Mac-App überwacht daneben weiter selbst: Laufen Mac und Server gleichzeitig, kommen Push-Meldungen doppelt – dann an einem der beiden „Alarme als Web-Push senden“ ausschalten. Geänderte Einstellungen kommen vorerst per Export und Import auf den Server. Am besten die Tailscale-Adresse des Pi eintragen – dann ist die Verbindung verschlüsselt und klappt auch von unterwegs.

Die Server-Ansicht zeigt die Web-App des Servers – im Client-Modus als Rückfall nützlich (siehe Kapitel Client-Modus).

Zeitserver fürs Show-Netz

Viele Pulte, Processing Units und Nodes haben keine Zeitquelle und laufen mit der Zeit Minuten bis Jahre auseinander – Zeitstempel in Protokollen lassen sich dann nicht mehr vergleichen. sudo /opt/stagesense/install.sh --ntp-server richtet auf dem Pi zusätzlich einen Zeitserver (chrony) ein; voreingestellt ist er aus. Er beantwortet nur Anfragen aus privaten Netzen (10/8, 172.16/12, 192.168/16, 2/8) und sendet selbst nichts ins Show-Netz; auch ohne Internet gibt er die Uhrzeit des Pi weiter (darum die RTC-Batterie). Danach an den Geräten, die NTP können, die IP des Pi im jeweiligen VLAN als Zeitserver eintragen.

Uhr ohne Internet

Ein Pi ohne Internet und ohne RTC-Batterie startet mit einer alten Uhrzeit (z. B. dem Datum des Abbilds). Gekoppelte Macs signieren ihre Anfragen mit der Uhrzeit und der Server lässt nur 2 Minuten Abweichung zu – deshalb stellt StageSense die Uhr in diesem Fall selbst, nur solange sie nicht per Zeitserver (NTP) synchronisiert ist:

• Vom Lizenzserver: Bekommt der Pi eine Freischaltung (Aktivieren, Online-Bestätigung – auch über Handy oder Mac weitergereicht), gilt deren Ausstellungszeit, wenn die eigene Uhr nachgeht.
• Vom gekoppelten Mac: Lehnt der Server eine Anfrage wegen der Uhrzeit ab, gleicht der Mac sie einmal automatisch ab (Einmal-Code des Servers, Anfrage vom Mac unterschrieben) und schickt die Anfrage noch einmal. Das klappt auch beim Koppeln. Geht danach etwas noch nicht, meldet der Mac, dass seine eigene Uhr falsch geht oder der Server per Zeitserver synchronisiert ist.
• Das gilt genauso für die Bridge.
• Zurückstellen lässt sich die Uhr so nie vor die letzte sichere Zeit (Lizenzserver bzw. Zeitserver plus die seither gelaufene Betriebszeit), nach vorn nur bis kurz nach der Frist der Online-Bestätigung. Ein Mac mit richtiger Uhr stellt eine falsch gestellte Uhr jederzeit zurück.
• Liegt die übernommene Zeit weit (mehr als 1 Tag) nach der letzten sicheren Zeit, warnen Web-App, Bildschirm und Statusseite („Uhr des Macs prüfen“). Sitzt eine falsche Zeit fest: sudo stagesense --uhr-zuruecksetzen (Bridge: sudo stagesense-bridge --uhr-zuruecksetzen).
• Wird die Online-Bestätigung erst durch das Vorstellen der Uhr überfällig, läuft die Lizenz noch 24 Stunden weiter (Hinweis „Online-Bestätigung überfällig … noch bis“) – Zeit, sie über Handy oder Mac zu bestätigen.
• Web-App (Verbindung → Uhr), Bildschirm am Pi und Statusseite der Bridge zeigen „Uhr nicht synchronisiert“ bzw. „vom Lizenzserver/gekoppelten Client übernommen“. Jede Änderung steht im Protokoll (journalctl -u stagesense).
• Am besten bleibt trotzdem: Zeitserver im Show-Netz (siehe „Zeitserver fürs Show-Netz“) oder eine RTC-Batterie im Pi 5.

Tipps

• Getaggte VLANs: Gehen an einem USB-Netzwerkadapter große getaggte Pakete verloren (Telnet-Mitschnitt hängt, Seiten laden halb), die MTU des VLANs senken, z. B. sudo nmcli con mod vlan201 802-3-ethernet.mtu 1496.
• Mitschnitt und Ping brauchen besondere Netzwerkrechte; das Installationsskript richtet sie für das Dienstkonto ein. --check zeigt, ob sie da sind. Außerdem hebt es zwei Grenzen des Linux-Systems an (Zahl der Multicast-Gruppen je Empfänger, Empfangspuffer), damit alle sACN-Universen und MA-Net auf allen VLANs ankommen.
• Ändert sich am Mac etwas an Geräten oder Alarmen, erneut exportieren und auf dem Pi importieren – oder den Mac im Client-Modus nutzen, dann gelten Änderungen gleich auf dem Server.
• Zeitzone: Alle Uhrzeiten (Protokolle, MA-Tagesprotokolle, Push) folgen der Zeitzone des Pi. Ohne Einstellung im Imager steht Raspberry Pi OS auf London; stagesense --check und das Installationsskript weisen darauf hin. Umstellen mit sudo timedatectl set-timezone Europe/Berlin.
• USV per USB: sudo ./install.sh --nut installiert NUT, erkennt die USB-USV und richtet sie nur für den Pi selbst ein. StageSense zeigt Akku und Laufzeit; bei leerem Akku fährt der Pi geordnet herunter. Ohne angeschlossene USV gibt es nur einen Hinweis.

Client-Modus (Mac steuert den Server)

Ist ein StageSense-Server (Raspberry Pi) im Einsatz, überwacht nur er. Die Mac-App wird dann zum Client: dieselbe Oberfläche, aber Zustand, Einstellungen und Knöpfe gehören dem Server. Der Mac überwacht in dieser Betriebsart nichts selbst und sendet nichts ins Show-Netz – keine doppelten Abfragen, keine doppelten Meldungen.

Client-Modus einrichten

1. Kopplungscode holen: im Geräte-Konto des Servers (Web-App → Mehr → Gerät → Netzwerk → „Netzwerk verwalten …“, Karte „Kopplung (StageSense-App)“) „Kopplungscode erzeugen“ – oder auf dem Pi sudo stagesense --pair. Der Kopplungscode (6 Ziffern) gilt 10 Minuten und einmal.
2. Am Mac koppeln – einer von drei Wegen; StageSense prüft dabei immer zuerst die Kennung des Servers (siehe „Fenster Koppeln“):
   • Ist das Geräte-Konto am Mac im Browser offen: Knopf „Mit StageSense koppeln“ – er öffnet das Fenster „Koppeln“ der Mac-App.
   • „QR-Code scannen …“ in der Mac-App (Einstellungen → Server → „Geräte in der Nähe“ oben rechts oder im Fenster „Koppeln“) und den QR-Code aus dem Geräte-Konto – etwa auf iPhone oder iPad angezeigt – vor die Kamera halten (eingebaute Kamera, iPhone als Continuity Camera oder angeschlossene Kamera). StageSense erkennt ihn selbst.
   • Einstellungen (⌘,) → Server → Geräte in der Nähe → beim Server „Koppeln …“ und den Code eintippen. Oder die Adresse des Pi unter Einstellungen → Server eintragen – am besten den Tailscale-Namen (z. B. stagesense) oder die 100.x-Adresse (tailscale ip -4 auf dem Pi), dann ist die Verbindung verschlüsselt und klappt auch von unterwegs – und im Abschnitt Client-Modus den Code eingeben → „Koppeln“.

   Den Zugang merkt sich der Mac im Schlüsselbund. Die PIN der Web-App ersetzt den Code nicht.

3. Menü Betriebsart → Client – nur den Server fernsteuern … wählen und bestätigen – oder unter Einstellungen → Server „Diesen Mac als Client des Servers nutzen“ einschalten und „StageSense neu starten“. StageSense startet neu und ist danach Client. Unten in der Seitenleiste steht „Client · verbunden mit <Server>“ (grün) oder „Client · keine Verbindung“ (orange – erst, wenn der Server dreimal in Folge bzw. 5 s lang nicht antwortet; ein einzelner Aussetzer ändert die Anzeige nicht); ein Klick öffnet Einstellungen → Server mit Verbindung, letztem Abgleich und Fehlern.

Fenster „Koppeln“ (für alle Wege gleich): Beim Öffnen prüft StageSense beim Gerät die Kennung – grün „bestätigt“, rot „andere Kennung“ (dann ist Koppeln nicht möglich), orange „antwortet nicht“. Nach einem gescannten QR-Code bzw. einem Link aus einer anderen App steht ein Hinweis da („Per QR-Code gescannt – nur koppeln, wenn der Code eben im Geräte-Konto dieses Geräts angezeigt wird“ bzw. „Link aus einer anderen App – nur koppeln, wenn du ihn eben selbst im Geräte-Konto dieses Geräts geöffnet hast“). Andere QR-Codes (WLAN, Webseiten) übergeht StageSense mit einem Hinweis; gehört ein Code zu einem anderen Gerät als dem im Fenster, steht dort „QR-Code gehört zu einem anderen Gerät“. Würde das Koppeln einen anderen eingestellten Server ersetzen, muss „Bisherigen Server ersetzen“ eigens eingeschaltet werden; schlägt das Koppeln fehl, bleibt alles beim bisherigen Server.

Geräte in der Nähe: Server und Sensoren melden sich im Netz per Bonjour (Name = Hostname des Pi). Einstellungen → Server bzw. Bridges → „Geräte in der Nähe“ listet alle, die der Mac findet – per Bonjour, über die Fallback-Adressen 169.254.255.1/.2 (Kabel direkt) und im eigenen Tailnet. Jedes Gerät muss seine Kennung beweisen und steht nur einmal da, auch wenn es über mehrere Wege erreichbar ist: Name, Art, Build, Wege, Kennung und ob der Mac schon gekoppelt ist. Ältere Geräte ohne Kennung stehen als „älterer Stand – Update nötig“ da.

Kamera und Datenschutz: Die Kamera startet erst nach dem Klick auf „QR-Code scannen …“ und läuft nur, solange das Fenster offen ist; genutzt wird sie nur für den Kopplungs-QR-Code, Bilder werden nicht gespeichert. Beim ersten Mal fragt macOS nach dem Kamerazugriff; ohne Zugriff weist StageSense auf Systemeinstellungen → Datenschutz & Sicherheit → Kamera hin.

Kopplung gilt für den Server, nicht für die Adresse: Beim Koppeln merkt sich der Mac die Kennung des Servers (seinen Geräteschlüssel). Wechselt die Adresse – z. B. von der LAN-Adresse zur Tailscale-Adresse –, bleibt der Mac gekoppelt: Bevor er seinen Zugang schickt, muss der Server unter der neuen Adresse seine Kennung beweisen (signierte Antwort auf eine Zufallszahl). Antwortet dort ein anderes Gerät, geht der Zugang nicht raus, und Einstellungen → Server meldet „Unter dieser Adresse antwortet ein anderer Server …“. Dort steht auch, womit der Mac gekoppelt ist: „Gekoppelt mit <Name> (Kennung …)“. Kopplungen von früher (an die Adresse gebunden) übernimmt der Mac beim ersten Verbinden von selbst; ältere Server ohne Kennung bleiben wie bisher an die Adresse gebunden.

Lizenz und Sicherheit: Koppeln und alles, was der Client auf dem Server ändert oder auslöst, verlangt eine eigene Lizenz des Macs vom selben Kunden wie die Lizenz des Servers – beide einmal online bestätigt. Jede solche Anfrage unterschreibt der Mac mit seinem Geräteschlüssel (bleibt im Schlüsselbund); der Server prüft Lizenz, Kunde, Gerät, Unterschrift und Uhrzeit und lehnt sonst ab. Auch zum Ansehen braucht der Mac eine eigene Lizenz: Ein Client ohne eigenen Schlüssel zeigt keine Live-Daten, sondern oben „Client-Modus – dieser Mac braucht einen eigenen Lizenzschlüssel (Beta/Vorführung kostenlos), sonst keine Live-Daten vom Server.“ mit dem Knopf „Lizenzschlüssel eingeben …“. Ohne gültige Lizenz auf dem Server zeigt der Client das an (auf dem Server: sudo stagesense --license).

Was im Client geht

• Strom: Messgeräte mit Live-Werten, Verlauf (beim Verbinden die letzten 15 Minuten vom Server, danach laufend), Alarmen und Unterzählern, Anschlüsse, Stromplan; Verbinden und Trennen, Min/Max, CSV-Aufzeichnung (die Datei entsteht auf dem Server und kommt beim Stoppen in den Downloads-Ordner des Macs). Einen Unterzähler mit Start in der Vergangenheit rechnet der Server aus dem Gerätespeicher nach.
• Netzwerk und Licht: Geräte, Switche, Universen, Nodes, StageSmarts, Dienste, NDI, Luminex, Timecode; RDM läuft über den Server. Der DMX-Monitor (Licht → DMX) zeigt die Werte des Servers – etwa viermal pro Sekunde, solange die Ansicht offen ist; ist StageSense im Hintergrund, pausiert er („Pausiert“), ältere Server melden „Update nötig“.
• Probleme und Alarme mit Bestätigen und Wartung, Showmodus, Einsätze (Bericht als PDF am Mac), Standorte und Hallenplan, Dashboards, Showprofile, Push-Einstellungen.
• Mitteilungen am Mac: Alarme, Warnungen und Behobenes des Servers zeigt der Mac als macOS-Mitteilung, wie per Push („🔴 Alarm – Gerät“ …) – nur neue, nicht nachträglich beim Verbinden; höchstens 5 einzeln, der Rest in einer Sammel-Mitteilung („… weitere Meldungen vom Server“); still im Showmodus des Servers. Schalter „Meldungen des Servers als Mitteilung an diesem Mac“ unter Einstellungen → Server (ab Werk an). Die Web-App auf demselben Mac bekommt dann keinen Web-Push dazu.
• Patch und DMX-Test: Änderungen gehen an den Server; Hell machen, Lauflicht und Test-Cue sendet der Server – nur auf Knopfdruck.
• MA: System Monitor je Pult ein- und ausschalten, MA-Protokoll mit Filtern, Statistik, Showfile-Sicherungen, Bediener-Übersicht und FOH-Leaderboard – alles vom Server (Uhrzeiten nach Empfang am Server). „Leeren“ und „Zurücksetzen …“ wirken dort; „Tagesprotokolle laden …“ holt die Tagesprotokolle der letzten 14 Tage in den Downloads-Ordner („StageSense MA-Protokoll (Server)“).
• Werkzeuge: Geräte-Suche, Konsolen-Check, Geräte- und Messgerät-Test und SNMP-Abzug laufen auf dem Server – der Mac zeigt nur das Ergebnis. Die Geräte-Suche erscheint in der Seitenleiste, sobald der Server sie anbietet; „Beim Start nach Geräten suchen“ (ab Werk aus) gilt dann für den Server.
• Dienste: „Ordner hinzufügen …“ (Sicherungsordner) zeigt Ordner auf dem Server – den Datenordner sowie /media, /mnt, /run/media und /srv. „Showfiles → Sicherungsordner“ prüft dort, „Jetzt prüfen“ beim Zeitserver fragt über den Server ab.
• Web-App des Servers: Einstellungen → Web-App zeigt und ändert die Web-App des Servers – Adressen und QR-Code, Zugang aus dem LAN, PIN fürs Ansehen (neue PIN eingeben und „Setzen“, „Entfernen“), alle abmelden, Push-Geräte, HTTPS über „tailscale serve“ auf dem Pi. Port und „eingeschaltet“ lassen sich nur am Server ändern, damit sich der Client nicht selbst aussperrt.
• Lizenz: Einstellungen → Lizenz zeigt oben die Lizenz des Servers; dort lässt sich auch ein Schlüssel für den Server aktivieren – hat der Server kein Internet, „Über diesen Mac aktivieren“ bzw. „Über diesen Mac bestätigen“.
• Zurücksetzen & Sicherung: Bereiche des Servers einzeln zurücksetzen – der Server sichert vorher, die Meldung nennt die Sicherung – und Live-Daten leeren. Die Sicherungen des Servers stehen als Liste da; „Wiederherstellen …“ spielt eine davon ein, „Löschen“ entfernt eine. „Alles zurücksetzen“ stellt den Werkszustand des Servers her – Lizenz und gekoppelte Macs bleiben, damit der Client verbunden bleibt. Bei „Web-App & Push“, „Alles zurücksetzen“ und „Wiederherstellen“ startet der Server neu (ca. 10 s), danach verbindet der Mac von selbst wieder.
• Adapter des Servers: Das Adapter-Fenster zeigt die Adapter des Pi; „Pi-Netzwerk verwalten …“ hat drei Reiter. Adapter: VLANs anlegen und entfernen, IP (fest oder DHCP) und MTU ändern; bei fester Adresse auch ein Gateway (ebenso für VLANs) und „Internet über diesen Adapter: automatisch / nie“. Oben steht „Internet gerade über …“, je Adapter „Internet: ja / nein / nicht geprüft“ (Internet-Prüfung von NetworkManager). Ältere Server kennen die Internet-Einstellung noch nicht – dort ist sie ausgegraut („Update nötig“). WLAN: bekannte Netze mit Priorität (hinzufügen, Priorität ändern, entfernen; „Netze suchen“ zeigt die WLANs in Reichweite des Pi, ein Klick übernimmt den Namen) und das eigene WLAN (Name, Passwort, Band, automatisch/immer an/aus). Gerät: Gerätename, Kopplungscode erzeugen, gekoppelte Clients entkoppeln (der eigene Mac ist markiert), Tailscale (Stand mit Name und Tailscale-Adresse; „Tailscale einrichten“ installiert und meldet an – den Anmelde-Link im Browser öffnen und das Gerät im eigenen Tailnet bestätigen, braucht Internet am Pi) und Neustart. Jede Änderung im Countdown bestätigen, sonst nimmt der Server sie nach 2 Minuten zurück – auch wenn er in der Zeit neu startet („Rückgängig“ sofort). Ist der Mac per WLAN mit dem Pi verbunden, weist das Fenster darauf hin, dass WLAN-Änderungen die Verbindung trennen können. Ältere Server zeigen nur die Adapter. Der Server ändert über seinen root-Helfer (wie „Netzwerk verwalten“ in der Web-App). Tailscale und Adapter, die NetworkManager nicht verwaltet, sind gesperrt. Ab Server-Version mit Adapterverwaltung – bei älteren Servern fehlt der Knopf.
• Einstellungen gelten für den Server. Zugangsdaten (z. B. Push-Tokens) zeigt der Client nicht – dort steht „gesetzt – leer lassen für unverändert“. Die eigenen Einstellungen des Macs bleiben unberührt und gelten wieder im Eigenständig-Betrieb.

Was im Client nicht geht

• Was der Mac selbst ins Show-Netz senden würde, bleibt gesperrt, z. B. die Einrichtung der USB-Brücke übers Netz. Funktionen, die ein älterer Server noch nicht kennt, sind ausgegraut mit dem Hinweis „Update nötig“.
• Die Simulatoren sind ausgeblendet (auch in der Schnellsuche).
• Der MA-Net-Mitschnitt (Tab Mitschnitt) läuft am Server – den MA-Net-Verkehr hört nur er: Start, Restzeit, „Gefundene Texte“ und Stoppen wie gewohnt; danach holt der Mac .pcap und .txt in seinen Ordner MA-Mitschnitte („Im Finder zeigen“). Der Dauer-Mitschnitt auf der Platte des Servers steht eingeklappt darunter.
• Sicherungen des Macs und „Für Server exportieren“ sind ausgeblendet (die Sicherungen des Servers stehen an ihrer Stelle, siehe oben). Auf dem Server selbst: sudo stagesense --backups, --restore NAME, --export.
• Den Gerätespeicher eines Messgeräts (Reiter „Speicher“) gibt es im Client nicht.
• Pult-Diagnose, Boot-Stick und MA3-Export auf USB arbeiten weiter mit Dateien und USB-Sticks am Mac selbst.

Zurück zum Eigenständig-Betrieb

Menü Betriebsart → Eigenständig – dieser Mac überwacht selbst wählen und bestätigen: StageSense startet neu und überwacht wieder mit den eigenen Einstellungen. Läuft der Server weiter, überwachen danach beide – mit doppelten Meldungen.

StageSense Bridge (Raspberry Pi 4)

Die StageSense Bridge macht MRG/connex-Verteiler über USB im Netz lesbar: Ein Raspberry Pi 4 liest jeden Verteiler über dessen USB-Buchse „NW“ (FTDI → Janitza UMG 96, Modbus RTU 921600 Baud 8N1) und gibt ihn als Modbus TCP weiter – an die Mac-App und den StageSense-Server gleichzeitig.

• Nur lesend: An das Messgerät gehen ausschließlich die Funktionen 03/04; alles andere beantwortet die Bridge selbst mit Fehler 01. Die Verteiler sind Mietgeräte.
• Ein Port je Verteiler ab 502. Die Zuordnung hängt an der Seriennummer des FTDI im Verteiler – nach dem Umstecken behält derselbe Verteiler seinen Port. Ein abgezogener Verteiler antwortet mit Modbus-Fehler 0B („Gerät antwortet nicht“).
• Statusseite unter http://<IP der Bridge>:8480 (Verteiler, Port, Messwerte, Fehler; JSON unter /api/status, dort auch die Auslastung des Pi – der StageSense-Server zeigt sie als Kachel „Sensor“ mit denselben Problemen wie beim Server). Die Bridge kündigt ihre Statusseite per Bonjour an (_stagesense-bridge._tcp, ab Bridge 20, auch ohne angeschlossenen Verteiler): Ein Server im selben Netz zeigt sie dann als Sensor, ohne dass vorher ein Messgerät angelegt sein muss. Hat sie noch kein Messgerät, steht in der Kachel „Noch kein Verteiler eingebunden“ – in der Mac-App (Übersicht → Auslastung) legt „Messgerät anlegen“ für jeden angeschlossenen Verteiler ein Messgerät an (Vorlage „StageSense USB-Brücke“, Port je Verteiler). Ältere Bridges findet der Server nur, solange ein Verteiler angeschlossen ist.

Immer erreichbar – Fallback-Adresse 169.254.255.2: Die Bridge hat am Netzwerkanschluss (ungetaggt) zusätzlich immer die feste Adresse 169.254.255.2 – egal ob DHCP fehlt, die VLANs falsch eingerichtet sind oder Tailscale nicht läuft. Der StageSense-Server hat 169.254.255.1; beide gehen nebeneinander im selben Netz. Wie beim Server steht sie als zusätzliche Adresse im NetworkManager-Profil des Anschlusses (DHCP läuft daneben weiter); stagesense-fallback-ip prüft das alle 5 Sekunden und geht dabei genauso vor (siehe Server). Abschalten mit sudo ./install-bridge.sh --no-fallback, wieder an mit --fallback. So kommst du immer dran: Mac per Kabel direkt an den Pi (oder in ein Netz ohne DHCP), warten, bis der Mac sich selbst eine Adresse 169.254.x.x gibt, dann http://169.254.255.2:8480 (Statusseite) oder ssh <benutzer>@169.254.255.2. Hat der Mac-Adapter eine feste Adresse, erreicht er die Fallback-Adresse nicht – dann den Adapter kurz auf DHCP stellen. Läuft auf demselben Pi auch der StageSense-Server, gilt dessen Adresse 169.254.255.1 (die Bridge überschreibt sie nicht); die Statusseite ist dann unter http://169.254.255.1:8480 erreichbar. Adressen aus 169.254.255.x vergibt kein Gerät selbst – keine Konflikte.

Eigenes WLAN als Notzugang: Wie beim StageSense-Server macht auch die Bridge ein eigenes WLAN auf, wenn sie 45 Sekunden lang keine echte Netzverbindung hat (keine Adresse per DHCP, keine feste IP/VLAN, kein bekanntes WLAN) – auch mit Kabel an einem Port ohne Netz. Name und Passwort nennt der Installer am Ende; sie stehen in /etc/default/stagesense-hotspot (nur root). Verbinden, dann http://10.42.0.1:8480 (Statusseite) oder ssh <benutzer>@10.42.0.1. Sobald eine echte Verbindung steht, geht es sofort aus; ist niemand verbunden, alle 5 Minuten kurz aus (bekannte WLANs dürfen sich verbinden). Abschalten: sudo ./install-bridge.sh --no-hotspot, wieder an mit --hotspot. Laufen Server und Bridge auf demselben Pi, gibt es nur ein gemeinsames WLAN. Band wie beim Server: Pi 5 auf 5 GHz, sonst 2,4 GHz; umstellen mit HOTSPOT_BAND=a/bg in /etc/default/stagesense-hotspot.

Bekannte WLANs (WPA2/WPA3-Übergangsmodus): Der WLAN-Chip von Pi 4 und Pi 5 scheitert an WPA3 (SAE) – an einem WLAN im WPA2/WPA3-Übergangsmodus verbindet er sich dann gar nicht („TX Auth frame operation is timedout“ im Systemprotokoll). Server und Bridge schalten deshalb bei allen bekannten WLANs mit WPA2-Passwort das Management-Frame-Schutzverfahren (PMF) aus, dann nimmt der Pi WPA2. Das gilt auch für WLANs aus dem Imager, aus cloud-init oder von Hand angelegte (Dienst stagesense-wlan-pmf, bei jeder Änderung der WLAN-Profile). Reine WPA3-Netze bleiben unverändert – mit ihnen kann sich der Pi aber ohnehin nicht verbinden.

Netzwerk verwalten – Geräte-Konto „admin“ (Statusseite): Unter http://<IP der Bridge>:8480/admin (Link unten auf der Statusseite) gibt es dieselbe Seite wie beim StageSense-Server (siehe dort): Gerätename, Kabel-Adapter (DHCP/fest, Gateway, DNS, VLAN, Internet je Adapter), WLAN (suchen, bekannte Netze, Priorität), eigenes WLAN, Kopplungscode und gekoppelte Clients, Neustart. Erstes Anmelden mit admin/admin nur im eigenen WLAN (http://10.42.0.1:8480/admin) oder am Pi, danach eigenes Passwort (dann auch per Kabel, http://169.254.255.2:8480/admin); jede Netzwerk-Änderung 2 Minuten auf Probe. Passwort vergessen: sudo stagesense-bridge --admin-reset. Tailscale nachrüsten: dort „Tailscale einrichten“ oder sudo stagesense-bridge --tailscale. Läuft auf demselben Pi auch der StageSense-Server, verwaltet dessen Geräte-Konto das Netz (ein Konto je Pi) – die Seite der Bridge verweist dann auf die Web-App des Servers.

Übersicht auf dem angeschlossenen Monitor: Hängt am Pi der Bridge ein Monitor (HDMI), zeigt er statt der Anmeldung eine Übersicht (Dienst stagesense-bridge-bildschirm, tty1, alle 3 Sekunden neu): Version und Uhrzeit, Lizenz-Hinweis (falls die Bridge eine eigene Lizenz braucht und sie fehlt), Zugang (Statusseite im Netz, Kabel direkt über die Fallback-Adresse 169.254.255.2, eigenes WLAN mit Name und Zustand, Tailscale, Internet über welchen Adapter), Modbus-Port und ob SNMP an ist, je Verteiler Zustand (online, angeschlossen ohne aktuelle Werte, nicht angeschlossen mit letztem Fehler) und Spannung, Strom und Leistung je Phase mit Summe und Frequenz, dazu die Auslastung des Pi (CPU, Temperatur, Speicher, Drosselung). Zugangsdaten zeigt sie nie. Anmelden: Alt+F2 (tty2), Alt+F1 zurück – oder per SSH. Abschalten: sudo ./install-bridge.sh --no-bildschirm (bleibt auch bei Updates aus), wieder an mit --bildschirm. Laufen Server und Bridge auf demselben Pi, zeigt der Monitor die Übersicht des Servers. Ausprobieren im Terminal: sudo -u stagesense-bridge stagesense-bridge --bildschirm (Ende mit Strg+C).

Hardware und Erde

• Raspberry Pi 4 (2 GB reichen) mit Raspberry Pi OS Lite (64-bit) und offiziellem Netzteil; je Verteiler ein USB-Kabel an die Buchse „NW“ (bis 3 Verteiler, mehr über einen aktiven USB-Hub); Netzwerkkabel ins Strom-VLAN bzw. das Netz, in dem StageSense die Messgeräte erreicht. Ab Bridge 18 – die Bridges bis 17 starten auf dem Pi 4 nicht (Absturz beim Start, „Illegal instruction“, Dienst startet ständig neu), auf dem Pi 5 schon.
• Erde: Nur Verteiler mit derselben Erde an einen Pi hängen – kaskadierte Unterverteilungen derselben Einspeisung sind in Ordnung. Verteiler aus getrennten Einspeisungen oder Aggregaten nicht an denselben Pi, sonst je Verteiler einen galvanisch getrennten USB-Isolator (z. B. ADuM4160, Full Speed reicht) dazwischen. Den Pi aus einer der angeschlossenen Unterverteilungen versorgen.

Bridge einrichten

1. Raspberry Pi Imager → „Raspberry Pi OS Lite (64-bit)“; Hostname (z. B. ss-bridge), Benutzer, SSH und Zeitzone Europe/Berlin einstellen. Feste IP oder DHCP-Reservierung empfohlen.
2. Paket auf den Pi kopieren, entpacken und im Paketordner sudo ./install-bridge.sh aufrufen (--tailscale installiert zusätzlich Tailscale für den Fernzugriff; auf die Anmeldung wartet der Installer höchstens 60 s, später sudo stagesense-bridge --tailscale, bis 300 s). Die Bridge läuft danach als Dienst und startet bei jedem Einschalten.
3. Sensor-Lizenz eintragen: sudo stagesense-bridge --license SS-XXXX-XXXX-XXXX-XXXX (braucht kurz Internet) – oder einmalig auf der Statusseite http://<IP>:8480 unter „Erste Lizenz eintragen“. Die Bridge braucht eine eigene Sensor-Lizenz desselben Kunden wie Server und Clients (eine Bridge-Lizenz ist in jeder PC-Lizenz enthalten, siehe Lizenz); sie ist an diesen Pi gebunden (Geräteschlüssel /var/lib/stagesense-bridge/device.key). Ohne gültige Lizenz gibt die Bridge nichts weiter: Modbus TCP antwortet mit Fehler 0B, SNMP schweigt, die Messgeräte werden nicht abgefragt, die Statusseite zeigt „Lizenz fehlt“. Über die Statusseite geht nur die allererste Lizenz – danach nur noch am Pi oder von einem gekoppelten Client (Sicherheitskonzept, Regel 3). Die Bridge bestätigt die Lizenz selbst online, sobald sie Internet hat; ohne Bestätigung länger als die Offline-Frist der Lizenz (plus ein Tag) geht sie aus wie eine abgelaufene. Bridge ohne Internet: Handy oder Laptop (mit Internet, z. B. Mobilfunk) mit dem Netz der Bridge verbinden, Statusseite öffnen und „Über dieses Gerät aktivieren“ wählen (erste Lizenz) bzw. „Über dieses Gerät bestätigen“, wenn die Online-Bestätigung fällig ist. Die Bridge signiert die Anfrage selbst; das Handy reicht sie nur weiter und bringt die Antwort zurück – gespeichert wird nur eine Lizenz, die zu genau dieser Bridge gehört. Geht die Uhr der Bridge falsch (ohne RTC-Batterie und Internet), nimmt sie für die Anfrage die Uhr des Handys. Die Antwort muss innerhalb von 10 Minuten zurückkommen, sonst den Knopf noch einmal drücken. Vor dem Aktivieren fragt die Statusseite nach, weil der Schlüssel dabei über das Handy an den Lizenzserver geht (beim Bestätigen nur die Lizenz-Nummer). Klappt es nicht, bleiben Grund und Tipps stehen (z. B. mobile Daten am Handy einschalten).
4. Verteiler einstecken – nach spätestens 5 s hat jeder seinen Port. sudo stagesense-bridge --list zeigt Verteiler, Port und Zustand; sudo stagesense-bridge --name 502 "Verteiler FOH" vergibt einen Namen (Port oder Seriennummer).

Verwaltung vom Client: Namen, SNMP-Einstellungen und Kopplungen lassen sich auch von einem gekoppelten Mac- oder Windows-Client desselben Kunden ändern (Port 8480, /api/v2). Koppeln: im Geräte-Konto der Bridge „Kopplungscode erzeugen“ – mit „Mit StageSense koppeln“, QR-Code oder Code wie beim Server (siehe Client-Modus einrichten; am Mac unter Einstellungen → Bridges → „Geräte in der Nähe“) – oder an der Bridge sudo stagesense-bridge --pair (Code 10 Minuten, einmal gültig) und am Client Adresse und Code eingeben. Die Kopplung gilt für die Bridge selbst, nicht für ihre Adresse: Über „Adresse ändern …“ (Mac: Einstellungen → Bridges) bekommt die Bridge eine neue Adresse, und unter der neuen Adresse muss sie zuerst ihre Kennung beweisen, bevor der Mac seinen Zugang schickt. Ältere Bridges ohne Kennung bleiben an die Adresse gebunden und brauchen dort eine neue Kopplung. Lesen braucht die Kopplung, jede Änderung zusätzlich die Signatur mit der eigenen Lizenz des Clients – Statusseite, Modbus TCP und SNMP bleiben nur lesend. sudo stagesense-bridge --clients zeigt die Kopplungen, --unpair ID (oder all) entfernt sie. Das Lizenz-Token der Bridge, das die Mac-App für Updates über den Mac braucht, gibt die Bridge nur an gekoppelte Clients mit signierter Anfrage heraus – nicht an die Browser-Sitzung des Geräte-Kontos.

In StageSense

Die Bridge kündigt jeden angeschlossenen Verteiler per Bonjour an (mit Name und Port). Die Geräte-Suche der Mac-App findet sie und legt sie automatisch an (Vorlage „StageSense USB-Brücke“ mit Leseschutz). Von Hand: Messgerät „StageSense USB-Brücke“, Modbus TCP, IP der Bridge, Port laut --list. Auf den StageSense-Server kommen die Verteiler wie alle Geräte per Export aus der Mac-App.

Updates der Bridge: mit Internet an der Bridge sudo stagesense-bridge --update oder in der Mac-App unter Einstellungen → Bridges → Update („Nachsehen“, „Einspielen …“); ohne Internet an der Bridge übers lokale Netz (auch ihr eigenes WLAN) mit „Aus dem Update-Kanal laden …“ bzw. „Paket wählen …“ (Paket + Signaturdatei .json). Nur signierte Pakete, nur neuere Versionen, nur im Rahmen von „Updates bis“ der Sensor-Lizenz; ein root-Dienst spielt ein und schaltet bei Problemen auf /opt/stagesense-bridge.prev zurück. Wie beim Server liegt nach einem Rückfall in /opt/stagesense-bridge.prev die Version vor der wieder aktiven, und reicht der Platz für die Sicherung nicht, wird nichts eingespielt. Im Geräte-Konto der Bridge (http://<IP>:8480/admin, Karte „Update“) geht das Einspielen auch ohne Mac.

SNMP (nur lesen) für Zabbix, LibreNMS & Co.

Die Bridge beantwortet SNMP v1/v2c auf UDP 161 – nur GET, GETNEXT und GETBULK; SET wird immer abgewiesen, Traps gibt es keine. Die Werte stammen aus der eigenen Abfrage der Verteiler alle 2 Sekunden (nur Funktion 03, sauber hintereinander mit den Modbus-TCP-Weiterleitungen) – eine SNMP-Abfrage erreicht das Messgerät nie. Diese Abfrage läuft nur, solange SNMP an ist oder die Statusseite in der letzten Minute geöffnet war – so wenig Last auf den Mietgeräten wie nötig. Community „public“ (Standard), Standort und Kontakt stellst du mit sudo stagesense-bridge --snmp-community TEXT, --snmp-location TEXT und --snmp-contact TEXT ein, --snmp off schaltet SNMP ab; die Änderung wirkt nach spätestens 5 Sekunden ohne Neustart. Gegen Fluten beantwortet die Bridge je Absender höchstens 200 Anfragen pro Sekunde (Spitzen bis 1000), eine falsche Community bleibt unbeantwortet.

Es werden nur Standard-MIBs verwendet, die Zabbix und LibreNMS mitbringen – keine eigene MIB nötig:

Sensoren je Verteiler (Wert = Anzeige × 10^Präzision): 1–3 Spannung L1–L3 (V, Präzision 1) · 4–6 Strom L1–L3 (A, 2) · 7 Strom N (A, 2) · 8–10 Wirkleistung L1–L3 (W, 0) · 11 Wirkleistung Summe (W, 0) · 12 Frequenz (Hz, 2) · 13–15 Leistungsfaktor L1–L3 (2) · 16 Energie gesamt (kWh, 1) · 17 Verbindung (1 = verbunden, 2 = nicht verbunden). Der Status (entPhySensorOperStatus) ist 1 = ok, 2 = unavailable (Verteiler abgezogen), 3 = nonoperational (Messgerät antwortet nicht).

Beispiel: snmpwalk -v2c -c public <IP der Bridge> 1.3.6.1.2.1.99 zeigt alle Sensorwerte, snmpwalk -v2c -c public <IP der Bridge> 1.3.6.1.2.1.47.1.1.1.1.7 die Namen. LibreNMS erkennt die Sensoren über die ENTITY-SENSOR-MIB automatisch; in Zabbix die Vorlage für ENTITY-SENSOR-MIB oder eigene Items auf 1.3.6.1.2.1.99.1.1.1.4.<Index> mit Vorverarbeitung „Multiplizieren“ mit 10^−Präzision.

Fertige Zabbix-Vorlage (nur Stromwerte): tools/zabbix/stagesense_strom_snmp.json (Zabbix 7.0, Import unter Datenerfassung → Vorlagen → Importieren). Sie holt alle 30 s einen einzigen SNMP-Walk und findet je Messgerät automatisch Spannung L1–L3, Strom L1–L3 und N, Wirkleistung je Leiter und Summe, Frequenz, cos φ, Energie und Verbindung – sonst nichts. Die Items hängen am Namen („<Gerät> <Messwert>“), nicht an der Reihenfolge, die Historie bleibt also, wenn Geräte dazukommen. Meldet ein Messgerät keine aktuellen Werte, verwirft die Vorlage den Wert statt 0 einzutragen. Trigger: Spannung ±6 % (Warnung) / ±10 % (hoch) um 230 V, Strom ab 80 % / 100 % des Nennstroms, Frequenz 0,2 / 0,5 Hz, cos φ unter 0,8 (Info), Messgerät nicht verbunden, keine SNMP-Antwort seit 5 min. Den Nennstrom je Verteiler setzt du am Host als Makro mit Kontext, z. B. {$STAGESENSE.I.MAX:"DC 1 Han"} = 63 (Standard 32 A). Am Host eine SNMPv2-Schnittstelle mit der Community von Server bzw. Bridge anlegen; beim Server vorher SNMP einschalten (sudo stagesense --snmp on). Gerätenamen dürfen kein Hochkomma (') enthalten.

Häufige Fragen

Kurze Antworten auf häufige Fragen; Einzelheiten stehen in den verlinkten Abschnitten.

Fragen: Allgemein

Was ist StageSense? StageSense überwacht Strom, Licht und Netzwerk einer Veranstaltung an einem Ort: Messgeräte und Verteiler in den Dimmer Cities, Art-Net, sACN und MA-Net, Switche und Dienste wie DHCP oder Zeitserver. Es fasst alles in einer Problemliste zusammen, ordnet es Standorten zu (FOH, DC 1 …) und meldet Auffälligkeiten aufs Handy. StageSense läuft auf dem Mac (macOS 14 oder neuer) und als Server auf einem Raspberry Pi; eine Windows-Version (aktuell 1.0.4) gibt es separat. → Überblick

Liest StageSense nur, oder schaltet es auch etwas? Überwachen heißt lesen: Messgeräte nur mit den Modbus-Lesefunktionen 03/04, Switche lesend per SNMP, MA-Net, Art-Net und sACN passiv. Etwas schalten oder senden tut StageSense nur, wenn du es am Mac ausdrücklich auslöst – etwa DMX-Test, Hellmachen, Identify oder RDM. Die Web-App ist nur zum Ansehen.

Sendet StageSense etwas ins Show-Netz? Zur Überwachung vor allem Ping, SNMP-Abfragen (nur lesen), ArtPoll und Modbus-Abfragen an Messgeräte (nur lesen), dazu Suchanfragen nach StageSmarts-Verteilern und per Bonjour. Ins DMX- bzw. sACN-Netz sendet es nur beim DMX-Test, den du startest, ins MA-Net nie. Die Geräte-Suche läuft nur auf Knopfdruck. Im Client-Modus sendet der Mac gar nichts ins Show-Netz – das übernimmt dann allein der Server. Alles mit Takt und Schalter: Was StageSense im Netz sendet.

Welche Geräte und Hersteller kennt StageSense? Strom: Janitza-Messgeräte (Modbus TCP), MRG/connex-Verteiler über die USB-Buchse „NW“, StageSmarts-Verteiler, USV (SNMP oder USB). Licht: grandMA2 und grandMA3 (MA-Net2/3), Art-Net- und sACN-Geräte, Nodes wie LumiNode/LumiCore. Netzwerk: Switche und Access Points per SNMP, z. B. Luminex GigaCore, Netgear AV, Cisco, UniFi. Rund 50 Vorlagen decken auch Audio, Video, USV und Kettenzüge ab; andere Geräte lassen sich mit Ping und eigenen SNMP-Werten anlegen. → Geräte und Vorlagen

Kann ich StageSense ohne echte Geräte ausprobieren? Ja. Ohne Lizenz läuft StageSense als Demo mit eingebauten Simulatoren für Strom, Licht und Netzwerk. → Simulatoren

Was macht die Blackbox? Sie hält laufend die letzten Minuten aus Strom, Licht, MA, Netzwerk und Server im Speicher. Bei einem Alarm, einem Ausfall oder auf „Jetzt sichern“ sichert sie ab Werk 10 Minuten davor und 2 Minuten danach und zeigt alles auf einer Zeitachse – am Mac unter Einsatz & Bericht, in der Web-App unter Meldungen (mit PIN). Sie zeigt die Abfolge, nicht die Ursache. → Nach einer Störung – Blackbox

Fragen: Lizenz und Preise

Welche Lizenzen gibt es? PC und Server, jeweils für einen Monat, ein Jahr oder ohne Ablauf (Lifetime); Beta und Vorführung kostenlos. Jeder Mac braucht einen eigenen Schlüssel, auch im Client-Modus. Jede PC-Lizenz enthält eine Bridge-Lizenz, eine Server-Lizenz bei Monat und Jahr zwei, bei Lifetime eine; weitere Bridges lassen sich dazukaufen; alle Lizenzen einer Anlage müssen vom selben Kunden sein. Preise und Angebote auf Anfrage an info@riesevt.de. → Lizenz

Brauche ich dauerhaft Internet für die Lizenz? Nein. Die Lizenz wird einmal online aktiviert und läuft danach offline. Alle 60 Tage bestätigt StageSense sie kurz online. Hat der Pi kein Internet, geht beides über das Handy, den Laptop oder den Mac, mit dem du die Web-App öffnest. → Server ohne Internet

Wie ziehe ich die Lizenz auf einen anderen Rechner oder Pi um? Eine Lizenz ist an das Gerät gebunden. Im Kundenkonto unter license.stagesense.de/konto beim alten Gerät „Freigeben“ wählen, dann am neuen aktivieren. Das gilt auch, wenn ein Pi neu aufgesetzt wurde – er hat dann einen neuen Geräteschlüssel. → Kundenkonto

Was ist der Freischaltcode von sudo stagesense --license? Freischalten ohne Abtippen: Der Pi zeigt einen sechsstelligen Freischaltcode und einen Link (15 Minuten, einmal gültig). Den Link am Handy oder Mac öffnen und den Lizenzschlüssel dort eintragen – der Pi holt die Freischaltung selbst ab und bekommt den Schlüssel nie zu sehen. Das geht mit Server-, Inhaber- und Beta-Lizenzen. → Server-Lizenz und Freischaltcode

Was passiert, wenn die Lizenz abläuft oder nicht bestätigt wird? Dann arbeitet StageSense wie ohne Lizenz: als Demo, ohne echte Geräte. Ein Server überwacht nicht mehr, ein Sensor gibt keine Messwerte mehr weiter. Vor der fälligen Online-Bestätigung erinnert StageSense daran (der Server 14 Tage vorher). Mit einer verlängerten Lizenz bzw. nach der Bestätigung geht es weiter wie vorher.

Was bedeutet „Updates bis“? Das Datum in der Lizenz, bis zu dem neue Versionen eingespielt werden dürfen. Updates, die später gebaut sind, lassen sich nicht einspielen; die installierte Version arbeitet weiter.

Fragen: Mac, Server und Sensor

Brauche ich einen Raspberry Pi? Nein. Der Mac überwacht auch allein. Ein StageSense-Server auf dem Pi lohnt sich, wenn rund um die Uhr überwacht werden soll, ohne dass ein Mac läuft, wenn viele Bildschirme die DC-Seiten zeigen oder wenn die Anlage von unterwegs (Internet-Ansicht) zu sehen sein soll. Der Mac wird dann Client. → StageSense-Server

Pi 4 oder Pi 5? Für den Server ein Raspberry Pi 5 (8 GB) mit NVMe-SSD, offiziellem Netzteil und RTC-Batterie; ein Pi 4 mit 64-bit-System geht auch. Für den Sensor, der USB-Verteiler ins Netz bringt, reicht ein Pi 4 mit 2 GB. Server und Sensor können auch auf demselben Pi laufen. → Hardware, StageSense Bridge

Was ist der Client-Modus? Der Mac steuert den Server: dieselbe Oberfläche, aber Zustand, Einstellungen und Knöpfe gehören dem Server. Der Mac überwacht dann nichts selbst – keine doppelten Abfragen, keine doppelten Meldungen. Gekoppelt wird einmal mit einem Code vom Server; der Mac braucht eine eigene Lizenz desselben Kunden. → Client-Modus

Wie finde ich den Pi, wenn ich seine Adresse nicht kenne? Mac per Kabel direkt an den Pi und http://169.254.255.1:8470 öffnen (Sensor: http://169.254.255.2:8480). Hat der Pi gar kein Netz, öffnet er nach 45 Sekunden ein eigenes WLAN mit http://10.42.0.1:8470. Hängt ein Monitor am Pi, zeigt er alle Adressen. → Fehlersuche

Wie kommen Updates auf Mac, Server und Sensor? Mac: Einstellungen → Updates. Server und Sensor: mit Internet am Pi sudo stagesense --update bzw. sudo stagesense-bridge --update, vom gekoppelten Mac (auch ohne Internet am Pi), im Geräte-Konto im Browser oder von Hand mit dem neuen Paket. Es gibt nur signierte Pakete, nie ein Update im Showmodus, und startet die neue Version nicht sauber, schaltet der Pi auf die vorige zurück. Lizenz und Einstellungen bleiben. → Updates des Servers

Funktioniert StageSense ohne Internet? Ja. Überwachung, Problemliste und Web-App im lokalen Netz laufen ohne Internet. Internet brauchen nur Aktivierung und Online-Bestätigung der Lizenz, Updates aus dem Update-Kanal, Push aufs Handy und die Internet-Ansicht. Damit die Uhr des Pi ohne Internet stimmt, gehört eine RTC-Batterie hinein. → Uhr ohne Internet

Fragen: Strom

Welche Verteiler und Messgeräte werden unterstützt? Janitza-Messgeräte über das Netzwerk (Modbus TCP), MRG/connex-Verteiler über ihre USB-Buchse „NW“ (direkt am Mac oder Server oder über einen Sensor in der Nähe), StageSmarts-Verteiler und USV. An die Messgeräte gehen nur Lesefunktionen – Mietverteiler werden nie verändert. → Messgeräte

Was ist der Unterschied zwischen USB- und Netzwerk-Verteilern? Netzwerk-UMGs liefern alle Werte, auch den gemessenen N-Strom (I4) und die Crest-Faktoren. Das Messgerät in den USB-Verteilern (UMG 96RM) misst diese Kanäle nicht – StageSense zeigt sie als „vom Messgerät nicht geliefert“ und rechnet den N-Strom aus L1–L3. USB braucht ein Kabel zum Pi bzw. Mac; an einen Pi nur Verteiler derselben Einspeisung (sonst USB-Isolator). → StageSense Bridge

Was heißen „N ber.“ und „N gem.“? „N gem.“ ist der vom Messgerät gemessene N-Strom (I4), „N ber.“ der aus den drei Phasen berechnete. Bei LED-Lampen und Netzteilen kann der gemessene deutlich höher liegen. StageSense nimmt den gemessenen nur, wenn er plausibel ist; sonst steht „N ber.“ mit dem Hinweis „I4 unplausibel – Wandler/Anschluss prüfen“. Die Ampel bewertet immer den höheren Wert. → Dashboard je Standort

Warum steht da „vom Messgerät nicht geliefert“ statt 0? Manche Messgeräte liefern für Kanäle, die sie gar nicht messen, einfach 0. Statt einer falschen 0 zeigt StageSense den Wert grau und lässt ihn aus Grenzwerten, Alarmen und Summen heraus. Das ist kein Fehler. → Messgeräte

Woher kommt die Leistung im Stromplan? Aus dem Patch (grandMA2/3-Show, MVR, Patchliste als PDF oder CSV) und der Leistung je Gerätetyp: eigener Wert vor Angabe aus der GDTF vor der mitgelieferten Bibliothek (922 Gerätetypen, maximale Leistung laut Datenblatt). Typen ohne Treffer trägst du einmal von Hand ein. → Stromplan, Patch

Was kann StageSense zu Lastgang, Energie und Kosten? Lastgang mit 15-Minuten-Spitze je Verteiler, Standort und gesamt; Energie in kWh aus den Zählern der Messgeräte und – mit einem Strompreis je kWh – die Kosten je Einsatz im PDF-Bericht; dazu CSV-Export. Der Server legt die Minutenwerte in einem Archiv ab, auf Wunsch auf einer eigenen Platte. → Lastgang & Spitzenlast, Einsatz & Bericht

Ist der Netzqualitätsbericht EN-50160-konform? Nein – er ist „angelehnt an EN 50160“: Spannung, Frequenz, THD und Unsymmetrie als 10-Minuten-Mittel gegen die Grenzen der Norm, mit Ampel. Er zeigt, ob etwas auffällig war, ersetzt aber keine Messung nach Norm mit dafür zugelassenem Messgerät und der vorgeschriebenen Messdauer. → Einsatz & Bericht

Fragen: Licht und MA

Wie liest StageSense die Befehle an der grandMA2 (System Monitor)? Über den Telnet-Zugang der Konsole (Port 30001), der laut MA nur lesend ist; StageSense schickt keine Befehle. An der Konsole einmal Setup → Console → Global Settings → Telnet „Login Enabled“ einstellen, dann in StageSense unter MA-Net (Tab Session) „System Monitor“ anhaken. grandMA3 bietet diesen Zugang nicht. → MA-Protokoll

Was sieht StageSense im MA-Net? Passiv mitgelesen: Sessions mit Teilnehmern, Master und Rolle, Versionen und Showfiles, Geräteart (Pult, onPC, NPU/PU, Node). Dazu per SNMP Modell, Seriennummer, CPU-Last, Arbeitsspeicher und Temperaturen. Alarme z. B. bei „Backup hat übernommen“, Station verlässt die Session oder unterschiedliche Versionen. → MA-Net

Was zeigt das Leaderboard – und wer darf es sehen? Ranglisten der Licht-Operator aus dem System Monitor: wie viele Befehle wer an welcher Konsole gegeben hat. Gezählt wird nur die Art des Befehls, nie der Inhalt der Befehlszeile. Weil das eine Auswertung von Personen ist, zeigt die Web-App Leaderboard, MA-Protokoll und Statistik nur nach Anmeldung mit PIN (Standard); freigeben lässt es sich bewusst mit „Bedienerdaten ohne Anmeldung zeigen“. Am besten die Operator vorher informieren. → Einrichten der Web-App

Zeigt StageSense den Timecode? Ja: den Art-Net-Timecode (läuft oder steht, Bildrate) und den Timecode der Pulte auf den DC-Seiten (läuft/steht, an welchem Pult). → Überblick und Timecode

Warum stimmen die Uhrzeiten der Pulte nicht? Viele Pulte und PUs haben keine Zeitquelle und laufen auseinander. StageSense nimmt deshalb die Zeit, zu der es eine Zeile empfangen hat; die Pult-Uhr steht nur als Zusatz dabei. Damit die Pulte selbst stimmen, kann der Server als Zeitserver fürs Show-Netz dienen. → MA-Protokoll

Fragen: Netzwerk

Welche Switche werden unterstützt? Alle, die SNMP v1/v2c sprechen (reines SNMP v3 nicht): Ports mit Auslastung und Fehlern, PoE, VLANs, Temperaturen und – über LLDP – wer wo hängt. Fertige Vorlagen gibt es z. B. für Luminex GigaCore, Netgear AV, Cisco und UniFi. → Netzwerk

Kann StageSense mehrere VLANs überwachen? Ja. Am besten hängen Mac oder Pi an einem Trunk-Port und haben je VLAN eine Schnittstelle; gleiche IP-Bereiche in verschiedenen VLANs sind erlaubt. → Der Rechner im Show-Netz

Kann ich die Werte in Zabbix oder LibreNMS sehen? Ja. Server und Sensor stellen die Stromwerte per SNMP bereit – nur lesend, mit Standard-MIBs. Eine fertige Zabbix-Vorlage für die Stromwerte gibt es. Am Server ist der SNMP-Agent standardmäßig aus, am Sensor an. → SNMP für Zabbix

Fragen: Web-App und Internet-Ansicht

Wer kann die Web-App sehen? Jeder, der die Web-App im Netz erreicht (Port 8470) – aber nur zum Ansehen. Mit „Auch zum Ansehen PIN verlangen“ sieht man nur nach Anmeldung etwas. Ohne PIN gehen nur Push-Abonnieren und Probleme quittieren; Bedienerdaten (Leaderboard, MA-Protokoll) immer nur mit PIN, außer du gibst sie frei. → Einrichten der Web-App

Was ist die Internet-Ansicht? Damit lässt sich die Anlage von unterwegs ansehen, unter live.stagesense.de mit Ansichts-Kennung und PIN. Der Server schickt seinen Stand nur ausgehend dorthin; von außen ist der Pi nicht erreichbar, und schalten oder quittieren geht im Internet nicht. Eingeschaltet wird am Mac im Client-Modus, die PIN setzt du dort (mindestens 6 Ziffern, besser 8–10). → Internet-Ansicht

Was wird für die Internet-Ansicht gespeichert? Auf live.stagesense.de liegt nur der jeweils letzte Stand deines Servers, abrufbar nur mit Ansichts-Kennung und PIN; eine Anmeldung gilt 12 Stunden, falsche PINs werden gesperrt. Ausschalten löscht den Stand, ohne neuen Stand ist er nach 7 Tagen weg. Solange niemand zusieht, schickt der Server nur einmal pro Minute ein Lebenszeichen. → Internet-Ansicht

Wie bekomme ich Meldungen aufs Handy? Web-App über eine HTTPS-Adresse öffnen (z. B. über Tailscale), zum Home-Bildschirm hinzufügen (iOS 16.4 oder neuer) und unter Mehr → Benachrichtigungen aktivieren. Alarme, Warnungen und Behobenes kommen auch im Showmodus – der macht nur den Mac still. → Push aufs Handy

Fragen: Sicherheit und Datenschutz

Was macht der Showmodus? Während der Show bleibt der Mac still – keine Töne und Mitteilungen – für 2, 4 oder 8 Stunden, verlängerbar. Push aufs Handy geht weiter wie sonst, damit man sofort handeln kann. Am Ende steht unter Ereignisse, was der Mac zurückgehalten hat. Updates werden im Showmodus nie eingespielt. → Showmodus

Wie sicher ist das Koppeln von Mac und Server? Gekoppelt wird mit einem Code aus dem Geräte-Konto des Servers (10 Minuten, einmal gültig) – per Knopf „Mit StageSense koppeln“, per QR-Code oder durch Eintippen. Vorher prüft der Mac die Kennung des Servers (grün = bestätigt). Die Kamera des Macs nutzt StageSense nur auf Klick für den Kopplungs-QR-Code und speichert keine Bilder. Danach unterschreibt der Mac jede Änderung mit seinem Geräteschlüssel, und der Server prüft Lizenz, Kunde, Gerät und Uhrzeit. Die Kopplung gilt für das Gerät, nicht für die Adresse: Antwortet unter der Adresse ein anderes Gerät, schickt der Mac seinen Zugang nicht. → Client-Modus einrichten

Was verlässt mein Netz?

• Lizenzserver (license.stagesense.de): Aktivierung, Online-Bestätigung und Update-Abfrage – mit Lizenz, Geräte-ID, Plattform und Version, keine Messwerte.
• Internet-Prüfung des Pi: einmal pro Minute je Adapter eine Anfrage ohne Daten an license.stagesense.de, um den Weg ins Internet zu finden (bei der Installation abschaltbar).
• Push-Meldungen über die Push-Dienste von Apple, Google, Mozilla bzw. Microsoft – nur, wenn du Push einschaltest.
• Internet-Ansicht – nur, wenn du sie einschaltest.
• Tailscale – nur, wenn installiert; GDTF Share – nur beim Suchen und Laden von Gerätetypen.

Kann jemand aus dem Internet auf meine Geräte zugreifen? Nein. StageSense öffnet keinen Zugang von außen. Fernzugriff gibt es nur über das eigene Tailnet (Tailscale); die Internet-Ansicht arbeitet nur ausgehend und nur zum Ansehen.

Stehen Namen von Bedienern in Blackbox-Sicherungen? Nur, wenn „Bedienerdaten ohne Anmeldung zeigen“ eingeschaltet ist: dann die MA-Benutzernamen aus Anmeldungen und Hinweisen. Ab Werk ist der Schalter aus, und StageSense ersetzt die Namen schon bei der Aufnahme durch „•••“. Befehle der Bediener nimmt die Blackbox nie auf. Den Inhalt einer Sicherung sieht man nur mit PIN bzw. am gekoppelten Mac. → Bedienerdaten und Datenschutz

Fehlersuche und Tipps

Je Symptom die häufigste Ursache und was zu prüfen bzw. zu tun ist. Die meisten Probleme im Show-Netz liegen an IP-Adresse oder Subnetzmaske des Rechners, nicht an den Geräten.

Netz und Geräte

Server, Sensor und Fernzugriff

Web-App im Browser

Strom und Stromplan

USB-Verteiler am Pi prüfen (Server oder Sensor, per SSH):

• sudo dmesg -T | grep -iE 'ftdi|usb disconnect' – „USB disconnect“ und „FTDI USB Serial Device converter now disconnected“ zur Zeit des Ausfalls heißen: Die USB-Verbindung ist weg (Stecker, Kabel, Buchse). Steht nichts davon da, antwortet das Messgerät nicht.
• ls -l /dev/serial/by-id/ – jeder angeschlossene Verteiler erscheint als usb-FTDI_FT232R_USB_UART_<Seriennummer>-if00-port0. Die FTDI-Seriennummer gehört fest zum Verteiler: So findest du, welcher fehlt. lsusb zeigt ihn als 0403:6001.
• Am Sensor: sudo stagesense-bridge --list – Port, Seriennummer, angeschlossen/abgezogen.

MA-Pulte

Mac-App

Der Rechner im Show-Netz

• Am besten hängt der Mac an einem Trunk-Port mit getaggten VLANs (Management, MA-Net, Art-Net/sACN, Dante, Energie-Monitoring) und hat je VLAN eine virtuelle Schnittstelle. StageSense erkennt die VLANs dann automatisch.
• VLAN-Adapter anlegen (z. B. für das Strom-Netz): Systemeinstellungen → Netzwerk → „…“ unten → Virtuelle Schnittstellen verwalten → + → Neues VLAN; Name (z. B. „Strom“), Tag und den Kabel-Adapter zum Trunk wählen. Danach das VLAN in der Netzwerkliste anklicken → Details → TCP/IP manuell mit fester IP im Strom-Netz. In StageSense oben „x Adapter“ → ↻, anhaken und als Aufgabe Strom (Messgeräte, USV) wählen; die Bezeichnung (z. B. „Strom DC2“) ist frei. Der Knopf „VLAN anlegen …“ im Adapter-Fenster zeigt diese Schritte und öffnet die Netzwerk-Einstellungen.
• So erscheinen VLANs: mit farbigem „VLAN 20“-Schild und lesbarem Namen aus Name, Tag und Träger-Adapter, z. B. „Strom · VLAN 20 · USB 10/100/1000 LAN“ – im Adapter-Fenster, in der Netzwerk-Übersicht, im Reiter VLANs und in der Web-App (Signal → Netzwerk → Geräte, „Adapter des Macs“). Ein VLAN ohne IP-Adresse steht unter „Ohne IP-Adresse“ mit dem Grund (keine IP vergeben bzw. kein Kabel am Träger-Adapter).
• Gleiches Subnetz: Gleiche IP-Range in verschiedenen VLANs ist gewollt (getrennte Netze, z. B. zwei Lichtnetze mit gleichem Adressschema) – dafür gibt es keine Warnung, auch nicht für ein VLAN neben seinem ungetaggten Träger-Adapter. Gewarnt wird nur, wenn zwei ungetaggte Adapter (oder zwei Adapter im selben VLAN) im selben Subnetz liegen: Dann schickt macOS Ping, SNMP und Modbus nur über einen davon. StageSense zeigt dazu ein orangefarbenes Warnzeichen am Adapter-Knopf und meldet „Mac-Adapter: Gleiches Subnetz“ (Warnung, auch in der Web-App). Hinweis: Auch bei verschiedenen VLANs geht Unicast zu einer Adresse nur über einen Adapter – Geräte mit gleicher IP in beiden VLANs sind per Ping/SNMP nicht getrennt erreichbar.
• Mehrere Adressen an einem Adapter: Hat ein Adapter mehrere eigene Adressen im selben Netz – typisch: feste IP plus eine zusätzliche DHCP-Adresse, weil in den Systemeinstellungen → Netzwerk mehrere Dienste auf demselben Adapter oder VLAN liegen –, zählt StageSense ihn trotzdem als einen Adapter. Er erscheint einmal mit allen Adressen; StageSense nutzt die erste. Dazu kommt der Hinweis „Mac-Adapter: … hat 2 Adressen im selben Netz“. Abhilfe: überzählige Dienste in den Systemeinstellungen entfernen oder deaktivieren. Adressen in einem anderen Subnetz (Alias für ein zweites Netz) bleiben eigene Einträge.
• Ein Spiegel-Port (Port-Mirroring) am Switch zeigt im Reiter Auslastung den gespiegelten Verkehr und lässt DHCP-Antworten sehen, die sonst nur beim anfragenden Gerät ankommen.
• Switch-Ports mit Beschreibung versehen („MON Pult FOH“): StageSense zeigt sie überall und kann die Auslastung danach filtern.
• Geräte so benennen, dass der Standort im Namen steht („Switch DC3“) – dann ordnet „Nach Namen zuordnen“ alles in einem Schritt zu.

Begriffe

Die Begriffe, wie sie in StageSense und in diesem Handbuch verwendet werden.

Begriffe: Geräte und Betriebsarten

Eigenständig – Betriebsart, in der der Mac selbst überwacht (Menü Betriebsart → „Eigenständig – dieser Mac überwacht selbst“).

StageSense-Server (kurz Server) – StageSense ohne Bildschirm auf einem Raspberry Pi (meist Pi 5). Er überwacht rund um die Uhr; bedient wird er über die Web-App und vom Mac im Client-Modus.

Client-Modus, Client – Der Mac (oder Windows-Rechner) steuert einen Server: gleiche Oberfläche, aber Zustand und Einstellungen gehören dem Server, der Mac überwacht nichts selbst und sendet nichts ins Show-Netz. Einschalten über Menü Betriebsart → „Client – nur den Server fernsteuern …“ oder Einstellungen → Server → „Diesen Mac als Client des Servers nutzen“; wirkt nach einem Neustart von StageSense.

Sensor – Raspberry Pi (meist Pi 4), der MRG/connex-Verteiler über USB ins Netz bringt. Auf ihm läuft die Software StageSense Bridge; in der Mac-App stehen Sensoren unter Einstellungen → Bridges, in der Web-App des Servers als Kachel Sensor.

Statusseite – die Web-Seite des Sensors (http://<IP>:8480): Verteiler, Ports, Messwerte, Lizenz.

Web-App – die Browser-Oberfläche von Server bzw. Mac (http://<IP>:8470). Nur zum Ansehen; quittieren und Push abonnieren gehen auch ohne PIN.

Geräte-Konto – die Anmeldung admin auf Server und Sensor im Browser (Seite „Netzwerk verwalten“, beim Sensor /admin). Einzige Stelle, an der der Browser etwas am Gerät ändert: Netzwerk, eigenes WLAN, Tailscale, Kopplungscode. Das Startpasswort admin gilt nur im eigenen WLAN des Pi oder am Pi selbst.

Fallback-Adresse – feste Zusatzadresse am Kabelanschluss: 169.254.255.1 (Server), 169.254.255.2 (Sensor). Damit ist der Pi per Kabel direkt am Mac immer erreichbar, auch ohne DHCP.

Eigenes WLAN – Notzugang „StageSense-<Name>“, den der Pi öffnet, wenn er 45 Sekunden lang kein Netz hat (Adresse 10.42.0.1).

Geräteschlüssel, Geräte-ID – Jedes Gerät erzeugt beim ersten Start einen eigenen Schlüssel, der es nie verlässt. Die Geräte-ID (32 Zeichen) ist daraus abgeleitet; ein neu aufgesetzter Pi hat einen neuen Schlüssel und damit eine neue Geräte-ID.

Kennung – Kurzform der Geräte-ID zum Vergleichen, z. B. „a1b2-c3d4“. Beim Koppeln prüft StageSense, ob das Gerät unter der Adresse wirklich diese Kennung hat.

Begriffe: Lizenz und Updates

Lizenz, Produkt – PC oder Server, je Monat, Jahr oder Lifetime; dazu eine Sensor-Lizenz je Sensor (in PC- und Server-Lizenzen enthalten, weitere dazukaufbar). Alle Lizenzen einer Anlage gehören zum selben Kunden.

Platz – ein aktiviertes Gerät einer Lizenz („x von N Plätzen“). Im Kundenkonto (license.stagesense.de/konto) lässt sich ein Platz freigeben.

Online-Bestätigung – Alle 60 Tage bestätigt StageSense die Lizenz kurz online; beim Pi geht das auch über Handy, Laptop oder Mac.

Freischaltcode – Code und Link von sudo stagesense --license (15 Minuten, einmal gültig): Den Link am Handy öffnen und den Lizenzschlüssel dort eintragen – der Pi holt die Freischaltung selbst ab. Nicht zu verwechseln mit dem Kopplungscode zum Koppeln eines Macs.

Updates bis – Datum in der Lizenz, bis zu dem neue Versionen eingespielt werden dürfen.

Update-Kanal, stabil, beta – Woher Updates kommen. Neue Versionen gehen zuerst in den Kanal beta (Beta-Tester), dann in den Kanal stabil für alle (in der App unter Einstellungen → Updates: „Kanal: Stabil“ bzw. „Beta“).

Signaturdatei – die .json-Datei neben einem Update-Paket (.tar.gz). Ohne passende Signaturdatei spielt kein Gerät ein Paket ein.

Rückfall – Startet eine neue Version auf dem Pi nicht sauber, schaltet er von selbst auf die vorige zurück.

Begriffe: Koppeln und Fernzugriff

Kopplung, koppeln – einmalige Verbindung zwischen Mac und Server bzw. Sensor. Sie gilt für das Gerät (seine Kennung), nicht für die Adresse, und braucht eine Lizenz des Macs vom selben Kunden.

Kopplungscode – Code aus 6 Ziffern vom Server bzw. Sensor (sudo stagesense --pair oder Geräte-Konto „Kopplungscode erzeugen“), 10 Minuten und einmal gültig.

Tailscale, Tailnet – privates, verschlüsseltes Netz für den Fernzugriff auf die eigenen Geräte. StageSense öffnet keinen Zugang aus dem Internet; Fernzugriff gibt es nur über das eigene Tailnet.

Internet-Ansicht – Ansicht des Servers von unterwegs unter live.stagesense.de, mit Ansichts-Kennung und PIN. Der Server sendet seinen Stand nur ausgehend dorthin; ansehen ja, schalten nie.

Ansichts-Kennung – die 8 Zeichen in der Adresse der Internet-Ansicht (live.stagesense.de/<Ansichts-Kennung>). Hat mit der Kennung des Geräts nichts zu tun.

Push – Mitteilungen der Web-App aufs Handy (über HTTPS, vom Home-Bildschirm gestartet).

Begriffe: Standorte

Standort – Ort mit eigener Seite, z. B. FOH, DC 1, Bühne, Rack. Geräte werden genau einem Standort zugeordnet.

FOH – Front of House, der Regieplatz; dort stehen die Pulte oben.

DC, Dimmer City – Stromverteil-Standort an der Bühne (DC 1, DC 2 …); dort steht der Strom oben.

DC-Seite – die Seite eines Standorts (am Mac: Dashboard je Standort; in der Web-App unter /dc).

Gesamtübersicht, Gesamt – die Seite über alle Standorte: Startseite am Mac, erste Seite der Web-App (/uebersicht).

Ampel – Zustand eines Standorts oder Bereichs: grün, orange, rot; grau für ruhig bzw. ohne Alarm. Ab welchem Wert orange bzw. rot gilt, legen die Grenzwerte fest.

Grenzwerte – die Zahlen, ab denen Werte orange oder rot werden: eine gemeinsame Quelle für Ampeln, DC-Seiten, Vorlagen der Alarmregeln und Blackbox, für alle Standorte gleich. Nennwerte und Strom-Grenzen stehen unter Einstellungen → Grenzwerte.

Strom-Alarme ab Werk – Unter-/Überspannung, Phase weg, Frequenz und Auslastung nach den Grenzwerten, auch ohne eigene Alarmregel; global und je Messgerät abschaltbar.

Schwachstellen – höchste Temperatur und Auslastung je Gerätetyp, wackelige Geräte.

Begriffe: Strom

Messgerät – das Gerät, das Strom und Spannung misst (z. B. Janitza UMG), gelesen per Modbus.

Verteiler – Stromverteiler mit eingebautem Messgerät; im Stromplan Hauptverteiler und Unterverteiler (UV).

USB-Buchse „NW“ – Anschluss am MRG/connex-Verteiler, über den StageSense das Messgerät per USB liest.

Anschluss, Absicherung – die Einspeisung eines Standorts und ihr Sicherungswert; Bezug für Prozent, Reserve und Phasenlast.

Reserve – Ampere bis zur Absicherung auf der höchsten Phase.

Phasenlast, Schieflast – Last je Phase in Prozent der Absicherung; Schieflast = Unterschied zwischen höchster und niedrigster Phase.

N ber. – N-Strom aus L1–L3 berechnet. N gem. – vom Messgerät gemessener N-Strom (I4), nur wenn plausibel. I4 gem., I4 gemessen – der gemessene Wert in Live-Ansicht bzw. Messwerttabelle.

Vom Messgerät nicht geliefert – Wert, den ein Messgerät nicht misst und als 0 meldet; StageSense zeigt ihn grau und rechnet nicht damit.

Getrennt seit … – Messgerät ohne aktuelle Werte (USB abgezogen, keine Antwort); zählt in keine Summe.

Typenschild – Seriennummer und Software-Stand eines Janitza-Messgeräts.

Lastgang – Leistung über die Zeit als 15-Minuten-Mittel. Spitze 15 min – die höchste Viertelstunde (heute bzw. im Einsatz).

Einsatz – Zeitraum einer Veranstaltung in „Einsatz & Bericht“: Energie, Kosten, Netzqualität im PDF.

Netzqualität (angelehnt an EN 50160) – Spannung, Frequenz, THD und Unsymmetrie gegen die Grenzen der Norm, als Orientierung; keine Messung nach Norm.

Stromplan – aus dem Patch berechnete Leistung je Verteiler, Plugbox, Steckplatz, Kreis und Phase.

Plugbox (auch Multicore), Steckplatz, Kreis, Phase – Teile des Strompfads einer Lampe, z. B. aus der Strom-Spalte einer Patchliste.

Leistungs-Bibliothek – mitgelieferte Liste mit der Leistung von rund 900 Gerätetypen laut Datenblatt.

Begriffe: Licht und MA

Universum – 512 DMX-Kanäle, übertragen per Art-Net, sACN oder MA-Net. Kommt ein Universum über mehrere Wege, zählt StageSense es einmal.

MA-Net2, MA-Net3 – Netzprotokolle der grandMA2 bzw. grandMA3; StageSense liest sie nur mit.

Session – Verbund der MA-Geräte, die zusammenarbeiten, mit einem Master. Nicht zu verwechseln mit einer Anmeldung (Sitzung) in Web-App oder Kundenkonto.

Station – jeder Teilnehmer im MA-Net: Pult, onPC, PU/NPU, Node.

Pult – Bedienpult (grandMA full-size, light, compact, onPC).

PU, NPU – Processing Unit: rechnet Parameter, ohne Bedienoberfläche.

Node – gibt Universen als DMX aus.

Konsole – im MA-Protokoll eine grandMA2-Station mit System Monitor (Pult oder PU/NPU).

System Monitor – Protokoll einer grandMA2-Konsole über Telnet, nur lesend; Grundlage für MA-Protokoll, Statistik und Leaderboard.

MA-Protokoll – die Zeilen des System Monitors in StageSense, mit Filtern und Tagesprotokoll je Konsole.

Bediener – wer gerade an einer Konsole arbeitet; erkannt am MA-Benutzer (Login an der Konsole).

Leaderboard, Operator – Ranglisten der Licht-Operator nach Zahl und Art der Befehle (nie der Inhalt).

Bedienerdaten – Leaderboard, MA-Protokoll und Befehls-Statistik; in der Web-App nur nach Anmeldung mit PIN, außer sie sind ausdrücklich freigegeben.

Timecode – Art-Net-Timecode und Timecode der Pulte (läuft/steht).

MA-Net-Mitschnitt – Aufzeichnung des MA-Net-Verkehrs als pcap-Datei (Wireshark), am Mac kurz oder am Server dauerhaft.

Begriffe: Netzwerk

Adapter – Netzwerkanschluss des Macs bzw. Pi (Kabel, VLAN, WLAN). Überwacht werden nur ausgewählte Adapter.

VLAN, Trunk-Port – getrennte Netze auf einem Kabel; am Trunk-Port kommen alle VLANs getaggt an.

Uplink – Verbindung eines Switches zum übergeordneten Switch.

SNMP – Abfrageprotokoll für Switche und andere Geräte (StageSense liest nur, v1/v2c).

Vorlage – Geräte-Typ mit passenden Einstellungen (SNMP, Schwellen, Schweregrad bei Ausfall).

Geräte-Suche – sucht auf Knopfdruck nach Geräten im Netz; bei jedem Start nur, wenn „Beim Start nach Geräten suchen“ an ist (ab Werk aus).

Überwachen aus – Gerät bleibt in der Liste, wird aber nicht abgefragt und meldet nichts.

Begriffe: Meldungen

Problem – Auffälligkeit in der gemeinsamen Problemliste, mit Schweregrad: Katastrophe, Hoch, Mittel, Warnung, Info.

Behoben – Meldung, dass ein gemeldetes Problem vorbei ist (✅), über denselben Weg wie die Meldung und mit der Dauer, z. B. „wieder erreichbar (IP) nach 10 s“.

Bestätigen (quittieren) – ein Problem als gesehen markieren; es zählt dann nicht mehr als offen.

Wartung – Meldungen für eine Zeit stummschalten (Aufbau, Abbau), global oder je Gerät.

Showmodus – während der Show: der Mac bleibt still (keine Töne und Mitteilungen), Push aufs Handy geht weiter; Updates nie im Showmodus.

Grauer Ring – ausgefallenes Gerät oder Pult ohne Alarm (bestätigt, „kein Alarm bei Ausfall“ oder „Überwachen“ aus); zählt mit, färbt aber nicht.

Blackbox – sichert nach einer Störung die Minuten davor und danach aus allen Bereichen (ab Werk 10 und 2 Minuten) als Sicherung mit Zeitachse. Auslöser sind z. B. ein Alarm, ein Gerät nicht erreichbar, ein Universum weg, eine Phase weg oder „Jetzt sichern“.

Totzeit – die 2 Minuten nach einem Auslöser, in denen weitere Auslöser zur selben Blackbox-Sicherung gehören.

Tastenkürzel

Marken und Rechtliches

© 2026 Robin Riese (RieseVT)

grandMA, grandMA2, grandMA3 und weitere MA-Bezeichnungen sind Marken der MA Lighting Technology GmbH. StageSense ist nicht mit MA Lighting verbunden. Alle genannten Marken gehören ihren jeweiligen Inhabern.

StageSense ist keine Sicherheitseinrichtung und ersetzt keine vorgeschriebenen Prüfungen bzw. Schutzeinrichtungen (FI/RCD, DGUV, Rigging, Pegel, Wind).

Sicherheitslücken bitte an info@riesevt.de melden.