PotoP VMS Studio

Der Client fragt das Betriebssystem nach seinen Bildschirmen und den Grafiktreiber nach Details. So zeigt jeder Monitor Hersteller, Modell, Seriennummer, Auflösung, Bildwiederholrate, Anschluss und die ansteuernde GPU – sowie Temperatur und VRAM, sofern der Treiber sie meldet. Jeder physische Bildschirm wird über seine Hardware-Identität zugeordnet, nicht über seine Position, und erhält einen dauerhaften Code wie M1. Umbenennungen und Codes werden auf diesem Client gespeichert und überstehen Neustarts und erneutes Anstecken. Ein abgesteckter Monitor bleibt in der Liste, bis Sie ihn löschen – eine gespeicherte Wand zeigt also weiterhin auf denselben Bildschirm.

Der Editor läuft im Browser und speichert das Multi-Layout auf dem Server, sodass dasselbe Rezept auch den Desktop-Clients zur Verfügung steht. Der Browser listet seine eigenen Bildschirme über die Window Management API, die eine sichere HTTPS-Verbindung und die Zustimmung des Benutzers voraussetzt. Jeder Eintrag zeigt einen Monitorcode; Codes, die es an diesem Browser nicht gibt, werden als nicht vorhanden angezeigt. Wird einem Code ein Layout zugewiesen, kommt es ins Rezept. Beim Projizieren öffnet sich pro passendem Bildschirm ein Browserfenster, das dort platziert wird und jeweils das Live-Layout zeigt.

Multi-Layouts werden auf dem Server als Liste von Monitorcodes mit dem jeweils zugehörigen Layout gespeichert. Diese Übersicht stellt jedes Rezept als kleines Bild seiner Bildschirme dar und zeigt, wie viele davon an Ihrem Browser vorhanden sind. „Projektion starten“ öffnet auf jedem passenden Bildschirm ein Fenster und startet dort die Live-Layouts. „Bearbeiten“ und „Löschen“ ändern das gespeicherte Rezept für alle Clients. Der Zugriff folgt denselben Benutzer- und Gruppenrechten wie im übrigen System, und eine Wand kann Benutzern oder Gruppen zugeordnet werden, damit sie sich für diese automatisch öffnet.

Über die Window Management API – sie erfordert HTTPS und eine einmalige Berechtigungsabfrage – erkennt der Browser, auf welchem physischen Bildschirm sich jedes Fenster befindet. „Identifizieren“ öffnet auf jedem erkannten Display ein randloses Fenster, zeichnet Monitorcode und Namen in großer Schrift und schließt es nach einigen Sekunden wieder. Der Code stammt aus einem in diesem Browser geführten Verzeichnis; Umbenennungen bleiben daher erhalten, und ein abgesteckter Monitor bleibt gelistet, bis Sie ihn löschen. Das Detailfenster meldet Auflösung, Position, Skalierung und Farbtiefe so, wie der Browser sie sieht.

Während die KI-Pipeline den Livestream auswertete, hat sie jede Erkennung mit Klasse, Konfidenz, Begrenzungsrahmen und Vorschaubild in der Analysedatenbank gespeichert. Die Wiedergabe liest diese Einträge für den gezeigten Moment und zeichnet den Rahmen im Browser über das Video – in die Aufzeichnung selbst wird nichts eingebrannt. Die Seitenliste speist sich aus denselben Einträgen und zeigt Klasse, Zeit und Konfidenz. Ein Klick auf einen Eintrag springt in der Aufzeichnung genau zu diesem Zeitpunkt. Der Tracker zählt außerdem, wie viele Sichtungen zu einem Objekt gehören – so lässt sich ein geparktes Auto von vielen vorbeifahrenden unterscheiden.

„Untersuchen“ nimmt das Bild unter dem Abspielkopf und schickt es an den Server, der den Detektor darauf anwendet und das Objekt samt Maske ausschneidet. Die Schaltfläche „Identifizieren“ übergibt diesen Ausschnitt an ein Vision-Language-Modell, das in den KI-Einstellungen konfiguriert ist – lokal oder über einen Anbieter Ihrer Wahl –, und zeigt dessen Beschreibung an. Die Farbe wird aus dem Ausschnitt selbst ermittelt. „Diesen Typ und diese Farbe suchen“ durchsucht dann die Analysedatenbank nach Erkennungen derselben Klasse und Farbe in allen Aufzeichnungen. Die Beschreibung ist die bestmögliche Einschätzung eines Modells – und es sagt das auch, wenn die Sicht schlecht ist.

Der Server geht die aufgezeichneten Segmente des gewählten Zeitraums durch, entschlüsselt sie im Arbeitsspeicher und tastet Bilder ab. Eine Hintergrundsubtraktion überspringt leere Bilder, sodass Objektdetektor und Tracker nur dort laufen, wo sich etwas bewegt. Jedes verfolgte Objekt wird zu einer Röhre aus ausgeschnittenen Bildern mit ihren ursprünglichen Zeitstempeln. Die Röhren werden neu angeordnet, sodass sie gleichzeitig über einem gemeinsamen Hintergrund ablaufen, und ffmpeg rendert das Ergebnis als MP4 mit der eingebrannten Originalzeit jedes Objekts. Der Job läuft im Hintergrund mit Fortschrittsanzeige und kann abgebrochen werden. Ein Klick auf ein Objekt setzt die Zeitleiste auf seinen ursprünglichen Moment.

