Projektideen und Entwicklungsstand

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

Aktuelle Gesamtfolge vom 07.10.2026

Die kanonische Gesamtroadmap NETCORE-MASTER-01 legt Z01.1 als ersten Schritt fest. Frühere Prioritätslisten weiter unten bleiben als Historie erhalten. Die technische Umsetzung ist durch diesen Dokumentationslauf nicht erfolgt.

Schwerpunkt	Belegter Status	Nächster Schritt und Blocker
Z01 Deployment und Betrieb konsolidieren	Historischer Featurecode bbf0397 fehlt auf main	Z01.1 vollständige Tip-Bäume vergleichen und Integrationsplan erstellen; danach Z01.2. Kein Live-Zugriff für die Quellenanalyse nötig.
Z02 Stabilität und Gruppensteuerung	Restore-Lücken und fehlende MM-Handler statisch bestätigt	Regressionen für Floor/Watchdog, IP-Routenschutz und GroupAccessPolicyApply/GroupDgnaApply. Core-ACK ist kein fachliches Ergebnis.
Z03/Z05 Einzelzelle und Alltagspfade	TBS/Core, SDS/MQTT, SIP, Warnungen und Medien teilweise vorhanden	Ende-zu-Ende-Rückweg, Neustart und Ausfall abnehmen; reale Geräte und aktuelle Logs erforderlich.
Z04 NETCORE-IAM-01	Geplant, keine zentrale Implementierung belegt	M0 Zugänge/Ressourcen inventarisieren; M1 Architektur, Produkt, Betriebsort, Sperren und Ausfallregeln entscheiden.
Z06/Z09 NETCORE-DRIVE-01	Design und Planung, Backend offen	D0 lokale Anmeldung, Datei-/Freigaberechte und Plugin-Vertrag entscheiden. D0–D5 und D7–D9 warten nicht auf IAM/D6.
Z07 Mehrzellen	Bausteine vorhanden, durchgängiger Runtime-Kontexttransfer offen	Zweite TBS, Kontext/Floor/Medien, dann laufende Rufe abnehmen. Bost-Code ersetzt keine NetCore-Abnahme.
Z08/Z10/Z11 Bedienung und Ausbau	Dark Mode auf main; Audio, Hardware, Sicherheit teilweise/offen	Bestehendes Design ausrollen; Audio/PTT, HA-Aktoren, Sensorik und spätere HA/Security-Stufen separat prüfen.

NETCORE-IAM-01

Die aktuelle Fachroadmap ist kanonisch. Zentrale Identität, lokale Durchsetzung der Ressourcenrechte und Ablösung regulärer menschlicher TOML-Zugangsdaten sind das Ziel. Eigener Identity-LXC, Keycloak, PostgreSQL, gemeinsamer Rust-Auth-Baustein und optionale AD-Anbindung bleiben Empfehlungen/offene Entscheidungen. M0/M1 sind der nächste Schritt; die Funkvermittlung darf nicht vom Weblogin abhängen. Identity-Ausfall öffnet keinen Zugriff und reaktiviert keine regulären lokalen Logins. Control-Room-Rollen sind eine vorhandene lokale Grundlage, kein zentrales IAM.

NETCORE-DRIVE-01

Drive-Roadmap: Core Console, Workspace und Archive Studio sind bestätigte Designrichtungen. Dateiverwaltung, externe Ordnerfreigaben, Versionen/Papierkorb, Sync und Browser-Plugins sind geplant. Nextcloud Files/PostgreSQL ist eine Empfehlung, keine endgültige Produktwahl. Drive startet nach D0 mit lokalen Konten/Gruppen und vollständigen Ressourcenrechten; zentrale Anmeldung und Identitätsmigration folgen in D6. Plugins für PDF/Bild/Audio/Video, danach Office/3D/Schaltpläne/Vektoren erhalten begrenzte Dateirechte und einen eigenen Abnahmepfad. Fehlendes IAM bedeutet keine offene Dateicloud.

