Repository navigation
Control Room
Verbindlich: main@8fb581b730f7a3833566c4bbb7c87875ad921e69; veröffentlicht bleibt v1.9.0. PR #74–#97 sind integriert. Deployment/Discovery, Imagebuilder, Pi-VPN und Syslog sind auf main, nicht mehr nur historische Vorschau. 26 reguläre Rollen einschließlich Deployment-VM; Provisioning ist optional zusätzlich.
Betreiberbestätigt: KDE-Boot, Rufe, SDS, Aufnahme/RF-Wiedergabe und WLAN am 13.10.; 28/28 Discovery-Agenten aktualisiert und keine ungeklärten Remote-Aufträge mehr am 15.10. Ein aktueller Backend-Gesamtrollout, NAS-Entlastung, SIP/Telegram, VPN-Wechsel und Dauerlauf bleiben separat offen. Vier alte Git-/Timeoutfehler bleiben Fehler.
Gesamtroadmap · Upstream-Vergleich · Roadmap und Releases. NETCORE-IAM-01 ist weiterhin Planung; AD-SSO-Pilot und Gruppenmapping sind konkretisiert, Produkt-/Betriebsentscheidung und Umsetzung offen.
Aktuelle Fachanleitung und Grenzen. Die bestätigte Pi-Kurzabnahme gilt nur für den dokumentierten Build und Funktionsumfang; sie ist keine generelle Mehrzellen-, SIP-, VPN- oder Dauerlaufabnahme.
Die folgende frühere Fassung bleibt als datierte Historie erhalten. Frühere Dienstzahlen, Featurebranch-Aussagen, offene Tests und Prioritäten sind keine aktuelle Statusaussage; heutige Verfahren stehen oben beziehungsweise in den verlinkten kanonischen Docs.
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
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.
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.
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.
[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
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
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.
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
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.
NetCore Tetra Systemwiki · Quellenstand main@8fb581b7, Abgleich 16.10.2026 · Release v1.9.0
Start · Projektstand · Roadmap und Releases · Sechs Upstreams · Deployment · Logs und NAS · Gesamte aktuelle Dokumentation
Datierte Altstände bleiben Historie. Konfiguration, installierter Build und tatsächliche Fach-/Funkprüfung bleiben für die konkrete Anlage gesondert zu prüfen.
NetCore Tetra
System
Aufbau
- Hardware und HF
- Installation
- Konfiguration
- Open-Lab-Deployment
- Deployment und Discovery (auf main)
- Provisioning
- Abnahme
Funk und Daten
- ISSI und GSSI
- Registrierung
- Rufe
- Dual Carrier
- SDS und U-STATUS
- Home Mode Display
- LIP und GPS
- Paketdaten und WAP
- Mehrzellenbetrieb
Bedienung und Integration
- Warnzentrale
- Dashboard
- Control Room
- Directory
- Directory API
- Geräte
- Basisstationen
- Gruppen
- Statusmeldungen
- Gerätegruppen
- Audio-Zentrale
- Integrationen
- SIP und Brew
- MQTT und Home Assistant
Betrieb und Hilfe