Der Server schneidet den gewünschten Zeitraum mit ffmpeg aus den aufgezeichneten Segmenten und entschlüsselt verschlüsselte Aufzeichnungen auf Wunsch im Arbeitsspeicher. Zeitstempel, Kameraname und Wasserzeichen werden ins Bild eingebrannt. Ist die Verschlüsselung aktiviert, wird das MP4 mit AES-256 verschlüsselt – mit einem Schlüssel, der per PBKDF2 aus Ihrem Passwort abgeleitet wird –, und daneben wird eine Signaturdatei geschrieben. Das Passwort wird nie gespeichert, daher kann es auch niemand wiederherstellen. Je nach gewähltem Ziel bleibt das Ergebnis auf dem Server, wird auf Ihren Computer heruntergeladen oder beides.

Der Player läuft auf jedem Computer, auch ohne PotoP-Server. Sie wählen das verschlüsselte Video und seine Signaturdatei und geben das Passwort ein. Zuerst prüft er die Signatur per HMAC, um nachzuweisen, dass die Datei unverändert ist, leitet dann mit PBKDF2 den Schlüssel aus dem Passwort ab und entschlüsselt mit AES-256. Das Klartextvideo existiert nur im Arbeitsspeicher, solange es läuft. Von dort aus können Sie die grünen Griffe ziehen, um einen Ausschnitt zuzuschneiden, ein Standbild speichern oder eine normale MP4-Kopie exportieren. Eine browserbasierte Variante liegt Exportordnern bei, mit Startern für Linux, Windows und macOS.

Jede Kamera hat ihre eigenen, auf dem Server gespeicherten Aufzeichnungseinstellungen, und der Rekorder übernimmt sie, sobald Sie speichern. Auslöser können durchgehend sein, ein Wochenplan oder Ereignisse wie Bewegung, Person, Kennzeichen, ein Alarmeingang oder ein Makro – mit Vor- und Nachlaufpuffer, damit auch der Moment vor dem Auslöser erhalten bleibt. Segmente werden in einer festgelegten Länge geschnitten und können nach dem Abschluss mit AES-256 verschlüsselt werden. Die Vorhalteregel entfernt alte Segmente nach Alter oder maximaler Größe. Start-, Stopp- und Erkennungsereignisse können Benachrichtigungen über Systemereignisse, E-Mail, Telegram oder einen Webhook auslösen.

Der primäre Detektor läuft mit einer eingestellten Bildrate und eigener Konfidenz, Überlappungsschwelle, maximaler Anzahl Erkennungen und eigenem Klassenfilter. Ein Tracker – in dieser Ansicht ByteTrack – verbindet Erkennungen über mehrere Bilder hinweg zu stabilen Objekt-IDs, auf denen Zählung und Verweildauer beruhen. Nachgelagerte Stufen sind an Klassen gebunden: Die Kennzeichenerkennung startet nur, wenn ein Auto, Lkw, Bus oder Motorrad gefunden wird, Pose oder Segmentierung nur, wenn ihre Auslöseklasse erscheint. Das hält die Last gering, denn die rechenintensiveren Modelle sehen nur einen kleinen Ausschnitt statt des ganzen Bildes.

Ein Posenmodell läuft auf dem Personenausschnitt, den der primäre Detektor gefunden hat, und liefert Körper-Schlüsselpunkte mit jeweils eigener Konfidenz. Der Server speichert das Skelett, und der Browser zeichnet es über das Bild, mit der Gelenktabelle daneben. Die Sturzerkennung betrachtet, wie sich diese Schlüsselpunkte im Zeitverlauf bewegen und anordnen; eine Empfindlichkeitseinstellung passt ihre Schwellen an. Löst sie aus, wird das Ereignis gespeichert und kann einen Alarm auslösen oder ein Makro starten. Die Live-Tabelle darunter fragt die Datenbank ab – Sie sehen also genau die Einträge, die auch das Alarmsystem erreichen.

Ein Segmentierungsmodell läuft auf den vom primären Detektor gefundenen Objekten und liefert für jedes eine Pixelmaske. Der Server schickt diese als Maskenbilder an den Browser, und die Vorschau legt sie über das Bild. Der Tracker behält eine Objekt-ID bei, sodass die Tabelle zeigen kann, wie lange jedes Objekt schon im Bild ist. Bleibt ein Objekt länger als die Stillstandsschwelle unbewegt, markiert die Lebenszykluslogik es als zurückgelassen, und die Zeile färbt sich rot. Lebenszyklusereignisse wie „erschienen“ oder „verlassen“ werden für die spätere Suche protokolliert.

Sie zeichnen Polygone und Linien direkt in ein Livebild, und der Server speichert sie in den normierten Koordinaten der Kamera – so bleiben sie bei jeder Auflösung korrekt. Der Tracker verfolgt Objekt-IDs, und eine Überschreitung wird erkannt, wenn die Position eines verfolgten Objekts von einer Seite der Linie auf die andere wechselt; daraus ergibt sich die Richtung A nach B oder B nach A. Zonen lösen Eintritts- und Verweilereignisse aus. Jedes Ereignis landet mit Zeitstempel und Track-ID in der Analysedatenbank, wo Zähler, Berichte, Alarme und Makros es nutzen können.

Die Bewegungserkennung hat zwei Quellen. Die kameraeigene Erkennung kommt als ONVIF-Bewegungsereignis an, während die Serveranalyse Videobilder auf dem Server mit einem Hintergrundmodell vergleicht – per CPU oder GPU. Die Maske ist ein Raster aus Blöcken, die Sie ins Bild malen; als ignoriert markierte Blöcke werden vom Vergleich ausgenommen, sodass Laub oder Straßenverkehr nichts auslösen. Empfindlichkeit, Mindestfläche, Abtastrate und Herunterskalierung lassen sich feinjustieren. Die Maske wird mit der Kamera gespeichert und vom Server sofort beim Speichern angewendet.

