RBT (SmartYard-Server) — o núcleo da plataforma

RBT (SmartYard-Server) é o backend principal da plataforma SmartYard. Ele armazena a configuração completa e o estado operacional (edifícios, entradas, dispositivos, usuários, chaves), mantém intercomunicadores e relés IP alinhados com esse modelo, orquestra chamadas de intercomunicação via Asterisk, entrega notificações push, coleta e processa eventos e integra-se com servidores de mídia, RBT-TT, e monitoramento.

Repositório: https://github.com/rosteleset/SmartYard-Server

O que o RBT armazena e gerencia

Infraestrutura e topologia

Dispositivos: intercomunicadores, câmeras CCTV, relés IP
Edifícios/objetos: edifícios, número de entradas, faixas de apartamentos por entrada
“Modo portão”: entradas que atendem a um grupo de edifícios

Usuários e permissões

contas de aplicativos móveis residentes
privilégios por usuário em todos os apartamentos aos quais o usuário está atribuído

Chaves e códigos de acesso

vários níveis principais:
Chave usuário
apartamento chave
construção chave
empresa gestora chave
chaves mestras (abrir tudo)
códigos de acesso ao apartamento

Subsistemas dentro do RBT (SmartYard-Server)

1) Domínio Principal (Registro + Controle de Acesso) — modelo do sistema e lógica de acesso

Um subsistema central único que atua como fonte de verdade para toda a plataforma:

armazena a topologia do local: edifícios, entradas, faixas de apartamentos, modos de entrada (incluindo “modo portão” que atende vários edifícios)
armazena o inventário de dispositivos: intercomunicadores, câmeras, relés IP e suas ligações
armazena usuários e suas permissões/privilégios nos apartamentos
armazena chaves e códigos de acesso (usuário/apartamento/edifício/gestão/chaves mestras)
realiza verificações de autorização e gera ações de controle de acesso (porta/portão/barreira)

Esse modelo de domínio e conjunto de regras são consumidos pelo autoconfigurador, API móvel, pipeline de eventos e integrações.

2) Autoconfigurador — sincronização de dispositivo desejada/real/diferente

Converge automaticamente a configuração do intercomunicador e do relé IP para o estado desejado definido no RBT:

compila uma configuração de estado desejado para cada dispositivo do Domínio Principal
lê a configuração atual (real) do dispositivo
calcula uma diferença entre real e desejado
aplica apenas as alterações necessárias (“patch”) para atingir o estado alvo
reduz reescritas/reinicializações desnecessárias e mantém o estado do dispositivo alinhado com o modelo de banco de dados

3) API móvel (API de aplicativo) — interface para aplicativos móveis

API pública usada por clientes iOS/Android: - autenticação/sessões - edifícios/apartamentos/dispositivos disponíveis - ações de acesso (por exemplo, “abrir”) com verificações de permissão - eventos e história - emissão de parâmetros de acesso à mídia através do servidor de mídia (HLS/WebRTC)

Documentação da API

Importante: os clientes móveis recebem vídeo por meio do servidor de mídia, não diretamente das câmeras.

3.1) Camada de personalização — Campos personalizados + módulos substituíveis + extensões da web

O RBT oferece suporte a uma camada de personalização que ajuda a estender a lógica de negócios sem bifurcar o projeto principal.

Campos personalizados para apartamentos estão disponíveis na IU
Campos personalizados para outras entidades também são suportados no nível do modelo/backend
O comportamento personalizado pode ser implementado por meio de back-end substituível e módulos de API móvel (por exemplo, em backends/*/custom e mobile/*/custom)
Extensões da Web de aplicativos móveis também fazem parte dessa camada para personalização da UI/fluxo de trabalho (consulte Extensões da Web)

Exemplo prático: você pode dividir o bloqueio de intercomunicação e bloqueio de câmera em campos de apartamentos separados e ajustar o comportamento da API com base nesses valores - enquanto mantém as atualizações RBT upstream mais fáceis.

3.2) Integração de faturamento — recursos básicos

O RBT inclui uma camada básica de integração de faturamento para sincronização entre dados de faturamento e da plataforma.

importação da hierarquia de endereços para RBT (região → cidade → rua → edifício → apartamentos + serviços de construção)
sincronização de assinaturas/contratos de apartamentos com atualizações para:
estado
login/senha
campos personalizados
números de telefone do usuário

Exemplo de documentação: Integração de faturamento

4) Orquestrador de Telefonia — Automação Asterisk

Gerencia automaticamente o Asterisk para lidar com chamadas de intercomunicação e intercomunicação ↔ interação com aplicativos móveis.

5) Push & Messaging – entrega de notificações

