Control Room und Node Gateway

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Nur main ist als Branch vorhanden. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

Oberflächen auf main seit PR #59

26 TBS-Ansichten und 29 Dienst-WebUIs verwenden das gemeinsame Design mit Hell/Dunkel. Die Basisstation behält zusätzlich Blau. Die Auswahl gilt pro Browser-Origin; Host-/Portwechsel teilen sie nicht. Rust-Binaries sowie Python-/HTML-Bundles betten die Assets ein, ein Node-Dienst ist nicht nötig. Design aktiviert kein zentrales IAM. Roadmap und Releases

Nach dem Update Anmeldung, Theme nach Neuladen, Formulare/Tabellen/Dialoge, schmale Darstellung und vorhandene Fachaktionen prüfen. RF-Lücken bleiben fehlende Daten; DSP-Pegel ist keine kalibrierte Antennenleistung. Nachbarzellenanzeige ist keine Handovermessung. Bei alten Assets Browser hart neu laden.

Dispatch und Identität

Zentrale IAM-Anbindung bleibt geplant; lokale Konten/Rollen sind keine netzweite SSO-Lösung. tetra-dispatch ist neue Audio/PTT-/LIP-Referenz mit Brew-Wireformat und eigenem Operator. NetCore muss die eigene Call-Control-/Media-Switch-Autorität beibehalten; Browser-Audio und echte Headset/PTT-Abnahme bleiben eigene Aufgaben. Upstream-Vergleich

Im verteilten Aufbau sind Node Gateway und Control Room verschiedene Dienste. Die TBS verbindet sich über [control_room] per WebSocket mit dem Node Gateway (/ws/node, Managementport im Beispiel 8080). Control Room (9010 im Inventory) zeigt netzweite Zustände und verarbeitet Operatoraktionen. Ein TBS-WebSocket direkt zur Control-Room-WebUI ist in dieser Topologie der falsche Zielpfad.

Daten- und Befehlsweg

TBS ── /ws/node ──> Node Gateway ── Fach-APIs/Backend-Sessions ──> Control Room
  <─────────────── Health-Matrix und autorisierte Kommandos ───────────────

node_id bezeichnet die TBS stabil im Backend. Control Room besitzt Operatorprofile, Rollen und Arbeitsplatzansichten; die lokale TBS bleibt RF- und CMCE-Instanz. Der vollständige Control-Room-Quellort enthält Core, UI, Auth-/Profil- und Deploymentunterlagen. Daneben gibt es bins/netcore-control-room; beim Deployment nicht ältere Standalone-Beispiele mit dem 25-Dienst-Inventory vermischen.

TBS-Anbindung im Open Lab

[control_room]
enabled = true
host = "<NODE-GATEWAY-IP>"
port = 8080
use_tls = false
endpoint_path = "/ws/node"
node_id = "TBS-LAB-01"
station_name = "TBS-LAB-01"
site = "Lab"

Nur diesen Block in eine vollständige und passende TBS-TOML übernehmen. Die sanitisierte Vorlage deaktiviert die Anbindung zunächst. Bei aktivem Open-Lab-Modus sind Node- und Managementverbindungen im isolierten Testnetz zu halten. Bei gesicherter Bereitstellung müssen Authentisierung und TLS für alle beteiligten Endpunkte gemeinsam geplant werden. Security-and-Operations

Bedienung und Grenzen

Die Codebasis bereitet Operatorrollen und Profile für menschliche Zugriffe vor. Im aktuellen Open-Lab-Profil sind Authentisierung und Rollenprüfung jedoch absichtlich deaktiviert (auth.enabled=false und --no-auth). Vor einem gesicherten Betrieb müssen Anmeldung, TLS, Maschinenidentität und Rechte gemeinsam aktiviert und getestet werden. Ein Node-Token (falls konfiguriert) dient dagegen der TBS-Identität. Der UI-Arbeitsplatz ersetzt weder die Teilnehmerdaten des Subscriber Core noch die Gruppenpolicy des Group Core. Bei Ausfall des Control Room kann die TBS lokal weiterarbeiten; bei Node-Gateway-Ausfall folgt sie dem [Mehrzellenbetrieb]]- und [Fallback-Verhalten.

Für einen Fehler zuerst Gateway-Listener, /ws/node, Service-Matrix und TBS-Logs prüfen, anschließend Control Room und dessen Fach-APIs. Netzwerk-und-Ports · Troubleshooting

Lesende Gateway-Telemetrie für Warnungen

Ab v1.9.0 liest [node_gateway] die Teilnehmer-/GPS-Lage über ws://node-gateway:8080/ws/backend. Die Vorlage startet mit enabled=false, reconnect_secs=3, timeout_secs=10 und stale_after_secs=30. Dieselbe Gateway-Adresse wie beim SDS Router setzen und den tatsächlich von der Unit gelesenen Config-Pfad prüfen. Nach Erstverbindung neue Registrierung/GPS-Meldung abwarten; ein vollständiger alter Positionssnapshot wird nicht geliefert. Dieser Kanal ermöglicht die Warnzentrale, ersetzt aber keine Fachautorität der Core-Dienste.

Stand des nativen Leitstellen-Arbeitsplatzes

Die native Rust-UI verwendet eframe/egui und enthält bereits abtrennbare Fenster sowie Kartenansichten. Ein vollständiger Desktop-Audio-/PTT-Pfad und die gewünschte NFC/RFID-/AD-Anmeldung sind damit nicht belegt. Die weitere Planung umfasst kleine Touchscreens bis zu mehreren Monitoren, einen klar abgegrenzten Dispatch-/Audiopfad und ein wirksames Rollenmodell. Projektideen und Entwicklungsstand · Roadmap und Releases

Upstream-Prüfpunkt vom 02.10.2026

Bost FlowStation bb87b84c korrigiert die lokale LST-Konsole: Hangtime-Late-Entry ohne aktiven Sprecher darf RX/PTT nicht als belegt verriegeln; Rufende räumt RX und Preempt auf. NetCore hat einen eigenen nativen Control Room und kein entsprechendes net_lst_dispatch-Modul. Die Zustandsfälle sind als Testkonzept sinnvoll übertragbar, ein direkter Patch oder ein nachgewiesener NetCore-UI-Fehler folgt daraus nicht. Vor Umsetzung Event-Verträge zwischen Arbeitsplatz, Call Control, Medien und Brew abgleichen. Upstream-Vergleich

Planungsreferenzen: Zentrale Anmeldung und RBAC · NetCore Drive. Beide Vorhaben sind Planung; keine installierte main-Funktion.