Pusimos un juego a correr en la pantalla de un SR-260, manejado con las teclas del propio remoto, con cero equipos Control4 en la red. El juego es la excusa: lo que se probó es que esa pantalla es un destino de escritura legítimo desde Home Assistant. Y de la prueba salió algo que no existía en ninguna parte — la hoja de datos de esa pantalla.
Una instalación Control4 sin controlador —porque se quemó, porque no se renovó la licencia, o porque el integrador que la puso ya no está— deja al dueño con hardware caro que dejó de responder. Los teclados, los dimmers y los remotos siguen ahí, siguen funcionando por radio, y no hay nada que les hable.
La pregunta que abrió esta línea de investigación es directa: ¿se puede rescatar ese hardware? No emulando un controlador, sino hablándole en su propio protocolo desde un sistema abierto.
Que el lazo cierre en las dos direcciones: que el equipo Control4 nos hable, y que nosotros podamos hablarle a él.
La investigación anterior ya había cerrado el sentido de entrada: el botón rojo de un SR-260 enciende un dispositivo SONOFF, de otra marca, sin que exista un procesador Control4 en la instalación. El remoto habla; nosotros escuchamos.
Faltaba la salida, que es la mitad difícil: escribir nosotros en un equipo propietario. Y el mejor destino posible es la pantalla del remoto, porque el resultado se ve — no hay que creerle a un log.
Cada dispositivo Zigbee publica un descriptor que dice qué sabe hacer. El del SR-260 declara
mac_capability_flags = 140, y el bit 3 de ese valor significa receptor siempre
encendido: un equipo al que se le puede escribir en cualquier momento.
No lo cumple. Una ráfaga de 30 escrituras con el remoto en reposo falló entera, con casi 15 segundos de espera por intento. Las mismas escrituras entran sin problema mientras el usuario tiene una tecla apretada.
Al remoto solo se le puede dibujar mientras está transmitiendo. Mantener una tecla apretada lo despierta cada 487 ms, y esa es toda la ventana que hay.
Ese dato no es una curiosidad del juego. Es lo que hay que saber antes de intentar cualquier integración con estos remotos: una etiqueta que se manda “cuando pasa algo” no llega, y el sistema parece roto sin estarlo.
Ni la documentación de Control4 ni la comunidad tienen esto escrito. Salió de sondear la pantalla carácter por carácter, código por código.
El ROM de caracteres se corta en 0x7E. No hay bloques, ni flechas, ni siluetas: cualquier dibujo tiene que hacerse con ASCII.
" \ ] — el delimitador y el escape del comando; se pierden en la tramaCada uno de esos renglones costó una prueba, y varios contradicen lo que decía la documentación de la que partimos. Cuando el hardware y el papel no coinciden, gana el hardware.
Con una sola línea de texto y sin glifos gráficos, el resultado iba a ser pobre. La documentación del protocolo tenía además una advertencia: no usar el menú de listas, porque suprime los eventos de los botones.
La advertencia era exagerada, y casi mata el mejor diseño. Suprime dos teclas, no todas. El disparador para revisarla fue una observación de sentido común: con un procesador Control4 de verdad, la tecla Watch del remoto muestra una lista de fuentes en varios renglones. Si el equipo sabe hacer eso, se puede usar.
Tres renglones de texto libre y una barra de resalte, repintables dos veces por segundo, es una interfaz de usuario completa en un equipo que se creía de solo lectura.
La barra blanca es el piso: es la fila seleccionada del menú, dibujada en video inverso por el propio remoto. El dino salta cambiando de renglón, y el cactus le pasa por debajo.
No se juega con el botón rojo: ese es una de las teclas que cierran cualquier lista en pantalla. Se descubrió chocando contra ello.
Banco propio: un SR-260, un coordinador Zigbee genérico y Home Assistant. Ningún equipo Control4 más.
El juego no le sirve a nadie en producción. Lo que sirve es lo que hizo falta para construirlo:
El código es libre y está publicado, con la lógica del juego separada de la parte de red: 26 pruebas automáticas corren sin radio, sin Home Assistant y sin remoto. Tres de esas pruebas existen por errores encontrados sobre el hardware real, y están para que no vuelvan.
Una investigación que exagera su alcance produce decisiones confiadas y equivocadas. Los límites, escritos con la misma letra que los resultados:
Si el documento y el hardware no coinciden, gana el hardware: se anota y se corrige el documento. En esta investigación pasó dos veces, y las dos veces el documento estaba mal.