# Nexus como o "cérebro" do condomínio inteligente _Plano estratégico — análise do que temos, do que o mercado tem, e um roadmap em fases para transformar o Nexus no sistema central (o "cérebro") de um condomínio inteligente._ **Escopo:** um único condomínio (self-hosted, single-tenant). Sem multi-tenancy/cobrança como produto — o foco é recurso, integração e inteligência. Data: julho/2026. --- ## Sumário executivo O Nexus já é, hoje, mais do que um controle de acesso: é uma **plataforma de acesso + automação com um motor de regras configurável**, integrações de nuvem e locais, vídeo, e autoatendimento do morador. Isso o coloca a meio caminho do padrão que o mercado chama de "cérebro": **uma camada de integração única sobre hardware heterogêneo, com um núcleo de eventos e um motor de automação**. A tese deste plano: **não trocar o Nexus por um Home Assistant** — e sim adotar as três ideias que fazem um hub virar cérebro, mantendo o núcleo PHP/MariaDB local-first como fonte da verdade: 1. **Um barramento de eventos interno (MQTT)** — hoje os subsistemas conversam ponto-a-ponto (polling, chamadas diretas). Um broker MQTT vira o "sistema nervoso": tudo publica e assina eventos, e qualquer coisa nova (medidores, Frigate, gateways Modbus/BACnet) se conecta sem reescrever o núcleo. 2. **Generalizar o motor de alertas em um motor de automação semântico** — o `AlertEngine`/`alert_rule` já faz gatilho→condição→ação (passagem, água, offline, anomalia). É a semente de um motor de regras cross-domínio (acesso + presença + energia + vídeo). 3. **Uma camada de IA opcional, local-capaz e "em forma de ferramenta"** — detecção de anomalias em medidores/bombas, assistente por linguagem natural (padrão de duas camadas: intents determinísticos + LLM local via Ollama só no que sobra), e análise de quadros de câmera. Em paralelo, fechar as **lacunas de "super-app" do morador** que o mercado brasileiro já trata como básico (avisos + push, reserva de áreas comuns, assembleias/votação, encomendas/lockers, ocorrências) e as de **acesso moderno** (pré-autorização de visita por QR/WhatsApp, vídeo-porteiro no celular, botão de pânico). Tudo isso com a **LGPD** como restrição de arquitetura, não de fachada: facial é dado **sensível** (opt-in + alternativa não-biométrica obrigatória + RIPD); CFTV/ALPR ficam em legítimo interesse com aviso, controle de acesso às imagens e retenção configurável (que já temos). --- ## 1. O que temos hoje Inventário real do repositório (não uma lista de intenções). O Nexus tem ~30 tabelas, ~25 módulos web, uma API REST com escopos, 10 workers de background e ~11 integrações externas. ### Núcleo de acesso (forte, maduro) Pessoas (`pessoa`, 7 tipos), veículos e placas (`pessoa_veiculo`, `veiculo_placa`), visitantes, pré-cadastro público, histórico de passagens (`historico_passagem` com confiança, direção, casamento placa↔veículo), portões (`access_door`) e **chaves compartilháveis por link** (`door_share`, com PIN/expiração). Perfis de acesso (`perfil_acesso` + horários) espelhados no **InControl (Intelbras/Control iD)**, que tratamos como **espelho** — o Nexus é a fonte da verdade de pessoas/grupos. ### ALPR + vídeo Câmeras ALPR (`camera`, `camera_config`; OpenALPR e Intelbras ITSAPI), `/monitor` ao vivo, ingestão por webhook (`POST /alpr/events`), reconhecimento facial via `faceQa` do InControl, e **vídeo ao vivo via go2rtc** (`video_camera`, yaml gerado do banco). O `monitor_bridge` é um worker WSS contínuo que grava eventos do InControl (`monitor_evento`). ### Automação (base sólida) Abstração de drivers (`DeviceDriver`: `http_custom`, `http_generic`, `ewelink`, `tuya`) com **múltiplas contas de nuvem** (`auto_account`), cômodos, **cenas** (`auto_scene`), **agendas** por hora ou nascer/pôr do sol (`auto_schedule`, `auto_sun`), e **cisterna/bomba** com liga/desliga automático e histórico de nível (`auto_water`, série temporal). **Kill-switches** por subsistema (`auto_setting`). Descoberta de dispositivos na nuvem (Tuya/eWeLink). Exportação para **Apple HomeKit via Homebridge** e, via Matter/pontes, **Google Home e Alexa**. ### Motor de alertas configurável (o embrião do cérebro) `alert_rule`/`alert_rule_state`/`alert_log` + `AlertEngine`: regras `device_offline` (com escalonamento por tempo), `water_level`, `passage` (pessoa/placa/câmera em tempo real, once/always), `device_online`, `denials_anomaly`. **Destinatários por regra**, **cooldown**, **kill-switch global**, **prévia (dry-run)**. Avaliação em **tempo real** (ALPR e InControl) + varredura periódica (`auto_alert`). Canais: **Pushover, e-mail (Resend), WhatsApp (Z-API)**. ### Morador e operação Autoatendimento: **`/casa`** (só os dispositivos atribuídos ao morador), **`/minha-foto`** (atualiza a própria face com QA), chaves públicas (`/k/{token}`), acesso remoto (`/cerberus`). **Central de operação** (`/central`, "tudo normal" + só problemas), **diagnósticos**, **auditoria** e **heartbeat de workers** (`worker_heartbeat`, classifica ok/atrasado/falha). ### Plataforma API REST `/api/v1` com **API keys + escopos** (`automation:read/control`, `doors:open`, `people:*`, `alpr:events`…), rate-limit, auditoria. Autoloader duplo (`App\`/`Web\`), roteador próprio, `schema.sql` canônico, PHP 8.3 + MariaDB 11.4 **local-first** — o Windows/WAMP alcança toda a LAN 172.16.0.x (InControl, câmeras, dispositivos). **Leitura:** o padrão comercial de "cérebro" — uma camada de integração sobre acesso heterogêneo (facial/LPR/QR/tag/SIP), núcleo de eventos logados, app do morador para pré-autorização/notificação, e um lado de automação/IoT — **já é o nosso**. O que falta é (a) generalizar o miolo de eventos, (b) as features de morador que viraram commodity, e (c) a camada de inteligência. --- ## 2. O que o mercado tem Duas referências importam: as **plataformas brasileiras de condomínio** (o que morador e síndico esperam) e os **hubs de casa inteligente** (o que define tecnicamente um cérebro). ### 2.1 Plataformas BR de condomínio — o "super-app" Em 2025-2026, o mercado (TownSq, Superlógica, uCondo, Group/Condomínio21, CondoConta) convergiu para um **app único** com um conjunto que virou padrão: - **Comunicação:** mural de avisos/comunicados **com push**, canal síndico↔morador, feed social/classificados, repositório de documentos (regimento, atas, balancetes). - **Governança/operação:** **reserva de áreas comuns** (com regras), **assembleias digitais + votação online** (respaldadas pela **Lei 14.309/2022** — voto restrito, confidencial, imutável, auditável), enquetes, **ocorrências/chamados** com sigilo por unidade, cadastro de **prestadores**, achados e perdidos. - **Encomendas:** registro + notificação de chegada, e a tendência 2025 dos **lockers inteligentes** (retirada por senha/QR, **notificação no WhatsApp com foto e código, sem precisar baixar app**). - **Acesso moderno (portaria remota/virtual):** liberação de visita por **QR/app enviado por WhatsApp**, **facial**, **LPR de placa**, **tag RFID**, biometria, **vídeo-porteiro/interfone no celular (SIP)** — áudio + vídeo + abertura numa tela só — e **botão de pânico/SOS**. Modelos **híbridos** (remoto + on-site pontual) são o mainstream. - **Financeiro:** boletos/2ª via/Pix, inadimplência (fora do escopo de um "cérebro" técnico, mas é o que ancora os apps comerciais). ### 2.2 Hubs de casa inteligente — o que define um "cérebro" A implementação de referência é o **Home Assistant** (Open Home Foundation); alternativas Homey Pro e openHAB. O núcleo não-negociável: - **Camada de abstração de dispositivos** (o nosso `DeviceDriver` já é isso). - **Barramento de eventos + máquina de estados** — o coração do HA é literalmente um _event bus + state machine_; tudo dispara e escuta no barramento, cada automação roda como tarefa independente. É o que falta generalizarmos. - **Motor de automação** gatilho→condição→ação, caminhando para **gatilhos semânticos** ("nível de água baixo", "demanda de aquecimento") em vez de lógica crua de sensores — exatamente a direção do nosso `alert_rule`. - **Cenas, presença/ocupação, dashboards (card/tile, mobile-first, escopo por usuário), painel de energia, backups, execução local-first, camada de voz e superfície de API/MCP.** ### 2.3 Padrões e tecnologia para adotar - **MQTT como barramento interno** — a maior alavanca única. É a língua franca: Frigate, medidores, gateways Modbus/BACnet/KNX todos publicam/assinam MQTT, com **auto-discovery** de dispositivos. - **Matter 1.5 (nov/2025)** — passou a cobrir **câmeras/campainhas (WebRTC)**, um cluster de **fechaduras/portões/garagem/persianas (Closures)** e **energia (tarifas, smart metering, limites de potência, EV)**. Vale **ingerir** Matter, não só exportar. Zigbee/Z-Wave seguem essenciais (Z-Wave domina sensores de segurança); Matter não os substitui. - **Protocolos de prédio (o diferencial vs. hub doméstico):** **Modbus** (medidores, bombas, geradores), **BACnet** (HVAC, elevadores, centrais), **KNX** (prédios de alto padrão). Padrão: **não implementar nativo em PHP** — usar **gateway protocolo→MQTT** na borda; o cérebro consome tópicos normalizados. - **Frigate** — NVR open-source com **detecção de objeto/pessoa local** que **publica em MQTT** (<200ms, sem nuvem, poucos falsos positivos). É o modelo para a nossa camada ALPR/câmera: Frigate → MQTT → motor de regras (encaixa no conceito de "passagem"). - **Sub-medição por unidade** (água/gás/energia): CT-clamp/pulso/Modbus/M-Bus → MQTT, com **padrão utility-meter** (acumuladores por ciclo) + painel de consumo + **alerta de anomalia**. Mapeia direto no nosso modelo de série temporal do `auto_water`. - **Confiabilidade:** **watchdogs** por camada e **degradação graciosa** (dependência dura→macia: se a nuvem/internet cai, o local segue). Já fazemos parcialmente (modo mock, ações manuais quando o motor está pausado, InControl best-effort, heartbeat) — falta **formalizar**. - **IA (2025-2026):** **detecção de anomalias** (Isolation Forest/autoencoder/LSTM) em consumo/equipamentos; **previsão de ocupação**; **assistente LLM de duas camadas** (intents determinísticos rápidos e offline; LLM só no aberto — local via **Ollama**, ou nuvem), voz 100% local (Whisper+Ollama+Piper); **IA "como ferramenta"** (analisar um quadro de câmera e devolver JSON, resumir incidentes); e expor o sistema como **servidor MCP** para qualquer LLM consultar/agir com segurança. --- ## 3. Análise de lacunas O que separa o Nexus de hoje do "cérebro". Prioridade: **A** (alto valor / baixo-médio esforço), **B** (médio), **C** (grande/estratégico). | Lacuna | Estado hoje | O que falta | Prio | |---|---|---|---| | **Barramento de eventos** | Ponto-a-ponto (polling, chamadas diretas) | Broker **MQTT** + ponte publicando passagens, estados, água | **A** | | **Notificação ao morador** | Pushover/e-mail/WhatsApp (operacional) | **Web Push (PWA)** + mural de avisos in-app | **A** | | **Pré-autorização de visita** | Pré-cadastro público + visitantes | **QR/WhatsApp** self-service pelo morador (já temos Z-API) | **A** | | **Botão de pânico/SOS** | — | Ação morador → `AlertEngine` → canais | **A** | | **Previsão do tempo + alertas meteo** | — | Multi-fonte (Open-Meteo/INMET/CEMADEN/OpenWeather) + regra `weather` parametrizável | **A** | | **Motor de automação semântico** | `alert_rule` (5 tipos) | Generalizar p/ gatilhos/ações nomeados cross-domínio | **A/B** | | **Reserva de áreas comuns** | — | Módulo novo (encaixa nos padrões atuais) | **B** | | **Encomendas / lockers** | — | Registro + notificação; código de locker por WhatsApp | **B** | | **Ocorrências / chamados** | Auditoria (só admin) | Módulo morador↔síndico com sigilo | **B** | | **Vídeo inteligente** | go2rtc (stream) + ALPR | **Frigate → MQTT** (pessoa/carro) ligado às regras | **B** | | **Sub-medição por unidade** | Só cisterna (prédio) | Água/gás/energia por unidade (Modbus/pulso→MQTT) + painel | **B** | | **Assembleias / votação** | — | Módulo Lei 14.309/2022 (voto sigiloso, auditável) | **B/C** | | **Vídeo-porteiro no celular** | Interfonia física | SIP → app (áudio+vídeo+abrir) | **C** | | **Interop de prédio** | Tuya/eWeLink/HTTP | **Matter 1.5** (ingest), gateways **Modbus/BACnet/KNX** | **C** | | **IA** | Anomalia de negados (regra) | Detecção de anomalia em medidores/bombas; assistente LLM; IA em quadros de câmera | **C** | | **App mobile** | Web desktop-first | **PWA** instalável + push (consolidando o morador) | **B** | | **Exposição MCP** | API REST com escopos | Servidor **MCP** sobre a API atual | **B** | --- ## 4. Arquitetura-alvo do "cérebro" Princípio: **o núcleo PHP/MariaDB continua a fonte da verdade e roda local-first**; ao redor dele, um barramento e camadas plugáveis. ``` ┌─────────────────────────────────────────────┐ │ NEXUS (núcleo local) │ Moradores ───────► │ Web/PWA · API REST + escopos · MCP server │ Síndico/portaria │ Motor de Automação (ex-AlertEngine) │ │ Fonte da verdade: pessoas, acesso, regras │ └───────────────┬─────────────────────────────┘ │ publica/assina ┌────────────▼─────────────┐ │ BARRAMENTO MQTT (novo) │ ← "sistema nervoso" └───┬─────┬─────┬─────┬─────┘ ┌─────────────────────┘ │ │ └───────────────────────┐ ▼ ▼ ▼ ▼ Acesso/InControl Frigate (vídeo IA) Medidores/Bomba Gateways de prédio ALPR · portões · facial pessoa/carro→MQTT água·gás·energia Modbus·BACnet·KNX (Modbus/pulso→MQTT) elevador·gerador ▲ ▲ │ export (já existe) ingest (novo) ▼ ▼ HomeKit · Matter 1.5 · Google Home · Alexa Matter 1.5 (câmeras/closures/energia) ┌──────────────── Camadas transversais ────────────────┐ │ IA: anomalia (medidores/bombas) · assistente LLM │ │ (Assist 2-camadas + Ollama local) · IA em câmera │ │ Confiabilidade: watchdogs · degradação graciosa │ │ LGPD: facial opt-in + fallback · retenção · auditoria │ └───────────────────────────────────────────────────────┘ ``` Decisões-chave: - **MQTT (Mosquitto) como barramento** — o Nexus vira um cliente que publica os eventos que já produz (passagens, estados de dispositivo, nível d'água) e assina os novos (Frigate, medidores, gateways). Isso desacopla e torna cada integração futura aditiva. - **Gateways na borda, não em PHP** — Modbus/BACnet/KNX entram por um gateway→MQTT (appliance ou um Home Assistant/ESPHome fazendo de tradutor). O PHP só lê tópicos normalizados. - **Matter nas duas direções** — já exportamos; passar a **consumir** câmeras/fechaduras/energia Matter 1.5. - **IA opcional e local-capaz** — nada crítico depende de LLM; o assistente é a segunda camada, e a detecção de anomalia roda sobre as séries temporais que já guardamos. --- ## 5. Roadmap em fases Do rápido de entregar (aproveita o que já existe) ao ambicioso. Cada item aponta onde encosta no código atual. ### Fase 0 — Fundação + quick wins (aproveitamento máximo do que já existe) Objetivo: instalar o barramento e entregar valor visível ao morador em semanas. - **Broker MQTT + ponte de eventos.** Subir Mosquitto na LAN; publicar no barramento o que o Nexus já emite: passagens (do `AlprService::flush`/`monitor_bridge`), estados de dispositivo (do `auto_poll`), nível d'água (`auto_water`). _Encosta em:_ workers `api/scripts/`, `AlertEngine`. - **Web Push (PWA).** Tornar o Nexus instalável (manifest + service worker) e mandar push ao navegador do morador. Reusa o `AlertService` (novo canal ao lado de Pushover/Resend/Z-API). - **Pré-autorização de visita por QR/WhatsApp.** Morador gera um convite (QR + link) e envia pelo WhatsApp (Z-API já integrado). _Encosta em:_ `visitors`, `pre_cadastro`, `door_share` (mesmo padrão de token). - **Botão de pânico/SOS.** Ação no app do morador → `AlertEngine` → canais (prioridade alta no Pushover). _Encosta em:_ `/casa`, `AlertService::dispatch`. - **Previsão do tempo multi-fonte + alertas meteorológicos inteligentes e parametrizáveis.** Agregar previsão de **várias fontes** com consenso/redundância — ex.: **Open-Meteo** (grátis, sem chave), **OpenWeather**, e os **avisos oficiais do INMET/CEMADEN** (BR) — e um novo tipo de regra `weather` no motor: gatilhos parametrizáveis (chuva forte, rajada de vento, temperatura, alagamento/aviso oficial previsto nas próximas N horas) com destinatários, canais e escalonamento como as demais regras. Pode **avisar** (portaria/morador) e **acionar automações** (recolher toldos, iluminação, preparar bomba/cisterna antes da chuva). Multi-fonte dá **resiliência** (se uma API cai, as outras seguem) e **confiança** (consenso). _Encosta em:_ `AlertEngine`/`alert_rule`/`AlertMatch`, `AlertService`, e o barramento MQTT (publica a condição do tempo p/ o resto do sistema). - **Generalizar o motor de alertas → "Automação/Regras".** Renomear conceitualmente e abrir gatilhos/ações nomeados (semânticos) além dos 5 tipos atuais, incluindo tópicos MQTT como gatilho. _Encosta em:_ `alert_rule`, `AlertMatch`, `AlertEngine`. - **Formalizar confiabilidade.** Estender o `worker_heartbeat` a cada driver/gateway; padronizar timeout+fallback+"modo degradado" (banner) em toda chamada externa. _Encosta em:_ `WorkerHealthRepository`, drivers. ### Fase 1 — Casa, energia e vídeo inteligente Objetivo: o lado IoT do cérebro ganha olhos e medição. - **Frigate → MQTT → regras.** Detecção local de pessoa/carro entra como "passagem" no motor de regras; alerta de pessoa em área/horário. _Encosta em:_ conceito `passage`, `historico_passagem`, motor de regras. - **Sub-medição por unidade.** Água/gás/energia via Modbus/pulso→MQTT; generalizar o modelo de série temporal do `auto_water` para um `medidor` genérico; **painel de consumo** + **alerta de anomalia** (limiar simples primeiro). _Encosta em:_ `auto_water`/`auto_water_param`, gráficos Chart.js já usados. - **Reserva de áreas comuns.** Módulo novo (salão, churrasqueira, quadra) com regras e conflito; notificação por push. Segue o padrão controller/repo/view + ability no `PermissionService`. - **Encomendas + código de locker.** Registro de encomenda + notificação (push/WhatsApp com foto e código). Base para integrar um locker depois. ### Fase 2 — Super-app do morador + governança Objetivo: consolidar a experiência do morador no padrão de mercado. - ✅ **PWA do morador** — hub `/inicio` mobile-first (tiles + status ao vivo) consolidando Minha Casa, reservas, encomendas, ocorrências, assembleias, convites-QR, prestadores. _(entregue)_ - ✅ **Ocorrências/chamados** morador↔síndico com sigilo por unidade, thread e histórico (`/ocorrencias`). _(entregue)_ - ✅ **Assembleias digitais + votação** conforme **Lei 14.309/2022** — voto secreto (participação separada da escolha), imutável (só INSERT) e resultado auditável (`/assembleias`). _(entregue)_ - ✅ **Portal de prestadores** — agenda + janela de acesso do `prestador_servico`, autorização pela portaria (`/prestadores`). _(entregue)_ - ⏳ **Vídeo-porteiro no celular (SIP)** — chamada da portaria/câmera roteada ao app (áudio+vídeo+abrir). Item mais pesado; integra com InControl/câmeras. _(adiado — precisa de hardware/infra SIP; validar demanda)_ ### Fase 3 — Cérebro com IA + interoperabilidade total (visão) Objetivo: o Nexus como orquestrador inteligente do prédio. - **Interop de prédio:** ✅ **Modbus TCP nativo** (driver `modbus` + `ModbusClient` self-contained) para bombas/quadros/geradores; ⏳ **Matter/BACnet/KNX** via **gateway → MQTT** (guia `INTEGRACAO-INTEROP-PREDIO.md`; sem stack nativo). _(Modbus entregue; demais pelo caminho gateway→MQTT)_ - **IA de operação:** ✅ detecção de anomalia (z-score robusto/MAD) + **manutenção preditiva** (tendência + ETA da caixa) sobre medidores/água, worker `auto_ai` + painel `/operacao`. _(entregue com estatística pura, sem dependência de ML)_ - **Assistente do condomínio (LLM):** ✅ duas camadas (intents determinísticos + **Ollama local** opcional) em `/assistente`; ⏳ voz local (Whisper/Piper) e IA de quadro de câmera ficam como extensões futuras. _(assistente por texto entregue)_ - **Servidor MCP:** ✅ `deploy/nexus-mcp` expõe dispositivos/água/portões via MCP sobre a API REST (escopo + auditoria do token). _(entregue)_ - **Confiabilidade grau-hub:** ✅ watchdog dos contínuos (Fase 0) + **backup/restore de configuração num clique** (`/backup`); ⏳ sequenciamento de boot fino. _(essencial entregue)_ --- ## 6. LGPD e segurança (transversal) A LGPD é restrição **de arquitetura**. Pontos que decidem o desenho: - **Facial = dado sensível (biométrico).** Legítimo interesse **não** vale. Deve ser **opt-in** (consentimento livre, informado, revogável) e **nunca o único meio de acesso** — sempre oferecer cartão/senha/tag/chave como alternativa. Recomenda-se **RIPD** (Relatório de Impacto). _No Nexus:_ o facial (InControl/`faceQa`, `/minha-foto`) deve ser sinalizado como opcional, com caminho de acesso não-biométrico garantido, e o consentimento registrado. - **CFTV/ALPR = dado pessoal, não sensível** (a imagem crua só vira biométrico quando processada para reconhecimento). Podem ficar em **legítimo interesse**, desde que: **aviso visível** de filmagem, **acesso às imagens restrito e logado**, e **retenção configurável** (já temos — `retention`, `retention_cleanup`). - **Assembleias:** voto **sigiloso, imutável e auditável** (Lei 14.309/2022); a maioria **não** pode obrigar um indivíduo a usar biometria. - **Fiscalização é real:** a ANPD abriu processos em 2025 sobre reconhecimento facial — tratar facial com cautela, não como default. Segurança técnica: manter API keys por escopo + rate-limit + auditoria (já temos); portões/chaves sempre atrás de escopo (`doors:open`) e auditados; o barramento MQTT autenticado e restrito à LAN. --- ## 7. Riscos e decisões em aberto - **Não virar um "Home Assistant pior".** O HA é imbatível em número de integrações. Nossa vantagem é ser o **dono do acesso + regras + dados do condomínio** com governança/LGPD embutida. Onde o HA/Frigate/gateways forem melhores (rádios, vídeo, protocolos de prédio), **consumi-los via MQTT** em vez de reimplementar. - **Escopo do morador.** Financeiro/boleto é o que ancora os apps comerciais, mas foge do "cérebro" técnico e da nossa escolha single-tenant — deixar de fora (ou integrar um provedor) conscientemente. - **SIP/vídeo-porteiro** é o item de maior esforço da lista de morador; validar demanda antes da Fase 2. - **IA local exige hardware** (GPU/VRAM p/ Ollama, TPU/Coral p/ Frigate) — dimensionar antes da Fase 1/3. - **Migração incremental:** cada fase deve poder ser publicada sozinha, atrás de kill-switch, sem quebrar o que roda (padrão que já praticamos). --- ## 8. Próximos passos imediatos (recomendados) Os quatro quick wins de maior relação valor/esforço, todos aproveitando o que já existe: 1. **Subir o MQTT e publicar os eventos atuais** (passagens, estados, água) — destrava todo o resto. 2. **Web Push (PWA)** — notificação de verdade ao morador reusando o `AlertService`. 3. **Pré-autorização de visita por QR/WhatsApp** — alto valor percebido, Z-API já pronto. 4. **Botão de pânico/SOS** — pequeno, e liga direto no motor de alertas. Em paralelo, começar a **generalizar o `AlertEngine` para um motor de automação semântico** — é a peça que, junto do MQTT, transforma o Nexus de "sistema de acesso com automação" em **cérebro do condomínio**. --- ## Fontes **Plataformas BR de condomínio e acesso** - TownSq — produto / portaria digital: https://townsq.com.br/ · https://blog.townsq.com.br/townsq/portaria-digital-townsq/ - Superlógica — funcionalidades / portaria remota / facial: https://superlogica.com/recursos/funcionalidades-condominios/ · https://blog.superlogica.com/controle-de-acesso/tudo-o-que-voce-precisa-saber-sobre-portaria-remota/ · https://blog.superlogica.com/controle-de-acesso/controle-de-acesso-reconhecimento-facial/ - uCondo — app / assembleia virtual / portaria / lockers: https://www.ucondo.com.br/blog/aplicativo-ucondo-como-funciona-o-sistema-ucondo-para-condominios · https://www.ucondo.com.br/blog/assembleia-virtual-no-condominio-conheca-os-beneficios · https://www.ucondo.com.br/solucoes/portaria-e-acessos · https://www.ucondo.com.br/blog/armario-inteligente-como-funcionam-os-lockers-para-portaria - Group Software — Condomínio21 / super app / portaria remota / LGPD: https://www.groupsoftware.com.br/administracao-de-condominios/condominio21/ · https://www.groupsoftware.com.br/lp/group-com/ · https://www.groupsoftware.com.br/blog/portaria-remota/ · https://www.groupsoftware.com.br/blog/lgpd-para-condominios/ - CondoConta (banco digital de condomínio): https://condoconta.com.br/ - Portaria virtual / modelos híbridos: https://grupoprevix.com.br/noticias/portaria-virtual-como-funciona · https://direcionalcondominios.com.br/seguranca-em-condominios-portaria-virtual-modelos-hibridos-e-tecnologia-de-protecao/ - Lockers inteligentes: https://modulocker.com/ · https://oihandover.com/us/for-residential/ · https://zibox.com.br/locker-inteligente-para-condominio/ **LGPD e assembleias** - ConJur — reconhecimento facial em condomínios sob a LGPD: https://www.conjur.com.br/2024-abr-07/reconhecimento-facial-em-condominios-desafios-sob-a-otica-da-lgpd/ - Idec — reconhecimento facial em condomínio: https://idec.org.br/dicas-e-direitos/reconhecimento-facial-em-condominio-direitos-de-consumidores - Ponto Tecnologia — facial + LGPD (2025): https://pontotecnologia.com.br/2025/08/29/reconhecimento-facial-lgpd-condominios-2/ - Lei 14.309/2022 (assembleias pela internet): https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2022/lei/l14309.htm **Hubs, padrões e tecnologia de "cérebro"** - Home Assistant — arquitetura (event bus / state machine): https://developers.home-assistant.io/docs/architecture_components/ - Home Assistant — IA no smart home / gatilhos por intenção / Ollama / Assist / MCP: https://www.home-assistant.io/blog/2025/09/11/ai-in-home-assistant/ · https://www.home-assistant.io/blog/2026/07/01/release-20267/ · https://www.home-assistant.io/integrations/ollama/ · https://www.home-assistant.io/voice_control/ · https://www.home-assistant.io/integrations/mcp/ - Home Assistant — energia / utility meter (água): https://www.home-assistant.io/docs/energy/water/ · https://www.home-assistant.io/integrations/utility_meter/ - Matter 1.5 (câmeras, closures, energia) — CSA: https://csa-iot.org/newsroom/matter-1-5-introduces-cameras-closures-and-enhanced-energy-management-capabilities/ - Matter vs Zigbee vs Z-Wave (2026): https://matterreviews.com/matter-vs-zigbee-vs-z-wave-smart-home-protocol-comparison-2026/ - Frigate — NVR local + MQTT: https://docs.frigate.video/ · https://github.com/blakeblackshear/frigate - BACnet vs Modbus / gateway→MQTT: https://www.emqx.com/en/blog/bacnet-vs-modbus · https://bliiot.com/products/modbus-bacnet-to-mqtt-gateway-ba113 - Sub-medição energia/água (MQTT): https://energy2mqtt.org/ · https://www.iammeter.com/docs/home-assistant - Anomalia/energia (IA em prédios): https://www.sciencedirect.com/science/article/pii/S0306261921001409 - Confiabilidade — degradação graciosa (AWS/Google) / watchdog HA: https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html · https://andrewdoering.org/blog/2025/home-assistant-automation-watchdog/