RBT (SmartYard-Server) — il cuore della piattaforma

RBT (SmartYard-Server) è il backend principale della piattaforma SmartYard. Memorizza la configurazione completa e lo stato operativo (edifici, ingressi, dispositivi, utenti, chiavi), mantiene i citofoni e i relè IP allineati con quel modello, orchestra le chiamate intercom tramite Asterisk, invia notifiche push, raccoglie ed elabora eventi e si integra con server multimediali, RBT-TT e monitoraggio.

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

Cosa archivia e gestisce RBT

Infrastruttura e topologia

Dispositivi: citofoni, telecamere CCTV, relè IP
Edifici/oggetti: edifici, numero di ingressi, fasce di appartamenti per ingresso
“Modalità cancello”: ingressi che servono un gruppo di edifici

Utenti e autorizzazioni

account di app mobili residenti
privilegi per utente su tutti gli appartamenti a cui è assegnato l'utente

Chiavi e codici di accesso

più livelli chiave:
Chiave utente
Chiave dell'appartamento
Chiave edificio
Tasto società di gestione
passepartout (apri tutto)
codici di accesso all'appartamento

Sottosistemi all'interno di RBT (SmartYard-Server)

1) Dominio principale (registro + controllo degli accessi): modello di sistema e logica di accesso

Un unico sottosistema core che funge da fonte di verità per l'intera piattaforma:

memorizza la topologia del sito: edifici, ingressi, serie di appartamenti, modalità di ingresso (inclusa la “modalità cancello” che serve più edifici)
memorizza l'inventario dei dispositivi: citofoni, telecamere, relè IP e i relativi collegamenti
memorizza gli utenti e i loro autorizzazioni/privilegi negli appartamenti
memorizza chiavi e codici di accesso (chiavi utente/appartamento/palazzina/gestione/padronale)
esegue controlli di autorizzazione e genera azioni di controllo accessi (porta/cancello/barriera)

Questo modello di dominio e questo set di regole vengono utilizzati dal configuratore automatico, dall'API mobile, dalla pipeline di eventi e dalle integrazioni.

2) Autoconfiguratore: sincronizzazione del dispositivo desiderata/effettiva/diff

Converge automaticamente la configurazione dell'interfono e del relè IP allo stato desiderato definito in RBT:

compila una configurazione dello stato desiderato per ciascun dispositivo dal dominio principale
legge la configurazione attuale (effettiva) del dispositivo
calcola una differenza tra effettivo e desiderato
applica solo le modifiche richieste (“patch”) per raggiungere lo stato target
riduce le riscritture/riavvii non necessari e mantiene lo stato del dispositivo allineato al modello di database

3) API mobile (API dell'applicazione): interfaccia per app mobili

API pubblica utilizzata dai client iOS/Android: - autenticazione/sessioni - edifici/appartamenti/dispositivi disponibili - azioni di accesso (es. “apri”) con verifica dei permessi - eventi e storia - emissione dei parametri di accesso ai media tramite il media server (HLS / WebRTC)

Documentazione API

Importante: i client mobili ricevono video attraverso il server multimediale, non direttamente dalle telecamere.

3.1) Livello di personalizzazione: campi personalizzati + moduli sovrascrivibili + estensioni web

RBT supporta un livello di personalizzazione che aiuta ad estendere la logica aziendale senza biforcare il progetto principale.

Campi personalizzati per appartamenti sono disponibili nell'interfaccia utente
I campi personalizzati per altre entità sono supportati anche a livello di modello/backend
Il comportamento personalizzato può essere implementato tramite backend sovrascrivibile e moduli API mobili (ad esempio, in backends/*/custom e mobile/*/custom)
Anche le estensioni web dell'app mobile fanno parte di questo livello per la personalizzazione dell'interfaccia utente/del flusso di lavoro (vedi Estensioni web)

Esempio pratico: puoi dividere il blocco dell'interfono e il blocco della telecamera in campi separati dell'appartamento e regolare il comportamento dell'API in base a tali valori, mantenendo più semplici gli aggiornamenti RBT a monte.

3.2) Integrazione della fatturazione: funzionalità di base

RBT include un livello di integrazione della fatturazione di base per la sincronizzazione tra la fatturazione e i dati della piattaforma.

importazione della gerarchia degli indirizzi in RBT (regione → città → via → edificio → appartamenti + servizi edificio)
sincronizzazione degli abbonamenti/contratti degli appartamenti con aggiornamenti a:
stato
login/password
campi personalizzati
numeri telefonici degli utenti

Esempio di documentazione: Integrazione fatturazione

4) Orchestratore di telefonia: automazione Asterisk

Gestisce automaticamente Asterisco per gestire le chiamate intercomunicanti e l'interazione intercom ↔ app mobile.

5) Push e messaggistica: invio di notifiche

