RDM (ANSI E1.20)

RDM, Remote Device Management, é um protocolo bidirecional definido pela ANSI E1.20 para adicionar descoberta, configuração, identificação e monitoramento a redes DMX512. O DMX512 tradicional é essencialmente unidirecional: um controlador transmite continuamente até 512 slots a receptores. RDM usa o mesmo par de dados e a mesma topologia básica, inserindo transações entre os quadros DMX de forma que o controle de iluminação continue. O controlador RDM, chamado controller, inicia todas as transações. Os dispositivos gerenciados, responders, respondem somente quando solicitados, salvo mecanismos definidos por extensões. A comunicação segue temporização rigorosa para evitar colisões. Um controlador envia uma requisição com destino, command class e Parameter ID, ou PID. O responder devolve dados, confirmação, erro, ACK_TIMER ou outras respostas. GET_COMMAND lê; SET_COMMAND altera; DISCOVERY_COMMAND participa da descoberta. PIDs padronizados cobrem identificação, fabricante, modelo, versão, label, endereço DMX, footprint, personalidade, sensores, horas de lâmpada, mensagens de status, pan/tilt invertido, curva, modos e outros. Fabricantes podem definir PIDs próprios sob regras. O UID de cada dispositivo tem 48 bits, composto por Manufacturer ID e Device ID. Deve ser único. O controlador usa para endereçar, mesmo antes de saber o endereço DMX. A descoberta é a parte mais característica. Como vários responders compartilham o barramento, o controlador usa um algoritmo de busca binária por intervalo de UID com mensagens DISC_UNIQUE_BRANCH. Responders dentro do intervalo enviam uma resposta codificada. Se há um, o controlador identifica e faz mute para que não responda às próximas buscas. Se há colisão, divide o intervalo e continua. Ao final, faz unmute conforme necessário. Esse processo permite localizar dispositivos sem endereço conhecido. A robustez depende de temporização, qualidade do cabo, terminação, splitters e implementação. Equipamentos DMX antigos que não são RDM devem ignorar a comunicação porque usa Start Code específico. Alguns produtos mal projetados piscam ou falham. Por isso, controladores permitem desativar RDM. Splitters precisam ser RDM compatíveis e bidirecionais. Um splitter DMX unidirecional bloqueia respostas. Optoisoladores e gateways também. A topologia DMX é daisy chain com terminação de 120 ohms no fim, cabos adequados e limites de carga. RDM não corrige instalação ruim. Como o barramento alterna direção, a camada física precisa controlar driver e turnaround. O controlador ocupa o meio de transmissão durante transações. Se a taxa de consulta for excessiva, reduz a frequência efetiva do DMX. O padrão estabelece janelas para manter. Sensores não devem ser polled a cada milissegundo. Um controlador profissional agenda. Status Messages permitem que dispositivos reportem falhas quando consultados. A função de queued messages ajuda recuperar eventos. Extensões da família ANSI E1.37 adicionam conjuntos de PIDs para configuração de rede, dimmers, gateways, file transfer e funções gerais. RDMnet, ANSI E1.33, transporta RDM em redes IP e permite brokers e discovery. Não é o mesmo que RDM físico. Art-Net possui transporte ArtRdm; sACN por si só não transporta RDM, embora RDMnet use arquitetura de rede relacionada. Gateways convertem. A tradução precisa preservar UID, PIDs, subdevices e respostas. RDM suporta sub-devices dentro de um responder, como módulos de um rack. O Sub-Device ID identifica. Um controlador precisa enumerar. A identificação visual usa IDENTIFY_DEVICE para piscar ou mostrar o aparelho. Isso ajuda manutenção em tetos e fachadas. DEVICE_LABEL permite nomes. DMX_START_ADDRESS altera. DEVICE_INFO informa footprint e personalidade. DMX_PERSONALITY seleciona modos. SLOT_INFO e DEFAULT_SLOT_VALUE descrevem. SENSOR_DEFINITION e SENSOR_VALUE leem temperatura, tensão, corrente ou outros. Os dados têm unidade, prefixo, faixa, normal e suporte. Não assumir Celsius sem ler. Status Messages têm categorias de erro, warning, advisory. A manutenção pode detectar sobretemperatura e falha de ventoinha. O protocolo não garante que todos os produtos implementem todos os PIDs. Há required e optional. O controller deve consultar SUPPORTED_PARAMETERS e tratar NACK_REASON. Um NACK não é falha de rede necessariamente; pode indicar PID desconhecido, acesso negado, formato incorreto, dado fora de faixa ou estado inválido. SETs precisam de confirmação e leitura posterior. Mudar endereço DMX de múltiplos dispositivos pode criar conflitos. O software deve validar footprint e universo. Em iluminação residencial arquitetural, RDM reduz necessidade de subir em escada para reendereçar luminárias, escolher personalidade, inverter parâmetros ou ver temperatura. O benefício é maior em instalações grandes e de difícil acesso. O custo é compatibilidade e infraestrutura. Um cabo ou splitter barato pode bloquear. A certificação e testes ESTA Plugfest ajudam, mas o comprador deve verificar. O padrão é normativo, não existe garantia de que um produto rotulado implementa corretamente. Ferramentas como DMXcat, Swisson XMT, ETC, Pathway e OLA podem descobrir. Alguns consoles fazem. O protocolo não oferece autenticação, criptografia ou autorização. Qualquer controlador conectado fisicamente pode SET endereço ou configuração. A segurança é física e de rede nos gateways. Não expor RDMnet ou ArtRdm a redes não confiáveis. Em um evento, patch de convidado pode alterar. Segmentar. A bidirecionalidade também pode revelar inventário. Em sistemas críticos, bloquear SET ou usar controller autorizado. RDM não é destinado a streaming de alta frequência. Sensores são gerenciamento, não telemetria de milissegundos. Para dados contínuos, usar protocolo de rede adequado. RDM resolve a manutenção do universo DMX com compatibilidade retroativa. A limitação honesta é que a convivência com equipamentos legados nem sempre é perfeita. Ativar gradualmente e testar cada cadeia.