Historie ergänzen

• 03.10.2026: PR #59 integriert das gemeinsame Design und persistenten Dark Mode für Basisstation und 29 Dienst-WebUIs; kein neuer Release.
• 05.10.2026: Gesamtroadmap, Drive/Plugins und IAM-Erweiterung dokumentiert; keine technische Implementierung dieser Planungsziele.
• 07.10.2026: PR #60 integriert historische Projektaufzeichnungen; frühere Fehler-/Teststände bleiben historisch.
• 07.10.2026: Sechste Vergleichsquelle tetra-dispatch aufgenommen; Bost-Mehrzellencode und Last-/Timingkorrekturen neu bewertet. Neue Priorisierung zusätzlicher Portierkandidaten ist eine Empfehlung.

Historische Planungsstände bis 03.10.2026

Stand 03.10.2026 · main 6aa9be8 · Laufzeitcode unverändert gegenüber 086a81fa · Roadmap und Releases · Upstream-Vergleich

Diese Bestandsaufnahme verbindet die belegbare Implementierung mit wiedergefundenen Projektwünschen. Sie enthält ausschließlich projektbezogene, abstrahierte Ziele. Ein Wunsch, ein früherer Assistentenvorschlag und ein vorhandenes Quellmodul haben unterschiedliche Aussagekraft. Die Reihenfolge ist eine Empfehlung, kein beschlossener Releaseplan. Es gibt keine zugesagten Termine oder pauschalen Fertigstellungsprozente.

Fortschreibung vom 03.10.2026 – neue Projektideen und Aufträge

Aktuell geprüftes main: 6aa9be8. Seit f4fd490f kam ausschließlich Docs/CENTRAL_IDENTITY_RBAC_ROADMAP.md hinzu; der Laufzeitcode auf main bleibt 086a81fa, veröffentlicht ist weiterhin v1.9.0. Die folgenden neuen Arbeitspakete ergänzen die bisherigen Ziele.

Neues Arbeitspaket	Bestätigter Umfang	Belegter Status	Nächster Schritt / Abnahme
Gemeinsames NetCore-Design	Das freigegebene Grunddesign durch Basisstation und sämtliche Dienst-WebUIs ziehen; das gewünschte RF-Layout passend integrieren	26 Basisstationsansichten und 29 vorhandene Dienst-WebUIs im gemeinsamen Branch feat/netcore-dashboard-design; PR #59 offen, nicht gemergt; Branchstand 2fe2a19	PR prüfen, Installation nach den Update-Anleitungen und reale Bedienung abnehmen; noch kein produktiver Host-Rollout nachgewiesen
Dark Mode auf jeder WebUI	Hell/Dunkel einschließlich Login, Tabellen, Dialogen, Statusanzeigen und RF; Auswahl speichern	Im selben UI-Branch implementiert; Auswahl je Browser-Origin, keine netzweite automatische Synchronisierung über verschiedene Hosts/Ports	Reale Dienstadressen, schmale Displays, Login/Logout, RF und gespeicherte Auswahl prüfen; beim späteren IAM-Pilot Rechte-/Fehleransichten in beiden Themes prüfen
Zentrale Anmeldung / RBAC – NETCORE-IAM-01	Reguläre menschliche Basisstations-Zugangsdaten aus config.toml ablösen; Identität zentral, Rechte im jeweiligen Backend; Basisstation, Control Room und Management-APIs der Dienste erfassen	Kanonische Roadmap auf main; ausschließlich Planung, noch kein Identity-LXC oder migrierter Dienst nachgewiesen	M0 Zugänge/Endpunkte inventarisieren, M1 Architektur und Rollen entscheiden; eigener Identity-LXC mit Keycloak ist Empfehlung, Produkt und Betriebsort bleiben offen