Sie zeichnen Blöcke in ein Livebild, und der Server speichert sie mit der Kamera. Je nach Schaltern verwischt oder verdeckt der Server diese Bereiche im Livestream, in Schnappschüssen und in Aufzeichnungen. Bei Live-Video und Aufzeichnungen geschieht das auf dem Server, bevor das Video gespeichert oder ausgeliefert wird – bei Aufzeichnungen ist der maskierte Bereich im gespeicherten Video daher unwiderruflich verloren, worauf die Seite auch hinweist. Farbe und Unschärfegrad sind einstellbar. Die Masken werden beim Speichern an die laufende Pipeline übertragen, sodass die Änderung ohne Neustart der Kamera wirkt.

Jeder Personen- oder Fahrzeugausschnitt wird von einem kleinen Re-Identifikationsmodell unter OpenVINO in einen Erscheinungsvektor mit 256 Werten umgewandelt und in der Analysedatenbank gespeichert. Bei der Suche wird das Suchbild auf dieselbe Weise eingebettet und per Kosinus-Ähnlichkeit mit den gespeicherten Vektoren verglichen – über einen Index im Arbeitsspeicher, sodass das Ergebnis exakt und schnell ist. Da das Gesamterscheinungsbild und nicht ein Gesicht verglichen wird, funktioniert es auch bei Personen, die von hinten oder in geringer Auflösung zu sehen sind. Die Auswahl eines Ergebnisses lädt Sichtungsverlauf und Route dieses Tracks, und „In der Wiedergabe verfolgen“ öffnet die Aufzeichnungen.

Überquert ein verfolgtes Objekt eine konfigurierte Linie, speichert der Server das Ereignis mit Richtung, Kamera, Linie und Uhrzeit. Dieser Bildschirm zeigt diese Ereignisse live in der Liste „Aktuell“. Der Verlaufsbericht gruppiert sie stunden- oder tageweise mit Spalten für Eingang, Ausgang und Summe und kann Verweildauer und Belegung ergänzen, sofern diese konfiguriert sind. Belegungsgrenzen lösen bei Überschreitung einen Alarm aus. Die CSV-Schaltfläche exportiert den Bericht für Tabellenkalkulationen – so werden Personal- und Belegungsanalysen üblicherweise durchgeführt.

Der Server zählt aus den Analysedaten die Erkennungen pro Kamera und Stunde, einschließlich Kennzeichen und Treffern auf der Beobachtungsliste. Diese Zahlen erhält ein Sprachmodell – hier ein kleines, lokal über Ollama bereitgestelltes Llama-Modell –, das daraus das Briefing in verständlicher Sprache formuliert. Ist kein Modell verfügbar, erscheint stattdessen eine einfache statistische Zusammenfassung. Der Anomaliedetektor verwendet kein KI-Modell: Er lernt für jede Tagesstunde einen typischen Wert, getrennt nach Werktagen und Wochenenden, und markiert Stunden, die deutlich darüber liegen. Bis genügend Verlaufsdaten vorliegen, bleibt er still.

Ein Gebäudeplan ist eine Zeichenfläche mit optionalem Hintergrundbild, gezeichneten Gebäudeelementen und Symbolen, die zusammen mit der übrigen Systemkonfiguration auf dem Server gespeichert wird. Jedes Symbol ist an ein reales Objekt gebunden, etwa eine Kamera, eine Leuchte, einen Türausgang oder eine Sprechstelle, und der Server überträgt dessen Zustand an alle geöffneten Clients – die Farbe des Symbols ändert sich also, sobald sich das Gerät ändert. Desktop-, Browser- und Telefon-Clients lesen dieselbe Plandefinition und zeichnen sie selbst; deshalb sieht ein Plan überall gleich aus. Zum Bearbeiten sind die Visualisierungsberechtigungen nötig.

Die Seite „Neuer Plan“ enthält eine Reihe integrierter Generatoren. Sie wählen einen Gebäudetyp, beantworten einige Parameter – etwa die Zahl der Beratungsräume und wie viel Ausstattung platziert werden soll –, und sofort wird eine Vorschau berechnet. Bei „Erstellen“ schreibt der Generator Wände, Räume, Türen und Symbole in einen normalen Plan auf dem Server. Danach ist nichts gesperrt: Das Ergebnis ist ein gewöhnlicher Plan, den Sie wie einen von Hand gezeichneten bearbeiten; alternativ lässt sich ein bestehender Plan klonen, mit oder ohne seine Gebäudeelemente.

Vorlagen sind codegesteuerte Generatoren, die Räume, Wände und Symbole aus wenigen Parametern anlegen – hier aus der Zahl der Serverreihen und der Ausstattungsstufe. Die Symbole entstehen ungebunden, mit dem passenden Typ und der passenden Beschriftung für jeden Raum, sodass der Errichter sie anschließend nur noch mit einer realen Kamera, einem Sensor oder einem Ausgang verknüpfen muss. Da das Ergebnis als normaler Plan gespeichert wird, lässt es sich wie jeder andere umbenennen, verschieben, erweitern oder klonen. Verschiedene Gebäudetypen nutzen einfach unterschiedliche Generatoren hinter demselben Formular.

Der Symbol-Editor hat einen Kamera-Reiter mit Kompassvorschau. Sie ziehen einen Griff zum Ausrichten, seitliche Griffe für die Breite und einen quadratischen Griff für die Reichweite – oder tippen Werte ein und nutzen Objektiv-Voreinstellungen. Die Vorschau zeigt genau, was der Plan nach „OK“ zeichnen wird; Ring und Hilfslinien gibt es nur im Editor. Im selben Reiter wählen Sie, welche Kamera und welchen Stream (Haupt- oder Substream) das Symbol verwendet und was ein Klick bewirkt, etwa das Öffnen einer Vorschau. Alle Werte werden mit dem Symbol gespeichert.

