RBT (SmartYard-Server) – der Kern der Plattform

RBT (SmartYard-Server) ist das Haupt-Backend der SmartYard-Plattform. Es speichert die vollständige Konfiguration und den Betriebszustand (Gebäude, Eingänge, Geräte, Benutzer, Schlüssel), sorgt dafür, dass Gegensprechanlagen und IP-Relais an diesem Modell ausgerichtet sind, orchestriert Intercom-Anrufe über Asterisk, liefert Push-Benachrichtigungen, sammelt und verarbeitet Ereignisse und lässt sich in Medienserver, RBT-TT und Überwachung integrieren.

Repository: https://github.com/rosteleset/SmartYard-Server

Was RBT speichert und verwaltet

Infrastruktur und Topologie

Geräte: Gegensprechanlagen, CCTV-Kameras, IP-Relais
Gebäude/Objekte: Gebäude, Anzahl Eingänge, Wohnungsbereiche pro Eingang
„Tormodus“: Eingänge, die eine Gebäudegruppe bedienen

Benutzer und Berechtigungen

Residente mobile App-Konten
Berechtigungen pro Benutzer für alle Wohnungen, denen der Benutzer zugewiesen ist

Schlüssel und Zugangscodes

mehrere Schlüsselebenen:
Benutzer-Schlüssel
Wohnungsschlüssel
Gebäude-Schlüssel
Schlüssel Verwaltungsgesellschaft
Hauptschlüssel (alles öffnen)
Zugangscodes zur Wohnung

Subsysteme innerhalb von RBT (SmartYard-Server)

1) Kerndomäne (Registrierung + Zugriffskontrolle) – Systemmodell und Zugriffslogik

Ein einzelnes Kernsubsystem, das als Quelle der Wahrheit für die gesamte Plattform fungiert:

speichert die Standorttopologie: Gebäude, Eingänge, Wohnungsbereiche, Eingangsmodi (einschließlich „Gate-Modus“, der mehrere Gebäude bedient)
speichert den Gerätebestand: Gegensprechanlagen, Kameras, IP-Relais und deren Bindungen
speichert Benutzer und ihre Berechtigungen/Privilegien in allen Apartments
speichert Schlüssel und Zugangscodes (Benutzer-/Wohnungs-/Gebäude-/Verwaltungs-/Hauptschlüssel)
führt Berechtigungsprüfungen durch und generiert Zutrittskontrollaktionen (Tür/Tor/Schranke)

Dieses Domänenmodell und dieser Regelsatz werden vom Autokonfigurator, der mobilen API, der Ereignispipeline und den Integrationen genutzt.

2) Autokonfigurator – gewünschte/tatsächliche/unterschiedliche Gerätesynchronisierung

Konvergiert die Intercom- und IP-Relay-Konfiguration automatisch mit dem gewünschten, in RBT definierten Zustand:

– kompiliert eine Sollzustandskonfiguration für jedes Gerät aus der Kerndomäne - liest die aktuelle (tatsächliche) Gerätekonfiguration - berechnet einen Diff zwischen tatsächlich und gewünscht - Wendet nur die erforderlichen Änderungen („Patch“) an, um den Zielzustand zu erreichen – Reduziert unnötige Umschreibungen/Neustarts und sorgt dafür, dass der Gerätestatus mit dem Datenbankmodell übereinstimmt

3) Mobile API (Application API) – Schnittstelle für mobile Apps

Öffentliche API, die von iOS-/Android-Clients verwendet wird: - Authentifizierung/Sitzungen - verfügbare Gebäude/Wohnungen/Geräte - Zugriffsaktionen (z. B. „Öffnen“) mit Berechtigungsprüfungen - Ereignisse und Geschichte - Vergabe von Medienzugriffsparametern über den Medienserver (HLS / WebRTC)

API-Dokumentation

Wichtig: Mobile Clients empfangen Videos über den Medienserver, nicht direkt von Kameras.

3.1) Anpassungsebene – Benutzerdefinierte Felder + überschreibbare Module + Weberweiterungen

RBT unterstützt eine Anpassungsebene, die dabei hilft, die Geschäftslogik zu erweitern, ohne das Kernprojekt zu verzweigen.

Benutzerdefinierte Felder für Wohnungen sind in der Benutzeroberfläche verfügbar – Benutzerdefinierte Felder für andere Entitäten werden auch auf Modell-/Backend-Ebene unterstützt
Benutzerdefiniertes Verhalten kann über überschreibbare Backend- und mobile API-Module implementiert werden (z. B. in backends/*/custom und mobile/*/custom).
Web-Erweiterungen für mobile Apps sind ebenfalls Teil dieser Ebene für die Benutzeroberflächen-/Workflow-Anpassung (siehe Web-Erweiterungen)

Praktisches Beispiel: Sie können die Blockierung von Gegensprechanlagen und Kameras in separate Wohnungsfelder aufteilen und das API-Verhalten basierend auf diesen Werten anpassen – und gleichzeitig vorgelagerte RBT-Updates einfacher durchführen.

3.2) Abrechnungsintegration – Basisfunktionen

RBT umfasst eine Basis-Integrationsschicht für die Abrechnung zur Synchronisierung zwischen Abrechnungs- und Plattformdaten.

Import der Adresshierarchie in RBT (Region → Stadt → Straße → Gebäude → Wohnungen + Haustechnik)
Synchronisierung von Wohnungsabonnements/Verträgen mit Aktualisierungen an:
Status
Login/Passwort
Benutzerdefinierte Felder
Telefonnummern der Benutzer