Prüfnachweis für den UI-Branch: Am Commit 2fe2a1939a8795db3816d45973282781dae856f0 sind die abgerufenen GitHub-Actions-Läufe erfolgreich abgeschlossen: Basisstations-Dashboard, Dienst-WebUIs, Warnzentrale und Funkregressionen. Das ersetzt keine reale Anlagen-/HF-Abnahme. In diesem Roadmap-Update wurden keine Softwarebuilds oder Live-Tests ausgeführt.

UI-Update-Anleitungen: Basisstation · Dienst-WebUIs. Die optische Vereinheitlichung implementiert keine zentrale RBAC. Die langfristige Dienstmatrix bleibt ein Ausbauvertrag und ist nicht allein durch 29 vorhandene WebUIs vollständig erfüllt.

IAM-Meilensteinfolge: M0 Bestandsaufnahme → M1 Architektur/Rollen/Ausfallregeln → M2 Identity-Pilot → M3 gemeinsamer Rust-Auth-Baustein → M4 eine Basisstation → M5 Control Room/Zentraldienste → M6 Provisionierung und Ablösung regulärer TOML-Logins → M7 Betriebs-/Restore-Abnahme. M8 NetCore-IAM-WebUI, AD, NFC/RFID und höhere Verfügbarkeit sind spätere optionale Erweiterungen. Maßgeblich bleiben die detaillierten Kriterien in der kanonischen Docs-Roadmap.

Abhängigkeiten: Der IAM-Pilot nutzt das gemeinsame UI-Design, benötigt aber serverseitige Rechteprüfungen für APIs, Exporte und WebSocket-Aktionen. Deployment provisioniert später vertrauenswürdige Identity-Clients; Discovery allein begründet kein Vertrauen. Observability nimmt Auth-/RBAC-Ereignisse und Audit auf. Funkbetrieb bleibt unabhängig von Web-Anmeldung und Identity-Erreichbarkeit; Offline-, Sperrfrist- und Notzugangsregeln müssen in M1 festgelegt werden. AD/NFC sind keine Voraussetzung für den ersten Pilot.

Kurzfristig priorisiert: CMCE-Restore stabilisieren

Nutzerentscheidung vom 03.10.2026: Diese beiden Stabilitätsfixes zeitnah angehen. Sie bilden den nächsten eigenständigen Stabilitäts-PR und stehen in der kurzen Roadmap an erster Stelle; sie warten weder auf Mehrzellenbetrieb noch auf zentrale RBAC. Keine verbindliche Kalenderfrist beschlossen. Status: priorisiert / Portierung geplant, noch nicht in NetCore umgesetzt.

Geprüfte Grundlage: NetCore main bei 6aa9be8f74ab731f72dc133a5f8e90c5018c626d, insbesondere restoration.rs. Beide beschriebenen Unterschiede sind am Code nachvollziehbar; konkrete Ausfälle im derzeit installierten Netz wurden durch dieses Roadmap-Update nicht reproduziert.

ID / Priorität	Problem und Ziel	Geplante Änderung	Abnahmekriterien
NETCORE-CMCE-RESTORE-01 · kurzfristig hoch	Einzelruf-Restore kann auf Anforderung eine zweite Sprechfreigabe geben, obwohl beim Simplexruf der andere Teilnehmer das Sprechrecht hält	Nur bei freiem Floor oder bereits gleichem Inhaber freigeben; bei Simplex internen Inhaber passend setzen; bei fremdem Inhaber GrantedToOtherUser; ohne Anforderung NotGranted; Duplex-Verhalten erhalten	Teilnehmer A spricht, B stellt wieder her und fordert Sprechen an: keine zweite Freigabe, A bleibt Inhaber. Freier Floor und Restore des aktuellen Inhabers funktionieren. Ohne Anforderung kein Grant; Duplex erhält seine beidseitige Sprachfunktion
NETCORE-CMCE-RESTORE-02 · kurzfristig hoch	Nach Gruppenruf-Restore mit Sprechfreigabe fehlt der Benachrichtigungspfad zur UMAC; damit startet dieser Pfad die Uplink-Inaktivitätsüberwachung nicht	Erfolgreichen Grant mit den passenden FACCH-/FloorGranted-Meldungen verbinden und UMAC benachrichtigen; NetCores Carrier-/logische Slotzuordnung und zentrale Rufautorität berücksichtigen	Lokaler Grant erreicht UMAC mit richtigen Kennungen/logischen Slots; beide Carrier bleiben voneinander isoliert. Remote-Floor startet keinen lokalen Uplink-Watchdog. Wiederhergestellter Teilnehmer sendet keine Sprachframes: konfigurierte Inaktivitäts-/Freigaberegeln greifen, keine dauerhaft blockierte Ressource. Wiederholte Restores erschöpfen die Zelle nicht; legitime Sprachframes und verweigerte Grants erzeugen keine falsche Freigabe oder Überwachung