Der gezeigte Dialog ist der Editor für Leuchtensymbole, in dem jeder Zustand (aus, an, gedimmt, Störung, offline) seine eigene Farbe und optionale Statuspunkte für Ein- und Ausgänge erhält. Ein Leuchtensymbol wird über ein Geräte-Plugin gebunden, etwa die Philips-Hue-Integration oder generische E/A, und der Server hält seinen Zustand mit der realen Leuchte synchron. Das automatische Schalten durch Sprechstellen- oder Sensoreingänge übernimmt die serverseitige Makro-Engine, nicht der Plan selbst. Vom Plugin gemeldete Probleme, etwa fehlende Verbindung, erhalten am Symbol eine eigene Farbe.

Ein Sprechstellensymbol ist an ein Sprechanlagen-Plugin gebunden – im Dialog die Commend-ICX-Integration –, und der Server verfolgt die Rufereignisse dieser Sprechstelle. Jedes Ereignis wird einem Symbolzustand zugeordnet, etwa Ruhe, Anruf, Klingeln, Gespräch, Halten, Notruf oder Leitungsstörung, und jeder Zustand hat eine eigene Farbe, die der Editor in der Vorschau zeigt. Der Zustand wird an alle verbundenen Clients übertragen, sodass der Plan den realen Zustand der Sprechstelle binnen Augenblicken wiedergibt. Aktionen am Symbol, etwa ein Ruf oder das Öffnen einer Tür, werden über dasselbe Plugin zurück an das Gerät gesendet.

Jede Symbolaktion lässt sich mit einer PIN sperren. Klickt ein Bediener auf ein solches Symbol, fragt der Client nach der PIN, bevor er den Befehl an den Server sendet – ein versehentlicher Klick kann so weder einen Ausgang schalten noch eine Tür öffnen. PINs können dauerhaft oder temporär sein und werden im Editor pro Symbol festgelegt. Die Sperre ist ein zusätzlicher Schutz zu den normalen Berechtigungsprüfungen, die der Server für den angemeldeten Benutzer weiterhin durchsetzt.

Das Panel „Gebäudeelemente“ listet zeichenbare Objekte wie Wände, Türen, Fenster, Treppen, Aufzüge, Straßen, Pflanzen, Zäune, Becken und Schilder, und Sie können eigene hinzufügen. Die Elemente sind Vektorformen, die im selben Plan wie die Gerätesymbole gespeichert werden, mit Position, Größe und Ebenenreihenfolge – so bleiben sie bei jeder Zoomstufe scharf. Ein Plan kann daher vollständig im Produkt gezeichnet werden oder über einem hochgeladenen PNG-, JPG-, BMP- oder GIF-Hintergrund wie einer Architektenzeichnung.

Jeder Desktop- und Browser-Client meldet sich unter einer eindeutigen ID beim Server an und meldet sich laufend zurück – so zeigt die Seite, was online ist, samt Benutzer, GPU, Anzahl der Monitore und Zeitpunkt der letzten Meldung. Ein Administrator kann einen Client anhand seiner ID vorab registrieren oder entfernen. Das Zuweisen eines Joysticks bindet einen Gerätedatensatz an diesen Client. Netzwerk-Joysticks senden kleine UDP- oder HTTP-Pakete und bleiben beim ersten Erkennen deaktiviert, damit niemand im LAN Kameras steuern kann, bevor ein Administrator sie freigibt. IP-Joystick-Controller verbinden sich per VISCA over IP: Der Server lauscht auf einem Port, verhält sich wie eine Kamera und leitet die Befehle an die PTZ-Schnittstelle der echten Kamera weiter.

Eine Gerätegruppe ist eine benannte Menge von Kameras auf einem Server. Benutzergruppen werden mit Gerätegruppen verknüpft, und fragt ein Benutzer Kameras ab, liefert der Server nur diejenigen, die zu einer mit einer seiner Gruppen verknüpften Gerätegruppe gehören. Die Statistik zeigt die Zahl der Kameras sowie wie viele Benutzergruppen und Benutzer Zugriff haben. Da die Regel vom Server und nicht vom Client ausgewertet wird, ist eine neu zur Gruppe hinzugefügte Kamera sofort für die richtigen Personen sichtbar; der integrierte Administrator sieht stets alles.

Die Auswahl listet alle Benutzergruppen mit einer kurzen Beschreibung ihrer Rechte, und ein Suchfeld grenzt die Liste ein. Das Hinzufügen einer Gruppe speichert auf dem Server eine Verknüpfung zwischen dieser Benutzergruppe und der Gerätegruppe. Ab dann erhält jedes Mitglied dieser Gruppe die Kameras der Gruppe in Liveansicht, Wiedergabe und Layouts – und über diese Verknüpfung keine anderen. Verknüpfen und Lösen ist ein einziger Schritt und wirkt für angemeldete Benutzer ohne Neustart.

Administratoren legen fest, ob Client-Aktionen und serverseitige Änderungen aufgezeichnet werden, ab welchem Schweregrad, welche Kategorien behalten werden und wie viele Tage die Aufbewahrung dauert. Eine Hintergrundbereinigung entfernt ältere Zeilen nach Zeitplan, und „Aufbewahrung jetzt anwenden“ startet sie auf Abruf. Authentifizierungs- und Sicherheitsereignisse werden stets mit ihrem eigenen Schweregrad behalten. Das Protokoll lässt sich als CSV oder PDF herunterladen, und ein geplanter Job kann den Bericht wöchentlich oder nach Wahl per E-Mail versenden – über den in den Ereigniseinstellungen konfigurierten Mailserver.

