Señalización digital headless: un script, un pipeline o un agente maneja las pantallas

En un sistema de señalización tradicional, la app web es la superficie de control y el reproductor la sigue. En un sistema headless, el control reside en una API. Cualquier cliente llama al mismo plano de control, el plano de control decide qué reproduce cada Player, y el Player lo renderiza e informa de vuelta. El panel es un cliente más, y ningún cliente necesita seguir abierto para que una pantalla siga reproduciendo.

Programable significa que el código controla lo que se reproduce. Programático suele significar la compra automatizada de espacios publicitarios en pantallas de publicidad exterior, algo que Players trata por separado.

El equipo de plataforma quiere su pipeline de lanzamientos en la TV junto a la máquina de café: cada paso a medida que ocurre, el más reciente primero, con una fila roja cuando algo falla. El pipeline, sus números de trabajo y sus hosts son contenido de demostración. La ejecución es real: 26 de octubre de 2026, en el entorno de staging de screenRIG, con las imágenes dibujadas por el Player en una ventana del navegador que hace las veces de la TV. Cada etapa del pipeline ejecuta un pequeño script una vez:

1. Pipeline iniciado. main, 3 commits.
2. Pruebas superadas. 412 pruebas en 3 min 10 s.
3. Falló el despliegue a producción. La comprobación de estado agotó el tiempo de espera en web-2; se está revirtiendo.
4. Reversión completada. web-1 y web-2 vuelven a estar en buen estado.

Tras el tercer paso, el error es la fila grande, los pasos anteriores aparecen con su antigüedad y el pie cuenta los eventos y errores de la hora. Tras el cuarto, la reversión queda arriba y el despliegue fallido debajo.

La parte del agente es breve y ocurre una sola vez. Crea un tablero de Feed de actividad, le da una primera fila para que la página no esté vacía y lo pone en la pantalla. Después le entrega un script al pipeline. El script lee el tablero y su revisión, pone la fila nueva primero y la escribe de vuelta solo si nadie escribió mientras tanto:

# $url is the board's address and $auth carries your token.
# 1. Read the board and its revision (the ETag).
etag=$(curl -sS -D - -o current.json -H "$auth" "$url" | awk 'tolower($1) == "etag:" { print $2 }' | tr -d '\r')
# 2. Write the board back with the new row first. A stale revision is refused, and the script reads again.
curl -sS -X PUT "$url" -H "$auth" -H "Content-Type: application/json" -H "If-Match: $etag" -H "Idempotency-Key: board-$(date -u +%s%N)" --data @next.json

No hace sondeos. El flujo de eventos del proyecto se puede reproducir y un pipeline puede leerlo mientras se escribe. En el caso del despliegue fallido, el flujo transportó la escritura, el cambio y, después, el propio informe del Player de que había aplicado esa revisión a esa página (horas en UTC, reducidas a evento y revisión):

03:43:47.501  kv.updated                 revision 5 written
03:43:47.505  screen.card_data_changed   revision 5
03:43:49.306  screen.card_data_applied   revision 5, page "board"

El Player informó de la revisión 1.8 segundos después de que se aceptara la escritura. Un trabajo que no debe continuar hasta que la pantalla muestre el fallo puede esperar a esa última línea, y un trabajo al que no le importe puede ignorarla. Los eventos de pantalla son gratuitos en el flujo de escucha, y una reconexión se reanuda desde el último cursor.

Dos trabajos pueden escribir a la vez. Una escritura que lleva una revisión obsoleta se rechaza, y el rechazo indica cuál es la revisión vigente, así que nadie sobrescribe una fila más reciente. El script vuelve a leer y reintenta, hasta tres veces.

Todo lo que debe seguir funcionando cuando no hay ningún cliente conectado. El Player renderiza; el servidor decide.

Una etiqueta selecciona una flota, así que un solo comando llega a cada pantalla que la lleva.

El panel es un cliente más, y algunas tareas son más adecuadas para una persona.

• Revisiones. Un agente que inició sesión con el acceso Proponer, o un proyecto que exige revisión, envía los cambios a la página Revisiones. Una persona aprueba, solicita cambios o rechaza, y nada llega a una pantalla antes de eso.
• Acceso. La página Acceso enumera cada agente, app conectada y cliente de servicio, y una persona puede finalizar cualquiera de ellos desde allí.
• Personas y proyectos. Las invitaciones y los ajustes del proyecto corresponden a las personas.

¿La señalización digital headless es lo mismo que la señalización digital API-first?

Describen el mismo diseño desde dos lados. API-first significa que la API se diseña primero y todos los clientes la usan. Headless significa que no se necesita ninguna interfaz concreta para manejar las pantallas.

¿Necesito un desarrollador para usar señalización digital headless?

No. Un agente puede manejarlo a partir de una frase, y una persona aprueba lo que propone cuando el proyecto exige revisión. Un desarrollador añade scripts como el anterior cuando un sistema debe escribir en una pantalla por sí solo.

¿Puedo mantener mi contenido en otro sistema?

Sí. Un script lee el sistema y escribe los valores en un tablero. Las pantallas renderizan lo que guarda el servidor.

¿Qué Players maneja una configuración headless?

Doce: el Player web, Android y Google TV, el Amazon Signage Stick, Apple TV, macOS, iPhone e iPad, Windows, Linux, Raspberry Pi, LG webOS Signage, Samsung Smart Signage (Tizen) y BrightSign. La guía de Players incluye los pasos de instalación.

¿La señalización digital headless es gratis?

screenRIG es gratis, con pantallas ilimitadas. Los planes de pago añaden herramientas de negocio, más personas, personas con quienes hablar, gobernanza y condiciones contractuales. Vea los precios; Desarrolladores muestra cada interfaz.

Lea la referencia de la API REST con las llamadas que hace el script, o comience gratis y deje que su agente escriba el script.