Übernahmekandidat und Herkunft: c71c9ad51462bbc64fb7669f9b192d5f6f325d8b, fix(cmce): fix floor and timeslot leaks, add group-call late entry, Autor und Committer Răzvan Zeceș, 19.07.2026. Der gleiche Commit ist in der FlowStation-Historie vorhanden und über Bost nachvollziehbar. Autorenschaft, bestehende Lizenz-/Copyright-Hinweise und Ursprungs-SHA bei einer adaptierten Übernahme erhalten; Portierungsänderungen separat kenntlich machen.

Arbeitsfolge: Fehlerfälle mit NetCore-Regressionen festhalten → beide Restore-Korrekturen gezielt anpassen → vorhandene Funk-/CMCE-Regressionen plus Timer-/Ressourcenabbau prüfen → Code-PR → reale Einzel-/Gruppenruf-Abnahme. Der Upstream-Test für Gruppen-Restore weist die UMAC-Meldung nach; für NetCore zusätzlich den tatsächlichen Timerablauf und die Ressourcenfreigabe prüfen. NetCores Herkunfts-/Routingprüfung einschließlich Local/Network-Ursprung, tatsächlichem Netzwerkziel und erlaubten Teilnehmern bleibt erhalten. Zentral verwaltete Rufe dürfen durch Restore keine Medienbereitschafts- oder Floor-Prüfung umgehen; lokale und entfernte Floor-Ereignisse getrennt prüfen. Kein pauschaler Cherry-pick des Gesamtcommits.

Zusätzlicher Umfang desselben Commits: Gruppenruf-Late-Entry ohne zweiten Circuit, Auswahl nicht sendender Preemption-Kandidaten und Aufräumen fehlgeschlagener Netzruf-/Brew-Zuweisungen bleiben getrennte Prüf-/Portierkandidaten im allgemeinen Stabilisierungspaket. Sie sind nicht durch die Priorisierung der beiden Restore-Fixes automatisch mitbeauftragt oder umgesetzt. Upstream-Vergleich · Mehrzellenbetrieb

Historischer Pflegebefund vom 02.10.2026

Veröffentlicht: v1.9.0. Auf main: f4fd490f; nach 086a81fa wurden nur die datierten Dokumentausgaben gemergt. Nur im Entwicklungsbranch: Deployment/Discovery, Pi-Images/VPN und Syslog bei bbf0397, Komponentenversion 0.2.3. Der jüngste geprüfte CI-Lauf bleibt 36349402097. Keine neuen Laufzeit- oder Funkprüfungen in diesem Pflege-Lauf.

Separates Artefakt: Der bereitgestellte Windows-Launcher NetCore-Discovery.bat trägt Stand 28.09.2026 / Rollout-Fix 0.2.6. Die aktuelle Datei enthält SSH-Portprüfung und verdeckte Eingabe beim Bereitschaftshinweis. Dies ist kein Repository-Release und kein Beleg eines erfolgreich abgeschlossenen Anlagenrollouts. Vor Verwendung den Launcher mit Agent-/Controller-Commit und tatsächlichen Rollen abgleichen. Standortdaten bleiben außerhalb des öffentlichen Wikis.

