Digital signage headless: uno script, una pipeline o un agente gestisce gli schermi

In un sistema di signage tradizionale la web app è la superficie di controllo e il player la segue. In un sistema headless il controllo vive in un’API. Qualsiasi client chiama lo stesso piano di controllo, il piano di controllo decide cosa riproduce ogni Player, e il Player lo mostra e riferisce l’esito. La dashboard è un client in più, e nessun client deve restare aperto perché uno schermo continui a riprodurre.

Programmabile significa che è il codice a controllare cosa viene riprodotto. Programmatic di solito indica l’acquisto automatizzato di spazi pubblicitari su schermi out-of-home, che la pagina Player tratta a parte.

Il team di piattaforma vuole la sua pipeline di rilascio sulla TV vicino alla macchinetta del caffè: ogni passaggio mentre accade, il più recente in cima, con una riga rossa quando qualcosa fallisce. La pipeline, i numeri dei job e gli host sono contenuti dimostrativi. L’esecuzione è reale: 26 ottobre 2026, sull’ambiente di staging di screenRIG, con le immagini disegnate dal Player in una finestra del browser al posto della TV. Ogni fase della pipeline esegue una volta un piccolo script:

1. Pipeline avviata. main, 3 commit.
2. Test superati. 412 test in 3 min 10 s.
3. Deploy in produzione non riuscito. Il controllo di integrità è scaduto su web-2, rollback in corso.
4. Rollback completato. web-1 e web-2 di nuovo funzionanti.

Dopo il terzo passaggio l’errore è la riga grande, i passaggi precedenti sono elencati con la loro età e il piè di pagina conta gli eventi e gli errori dell’ora. Dopo il quarto, il rollback è in cima e il deploy fallito sta sotto.

La parte dell’agente è breve e avviene una sola volta. Crea una bacheca Feed attività, le dà una prima riga perché la pagina non sia vuota e la mette sullo schermo. Poi consegna alla pipeline uno script. Lo script legge la bacheca e la sua revisione, mette la nuova riga in cima e la riscrive solo se nessuno ha scritto nel frattempo:

# $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

Non fa polling. Il flusso di eventi del progetto è riproducibile, e una pipeline può leggerlo mentre scrive. Per il deploy fallito, il flusso ha riportato la scrittura, la modifica e poi la segnalazione del Player stesso di aver applicato quella revisione a quella pagina (orari in UTC, ridotti a evento e revisione):

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"

Il Player ha riportato la revisione 1,8 secondi dopo che la scrittura è stata accettata. Un job che non deve proseguire finché lo schermo non mostra un errore può attendere quell’ultima riga, e un job a cui non importa può ignorarla. Gli eventi dello schermo sono gratuiti sul flusso di ascolto, e una riconnessione riprende dall’ultimo cursore.

Due job possono scrivere nello stesso momento. Una scrittura che porta una revisione obsoleta viene rifiutata, e il rifiuto indica quale revisione è quella corrente, così nessuno sovrascrive una riga più recente. Lo script rilegge e riprova, fino a tre volte.

Tutto ciò che deve continuare a funzionare quando nessun client è connesso. Il Player visualizza; il server decide.

Un tag seleziona una flotta, quindi un solo comando raggiunge tutti gli schermi che lo hanno.

La dashboard è un client in più, e alcune attività sono adatte a una persona.

• Revisioni. Un agente che ha effettuato l’accesso con Proponi accesso, o un progetto che richiede la revisione, invia le modifiche alla pagina Revisioni. Una persona approva, richiede modifiche o rifiuta, e nulla raggiunge uno schermo prima di allora.
• Accesso. La pagina Accesso elenca ogni agente, app connessa e client di servizio, e una persona può terminare l’accesso di ciascuno da lì.
• Persone e progetti. Inviti e impostazioni del progetto spettano alle persone.

Il digital signage headless è lo stesso del digital signage API-first?

Descrivono lo stesso progetto da due lati. API-first significa che l’API viene progettata per prima e ogni client la usa. Headless significa che per gestire gli schermi non serve alcuna interfaccia particolare.

Mi serve uno sviluppatore per gestire il digital signage headless?

No. Un agente può gestirlo con una frase, e una persona approva ciò che propone quando il progetto richiede la revisione. Uno sviluppatore aggiunge script come quello qui sopra quando un sistema deve scrivere su uno schermo da solo.

Posso tenere i miei contenuti in un altro sistema?

Sì. Uno script legge il sistema e scrive i valori su una bacheca. Gli schermi mostrano ciò che custodisce il server.

Quali Player pilota una configurazione headless?

Dodici: il Player web, Android e Google TV, l’Amazon Signage Stick, Apple TV, macOS, iPhone e iPad, Windows, Linux, Raspberry Pi, LG webOS Signage, Samsung Smart Signage (Tizen) e BrightSign. La guida ai Player contiene i passaggi di installazione.

Il digital signage headless è gratuito?

screenRIG è gratuito, con schermi illimitati. I piani a pagamento aggiungono strumenti aziendali, più persone, persone con cui parlare, governance e condizioni contrattuali. Vedi i prezzi; Sviluppatori mostra ogni interfaccia.

Leggi il riferimento API REST per le chiamate che fa lo script, oppure inizia gratis e lascia che sia il tuo agente a scrivere lo script.