Gladys Assistant

Gladys Assistant é distribuído como software open source e pode ser executado dentro da residência. O código pode ser auditado, modificado e ampliado. A lógica de automação, os estados e muitas integrações permanecem locais, reduzindo a necessidade de enviar cada evento a serviços externos. A vantagem é controle sobre a infraestrutura e sobre a retenção de dados. A limitação é a responsabilidade. O proprietário precisa manter hardware, armazenamento, atualizações, backups e rede. Código aberto não significa automaticamente seguro; versão desatualizada, senha fraca ou serviço exposto criam risco. A instalação deve usar host suportado, conta administrativa protegida, HTTPS ou VPN para acesso externo e cópias testadas. Integrações de nuvem continuam com suas próprias políticas. A privacidade precisa ser analisada de ponta a ponta.

A estratégia atual do projeto prioriza Zigbee, Matter e MQTT, além de integrações diretas para Shelly, Sonos, Tuya, TP-Link, câmeras RTSP e outros produtos. Zigbee permite ampla oferta de sensores e atuadores; Matter reduz dependência de marca; MQTT conecta projetos locais e gateways. A plataforma oferece uma camada comum de dispositivos e recursos. A vantagem é interoperabilidade. A limitação é que cada padrão possui versões e escopos. Matter não expõe todos os recursos proprietários. Zigbee depende do coordenador e de conversores. MQTT exige definir tópicos e payload. Uma integração listada não significa suporte a cada modelo. O inventário deve registrar fabricante, firmware, protocolo e funções testadas. Dispositivos de segurança precisam de validação adicional e não devem depender de suporte experimental.

Gladys oferece dashboard, cômodos, dispositivos, cenas e automações numa interface voltada a usuários domésticos. Integrações oficiais são gratuitas e fazem parte do projeto. Isso reduz fragmentação de licenças. Em comparação com plataformas baseadas em mercados extensos, a curadoria busca uma experiência mais uniforme. O custo é menor amplitude imediata para equipamentos raros. Um dispositivo não suportado pode exigir desenvolvimento, Matterbridge, MQTT ou espera. O usuário precisa avaliar o catálogo antes de migrar. A ausência de taxa por plugin não elimina custo de hardware e manutenção. A interface precisa continuar simples, mas automações complexas exigem documentação. O projeto deve separar regras essenciais e experimentais, usar nomes estáveis e testar reinícios.

A documentação oficial descreve integração de dispositivos Matter para controlar luzes, tomadas, persianas, termostatos e sensores de fabricantes diferentes. A implantação exige controlador e infraestrutura compatíveis com o transporte do dispositivo. Matter over Wi‑Fi usa a LAN; Matter over Thread exige Border Router e credenciais Thread. O servidor Gladys precisa alcançar a rede IP e atender aos requisitos da implementação. O benefício é integrar produtos certificados sem escrever um plugin por marca. A limitação é a maturidade. Classes, atributos e comandos disponíveis dependem da versão Matter e do dispositivo. Funções avançadas podem ficar no app original. Códigos de comissionamento devem ser guardados. A mesma unidade não deve ser comissionada de maneira duplicada sem governança.

Gladys pode ser usado como núcleo local e complementar o acesso remoto por serviços opcionais ou infraestrutura própria. O modelo permite que a casa continue executando automações quando a internet falha, desde que os dispositivos e integrações sejam locais. O benefício é disponibilidade. A limitação é que câmeras em nuvem, Tuya, notificações push e assistentes podem continuar dependentes de terceiros. O projeto precisa classificar cada automação. Luz por Zigbee pode ser local; um comando de voz pode exigir nuvem. O dashboard remoto pode depender de túnel. Testes de desconexão mostram. Para funções críticas, controle físico permanece. A arquitetura local-first reduz dependência, não elimina.