Neue Vergleichsquelle: Bost FlowStation wird bei bb87b84c (01.10.2026) als fünfte Quelle geführt. Neu sind LST-Hangtime-/PTT-Korrekturen und Stations-/Profilpakete. Ältere Restore-Korrekturen aus c71c9ad5 fehlen im entsprechenden NetCore-Pfad und sind sinnvolle Prüf-/Portierkandidaten. Ein fertiges Seamless-Handover ist dadurch nicht belegt. Upstream-Vergleich · Mehrzellenbetrieb

Empfohlene Ergänzung der Prioritäten 4 und 5: zuerst konkurrierende Sprechfreigaben und stummen Teilnehmer nach Restore reproduzieren, danach die Korrekturen an NetCores Dual-Carrier-/Core-Verträge anpassen; anschließend den durchgängigen Medien-/Kontextübergang über zwei TBS prüfen. Stationspakete bleiben eine Empfehlung für spätere Recovery-Arbeit, keine beschlossene oder implementierte NetCore-Funktion.

Dokumentationshistorie: Die sechs Dateien vom 28.09.2026 aus PR #58 sind seit 02.10.2026 auf main. Der Merge ändert den NetCore-Funktions-/Installationsstand nicht. Daher keine neue Handbuchausgabe und kein zusätzlicher Dokumentations-PR am 02.10.2026. Frühere Meilensteine und vollständige Releasechronik bleiben erhalten.

Kurze Entwicklungsroadmap ab 03.10.2026

Die Reihenfolge ist eine Empfehlung ohne zugesagte Termine. Die beiden Restore-Fixes bilden den nächsten kurzfristigen Stabilitätsblock. UI-Abnahme, IAM-Bestandsaufnahme und bestehende Infrastrukturarbeiten können parallel weiterlaufen. Historische Phasen und Releases bleiben erhalten.

Priorität	Ziel und heutiger Stand	Nächster Schritt und Blocker
1	CMCE-Restore: beide Fixes kurzfristig hoch priorisiert, Portierung geplant	NETCORE-CMCE-RESTORE-01/02: doppelte Simplex-Freigabe verhindern und UMAC-Inaktivitätsüberwachung nach Gruppen-Restore starten; gezielter Stabilitäts-PR mit Regressionen und realer Abnahme; kein Warten auf Mehrzellen/RBAC
2	Deployment-VM, Discovery und gezielte Updates: Entwicklung 0.2.3, CI geprüft	Bestands-LXC/VM-Rollen, verlorenen Auftrag und Wiederanlauf real prüfen; PBX als VM korrekt behandeln; danach Code-PR nach main
3	Einheitliche WebUIs und Dark Mode: 26 Basisstationsansichten / 29 Dienst-WebUIs, PR #59, Branch 2fe2a19, abgerufene CI-Läufe erfolgreich	PR-Review und reale Bedienabnahme anhand der Update-Anleitungen; Merge und Host-Rollout noch offen
4	Zentrale Anmeldung / RBAC: NETCORE-IAM-01 auf main dokumentiert, technische Umsetzung geplant	M0 Endpunkt-/Rechtematrix und M1 Architekturentscheidung; Produkt, Betriebsort, Ressourcenrechte und Ausfallregeln offen
5	Pi-Image und VPN-Autotoggle: Rezept und Netzrichtlinie im Entwicklungsbranch	SXceiver-Pi booten; physische LAN/WLAN/VPN-Wechsel und isolierten Weiterbetrieb prüfen; Tunnelroute nicht als Heimnetz werten
6	Syslog und NAS-Archiv: Implementierung im Entwicklungsbranch	Sender→RELP→Collector→gzip am echten Share abnehmen; Mountausfall, Retention und Verlustzähler
7	main stabilisieren und Upstream-Reparaturen übernehmen	Audit-/API-/Config-Drift, Circuit-Reopen, SDS, RTP/CANCEL und MAC prüfen; Late Entry, Preemption und Netzruf-/Brew-Cleanup des Restore-Quellcommits getrennt prüfen; weitere Portierungen mit Regressionen
8	Laufender Mehrzellenruf und Leitstellen-Arbeitsplatz: Fachkerne/UI vorhanden, Gesamtpfad offen	Zwei reale TBS, konkurrierende Sprecher/Restore, SIP-/Medienübergang, Desktop-Audio/PTT und Dispatch-Autorität abnehmen; IAM für Management anbinden
9	HA/Homematic, Hardware und Simulation: Grundlagen vorhanden	Quittierte Funk→MQTT→Aktion→SDS-Kette messen; Simulatorvertrag, Pinbelegung, Sensor-/Anzeige-Module und Rack-Prototyp
10	Betriebsreife und weitere Erweiterungen	IAM M5–M7, TLS, Recovery und Versionskonflikte; AD/NFC und höhere Verfügbarkeit später; Nexus-2-/Router-/Gateway-Konzepte nach Quellen-/Hardwareprüfung