Das PDF wird auf dem Server aus denselben Protokollzeilen erzeugt, die der Reiter „Berichte“ zeigt – mit einer Standard-PDF-Bibliothek für Python statt per Bildschirmfoto. Es enthält Produktkopf und Logo, wer den Bericht wann erstellt hat, die aktiven Filter, eine mehrseitige Tabelle mit wiederholter Kopfzeile und eine Fußzeile. Sehr große Ergebnismengen werden begrenzt, und der Bericht weist ausdrücklich darauf hin, etwa mit „5000 von insgesamt …“. Der geplante E-Mail-Bericht hängt genau diese Datei an.

Der Makro-Editor ist ein visueller Knotengraph, der auf dem Server läuft. Ein Knoten „Systemereignis“ löst aus, wenn die Zustandsüberwachung ein passendes Ereignis meldet – etwa ein bald ablaufendes Zertifikat, hohe Festplatten- oder GPU-Auslastung oder einen schwachen Geräteakku – und gibt Ereignistext und Wert an seinen Ausgängen weiter. Mit einem Telegram-Send-Knoten verbunden, sendet er eine Nachricht über die Telegram-Bot-API. Der Graph wird mit „Validieren“ geprüft, lässt sich simulieren, und im Live-Betrieb zeigt der Editor die Werte, die durch jeden Knoten fließen.

Der Bildschirm zeigt den Telegram-Send-Knoten des Makro-Editors: Bot-Token, Chat-ID, eine Nachrichtenvorlage mit Platzhaltern für Zeit und Wert, eine Test-Schaltfläche und einen Mindestabstand zwischen den Sendungen, damit wiederholte Ereignisse den Chat nicht überfluten. Der Server sendet an die Telegram-Bot-API, sobald der Knoten eine steigende Flanke empfängt. E-Mail-Alarme nutzen den SMTP-Server, der in den Ereigniseinstellungen konfiguriert ist. Die Ereignisse selbst stammen aus der Zustandsüberwachung des Servers und den Ereignisströmen der Kameras.

Der Server definiert rund 144 Berechtigungen, jede mit einem Modul und einer Aktionsstufe wie Benutzen oder Bearbeiten. Der Gruppendialog listet sie in Abschnitten, mit Filterfeld, Kürzeln für alle/Benutzen/Bearbeiten und Voreinstellungen, die eine typische Auswahl ankreuzen. Der Server prüft die jeweilige Berechtigung bei jedem API-Aufruf und jedem Live-Kanal – ein Benutzer ohne PTZ- oder Aufzeichnungsrechte wird also auch beim direkten Aufruf der API abgewiesen. Abgelehnte Versuche werden mit dem Namen der Berechtigung ins Prüfprotokoll geschrieben.

Statt Rechte Benutzer für Benutzer zu vergeben, verschiebt ein Administrator Benutzer zwischen fertigen Gruppen wie Bedienern, Betrachtern sowie Redakteur- und Benutzerpaaren für Layouts, Makros, Karten, PTZ, Geräte und mehr. Die wirksamen Rechte eines Benutzers sind die Vereinigung der Rechte aller seiner Gruppen, dazu ihre Layouts und die Kameras der mit diesen Gruppen verknüpften Gerätegruppen. Eine Änderung an einer Gruppe wirkt sofort auf alle Mitglieder – so bleiben Rollen über viele Konten hinweg einheitlich.

Der Reiter „Ressourcen“ einer Gruppe legt numerische Obergrenzen fest, wobei null unbegrenzt bedeutet: Kameras und gleichzeitige Streams, die ein Mitglied öffnen darf, Exportlänge, -größe und -anzahl pro Tag, wie viele Layouts, Makros und Lesezeichen angelegt werden dürfen sowie API-Anfragen pro Stunde und Token. Der Server setzt sie bei jeder Anfrage durch und verweigert beispielsweise einen Stream über der Grenze. Einzelne Benutzereinstellungen können den Gruppenwert übersteuern, sodass eine gemeinsam genutzte Installation auch unter Last berechenbar bleibt.

Der Reiter „Sicherheit“ einer Gruppe legt gleichzeitige Sitzungen, Sitzungs-Timeout, verpflichtende Zwei-Faktor-Authentifizierung, minimale Passwortlänge, Komplexität, Ablauf, Wiederverwendungssperre, Sperre nach Fehlversuchen samt Dauer sowie Protokollierungsstufe und Aufbewahrung fest. Der Server setzt die Richtlinie bei der Anmeldung und bei Passwortänderungen durch; Passwörter werden als gesalzene bcrypt-Hashes gespeichert, nicht in lesbarer Form. Die Antwortzeit bei der Anmeldung ist angeglichen, damit sich ein unbekannter Benutzername nicht von einem falschen Passwort unterscheiden lässt.

Der Reiter „Berechtigungen“ des Benutzers zeigt dieselbe Matrix wie bei einer Gruppe, in zwei Farben: Blaue Kästchen sind direkte Berechtigungen, die hier geändert werden können, violette stammen aus den Gruppen des Benutzers und sind in dieser Ansicht schreibgeschützt. Der Server kombiniert beide Mengen bei der Prüfung einer Anfrage. Direkte Berechtigungen eignen sich für einmalige Ausnahmen, und der Zähler zeigt, wie viele von allen aktiv sind und wie viele aus Gruppen stammen. „Alle direkten entfernen“ beseitigt Ausnahmen, ohne die Gruppenrechte anzutasten.

