sACN (ANSI E1.31)

sACN, abreviação de Streaming Architecture for Control Networks, é o uso da família ACN para transportar dados de controle DMX512 em redes IP. O padrão ANSI E1.31 foi desenvolvido pela ESTA e tornou-se uma das principais formas de distribuir universos de iluminação sobre Ethernet. A unidade lógica é o universo. Um emissor, chamado source, transmite valores de até 512 slots, prioridade, sequência, identificação e metadados. Um receptor escuta um ou mais universos e aplica os dados a uma saída DMX, luminária nativa, controlador de pixels ou software. O protocolo usa UDP e define multicast IPv4 específico para cada universo, além de unicast. O multicast evita broadcast para toda a sub-rede: switches com IGMP snooping encaminham o grupo apenas às portas que têm receptores interessados. Isso melhora escala. Sem IGMP snooping, o switch pode inundar o multicast como broadcast. Em Wi‑Fi, o tráfego continua custoso porque grupos podem ser enviados em taxa básica. Instalações profissionais preferem Ethernet cabeada e segmentação. sACN é construído sobre ACN, ANSI E1.17, e usa uma estrutura em camadas de PDUs. O Root Layer identifica a família e a fonte por CID, um UUID de 128 bits. O Framing Layer inclui nome da fonte, prioridade, número de sequência, opções e universo. O DMP Layer carrega os valores DMX. O nome da fonte ajuda operação; o CID identifica de forma estável. Dois emissores não devem usar o mesmo CID. A prioridade normalmente varia de 0 a 200, com valor padrão 100. O receptor escolhe a fonte de maior prioridade para um universo. Se duas fontes têm a mesma prioridade, pode ocorrer merge por slot conforme as regras e capacidades. Extensões posteriores introduzem Per-Address Priority, permitindo prioridade por canal. Nem todo equipamento implementa. O projeto precisa verificar. Em um sistema principal e backup, o principal pode transmitir prioridade 100 e o backup 90. Se o principal para, após timeout o receptor passa ao backup. Isso é mais determinístico que depender apenas de HTP. A mudança precisa ser testada para evitar blackout. O número de sequência tem 8 bits e incrementa por pacote. O receptor detecta pacotes fora de ordem. Após wrap, continua. Perdas podem ser toleradas porque quadros seguintes atualizam. O padrão define comportamento de terminação de stream. Um source envia pacotes com stream termination para informar saída. Se falha abruptamente, o receptor usa timeout. O estado após ausência depende do dispositivo: manter último look, zerar, usar outra fonte ou cena. Configurar. O protocolo pode enviar Preview Data para indicar dados que não devem ser usados em saída normal, útil em visualizadores. Synchronization Address permite coordenar universos. Um source transmite dados com endereço de sincronização e depois pacote Sync para aplicação simultânea. Isso reduz tearing em grandes matrizes. Receptores precisam suportar. Discovery de universos foi adicionado para anunciar quais universos uma fonte transmite. Isso ajuda consoles e monitoramento. Não é autenticação. Qualquer nó na rede pode enviar sACN com prioridade alta. O padrão não inclui criptografia ou controle de acesso. VLAN, ACL e segurança do controlador são necessárias. Não expor UDP sACN à Internet. Acesso remoto deve passar por VPN ou software autenticado que gere localmente. A interoperabilidade é um ponto forte porque E1.31 é um padrão ANSI e fabricantes implementam. ETC, Pathway, Luminex, Swisson, ENTTEC, DMXKing, Madrix, QLC+, OLA e outros oferecem suporte. Contudo, um rótulo “sACN” não garante todas as extensões. Alguns receptores aceitam apenas multicast; outros unicast. Alguns fazem merge de duas fontes; outros apenas prioridade. Alguns suportam universos 1–63999 ou subconjuntos. O padrão possui faixa de universo definida e reservas. A versão da edição importa. O integrador deve testar com equipamento real. Comparado a Art-Net, sACN entrega padronização ANSI, multicast por universo e prioridade de fonte bem definida. Art-Net oferece descoberta e configuração de nós mais ampla no protocolo e possui grande legado. Ambos funcionam. A escolha depende do ecossistema. Em instalações novas e multi-vendor, sACN costuma ser preferido para streaming. Art-Net pode permanecer para equipamentos específicos. Gateways traduzem, mas a tradução de prioridade, sync e merge precisa ser validada. Comparado a DALI, sACN é transporte de níveis de alta taxa, não barramento de configuração e controle endereçado de luminárias. DALI trabalha com dispositivos e comandos; sACN envia slots DMX continuamente. Em automação residencial, sACN é útil em fachadas, jardins cênicos, home theaters, pixel mapping e integração com show control. Para iluminação comum de cômodos, KNX, DALI, Matter ou relés podem ser mais adequados. O protocolo não armazena cenas nos dispositivos necessariamente. Se o servidor falha, o receptor pode manter último estado, mas não existe garantia funcional. Controladores locais e fallback devem ser projetados. A taxa de quadros pode chegar ao equivalente DMX e além, mas não deve ser maior que a necessidade. Cada universo completo gera cerca de centenas de bytes por pacote. Mil universos a 44 fps produzem dezenas ou centenas de megabits considerando overhead e multicast. A rede precisa de margem. Um switch gigabit pode suportar, mas receptores e uplinks podem não. IGMP querier é importante quando não há roteador multicast. Sem querier, tabelas de snooping podem expirar e inundar. O projeto deve configurar. Em redes com VLAN, multicast não atravessa sem roteamento PIM ou gateway. Normalmente mantém-se local. Monitoramento pode usar sACNView, Wireshark e OLA. O diagnóstico verifica CID, source name, universo, prioridade, sequência, taxa e grupos. Um erro comum é ter dois consoles com prioridade 100 e esperar failover limpo. Devem existir prioridades e política. Outro erro é usar multicast em Wi‑Fi para milhares de pixels. A consequência prática é atraso e perda. Ethernet é preferível.