Weitere erhaltene Ideen sind virtuelle Funkgeräte mit PTT, Tasten, Display und GPS/Zellwechsel, ein getrennt nutzbarer Brew-Server mit klarer Rufautorität, NFC/RFID-/AD-Anmeldung, vom kleinen Touchscreen bis zur Anzeigewand skalierbare Leitstellenfenster sowie GPIO, Sensoren, Lüfter, Anzeigen, Watchdog und eine spätere Rack-Platine. Mock-TBS, native UI, Hardware Gateway oder RF Monitor sind vorhandene Grundlagen, aber kein fertiger Simulator, Audio-Arbeitsplatz oder geprüfter PCB-Entwurf. Ein vollständiger Geräte-/RF-/ETSI-Simulator und ein real abgenommener Mid-Call-Handover bleiben eigenständige Ziele.

Auch mobile Router mit 5G, M.2-Funkmodulen, Access Point und kleinem Switch sowie weitere Voice-Gateways wie Zello/FRN bleiben erhaltene Ausbauideen. Für diskutierte BPI-R4-/R4-Pro-Varianten sind Strombudget, Treiber, Antennen, AP-Betrieb und VPN-Übergänge noch konkret festzulegen. Ein Pi-5/AI-HAT war eine Machbarkeitsidee ohne beschlossenen NetCore-Anwendungsfall.

Die aktuelle Entwicklungsentscheidung lautet Ubuntu-VM für den Imagebuilder, getrennte Observability im bestehenden LXC und lokale Caches für den Weiterbetrieb ohne Zentrale. Sie konkretisiert die ältere Deployment-LXC-Idee, ohne sie aus der Historie zu entfernen. Reale Zugangsdaten, private Adresslisten und projektfremde Gesprächsinhalte werden nicht Bestandteil dieser Roadmap.

Deployment und Inbetriebnahme

Entwicklung statt nur Planung. Der frühere Wunsch nach Deployment-LXC/VM ist im Entwicklungsbranch als Ubuntu-VM mit WebUI, Git-Abgleich, gezielten Updates, Hostrollen, Discovery und Pi-Imagebuilder konkret umgesetzt. Version 0.2.3 verlangt echte installierte systemd-Units und schränkt Rollouts auf die gewählte Hostrolle ein. Ein Controller-LXC bleibt ohne Imagebuilder nutzbar. Main enthält weiterhin den bisherigen CLI-Deployer. Deployment und Discovery

Wizard Neue TBS und Image. Name, MCC/MNC, ISSI, LA und CC sowie eine geprüfte Standort-TOML liefern Profil und Bootstrap. Das ARM64-Image wird vor dem Download gebaut; Pi-Boot, SDR und lokaler SIP-Fallback benötigen eigene Prüfungen. Ein allgemeiner atomarer Rollback oder bitidentischer Neubau ist nicht zugesichert. Teilnehmer-/Gruppen-Provisioning ist eine getrennte Aufgabe. Provisioning

