Salute dei dispositivi: comandi CLI

Riavvia il dispositivo di uno schermo o i dispositivi di una flotta.

screen reboot (<id>... | --tag TAG | --folder ID) [--yes] [--expires-in DURATION] [--expect-rev REVISION]

screenrig screen reboot scr_LOBBY
screenrig screen reboot scr_LOBBY --expires-in 2h
screenrig screen reboot --tag Lobby --yes
screenrig screen reboot --folder sfd_01EXAMPLEFOLDER000000000 --yes

Il Player riavvia il dispositivo, non solo se stesso. Uno schermo online riceve subito il riavvio (state sent); uno schermo offline lo tiene queued e lo riceve quando torna online prima di expires_at, 24 ore dopo la richiesta salvo diversa indicazione di --expires-in. La risposta contiene reboot_id, state e expires_at. Un riavvio più recente sostituisce uno ancora in coda. screen show elenca i commands dello schermo: un riavvio inviato diventa done quando il dispositivo riporta di essersi avviato, e screen command cancel ne annulla uno ancora in coda. In una flotta, il reboot di ogni risultato contiene lo stesso state. Una richiesta rifiutata o fallita, e una ripetizione esatta della stessa richiesta, non contano per il limite per schermo. Dal momento in cui un riavvio viene inviato finché il dispositivo riporta di essersi avviato o passano dieci minuti, lo schermo non apre alert screen_offline o display_disconnected; un avviso per uno dei due in scadenza in quel lasso attende la fine del periodo più la sua attesa, e un avviso crashing viene saltato come planned_reboot. Una condizione che persiste dopo si apre normalmente.

Svuota le cache del Player di uno schermo o dei Player di una flotta.

screen clear-cache (<id>... | --tag TAG | --folder ID) [--yes] [--expires-in DURATION] [--expect-rev REVISION]

screenrig screen clear-cache scr_LOBBY
screenrig screen clear-cache scr_LOBBY --expires-in 2h
screenrig screen clear-cache --tag Lobby --yes

Il Player elimina i media scaricati, i pacchetti applicativi e le cache dei dati, mantiene associazione, identità e impostazioni, poi recupera di nuovo il manifest e i contenuti; lo schermo può mostrare il suo stato di caricamento mentre i contenuti si ripopolano. Raggiunge solo un Player che dichiara clear_cache. Uno schermo online riceve subito la richiesta (state sent); uno schermo offline la mantiene queued e la riceve quando torna online prima di expires_at, 24 ore dopo la richiesta salvo diversa indicazione di --expires-in. La risposta contiene command_id, command, state e expires_at. Un Player che non dichiara la capacità risponde 409 command_unsupported e non viene inviato nulla; in una flotta quello schermo fallisce da solo. screen show elenca il comando sotto commands e, quando il Player riporta, lo contrassegna done o failed con una cause e un breve detail: cleared quando le cache sono svuotate e il recupero è iniziato, oppure clear_failed quando una cache non può essere svuotata. Un comando inviato senza report resta sent. Un comando più recente dello stesso tipo sostituisce uno ancora in coda, e screen command cancel ne annulla uno ancora in coda. In una flotta, il command di ogni risultato contiene lo stesso state. Una flotta (più id, --tag o --folder) necessita --yes. Una richiesta rifiutata o fallita, e una ripetizione esatta della stessa richiesta, non contano per il limite per schermo di 2 richieste insieme di clear-cache, restart-app e update-software ogni 10 minuti.

Riavvia l’applicazione del Player di uno schermo o dei Player di una flotta.

screen restart-app (<id>... | --tag TAG | --folder ID) [--yes] [--expires-in DURATION] [--expect-rev REVISION]

screenrig screen restart-app scr_LOBBY
screenrig screen restart-app scr_LOBBY --expires-in 2h
screenrig screen restart-app --tag Lobby --yes