Fornece notificações push para chamadas de intercomunicação e outras mensagens/eventos do sistema para aplicativos móveis.

6) Pipeline de eventos (ingestão de Syslog) — coleta e processamento de eventos

Um subsistema dedicado que recebe eventos via syslog, normaliza e enriquece-os com metadados, armazena-os no ClickHouse e aciona ações de acompanhamento.

Principais responsabilidades: - ingestão de syslog de dispositivos/serviços - análise, normalização, enriquecimento (edifício/entrada/dispositivo/apartamento/usuário) - gravar eventos estruturados no ClickHouse (incluindo metadados e, quando necessário, snapshots/links) - acionadores de reconhecimento: para tipos de eventos suportados, inicia o processamento FALPRS (faces/placas)

7) Armazenamento de eventos (ClickHouse) — armazenamento de eventos

Armazena o histórico completo de eventos no ClickHouse: metadados de eventos mais artefatos relacionados (por exemplo, instantâneos de câmeras).

8) Roteamento de mídia — mapeando câmeras para servidores de mídia

Mantém o mapeamento de câmeras/streams para servidores de mídia. O vídeo chega aos clientes somente por meio do servidor de mídia usando HLS/WebRTC.

9) Apresentação da câmera — como as câmeras aparecem no aplicativo

Permite definir a apresentação da câmera para os moradores: - árvore de pastas - visualização baseada em mapa (layout geográfico/visual)

10) Integração de tickets (RBT-TT)

Cria e mantém tickets de serviço em RBT-TT para fluxos de trabalho operacionais gerenciados pela equipe do operador e técnicos de campo (PWA).

11) Integração de monitoramento (Zabbix)

Monitora dispositivos ativos por meio da integração com o Zabbix.

Tabela resumo “subsistema → responsabilidade”

Subsistema	Responsabilidade	Armazenamento/Integrações
Domínio Principal	topologia, dispositivos, usuários, chaves, permissões + ações de acesso	BD RBT
Autoconfigurador	sincronização desejada/real/diff e atualizações de patch	RBT ↔ intercomunicadores/relés IP
API móvel (API de aplicativo)	API iOS/Android: acesso, eventos, parâmetros de mídia	AplicaçãoAPI + RBT
Camada de Personalização (Campos Personalizados + Extensões Web)	dados/modelo específico do projeto + extensões de UI/fluxo de trabalho móvel sem bifurcação principal	RBT + módulos substituíveis + SmartYard-web
Integração de faturamento	importação de hierarquia de endereços + sincronização de assinaturas/contratos	faturamento ↔ RBT
Orquestrador de Telefonia	Gerenciamento de asterisk, chamadas de intercomunicação	Asterisco
Push e mensagens	entrega de notificação push	fornecedores push
Pipeline de eventos (ingestão de Syslog)	syslog → normalizar → armazenar → reconhecimento de gatilho	Syslog → ClickHouse → FALPRS
Armazenamento de Eventos	loja de eventos durável	ClickHouse
Roteamento de mídia	Mapeamento “câmera → servidor de mídia/streams”	Flussonic/alternativas
Apresentação da câmera	árvore de pastas/visualização de mapa	RBT
Integração de ingressos	tickets e fluxos de trabalho operacionais	RBT-TT
Integração de Monitoramento	monitoramento de dispositivos	Zabbix

Fluxos típicos

Configuração automática do dispositivo (atualizações baseadas em diferenças)

1) Mudanças de dados no RBT (permissões/chaves/apartamentos/dispositivos)
2) O autoconfigurador cria uma configuração de estado desejado
3) O autoconfigurador lê a configuração do dispositivo real
4) Uma diff/patch é calculada e apenas as alterações necessárias são aplicadas
5) O estado do dispositivo converge para o modelo de banco de dados

Evento → ClickHouse → reconhecimento

1) Um dispositivo/serviço emite um evento via syslog
2) Event Pipeline analisa/enriquece
3) O evento é armazenado no ClickHouse
4) Para tipos de eventos suportados, FALPRS é acionado (faces/placas)
5) O resultado é armazenado e fica disponível para clientes/lógica

Vídeo no aplicativo móvel

1) Um usuário abre uma visualização da câmera
2) RBT verifica permissões e emite acesso à mídia através do servidor de mídia
3) O vídeo é entregue via HLS/WebRTC por meio do servidor de mídia

Chamada de intercomunicação → aplicativo móvel

1) Intercom inicia uma chamada
2) RBT orquestra isso via Asterisk
3) Uma notificação push chega ao usuário
4) O usuário pode abrir/agir (permissão verificada) e os eventos são registrados