Dienstsuche und Pi-VPN. Rollen, 90-Sekunden-Lease, Konfliktanzeige, lokaler Cache, manuelle Suche und Seeds sind im Branch vorhanden. Suchen startet keine Funkdienste neu. VPN-Autotoggle wertet physische NetworkManager-WLAN/LAN-Verbindungen aus und ignoriert die Tunneladresse als Heimnetznachweis. Reale Wechseltests bleiben offen; private SSIDs, Präfixe und Schlüssel stehen nur in lokaler Konfiguration.

Syslog und Netzwerkarchiv. Die Entscheidung vom 27.09. hält Observability im eigenen LXC und die Deployment-Verwaltung auf der VM. PR #57 wurde in den Entwicklungsbranch integriert. Separater RELP-/Syslog-Empfang, begrenzte Vorschau, tägliche verifizierte gzip-Archivierung und Verlustzähler sind im Code vorhanden. Standortberichte sind keine in diesem Lauf unabhängig bestätigte NAS-Abnahme. Syslog und Archivierung

Funk, Simulation und Medien

Virtuelle Funkgeräte/TBS. Gewünscht wurden PTT, Display, Tasten/D-Pad, GPS und steuerbare Zellwechsel in einer Weboberfläche (11.09.). mock_tbs.py ist bereits ein deterministischer Integrationspartner für Core-Tests. Er belegt weder einen vollständigen RF-/ETSI-Simulator noch die gewünschte Gerätebedienung. Eine ältere virtuelle Luftschnittstelle über WebSocket neben HF und Android-VMs wurde ebenfalls angesprochen; der vollständige aktuelle Pfad wurde hier nicht nachgewiesen und bleibt separat zu prüfen.

Laufender Mehrzellenruf und Latenz. Mobility Core, Call Control und Media Switch sind vorhanden. Call Control besitzt bereits Readiness-Prüfungen für Medienwege; die Latenzarbeit beginnt nicht bei null. Offen bleiben reproduzierbare Messungen von PTT bis Audio, beiden Richtungen, Zellwechsel, Kontext-/SIP-Übernahme und Wiederverbindung. Frühere geschätzte Millisekundenwerte sind keine Messresultate. Mehrzellenbetrieb · Calls

Brew und zentrale Rufautorität. Ein separater Rust-Brew-Server liegt unter misc/brew-server; der ältere Python-Server bleibt ebenfalls erhalten. Die diskutierte engere Integration braucht eine klare Zuständigkeit für Call Control, Floor, Medien und externe Bridges. Ein automatischer Ersatz des laufenden Python-Servers oder eine komplette Verlagerung aller Cores in Brew ist nicht beschlossen. SIP-und-Brew

Leitstelle und Bedienung

Nativer Arbeitsplatz. Der Wunsch vom 13.09. reicht von kleinen Touchscreens bis zu mehreren Monitoren beziehungsweise einer Anzeigewand. Unter control-room/ui liegen bereits eine native Rust-UI mit eframe/egui, abtrennbare Fenster und Kartenfunktionen. Ein vollständiger Audio-Arbeitsplatz mit Aufnahme/Wiedergabe, PTT und nachgewiesener Ende-zu-Ende-Latenz ist daraus nicht abzuleiten. Der vorgeschlagene Dispatch-Kern muss die bestehenden Fachkerne koordinieren und ihre Autorität eindeutig abgrenzen. Control-Room

Identität und Rechte. Rollen, privilegierte Administration, Anmeldung mit NFC/RFID und Anbindung an AD sind Ausbauwünsche. Die Auth-Unterlagen beschreiben vorbereitete Rollen; Open Lab arbeitet mit deaktivierter Authentisierung. NFC-/AD-Integration wurde im aktuellen Control-Room-Code nicht nachgewiesen. Zuerst Berechtigungsmodell und Sitzungslebenszyklus festlegen, danach Leser/Verzeichnisdienst und Ausfallverhalten testen. Security-and-Operations