Il Player riavvia la sua applicazione, non il dispositivo (un Player web ricarica la sua pagina) e riporta dal processo riavviato. Raggiunge solo un Player che dichiara restart_app; screen reboot riavvia il dispositivo. Uno schermo online riceve subito la richiesta (state sent); uno schermo offline la mantiene queued e la riceve quando torna online prima di expires_at, 24 ore dopo la richiesta salvo diversa indicazione di --expires-in. La risposta contiene command_id, command, state e expires_at. Un Player che non dichiara la capacità risponde 409 command_unsupported e non viene inviato nulla; in una flotta quello schermo fallisce da solo. screen show elenca il comando sotto commands e, quando il Player riporta, lo contrassegna done o failed con una cause e un breve detail: restarted, oppure restart_failed quando il riavvio non può partire. Un comando inviato senza report resta sent. Un comando più recente dello stesso tipo sostituisce uno ancora in coda, e screen command cancel ne annulla uno ancora in coda. In una flotta, il command di ogni risultato contiene lo stesso state. Una flotta (più id, --tag o --folder) necessita --yes. Una richiesta rifiutata o fallita, e una ripetizione esatta della stessa richiesta, non contano per il limite per schermo di 2 richieste insieme di clear-cache, restart-app e update-software ogni 10 minuti.

Aggiorna il Player di uno schermo, o i Player di una flotta, all’ultima release.

screen update-software (<id>... | --tag TAG | --folder ID) [--yes] [--expires-in DURATION] [--expect-rev REVISION]

screenrig screen update-software scr_LOBBY
screenrig screen update-software scr_LOBBY --expires-in 2h
screenrig screen update-software --tag Lobby --yes

Il Player controlla subito l’ultima release del Player e la installa dove la sua piattaforma consente al Player di aggiornarsi da solo; un Player web aggiorna il suo service worker, poi si ricarica. Raggiunge solo un Player che dichiara update: un Player installato da uno store o gestito da un gestore di dispositivi si aggiorna tramite quel canale. Uno schermo online riceve subito la richiesta (state sent); uno schermo offline la mantiene queued e la riceve quando torna online prima di expires_at, 24 ore dopo la richiesta salvo diversa indicazione di --expires-in. La risposta contiene command_id, command, state e expires_at. Un Player che non dichiara la capacità risponde 409 command_unsupported e non viene inviato nulla; in una flotta quello schermo fallisce da solo. screen show elenca il comando sotto commands e, quando il Player riporta, lo contrassegna done o failed con una cause e un breve detail: up_to_date quando l’ultima release è già in esecuzione, updated una volta avviata la nuova versione oppure, in caso di errore, update_check_failed, download_failed, install_failed o no_update_channel. Un comando inviato senza report resta sent. Un comando più recente dello stesso tipo sostituisce uno ancora in coda, e screen command cancel ne annulla uno ancora in coda. In una flotta, il command di ogni risultato contiene lo stesso state. Una flotta (più id, --tag o --folder) necessita --yes. Una richiesta rifiutata o fallita, e una ripetizione esatta della stessa richiesta, non contano per il limite per schermo di 2 richieste insieme di clear-cache, restart-app e update-software ogni 10 minuti.

Annulla un comando ancora in coda per uno schermo offline.

screen command cancel <id> <command_id> [--expect-rev REVISION]

screenrig screen command cancel scr_01EXAMPLESCREEN00000000 rbt_01EXAMPLEREBOOT00000000

Annulla un reboot, reload, clear_cache, restart_app o update che attende uno schermo offline, così non viene mai inviato. Solo un comando in coda può essere annullato. Un comando già inviato (sent o done) risponde 409 resource_conflict con "The command was already sent.", uno non più in coda (expired, cancelled o superseded) risponde 409 resource_conflict con "The command is no longer queued.", e un ID che lo schermo non elenca risponde 404 not_found. La risposta è lo schermo con il comando in stato cancelled, e la revisione dello schermo non cambia.

Accendi o spegni ora il display di uno schermo o di una flotta, oppure annulla questa sovrascrittura.

screen display [set] (<id>... | --tag TAG | --folder ID) --power on|off [--until TIME | --for DURATION] [--expect-rev REVISION]
screen display clear (<id>... | --tag TAG | --folder ID) [--expect-rev REVISION]

screenrig screen display scr_LOBBY --power off --for 2h
screenrig screen display --tag Lobby --power on
screenrig screen display scr_A scr_B --power off --for 8h
screenrig screen display clear --tag Lobby

