RBT (SmartYard-Server) — le cœur de la plateforme

RBT (SmartYard-Server) est le backend principal de la plateforme SmartYard. Il stocke la configuration complète et l'état opérationnel (bâtiments, entrées, appareils, utilisateurs, clés), maintient les interphones et les relais IP alignés sur ce modèle, orchestre les appels intercom via Asterisk, envoie des notifications push, collecte et traite les événements et s'intègre aux serveurs multimédias, RBT-TT et à la surveillance.

Référentiel : https://github.com/rosteleset/SmartYard-Server

Ce que RBT stocke et gère

Infrastructure et topologie

Appareils : interphones, caméras de vidéosurveillance, relais IP
Bâtiments/objets : bâtiments, nombre d'entrées, plages d'appartements par entrée
« Mode portail » : entrées qui desservent un groupe de bâtiments

Utilisateurs et autorisations

comptes d'applications mobiles résidents
privilèges par utilisateur dans tous les appartements auxquels l'utilisateur est affecté

Clés et codes d'accès

plusieurs niveaux clés :
Clé utilisateur
Clé de appartement
Clé du bâtiment
Clé société de gestion
clés principales (tout ouvrir)
codes d'accès à l'appartement

Sous-systèmes à l'intérieur de RBT (SmartYard-Server)

1) Domaine principal (registre + contrôle d'accès) — modèle de système et logique d'accès

Un sous-système central unique qui fait office de source de vérité pour l'ensemble de la plateforme :

stocke la topologie du site : bâtiments, entrées, plages d'appartements, modes d'entrée (y compris le « mode portail » desservant plusieurs bâtiments)
stocke l'inventaire des appareils : interphones, caméras, relais IP et leurs liaisons
stocke les utilisateurs et leurs autorisations/privilèges dans tous les appartements
stocke les clés et codes d'accès (utilisateur/appartement/bâtiment/gestion/clés principales)
effectue des vérifications d'autorisation et génère des actions de contrôle d'accès (porte/portail/barrière)

Ce modèle de domaine et cet ensemble de règles sont consommés par le configurateur automatique, l'API mobile, le pipeline d'événements et les intégrations.

2) Autoconfigurateur — synchronisation des appareils souhaitée/réelle/diff

Fait converger automatiquement la configuration de l'interphone et du relais IP vers l'état souhaité défini dans RBT :

compile une configuration de l'état souhaité pour chaque appareil du domaine principal
lit la configuration actuelle (réelle) de l'appareil
calcule une diff entre réel et désiré
applique uniquement les modifications requises (« patch ») pour atteindre l'état cible
réduit les réécritures/redémarrages inutiles et maintient l'état de l'appareil aligné sur le modèle de base de données

3) API mobile (API d'application) — interface pour les applications mobiles

API publique utilisée par les clients iOS/Android : - authentification/sessions - bâtiments/appartements/appareils disponibles - actions d'accès (par exemple, "ouvrir") avec contrôles d'autorisation - événements et histoire - émission des paramètres d'accès aux médias via le serveur multimédia (HLS / WebRTC)

Documentation API

Important : les clients mobiles reçoivent la vidéo via le serveur multimédia, et non directement depuis les caméras.

3.1) Couche de personnalisation — Champs personnalisés + modules remplaçables + extensions Web

RBT prend en charge une couche de personnalisation qui permet d'étendre la logique métier sans bifurquer du projet principal.

Les champs personnalisés pour les appartements sont disponibles dans l'interface utilisateur
Les champs personnalisés pour d'autres entités sont également pris en charge au niveau du modèle/backend
Un comportement personnalisé peut être implémenté via des modules backend et API mobiles remplaçables (par exemple, dans backends/*/custom et mobile/*/custom)
Les extensions Web des applications mobiles font également partie de cette couche pour la personnalisation de l'interface utilisateur/du flux de travail (voir Extensions Web)

Exemple pratique : vous pouvez diviser le blocage de l'interphone et le blocage des caméras en champs d'appartement distincts et ajuster le comportement de l'API en fonction de ces valeurs, tout en facilitant les mises à jour RBT en amont.

3.2) Intégration de la facturation – capacités de base

RBT comprend une couche d'intégration de facturation de base pour la synchronisation entre la facturation et les données de la plateforme.

import de la hiérarchie d'adresses dans RBT (région → ville → rue → immeuble → appartements + services du bâtiment)
synchronisation des abonnements/contrats d'appartements avec mises à jour de :
statut
identifiant/mot de passe
champs personnalisés
numéros de téléphone des utilisateurs

Exemple de documentation : Intégration de facturation

4) Telephony Orchestrator — Automatisation d'Asterisk