Integrationen und Hardware

HA/Homematic. MQTT, Home-Assistant-Discovery, Command/Ack-Ledger und Default-Deny-Regeln sind bereits vorhanden. Ein älterer Bericht über ausbleibende SDS-Nachrichten beweist keinen fortbestehenden Fehler im heutigen Build. Der nächste Nachweis ist eine reale, korrelierbare Kette Funkstatus → IoT Gateway → Automation → Ergebnis → SDS, einschließlich Wiederholung, Timeout und Neustart. MQTT-und-Home-Assistant

GPIO, Anzeigen und Rack. Genannt wurden Sensoren/Aktoren, Temperatur-/Spannungsüberwachung, Lüfter, LEDs, LCD/TFT, Watchdog und eine eigene Platine. Hardware Gateway und RF Monitor bilden Softwaregrundlagen. Eine fertigungstaugliche und geprüfte Platine oder ein getesteter Treiber für jede Hardware ist damit nicht belegt. Für den nächsten Schritt konkrete Sensoren, Busse und Pinbelegung wählen und mit Modulen prüfen; frühere Entwürfe und gewünschte spätere PCB-Arbeit bleiben als solche erhalten. RF-Monitor-DSP-EVM vor der Endstufe ist kein Ersatz für gemessene Sendeleistung/VSWR. Hardware-und-RF

Mobiler Router, 5G und WLAN. BPI-R4-/R4-Pro-Varianten, SIM/M.2-Mobilfunk, Access Point und ein kompakter Switch wurden im Juli/September diskutiert. Modell und Funkmodule sind hier nicht als endgültig ausgewählt oder abgenommen festgeschrieben. Vor Umsetzung: Strombudget, Treiber, Antennen, AP-Betrieb und VPN-Übergänge prüfen. Die zusätzliche Pi-5/AI-HAT-Idee war eine Machbarkeitsfrage; ein konkreter NetCore-Anwendungsfall ist noch offen.

Weitere ältere Ideen. Zello/FRN und zusätzliche Voice-Gateways, aktive LIP-Anforderungen, Karten-Erweiterungen, mobile Bedienung/Asset-QR sowie ein SystemPulse-ähnlicher Betriebsüberblick bleiben eine Sammlung zu konkretisierender Ziele. Karten, GPS-/LIP-Verarbeitung und Observability sind teilweise bereits vorhanden; die älteren Ideen dürfen nicht pauschal als fehlende Grundfunktionen behandelt werden. Die damalige Priorität für aktive LIP-Abfragen und weitere Kartenfunktionen war nachrangig. Ein kleiner mobiler Rack-Aufbau und Strom-/Gewichtsfragen sind Hardwareplanung, kein abgeschlossener Softwaremeilenstein.

Herkunft, Statuspflege und Grenzen

Grundlage sind die veröffentlichten Releases, der fixierte main-Stand, bestehende Roadmap-Dateien und die für diesen Lauf verfügbaren einschlägigen Projektgespräche aus Juli bis Oktober 2026. Die Recherche ist keine Garantie, dass jedes frühere Gespräch vollständig erfasst wurde. Frühe Wünsche (etwa eine ausschließlich native Bedienung) werden historisch erhalten, aber nicht gegen später hinzugekommene Weboberflächen als heutige Ausschlussregel ausgelegt.

Statuswechsel benötigen Belege: geplant → konkreter Entwurf/PR → nur im Entwicklungsbranch → auf main implementiert → veröffentlicht; Labor-/Feldabnahme wird separat benannt. Alte Fehlerbeobachtungen bleiben historisch, bis sie am aktuellen Stand reproduziert sind. Die vollständige Releasechronik und bereits erreichten Meilensteine stehen weiterhin unter Roadmap und Releases.