Fornisce notifiche push per chiamate intercomunicanti e altri messaggi/eventi di sistema alle app mobili.

6) Pipeline di eventi (Syslog Ingest): raccolta ed elaborazione di eventi

Un sottosistema dedicato che riceve eventi tramite syslog, li normalizza e li arricchisce con metadati, li archivia in ClickHouse e attiva azioni di follow-up.

Responsabilità principali: - Ingestione di syslog da dispositivi/servizi - parsing, normalizzazione, arricchimento (edificio/ingresso/dispositivo/appartamento/utente) - scrivere eventi strutturati su ClickHouse (inclusi metadati e, quando necessario, istantanee/link) - attiva il riconoscimento: per i tipi di eventi supportati, avvia l'elaborazione FALPRS (volti/targhe)

7) Archiviazione eventi (ClickHouse) — archivio eventi

Memorizza la cronologia completa degli eventi in ClickHouse: metadati degli eventi più artefatti correlati (ad esempio, istantanee della fotocamera).

8) Media Routing: mappatura delle telecamere sui server multimediali

Mantiene la mappatura delle telecamere/flussi sui server multimediali. Il video raggiunge i client solo tramite il server multimediale utilizzando HLS/WebRTC.

9) Presentazione della fotocamera: come appaiono le fotocamere nell'app

Permette di definire la presentazione della telecamera per i residenti: - albero delle cartelle - visualizzazione basata su mappa (layout geografico/visivo)

10) Integrazione ticketing (RBT-TT)

Crea e gestisce ticket di servizio in RBT-TT per flussi di lavoro operativi gestiti da personale operatore e tecnici sul campo (PWA).

11) Monitoraggio dell'integrazione (Zabbix)

Monitora i dispositivi attivi tramite l'integrazione con Zabbix.

Tabella riassuntiva “sottosistema → responsabilità”

Sottosistema	Responsabilità	Archiviazione/Integrazioni
Dominio principale	topologia, dispositivi, utenti, chiavi, permessi + azioni di accesso	RBT DB
Autoconfiguratore	sincronizzazione desiderata/effettiva/diff e aggiornamenti patch	RBT ↔ citofoni/relè IP
API mobile (API dell'applicazione)	API iOS/Android: accesso, eventi, parametri multimediali	ApplicazioneAPI + RBT
Livello di personalizzazione (campi personalizzati + estensioni Web)	dati/modelli specifici del progetto + estensioni dell'interfaccia utente/flusso di lavoro mobile senza core forking	RBT + moduli sovrascrivibili + SmartYard-web
Integrazione fatturazione	importazione gerarchia indirizzi + sincronizzazione abbonamenti/contratti	fatturazione ↔ RBT
Orchestratore di telefonia	Gestione asterisco, chiamate intercomunicanti	Asterisco
Push e messaggistica	consegna delle notifiche push	spingere i fornitori
Pipeline di eventi (acquisizione Syslog)	syslog → normalizza → memorizza → riconoscimento trigger	Syslog → ClickHouse → FALPRS
Archiviazione eventi	negozio di eventi durevole	Fare clic su Casa
Instradamento multimediale	Mappatura “fotocamera → server multimediale/flussi”	Flussonic/alternative
Presentazione della fotocamera	albero delle cartelle/visualizzazione mappa	RBT
Integrazione biglietteria	ticket e flussi di lavoro operativi	RBT-TT
Monitoraggio dell'integrazione	monitoraggio del dispositivo	Zabbix

Flussi tipici

Configurazione automatica del dispositivo (aggiornamenti basati su differenze)

1) Modifiche dati in RBT (autorizzazioni/chiavi/appartamenti/dispositivi)
2) L'autoconfiguratore crea una configurazione dello stato desiderato
3) L'autoconfiguratore legge la configurazione attuale del dispositivo
4) Viene calcolata una diff/patch e vengono applicate solo le modifiche richieste
5) Lo stato del dispositivo converge al modello di database

Evento → ClickHouse → riconoscimento

1) Un dispositivo/servizio emette un evento tramite syslog
2) La pipeline di eventi la analizza/arricchisce
3) L'evento è archiviato in ClickHouse
4) Per i tipi di eventi supportati, viene attivato FALPRS (facce/piastre)
5) Il risultato viene archiviato e diventa disponibile per i client/la logica

Video nell'app mobile

1) Un utente apre una vista della telecamera
2) RBT controlla le autorizzazioni e rilascia l'accesso ai media tramite il media server
3) Il video viene distribuito tramite HLS/WebRTC tramite il server multimediale

Chiamata intercomunicante → app mobile

1) L'interfono avvia una chiamata
2) RBT lo orchestra tramite Asterisk
3) Una notifica push arriva all'utente
4) L'utente può aprire/agire (autorizzazione controllata) e gli eventi vengono registrati