Der Reiter „Sicherheit“ verwaltet den zweiten Faktor eines Benutzers – ein zeitbasiertes Einmalpasswort (TOTP), kompatibel mit gängigen Authenticator-Apps – zusammen mit einmaligen Backup-Codes. Er zeigt außerdem den Kontostatus wie Sperre, Fehlversuche und letzte Anmeldung und erlaubt einem Administrator, zu entsperren oder zurückzusetzen. Aktive Sitzungen werden mit IP und Browser aufgelistet und lassen sich einzeln oder alle zusammen beenden. API-Token sind eigene Zugangsdaten mit Namen und Ablaufdatum, sodass Skripte und Integrationen nicht das Passwort des Benutzers benötigen; sie können jederzeit widerrufen werden.

Der Reiter „Aktivität“ liest für einen Benutzer zwei Dinge vom Server: die aktiven Sitzungen mit IP-Adresse, Client-Kennung und letzter Aktivität sowie die neuesten Sicherheitsereignisse aus dem Prüfprotokoll. Abgelehnte Aktionen – etwa eine verweigerte Berechtigung oder eine Kamera, die der Benutzer nicht sehen darf – werden in dem Moment protokolliert, in dem der Server die Anfrage zurückweist, zusammen mit dem Namen der Berechtigung oder Ressource. Die Sitzungen zeigen die Art des Clients, zum Beispiel einen Browser oder ein Skript über die API, was hilft, normale Nutzung von unerwartetem Zugriff zu unterscheiden.

Der Server kann eine Zertifizierungsstelle erzeugen oder eine bestehende importieren. CA-Zertifikat und privater Schlüssel werden auf dem Server gespeichert; die Schlüsseldatei ist nur für das Dienstkonto lesbar und optional passwortgeschützt, und nur signierte Zertifikate verlassen den Rechner. Der Reiter lädt außerdem das CA-Zertifikat herunter, sichert und stellt es wieder her, installiert es im Vertrauensspeicher des Systems, widerruft Zertifikate anhand der Seriennummer und erstellt eine Sperrliste (CRL). Auch ein RADIUS-Serverzertifikat für 802.1X lässt sich von derselben CA ausstellen.

Ein neues Schlüsselpaar wird erzeugt und von der gespeicherten CA ein Zertifikat für die angegebenen Namen-, DNS- und IP-Einträge signiert, mit gewählter Gültigkeit und gewähltem Schlüsseltyp. Das Ergebnis wird als PEM (Zertifikat, Schlüssel und CA) oder als PKCS#12-Paket angeboten. Mit der Server-Option wird das Zertifikat als eigenes Zertifikat des Servers installiert, die CA für den Desktop-Client als vertrauenswürdig hinterlegt, das alte selbstsignierte Zertifikat ausgemustert und der Dienst neu gestartet – Browser zeigen dann keine Warnungen mehr, sobald sie der CA vertrauen.

Sie listen Kameras von Hand auf oder importieren eine CSV-Datei mit Adresse, Hersteller, Zugangsdaten und Ports. Für jede Zeile stellt der Server ein Gerätezertifikat aus der Zertifizierungsstelle aus, überträgt Zertifikat und CA über die Web-API des jeweiligen Herstellers auf die Kamera und schaltet dann HTTPS ein. Es gibt auch Aktionen zum Deaktivieren und zum Testen von HTTPS. Der Server muss die Kameras im Netzwerk erreichen, und die Zugangsdaten werden nur für diesen Durchgang verwendet. Das Ergebnis: ein einziger Durchgang statt einer Anmeldung an jeder Kamera.

Für eine Kamera signiert der Server ein Gerätezertifikat, lädt es über die Hersteller-API hoch und kann die CA mitschicken, HTTPS aktivieren, unverschlüsseltes HTTP abschalten und die gesicherte Verbindung testen. Der zweite Abschnitt verbindet sich per SSH mit einem anderen PotoP-Host, kopiert Zertifikat, Schlüssel und CA-Datei in das Zielverzeichnis und kann einen Dienst neu starten. Beide Vorgänge laufen auf dem Server, der das Ziel daher erreichen können muss, und erfordern Administratorrechte.

Das Panel zeigt das aktuell für den Web-Client geladene Zertifikat mit Inhaber, Aussteller, Gültigkeit, Schlüsseltyp und -länge, Signaturalgorithmus und SHA-256-Fingerabdruck und kann es als PEM exportieren. Der Mobilbereich stellt das CA-Zertifikat zum Download oder als QR-Code bereit, den ein Telefon oder Tablet scannen kann – so vertraut das Gerät dem Server einmalig und warnt nicht mehr. Installationsanleitungen und Skripte gibt es für Linux, macOS und Windows.

Bevor das Passwort gesendet wird, kontaktiert die Anmeldeseite den gewählten Server über HTTPS und prüft das Zertifikat gegen den Vertrauensspeicher des Browsers. Ist die Kette gültig und passend, erscheint die grüne Meldung „Sichere Verbindung“, andernfalls sieht der Benutzer eine Warnung. Diese Prüfung übernimmt der TLS-Stack des Browsers selbst, sie kann also von der Seite nicht vorgetäuscht werden. Die Zugangsdaten werden anschließend über die verschlüsselte Verbindung an den verifizierten Server gesendet.

