RBT (SmartYard-Server) — the core of the platform

RBT (SmartYard-Server) is the main backend of the SmartYard platform. It stores the full configuration and operational state (buildings, entrances, devices, users, keys), keeps intercoms and IP relays aligned with that model, orchestrates intercom calling via Asterisk, delivers push notifications, collects and processes events, and integrates with media servers, RBT-TT, and monitoring.

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

What RBT stores and manages

Infrastructure & topology

Devices: intercoms, CCTV cameras, IP relays
Buildings/objects: buildings, number of entrances, apartment ranges per entrance
“Gate mode”: entrances that serve a group of buildings

Users & permissions

resident mobile app accounts
per-user privileges across all apartments the user is assigned to

Keys & access codes

multiple key levels:
user key
apartment key
building key
management company key
master keys (open everything)
apartment access codes

Subsystems inside RBT (SmartYard-Server)

1) Core Domain (Registry + Access Control) — system model and access logic

A single core subsystem that acts as the source of truth for the whole platform:

stores the site topology: buildings, entrances, apartment ranges, entrance modes (including “gate mode” serving multiple buildings)
stores the device inventory: intercoms, cameras, IP relays and their bindings
stores users and their permissions/privileges across apartments
stores keys and access codes (user/apartment/building/management/master keys)
performs authorization checks and generates access control actions (door/gate/barrier)

This domain model and rule set is consumed by the autoconfigurator, mobile API, event pipeline, and integrations.

2) Autoconfigurator — desired/actual/diff device synchronization

Automatically converges intercom and IP relay configuration to the desired state defined in RBT:

compiles a desired-state configuration for each device from the Core Domain
reads the current (actual) device configuration
computes a diff between actual and desired
applies only the required changes (“patch”) to reach the target state
reduces unnecessary rewrites/restarts and keeps device state aligned with the database model

3) Mobile API (Application API) — interface for mobile apps

Public API used by iOS/Android clients: - authentication/sessions - available buildings/apartments/devices - access actions (e.g., “open”) with permission checks - events and history - issuing media access parameters via the media server (HLS / WebRTC)

API documentation

Important: mobile clients receive video through the media server, not directly from cameras.

4) Telephony Orchestrator — Asterisk automation

Automatically manages Asterisk to handle intercom calling and intercom ↔ mobile app interaction.

5) Push & Messaging — notifications delivery

Delivers push notifications for intercom calls and other system messages/events to mobile apps.

6) Event Pipeline (Syslog Ingest) — event collection and processing

A dedicated subsystem that receives events via syslog, normalizes and enriches them with metadata, stores them in ClickHouse, and triggers follow-up actions.

Key responsibilities: - syslog ingestion from devices/services - parsing, normalization, enrichment (building/entrance/device/apartment/user) - writing structured events to ClickHouse (including metadata and, when needed, snapshots/links) - recognition triggers: for supported event types, initiates FALPRS processing (faces/plates)

7) Events Storage (ClickHouse) — event store

Stores the full event history in ClickHouse: event metadata plus related artifacts (e.g., camera snapshots).

8) Media Routing — mapping cameras to media servers

Keeps the mapping of cameras/streams to media servers. Video reaches clients only via the media server using HLS/WebRTC.

9) Camera Presentation — how cameras appear in the app

Allows defining camera presentation for residents: - folder tree - map-based view (geo/visual layout)

10) Ticketing Integration (RBT-TT)

Creates and maintains service tickets in RBT-TT for operational workflows handled by operator staff and field technicians (PWA).

11) Monitoring Integration (Zabbix)

Monitors active devices via integration with Zabbix.

Summary table “subsystem → responsibility”

Subsystem	Responsibility	Storage/Integrations
Core Domain	topology, devices, users, keys, permissions + access actions	RBT DB
Autoconfigurator	desired/actual/diff sync and patch updates	RBT ↔ intercoms/IP relays
Mobile API (Application API)	iOS/Android API: access, events, media parameters	ApplicationAPI + RBT
Telephony Orchestrator	Asterisk management, intercom calls	Asterisk
Push & Messaging	push notification delivery	push providers
Event Pipeline (Syslog Ingest)	syslog → normalize → store → trigger recognition	Syslog → ClickHouse → FALPRS
Events Storage	durable event store	ClickHouse
Media Routing	“camera → media server/streams” mapping	Flussonic/alternatives
Camera Presentation	folder tree / map view	RBT
Ticketing Integration	tickets & operational workflows	RBT-TT
Monitoring Integration	device monitoring	Zabbix

Typical flows

Device auto-configuration (diff-based updates)

1) Data changes in RBT (permissions/keys/apartments/devices)
2) Autoconfigurator builds a desired-state config
3) Autoconfigurator reads the actual device config
4) A diff/patch is computed and only required changes are applied
5) Device state converges to the database model

Event → ClickHouse → recognition

1) A device/service emits an event via syslog
2) Event Pipeline parses/enriches it
3) Event is stored in ClickHouse
4) For supported event types, FALPRS is triggered (faces/plates)
5) The result is stored and becomes available to clients/logic

Video in the mobile app

1) A user opens a camera view
2) RBT checks permissions and issues media access via the media server
3) Video is delivered via HLS/WebRTC through the media server

Intercom call → mobile app

1) Intercom initiates a call
2) RBT orchestrates it via Asterisk
3) A push notification reaches the user
4) The user can open/act (permission-checked), and events are logged