screen display ID è la forma abbreviata di screen display set ID; clear non accetta --power, --until né --for. screen display è un override manuale del programma di visualizzazione. Senza --until o --for termina al prossimo confine del programma; un successivo cambio di programma o fuso orario sposta quella fine al nuovo confine. Senza confini nei prossimi otto giorni, per esempio senza programma abilitato, dura fino a screen display clear o a un sostituto. screen display clear termina l’override, quindi il programma di visualizzazione si applica di nuovo; senza uno, la visualizzazione è attiva.

Salvare un override non attende il Player. display.override_status confronta con essa un report di visualizzazione più recente: matches, mismatch, pending, stale o unknown; matches descrive il report, non l’esecuzione del comando. L’avviso display_power_mismatch indica un report recente che differisce e display_power_unconfirmed dice che serve un report più recente e utilizzabile; controlla quindi screen show prima di fare uno screenshot. display_scrim_only significa che il Player controlla solo una sovrapposizione nera: on la rimuove e non invia alcun comando di riattivazione hardware. Uno schermo in una cartella protetta rifiuta una modifica del display (protected_target).

Mostra, imposta o cancella quando il display di uno schermo è acceso.

screen display-schedule show <id>
screen display-schedule set (<id>... | --tag TAG | --folder ID) --file FILE [--expect-rev REVISION]
screen display-schedule clear (<id>... | --tag TAG | --folder ID) [--expect-rev REVISION]

screenrig screen display-schedule set scr_LOBBY --file hours.json
screenrig screen display-schedule set --tag Cafe --file hours.json

Un programma di visualizzazione è {enabled, windows}, entrambi obbligatori, e windows elenca da 1 a 16 finestre in cui il display è acceso, nel fuso orario dello schermo; fuori da ogni finestra il display va in standby. Il Player la valuta sul dispositivo, quindi funziona anche offline. Una finestra il cui end è uguale o precedente a start attraversa la mezzanotte, e una finestra senza start e end copre l’intera giornata. enabled: false mantiene le finestre e lascia il display acceso. display-schedule show risponde con display_schedule (null quando non ce n’è) e lo stato display dello schermo. L’output salvato può essere modificato e rinviato con set --file. Uno schermo in una cartella protetta rifiuta una modifica al suo programma di visualizzazione (protected_target).

{"enabled": true, "windows": [{"days": ["mon", "tue", "wed", "thu", "fri"], "start": "07:00", "end": "19:00"}, {"days": ["sat"]}]}

screen show --human stampa Display: con la potenza richiesta, la sua origine (override manuale, programmazione display o predefinita) e fino a quando nel fuso orario dello schermo, le finestre di programmazione e la potenza riportata dal Player, segnata come obsoleta dopo 35 minuti senza report.

Imposta il volume di uno schermo, o silenzialo, su uno schermo o su una flotta.

screen volume (<id>... | --tag TAG) [--level 0-100] [--mute | --unmute] [--expect-rev REVISION]

screenrig screen volume scr_LOBBY --level 40
screenrig screen volume scr_LOBBY --mute
screenrig screen volume scr_LOBBY --unmute
screenrig screen volume --tag Lobby --level 25 --unmute

Uno schermo ha un solo volume: un livello da 0 a 100 e un silenziamento. Silenziare mantiene il livello, quindi riattivare l’audio lo ripristina. Uno schermo online applica subito la modifica; uno schermo offline applica l’ultima richiesta quando torna online, e una richiesta più recente sostituisce la precedente. Una modifica fatta in seguito nel menu delle impostazioni del Player prevale fino alla successiva screen volume, e cambiare lì il livello disattiva il silenziamento. screen show riporta volume con l’ultima modifica requested e, come reported, i valori level e muted raggiunti dal Player e hardware: true quando il livello arriva all’uscita del dispositivo o del pannello, false quando è il guadagno proprio del Player; stale diventa true dopo 35 minuti senza un rapporto. Solo un Player che dichiara la capacità volume lo applica: ogni altro schermo risponde 409 volume_unsupported (codice di uscita 5) e non viene registrato nulla. Uno schermo archiviato risponde screen_archived e uno schermo ancora in attesa di associazione risponde resource_conflict. Uno schermo in una cartella protetta rifiuta la modifica (protected_target), e in una flotta un solo schermo protetto fa rifiutare l’intera richiesta. La pagina dello schermo nella dashboard ha lo stesso controllo Volume.