Das RAID-Panel in den Server-Admin-Einstellungen ist eine Zeichen-Engine, die Platten, Stripes und Parität für das gewählte Level darstellt. Im Simulationsmodus wählen Sie Level und Plattenanzahl, und es wird ein synthetisches Array gerendert – nichts Reales wird angetastet. Auf einem Live-Server füllt sich dieselbe Ansicht aus dem tatsächlichen Controller: Software-RAID über mdadm oder Hardware-Controller über die Kommandozeilenwerkzeuge des Herstellers. Ausfalltoleranz und nutzbare Kapazität werden aus Level und Plattenanzahl berechnet, und das Diagramm zeigt, wie die Parität über die Mitglieder rotiert – so können Errichter planen, bevor sie ein Array aufbauen.

Derselbe RAID-Monitor kann auch verschachtelte Level darstellen. Hier wird ein simuliertes RAID 60 aus sechzehn Platten als vier RAID-6-Gruppen gezeigt, darüber das Striping über die Gruppen. Das Panel ermittelt die Ausfalltoleranz pro Gruppe – jede Gruppe übersteht zwei ausgefallene Platten – und die nutzbare Kapazität von acht der sechzehn Platten. Der Was-wäre-wenn-Regler darunter gibt diese Kapazität an den Rechner für die Aufzeichnungsdauer weiter, der sie durch die gemessene Kamerabitrate teilt. Geplant wird auf Basis der Serverdaten, ohne eine einzige Platte zu verändern.

Der Dialog „RAID-Verwaltung“ läuft im Desktop-Client, wirkt aber auf den Server, an dem Sie angemeldet sind. Ein Administrator gibt sein Passwort erneut ein, um ein kurzlebiges Admin-Token zu erhalten. Das Anlegen eines Arrays erstellt einen Plan: Der Server listet die erkannten Platten auf, bereitet den exakten Befehl als Argumentliste vor – niemals als Shell-String – und zeigt ihn als Vorschau. Beim Planen wird nichts ausgeführt. „Anwenden“ führt ausschließlich diesen gespeicherten Plan über eine feste Positivliste von RAID-Werkzeugen aus, und bei gefährlichen Aktionen müssen Sie zuerst die Kennung des Ziels eintippen. Software-RAID nutzt mdadm.

Erweiterungs- und Wartungsaktionen folgen demselben Ablauf „erst planen, dann anwenden“ wie das Anlegen eines Arrays. Der Client sendet die Anfrage, der Server validiert jeden Gerätenamen, baut den exakten mdadm-Befehl zum Hinzufügen von Platten, Vergrößern, Ändern der Chunk-Größe oder Umwandeln des Levels und gibt ihn zur Prüfung zurück. Scrub-Prüfung und -Reparatur starten den Konsistenzscan des Kernels auf dem Array. Minimale und maximale Resync-Geschwindigkeit sind die Standardgrenzen des Linux-Software-RAID, sodass sich ein Rebuild verlangsamen lässt, während Kameras aufzeichnen. Zum Anwenden sind das Admin-Token und bei riskanten Schritten eine Identitätsbestätigung nötig.

Der Reiter „Konfiguration“ legt fest, wie ein Ausfall erkannt wird und wie der Standby-Server aktuell bleibt. Der Monitor prüft jeden Server im eingestellten Intervall, und ein Server gilt erst nach der konfigurierten Zahl aufeinanderfolgender fehlgeschlagener Prüfungen als ausgefallen. Pflichtdienste werden immer überwacht, optionale wie VoIP oder Analysen zählen nur, wenn sie angehakt sind. Sicherungsintervall, Zahl der aufbewahrten Snapshots und eine Bandbreitenbegrenzung steuern den Replikationsagenten auf dem Failover-Knoten. Alarme können per E-Mail (SMTP), Telegram oder Desktop-Benachrichtigung ausgegeben werden.

Während eines Sicherungszyklus fordert der Failover-Knoten ein Manifest der Dateien und Datenbanken des Live-Servers an und holt dann nur das, was sich seit dem vorherigen Snapshot geändert hat. Unveränderte Dateien werden aus der vorherigen Kopie verlinkt – deshalb kann das Panel Tausende Dateien zeigen, von denen nur eine Handvoll übertragen wurde. Der Fortschritt in Dateien und Megabytes wird in einen Statusdatensatz geschrieben, den der Client live anzeigt. Der fertige Export wird in einen Snapshot-Ordner rotiert, und die Datenbankzeile des Standby-Servers zeigt „Wird synchronisiert“, solange Daten eingespielt werden.

Eine Übernahme erfolgt automatisch, wenn die Ausfallschwelle erreicht ist, oder manuell per „Übernahme erzwingen“. Der Standby-Server bedient dann die Kameras des ausgefallenen Servers, dieser wird als offline markiert, und Banner und obere Statuszeile färben sich rot. Antwortet der ursprüngliche Server wieder auf die Prüfungen, holt „Failback“ die Kameras zurück. Der Reiter „Konfiguration“ kann dies auch automatisch erledigen, nachdem der Server eine festgelegte Anzahl Minuten lang gesund war. Clients arbeiten weiter, weil Benutzer und Sitzungen bereits auf den Standby-Server gespiegelt waren.

Der Reiter „Ereignisprotokoll“ zeichnet jeden Schritt des Redundanzprozesses in Echtzeit mit lokalem Zeitstempel auf: einen erzwungenen Replikationszyklus, die Übernahmeanfrage, den Start des Übernahme-Workers, die Kameramigration, die Zahl der auf dem ausgefallenen Server gestoppten Streams und das Endergebnis. Die Einträge stammen aus der Übernahmesequenz des Servers und bleiben für die Sitzung erhalten, mit einer Schaltfläche zum Leeren. Da jeder Übergang der Reihe nach festgehalten wird, kann ein Bediener im Nachhinein prüfen, was das System getan hat, und es in einen Vorfallbericht übernehmen.