Gère automatiquement Asterisk pour gérer les appels intercom et l'interaction interphone ↔ application mobile.

5) Push & Messaging — envoi de notifications

Fournit des notifications push pour les appels intercom et autres messages/événements système aux applications mobiles.

6) Pipeline d'événements (Syslog Ingest) — collecte et traitement des événements

Un sous-système dédié qui reçoit les événements via syslog, les normalise et les enrichit avec des métadonnées, les stocke dans ClickHouse et déclenche des actions de suivi.

Principales responsabilités : - Ingestion Syslog à partir d'appareils/services - analyse, normalisation, enrichissement (bâtiment/entrée/appareil/appartement/utilisateur) - écrire des événements structurés dans ClickHouse (y compris les métadonnées et, si nécessaire, les instantanés/liens) - déclencheurs de reconnaissance : pour les types d'événements pris en charge, lance le traitement FALPRS (faces/plaques)

7) Stockage d'événements (ClickHouse) — magasin d'événements

Stocke l'historique complet des événements dans ClickHouse : métadonnées des événements ainsi que les artefacts associés (par exemple, instantanés de la caméra).

8) Routage multimédia : mappage des caméras vers les serveurs multimédias

Conserve le mappage des caméras/flux vers les serveurs multimédias. La vidéo atteint les clients uniquement via le serveur multimédia à l'aide de HLS/WebRTC.

9) Présentation de la caméra : comment les caméras apparaissent dans l'application

Permet de définir la présentation de la caméra pour les résidents : - arborescence des dossiers - vue basée sur une carte (mise en page géo/visuelle)

10) Intégration de la billetterie (RBT-TT)

Crée et gère les tickets de service dans RBT-TT pour les flux de travail opérationnels gérés par le personnel des opérateurs et les techniciens de terrain (PWA).

11) Intégration de surveillance (Zabbix)

Surveille les appareils actifs via l'intégration avec Zabbix.

Tableau récapitulatif « sous-système → responsabilité »

Sous-système	Responsabilité	Stockage/Intégrations
Domaine principal	topologie, appareils, utilisateurs, clés, autorisations + actions d'accès	Base de données RBT
Configurateur automatique	synchronisation souhaitée/réelle/diff et mises à jour des correctifs	RBT ↔ interphones/relais IP
API mobile (API d'application)	API iOS/Android : accès, événements, paramètres médias	ApplicationAPI + RBT
Couche de personnalisation (Champs personnalisés + Extensions Web)	données/modèles spécifiques au projet + extensions d'interface utilisateur/workflow mobile sans fork principal	RBT + modules remplaçables + SmartYard-web
Intégration de facturation	import de hiérarchie d'adresses + synchronisation des abonnements/contrats	facturation ↔ RBT
Orchestrateur de téléphonie	Gestion des astérisques, appels interphones	Astérisque
Push et messagerie	livraison de notifications push	fournisseurs de push
Pipeline d'événements (Ingestion Syslog)	syslog → normaliser → stocker → déclencher la reconnaissance	Syslog → ClickHouse → FALPRS
Stockage d'événements	magasin événementiel durable	Cliquez sur Maison
Routage des médias	Mappage « caméra → serveur multimédia/flux »	Flussonic/alternatives
Présentation de la caméra	arborescence de dossiers / vue cartographique	RBT
Intégration de la billetterie	tickets et flux de travail opérationnels	RBT-TT
Intégration de surveillance	surveillance des appareils	Zabbix

Flux typiques

Configuration automatique de l'appareil (mises à jour basées sur les différences)

1) Modifications des données dans RBT (autorisations/clés/appartements/appareils)
2) L'autoconfigurateur crée une configuration à l'état souhaité
3) L'autoconfigurateur lit la configuration réelle de l'appareil
4) Un diff/patch est calculé et seules les modifications requises sont appliquées
5) L'état de l'appareil converge vers le modèle de base de données

Événement → ClickHouse → reconnaissance

1) Un appareil/service émet un événement via syslog
2) Event Pipeline l'analyse/l'enrichit
3) L'événement est stocké dans ClickHouse
4) Pour les types d'événements pris en charge, FALPRS est déclenché (faces/plaques)
5) Le résultat est stocké et devient disponible pour les clients/logique

Vidéo dans l'application mobile

1) Un utilisateur ouvre une vue de caméra
2) RBT vérifie les autorisations et délivre un accès aux médias via le serveur multimédia
3) La vidéo est diffusée via HLS/WebRTC via le serveur multimédia

Appel interphone → application mobile

1) L'interphone lance un appel
2) RBT l'orchestre via Asterisk
3) Une notification push parvient à l'utilisateur
4) L'utilisateur peut ouvrir/agir (autorisation vérifiée) et les événements sont enregistrés