Oscura il display di uno schermo dopo un periodo senza uso, oppure disattiva questa funzione.

screen display-idle <id> --after SECONDS --wake WAKE [--expect-rev REVISION]
screen display-idle <id> --off [--expect-rev REVISION]

screenrig screen display-idle scr_LOBBY --after 300 --wake touch
screenrig screen display-idle scr_LOBBY --after 600 --wake touch,presence --expect-rev 4
screenrig screen display-idle scr_LOBBY --off

Il display si oscura dopo --after secondi senza un tocco o un tasto o, quando --wake elenca presence, senza nessuno davanti allo schermo. Mentre è oscurato il Player sospende la riproduzione, senza riproduzioni né annunci, e segnala l’alimentazione del display come off; un evento di riattivazione riaccende il display subito e la riproduzione riprende, e il tocco che riattiva un display oscurato non viene passato alla pagina. Una programmazione del display o un override che tiene spento il pannello ha la precedenza, così come un’applicazione che tiene device.display mentre la sua pagina è sullo schermo. Cambia solo display.idle. Un Player lo applica quando screen show elenca display_power.idle tra le sue capacità dell’host; l’impostazione viene memorizzata in ogni caso, e screen show la elenca come Display idle. L’accesso Propose non può modificarla (insufficient_access), e uno schermo in una cartella protetta la rifiuta (protected_target).

Imposta se la luminosità di uno schermo segue il sensore di luce del dispositivo.

screen brightness <id> --mode auto|fixed [--expect-rev REVISION]

screenrig screen brightness scr_LOBBY --mode auto
screenrig screen brightness scr_LOBBY --mode fixed --expect-rev 4

Cambia solo display.brightness. Un Player applica auto quando screen show elenca brightness.auto tra le sue capacità dell’host, che un dispositivo dichiara solo con un sensore di luce; un’applicazione che imposta la luminosità del display ha la precedenza finché la sua pagina è mostrata. L’impostazione viene memorizzata in ogni caso, e screen show la elenca come Display brightness. Si applicano le regole di accesso di screen display-idle.

Imposta la modalità video che il Player di uno schermo applica alla sua uscita, oppure cancellala.

screen display-output <id> (--mode MODE | --clear) [--expect-rev REVISION]

screenrig screen display-output scr_LOBBY --mode 3840x2160x60p
screenrig screen display-output scr_LOBBY --mode auto --expect-rev 4
screenrig screen display-output scr_LOBBY --clear

screen show elenca le modalità che il Player può impostare ora, sotto Output modes the Player can set, e la modalità in vigore. Una volta che il Player le ha riportate, una modalità fuori da quell’elenco è invalid_request, quindi scegline una tra quelle elencate. Cambia solo display.output. Un Player lo applica quando screen show elenca display_output.mode tra le sue capacità dell’host, che un player BrightSign dichiara; qualsiasi modalità diversa da auto su un altro Player risponde display_output_unsupported, e la cancellazione funziona sempre. Il Player applica una modalità una sola volta, può riavviarsi per farlo e riporta la modalità raggiunta. Si applicano le regole di accesso di screen display-idle.

Fai in modo che il Player di uno schermo prenda l’ingresso HDMI della TV tramite CEC, oppure smetta di farlo.

screen display-cec <id> (--on | --off | --clear) [--expect-rev REVISION]

screenrig screen display-cec scr_LOBBY --on
screenrig screen display-cec scr_LOBBY --off --expect-rev 4
screenrig screen display-cec scr_LOBBY --clear

Cambia solo display.cec. Un Player lo applica quando screen show elenca display_power.cec_active_source tra le sue capacità dell’host, che un player BrightSign dichiara; --on su un altro Player risponde display_cec_unsupported, mentre --off e --clear funzionano sempre. Il Player non invia nulla finché una programmazione del display o un override tiene spento il display, e un errore CEC non influisce mai sulla riproduzione. screen show elenca l’impostazione come Display CEC. Si applicano le regole di accesso di screen display-idle.