Der Reiter „Training“ enthält die Einstellungen für Datensatz, Augmentierung und Bildquellen, die einen Trainingslauf speisen. Ein Datensatz ist ein Ordner mit Bildern und Labels, gefüllt aus hochgeladenen Dateien, einer Webcam, einer Videodatei oder einem RTSP-Stream. Augmentierungen wie Mosaic, Spiegelungen, Skalierung, Rotation und Farbverschiebungen werden während des Trainings laufend angewendet. Validierungsanteil und Zufalls-Seed machen Läufe reproduzierbar. Der gezeigte Dialog erscheint, wenn „Training starten“ ohne ausgewählten Datensatz gedrückt wird. Die Konvertierung nach ONNX und in Beschleunigerformate ist ein eigener Reiter.

Die Aktionserkennung arbeitet in zwei Stufen. Zuerst läuft ein Posenmodell über Ihr Video oder Ihre Bilder und extrahiert für jede Person Körper-Schlüsselpunkte, gespeichert mit dem gewählten Label, etwa Gehen oder Stürzen. Dann wird ein kleiner Sequenzklassifikator – standardmäßig ein LSTM – mit PyTorch auf dem gewählten Gerät auf Fenstern aufeinanderfolgender Bilder dieser Schlüsselpunkte trainiert. Nach dem Training werden Precision, Recall und F1 pro Klasse auf zurückgehaltenen Validierungsdaten berechnet. Das Ergebnis lässt sich zusammen mit einem Inferenz-Snippet für den Einsatz in den Analysen exportieren.

Der Kennzeichen-Reiter trainiert ein Netz zur Erkennung von Zeichenfolgen vom Typ LPRNet, das ein ausgeschnittenes Kennzeichenbild liest und die Zeichen per CTC dekodiert. Sie wählen einen Länder-Zeichensatz und eine Eingabegröße und sammeln dann Kennzeichenausschnitte aus Aufzeichnungen, Bildordnern, URL-Listen oder öffentlichen Datensätzen. Im Label-Editor korrigieren Sie unbeschriftete Kennzeichen, optional mit OCR-Vorschlägen. „Am Bild testen“ wendet das aktuelle Modell auf ein einzelnes Bild an. Fertige Modelle werden exportiert, können zu einem Paket für Axelera-Metis-Beschleuniger kompiliert und in die Live-Erkennungskaskade eingebunden werden.

Der Annotations-Reiter ist ein Beschriftungswerkzeug innerhalb des Training Studio. Sie legen Objektklassen fest, blättern durch die Bilder des Datensatzes und zeichnen mit der Maus Begrenzungsrahmen oder Polygone. Jede Annotation wird mit Klasse und Koordinaten im Datensatzordner gespeichert, in dem Format, das die Trainer lesen. „Auto-Annotation“ wendet ein vorhandenes Erkennungsmodell auf das Bild an und schlägt Labels vor, die Sie übernehmen oder korrigieren. Das Statistikpanel zählt Annotationen insgesamt und Rahmen pro Klasse, sodass Sie sehen, welchen Klassen Beispiele fehlen.

Bestandsfragen werden direkt aus der Datenbank des Servers beantwortet, ohne Sprachmodell. Die Eingabe „Kameras auflisten“ startet eine Abfrage auf dem Server und liefert Namen, IP-Adressen, Hersteller und ob die Kamera eingeschaltet ist und aufzeichnet – dargestellt als Texttabelle im Ergebnis-Board. Dieselbe Engine deckt Pläne, Server, Layouts und Makros ab. Der Chat präsentiert nur das Ergebnis, die Antwort spiegelt also die Live-Konfiguration wider und berücksichtigt die Berechtigungen des angemeldeten Benutzers.

Anfragen, denen ein Detail fehlt – etwa eine erweiterte Kameraabfrage –, starten einen kurzen Dialog auf dem Server. Der Assistent listet die gültigen Möglichkeiten aus der aktuellen Konfiguration auf, hier jede Kamera mit ihrer Adresse, und wartet auf die Antwort. Sie antworten mit dem Buchstaben, dem Namen oder der IP-Adresse. „Zurück“ kehrt zur vorherigen Frage zurück, „Abbrechen“ beendet den Dialog. Die Auswahl wird aus Live-Daten erzeugt und bietet daher nur Kameras an, die tatsächlich existieren.

Fragen zu Datenbank und Sicherungen werden von direkten Serverfunktionen beantwortet. Der Befehl „db status“ liest die Live-Verbindung zu PostgreSQL und meldet Typ, Version, Größe, Tabellenanzahl, Verbindungspool und Host, mit maskiertem Passwort. Der Befehl „backups“ listet die auf dem Server gespeicherten Konfigurationssicherungen mit Datum und Größe. Der LLM-Schalter aktiviert ein optionales Sprachmodell, das lokal über Ollama läuft – so lassen sich freie Fragen beantworten, ohne Daten an einen Cloud-Dienst zu senden.

Der Dialog für die Ausführlichkeit ändert, wie der Chat Serverantworten formatiert. Die vier Stufen reichen von einzeiligen Zählwerten bis zur vollständigen Ausgabe einschließlich Rohwerten. Zeitstempel, Statussymbole und ASCII-Tabellen lassen sich ein- und ausschalten, ebenso ein kompakter Abstandsmodus und eine Begrenzung der in Listen angezeigten Einträge. Die Einstellungen gelten auf dem Client beim Darstellen der Antworten, sodass verschiedene Bediener am selben Server unterschiedliche Stufen nutzen können. Das Panel hinter dem Dialog ist die nach Kategorien geordnete Hilfeliste mit Beispielbefehlen.