Dokumentationsbeispiel: Abrechnungsintegration

4) Telephony Orchestrator – Asterisk-Automatisierung

Verwaltet Asterisk automatisch für die Abwicklung von Intercom-Anrufen und der Interaktion zwischen Intercom und mobiler App.

5) Push & Messaging – Zustellung von Benachrichtigungen

Liefert Push-Benachrichtigungen für Intercom-Anrufe und andere Systemmeldungen/Ereignisse an mobile Apps.

6) Ereignispipeline (Syslog Ingest) – Ereigniserfassung und -verarbeitung

Ein dediziertes Subsystem, das Ereignisse über Syslog empfängt, sie normalisiert und mit Metadaten anreichert, sie in ClickHouse speichert und Folgeaktionen auslöst.

Hauptaufgaben: - Syslog-Aufnahme von Geräten/Diensten - Parsing, Normalisierung, Anreicherung (Gebäude/Eingang/Gerät/Wohnung/Benutzer) - Schreiben strukturierter Ereignisse in ClickHouse (einschließlich Metadaten und bei Bedarf Snapshots/Links) - Erkennungstrigger: Initiiert für unterstützte Ereignistypen die FALPRS-Verarbeitung (Gesichter/Platten)

7) Ereignisspeicher (ClickHouse) – Ereignisspeicher

Speichert den vollständigen Ereignisverlauf in ClickHouse: Ereignismetadaten sowie zugehörige Artefakte (z. B. Kamera-Schnappschüsse).

8) Medienrouting – Zuordnung von Kameras zu Medienservern

Behält die Zuordnung von Kameras/Streams zu Medienservern bei. Video erreicht Clients nur über den Medienserver mit HLS/WebRTC.

9) Kamerapräsentation – wie Kameras in der App angezeigt werden

Ermöglicht die Definition der Kamerapräsentation für Bewohner: - Ordnerbaum - Kartenbasierte Ansicht (geografisches/visuelles Layout)

10) Ticketing-Integration (RBT-TT)

Erstellt und pflegt Servicetickets in RBT-TT für betriebliche Arbeitsabläufe, die von Bedienpersonal und Außendiensttechnikern (PWA) abgewickelt werden.

11) Überwachungsintegration (Zabbix)

Überwacht aktive Geräte über die Integration mit Zabbix.

Übersichtstabelle „Subsystem → Verantwortung“

Subsystem	Verantwortung	Speicher/Integrationen
Kerndomäne	Topologie, Geräte, Benutzer, Schlüssel, Berechtigungen + Zugriffsaktionen	RBT DB
Autokonfigurator	gewünschte/tatsächliche/Diff-Synchronisierung und Patch-Updates	RBT ↔ Gegensprechanlagen/IP-Relais
Mobile API (Anwendungs-API)	iOS/Android-API: Zugriff, Ereignisse, Medienparameter	ApplicationAPI + RBT
Anpassungsebene (benutzerdefinierte Felder + Weberweiterungen)	Projektspezifische Daten/Modell + mobile UI/Workflow-Erweiterungen ohne Core-Forking	RBT + überschreibbare Module + SmartYard-web
Abrechnungsintegration	Adresshierarchie-Import + Abonnements/Verträge synchronisieren	Abrechnung ↔ RBT
Telefonie-Orchestrator	Asterisk-Verwaltung, Intercom-Anrufe	Sternchen
Push & Messaging	Push-Benachrichtigungszustellung	Push-Anbieter
Ereignispipeline (Syslog Ingest)	Syslog → normalisieren → speichern → Erkennung auslösen	Syslog → ClickHouse → FALPRS
Ereignisspeicher	langlebiger Eventshop	ClickHouse
Medienrouting	„Kamera → Medienserver/Streams“-Zuordnung	Flussonic/Alternativen
Kamerapräsentation	Ordnerbaum / Kartenansicht	RBT
Ticketing-Integration	Tickets & Betriebsabläufe	RBT-TT
Überwachungsintegration	Geräteüberwachung	Zabbix

Typische Abläufe

Automatische Gerätekonfiguration (unterschiedsbasierte Updates)

1) Datenänderungen in RBT (Berechtigungen/Schlüssel/Wohnungen/Geräte)
2) Der Autokonfigurator erstellt eine Konfiguration im gewünschten Zustand
3) Der Autokonfigurator liest die tatsächliche Gerätekonfiguration
4) Ein Diff/Patch wird berechnet und nur erforderliche Änderungen werden angewendet
5) Der Gerätestatus konvergiert mit dem Datenbankmodell

Veranstaltung → ClickHouse → Anerkennung

1) Ein Gerät/Dienst sendet ein Ereignis über Syslog
2) Event Pipeline analysiert/bereichert es
3) Ereignis wird in ClickHouse gespeichert
4) Für unterstützte Ereignistypen wird FALPRS ausgelöst (Gesichter/Platten)
5) Das Ergebnis wird gespeichert und steht Clients/Logik zur Verfügung

Video in der mobilen App

1) Ein Benutzer öffnet eine Kameraansicht
2) RBT prüft Berechtigungen und erteilt Medienzugriff über den Medienserver
3) Das Video wird über HLS/WebRTC über den Medienserver bereitgestellt

Intercom-Anruf → mobile App

1) Gegensprechanlage leitet einen Anruf ein
2) RBT orchestriert es über Asterisk
3) Eine Push-Benachrichtigung erreicht den Benutzer
4) Der Benutzer kann öffnen/handeln (Berechtigungsprüfung) und Ereignisse werden protokolliert