Blocca il Player di uno schermo sullo schermo, oppure rilascialo.

screen kiosk-lock <id> (--on | --off) [--expect-rev REVISION]

screenrig screen kiosk-lock scr_LOBBY --on
screenrig screen kiosk-lock scr_LOBBY --off --expect-rev 4

--on usa il blocco su schermo di Android: la persona presente allo schermo conferma la prima volta, e la barra di stato, home e recenti sono bloccate finché il Player resta bloccato sullo schermo. Il pannello delle impostazioni dell’operatore può uscire dal blocco finché il manifest successivo o un riavvio non lo applica di nuovo. Un Player lo applica quando screen show elenca kiosk_lock tra le sue capacità dell’host; l’impostazione viene memorizzata in ogni caso, e screen show elenca Kiosk lock finché il blocco è attivo. L’accesso Propose non può modificarla (insufficient_access).

Mostra, imposta o cancella quando il backend riavvia il dispositivo di uno schermo.

screen reboot-schedule show <id>
screen reboot-schedule set (<id>... | --tag TAG | --folder ID) (--window SPEC... | --file FILE) [--disabled] [--expect-rev REVISION]
screen reboot-schedule clear (<id>... | --tag TAG | --folder ID) [--expect-rev REVISION]

screenrig screen reboot-schedule set scr_LOBBY --window "Mon-Sun 04:00-04:30"
screenrig screen reboot-schedule set --tag Cafe --window "Mon-Fri 04:00-04:30" --window "Sat,Sun 05:00-06:00"
screenrig screen reboot-schedule set scr_LOBBY --file reboots.json --expect-rev 4
screenrig screen reboot-schedule set --folder sfd_01EXAMPLEFOLDER000000000 --window "Mon-Sun 04:00-04:30"

All'inizio di ogni finestra, nel fuso orario dello schermo, screenRIG emette lo stesso riavvio di screen reboot, quindi "Mon-Sun 04:00-04:30" riavvia lo schermo alle 04:00 locali ogni giorno. commands in screen show lo elenca con source schedule, e screen show e reboot-schedule show stampano next_reboot_at. Una finestra che termina prima o alla stessa ora dell'inizio attraversa la mezzanotte, e una finestra senza orari copre l'intera giornata. L'output salvato di reboot-schedule show può essere modificato e rispedito con set --file:

{"enabled": true, "windows": [{"days": ["mon", "tue", "wed", "thu", "fri", "sat", "sun"], "start": "04:00", "end": "04:30"}]}

Uno schermo online riceve subito il riavvio. Uno schermo offline lo tiene in coda solo fino alla fine della sua finestra, quindi un riavvio non cade mai fuori dalla finestra: uno schermo che torna dopo non ne riceve alcuno. Un inizio dentro un salto in avanti dell'ora legale scatta al primo minuto valido della finestra, e una ripetizione per il ritorno all'ora solare scatta una volta per finestra per data locale. Un riavvio programmato non sostituisce mai uno richiesto da una persona che attende ancora lo schermo; l'occorrenza viene saltata con screen.reboot_skipped (reboot_pending). Lo schermo richiede un Player che dichiara reboot; uno schermo che perde reboot in seguito salta ogni finestra e mantiene la sua programmazione. Cambiare il fuso orario annulla i riavvii programmati ancora in attesa e sposta next_reboot_at nel nuovo fuso. Un riavvio inviato da una programmazione non genera alert di offline, come in screen reboot. screen.reboot_schedule_changed registra ogni impostazione o cancellazione. Un file è {enabled, windows}, entrambi obbligatori. Le pianificazioni di riavvio sono incluse in ogni piano. In una flotta, ogni risultato è quello del singolo schermo: reboot_unsupported per uno schermo il cui Player non può riavviare.

Leggi la disponibilità giornaliera di uno schermo su giorni UTC.

screen uptime <id> [--day-from YYYY-MM-DD] [--day-to YYYY-MM-DD] [--format json|csv|xlsx|pdf] [--output FILE]

screenrig screen uptime scr_01EXAMPLESCREEN00000000
screenrig screen uptime scr_01EXAMPLESCREEN00000000 --day-from 2026-09-01 --day-to 2026-09-30
screenrig screen uptime scr_01EXAMPLESCREEN00000000 --format xlsx --output uptime.xlsx

data.items elenca una riga per ogni giorno UTC con uno stato registrato, dal più vecchio al più recente: online_s, offline_s, availability (online nel tempo registrato; null quando nulla è stato registrato), coverage (la quota del giorno con uno stato registrato), intervals e live per un giorno che include l’intervallo aperto fino ad ora. Il tempo senza stato registrato abbassa coverage e non è mai downtime. I giorni senza registrazioni non hanno riga.

Elenca le transizioni online e offline di uno schermo, dalla più recente

screen presence <id> [--since TIME] [--until TIME]

screenrig screen presence scr_01EXAMPLESCREEN00000000 --since 7d
screenrig screen presence scr_01EXAMPLESCREEN00000000 --since 2026-09-01T00:00:00Z --until 2026-09-08T00:00:00Z

data.items contiene at, state e detected_on_reconnect su un offline che il server ha notato solo quando lo schermo si è riconnesso (at è allora quando è terminato il lease di presenza). La CLI segue next_cursor fino alla fine e risponde a ogni transizione con next_cursor null, quindi restringi un intervallo lungo con --since.

Elenca la salute segnalata da uno schermo nel tempo, ogni rapporto o un riepilogo per ora

screen health-history <id> [--from TIME] [--to TIME] [--resolution raw|hour] [--format json|csv|xlsx|pdf] [--output FILE]

screenrig screen health-history scr_01EXAMPLESCREEN00000000 --from 6h
screenrig screen health-history scr_01EXAMPLESCREEN00000000 --from 30d --resolution hour
screenrig screen health-history scr_01EXAMPLESCREEN00000000 --from 30d --resolution hour --format csv --output health.csv

raw risponde data.samples, ogni report accettato ha la forma di health di screen show senza stale. hour risponde data.hours, un riepilogo per ogni ora UTC: report, temperatura massima e media, carico massimo e rapporto memoria, segnale Wi-Fi più debole, display_disconnected, e conteggi massimi di crash e riavvio renderer. La CLI segue next_cursor fino alla fine, quindi restringi un intervallo raw lungo o usa --resolution hour. I report raw arrivano in pochi secondi e i riepiloghi orari in circa 5 minuti.

Verifica se una playlist ci sta nell’archiviazione che il Player di uno schermo ha riportato per ultima, prima che la playlist venga assegnata.

screen storage-forecast <id> --playlist-id ID [--playlist-rev REVISION]

screenrig screen storage-forecast scr_01EXAMPLESCREEN00000000 --playlist-id pl_01EXAMPLEPLAYLIST000000
screenrig screen storage-forecast scr_01EXAMPLESCREEN00000000 --playlist-id pl_01EXAMPLEPLAYLIST000000 --playlist-rev 7

Non scrive nulla: nessuna assegnazione, nessuna revisione dello schermo, nessun evento. Basta l’accesso in sola lettura, e uno schermo accetta al massimo 30 controlli al minuto. data.fit è fits, partial (alcune pagine sono escluse), none_fit (non si carica nulla) o unknown (lo schermo non ha mai riportato l’archiviazione, oppure il contenuto della playlist non è pronto). data.excluded_page_count conta le pagine escluse, data.required_bytes è ciò che serve all’intera playlist, data.capacity_bytes ciò che il Player ha riportato di poter usare, data.basis è reported_capacity e data.received_at è il momento in cui il Player ha riportato. Con fit unknown i conteggi di byte e received_at sono null. Un report più vecchio di 24 ore è contrassegnato come obsoleto ma viene comunque usato. Quando la playlist non ci sta, la risposta include un avviso storage_full: libera archiviazione sul dispositivo che esegue il Player, poi controlla di nuovo. Cache e archiviazione spiega il piano. Un’assegnazione salvata non conferma la riproduzione.