Saúde dos dispositivos: comandos da CLI

Reiniciar o dispositivo de uma tela ou os dispositivos de uma frota.

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

O Player reinicia o dispositivo, não apenas a si mesmo. Uma tela online recebe o reinício na hora (state sent); uma tela offline o mantém queued e o recebe quando fica online antes de expires_at, 24 horas depois do pedido a menos que --expires-in diga o contrário. A resposta traz reboot_id, state e expires_at. Um reinício mais novo substitui um ainda na fila. screen show lista os commands da tela: um reinício enviado passa a done quando o dispositivo informa que iniciou, e screen command cancel cancela um ainda na fila. Em uma frota, o reboot de cada resultado traz o mesmo state. Uma requisição recusada ou que falhou, e uma repetição exata da mesma requisição, não contam para o limite por tela. Desde o momento em que um reinício é enviado até que o dispositivo informe que iniciou ou passem dez minutos, a tela não abre alerta screen_offline nem display_disconnected; um aviso de qualquer um dos dois que vence nesse intervalo espera até o fim do período mais seu tempo de espera, e um aviso crashing é ignorado como planned_reboot. Uma condição que ainda se mantém depois abre normalmente.

Limpar os caches do Player de uma tela ou dos Players de uma frota.

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

O Player exclui suas mídias baixadas, pacotes de aplicativo e caches de dados, mantém seu pareamento, identidade e configurações, e depois busca o manifesto e o conteúdo novamente; a tela pode exibir seu estado de carregamento enquanto o conteúdo é reabastecido. Alcança apenas um Player que declara clear_cache. Uma tela online recebe o pedido de imediato (state sent); uma tela offline o mantém queued e o recebe quando fica online antes de expires_at, 24 horas após o pedido, a menos que --expires-in diga o contrário. A resposta traz command_id, command, state e expires_at. Um Player que não declara a capacidade responde 409 command_unsupported e nada é enviado; em uma frota, essa tela falha sozinha. screen show lista o comando em commands e, quando o Player reporta, marca-o como done ou failed com um cause e um detail curto: cleared quando os caches são limpos e a nova busca começou, ou clear_failed quando um cache não pode ser limpo. Um comando enviado sem relatório permanece sent. Um comando mais novo do mesmo tipo substitui um ainda na fila, e screen command cancel cancela um ainda na fila. Em uma frota, o command de cada resultado traz o mesmo state. Uma frota (vários ids, --tag ou --folder) precisa de --yes. Um pedido recusado ou que falhou, e uma repetição exata do mesmo pedido, não contam para o limite por tela de 2 pedidos de clear-cache, restart-app e update-software somados a cada 10 minutos.

Reiniciar o aplicativo do Player de uma tela ou dos Players de uma frota.

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

O Player reinicia seu aplicativo, não o dispositivo (um Player web recarrega sua página) e reporta a partir do processo reiniciado. Alcança apenas um Player que declara restart_app; screen reboot reinicia o dispositivo. Uma tela online recebe o pedido de imediato (state sent); uma tela offline o mantém queued e o recebe quando fica online antes de expires_at, 24 horas após o pedido, a menos que --expires-in diga o contrário. A resposta traz command_id, command, state e expires_at. Um Player que não declara a capacidade responde 409 command_unsupported e nada é enviado; em uma frota, essa tela falha sozinha. screen show lista o comando em commands e, quando o Player reporta, marca-o como done ou failed com um cause e um detail curto: restarted, ou restart_failed quando a reinicialização não pode começar. Um comando enviado sem relatório permanece sent. Um comando mais novo do mesmo tipo substitui um ainda na fila, e screen command cancel cancela um ainda na fila. Em uma frota, o command de cada resultado traz o mesmo state. Uma frota (vários ids, --tag ou --folder) precisa de --yes. Um pedido recusado ou que falhou, e uma repetição exata do mesmo pedido, não contam para o limite por tela de 2 pedidos de clear-cache, restart-app e update-software somados a cada 10 minutos.

Atualizar o Player de uma tela para a versão mais recente, ou os Players de uma frota.

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

O Player verifica agora a versão mais recente do Player e a instala onde sua plataforma permite que o Player se atualize sozinho; um Player web atualiza seu service worker e depois recarrega. Alcança apenas um Player que declara update: um Player instalado de uma loja ou gerenciado por um gerenciador de dispositivos se atualiza por esse canal. Uma tela online recebe o pedido de imediato (state sent); uma tela offline o mantém queued e o recebe quando fica online antes de expires_at, 24 horas após o pedido, a menos que --expires-in diga o contrário. A resposta traz command_id, command, state e expires_at. Um Player que não declara a capacidade responde 409 command_unsupported e nada é enviado; em uma frota, essa tela falha sozinha. screen show lista o comando em commands e, quando o Player reporta, marca-o como done ou failed com um cause e um detail curto: up_to_date quando a versão mais recente já está em execução, updated quando a nova versão iniciou ou, em caso de falha, update_check_failed, download_failed, install_failed ou no_update_channel. Um comando enviado sem relatório permanece sent. Um comando mais novo do mesmo tipo substitui um ainda na fila, e screen command cancel cancela um ainda na fila. Em uma frota, o command de cada resultado traz o mesmo state. Uma frota (vários ids, --tag ou --folder) precisa de --yes. Um pedido recusado ou que falhou, e uma repetição exata do mesmo pedido, não contam para o limite por tela de 2 pedidos de clear-cache, restart-app e update-software somados a cada 10 minutos.

Cancelar um comando que ainda está na fila para uma tela offline.

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

screenrig screen command cancel scr_01EXAMPLESCREEN00000000 rbt_01EXAMPLEREBOOT00000000

Cancela um reboot, reload, clear_cache, restart_app ou update que aguarda uma tela offline, de modo que ele nunca é enviado. Somente um comando na fila pode ser cancelado. Um que já foi enviado (sent ou done) responde 409 resource_conflict com "The command was already sent.", um que não está mais na fila (expired, cancelled ou superseded) responde 409 resource_conflict com "The command is no longer queued.", e um id que a tela não lista responde 404 not_found. A resposta é a tela com o comando cancelled, e a revisão da tela não muda.

Ligue ou desligue a exibição de uma tela, ou das telas de uma frota, agora, ou limpe essa substituição.

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 é a forma abreviada de screen display set ID; clear não aceita --power, --until nem --for. screen display é uma substituição manual da programação do monitor. Sem --until ou --for termina no próximo limite da programação; uma mudança posterior na programação do monitor ou fuso horário move esse fim para o novo limite. Sem limite nos próximos oito dias, por exemplo sem programação ativada, mantém até screen display clear ou substituição. screen display clear termina a substituição, para que a programação do monitor se aplique novamente; sem uma, o monitor fica ligado.

Salvar uma substituição não espera o Player. display.override_status compara um relatório de exibição mais novo com ela: matches, mismatch, pending, stale ou unknown; matches descreve o relatório, não que o comando foi executado. O aviso display_power_mismatch nomeia um relatório recente que difere e display_power_unconfirmed diz que é preciso um relatório mais novo e utilizável; por isso, confira screen show antes de tirar uma captura de tela. display_scrim_only significa que o Player controla apenas uma sobreposição preta: on a remove e não envia nenhum comando de ativação de hardware. Uma tela em uma pasta protegida recusa uma alteração de exibição (protected_target).

Exiba, defina ou limpe quando o display de uma tela está ligado.

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

Uma programação de exibição é {enabled, windows}, ambos obrigatórios, e windows lista de 1 a 16 janelas em que o monitor fica ligado, no fuso horário da tela; fora de qualquer janela, o monitor entra em espera. O Player avalia isso no dispositivo, então continua funcionando offline. Uma janela cujo end é igual ou anterior ao seu start cruza a meia-noite, e uma janela sem start e end cobre o dia inteiro. enabled: false mantém as janelas e deixa o monitor ligado. display-schedule show responde com display_schedule (null quando não há nenhuma) e o estado display da tela. A saída salva pode ser editada e enviada de volta com set --file. Uma tela em uma pasta protegida recusa uma alteração em sua programação de exibição (protected_target).

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

screen show --human imprime Display: com a potência solicitada, sua fonte (sobrescrição manual, programação do display ou padrão) e até quando no fuso horário da tela, as janelas da programação, e a potência reportada pelo Player, marcada como obsoleta após 35 minutos sem relatório.

Defina o volume de uma tela, ou silencie-a, em uma tela ou em uma frota.

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

Uma tela tem um volume: um nível de 0 a 100 e um silenciamento. Silenciar mantém o nível, então reativar o som o restaura. Uma tela que está online aplica a mudança imediatamente; uma tela offline aplica a solicitação mais recente quando volta, e uma solicitação mais nova substitui a anterior. Uma mudança feita depois no próprio menu de configurações do Player prevalece até a próxima screen volume, e mudar o nível ali remove o silenciamento. screen show relata volume com a mudança requested mais recente e, como reported, o level e o muted que o Player alcançou e hardware: true quando o nível chega à saída do dispositivo ou do painel, false quando é o ganho do próprio Player; stale passa a true após 35 minutos sem relatório. Somente um Player que declara a capacidade volume a aplica: qualquer outra tela responde 409 volume_unsupported (código de saída 5) e nada é registrado. Uma tela arquivada responde screen_archived e uma tela que ainda aguarda o pareamento responde resource_conflict. Uma tela em uma pasta protegida recusa a alteração (protected_target), e em uma frota uma única tela protegida faz recusar a solicitação inteira. A página da tela no painel tem o mesmo controle de Volume.

Escurecer a tela de um display após um tempo sem uso, ou desativar isso.

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

A tela escurece após --after segundos sem um toque ou tecla ou, quando --wake lista presence, sem ninguém na frente da tela. Enquanto está escura, o Player suspende a reprodução, sem exibições e sem anúncios, e informa o display desligado; um evento de despertar acende a tela de imediato e a reprodução continua, e o toque que acorda uma tela escura não é repassado à página. Uma programação de exibição ou substituição que mantém o painel desligado prevalece, assim como um aplicativo que mantém device.display enquanto sua página está na tela. Somente display.idle muda. Um Player a aplica quando screen show lista display_power.idle em suas capacidades do host; a configuração é armazenada de qualquer forma, e screen show a lista como Display idle. O acesso Propose não pode alterá-la (insufficient_access), e uma tela em uma pasta protegida a recusa (protected_target).

Definir se o brilho de uma tela segue o sensor de luz do 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

Somente display.brightness muda. Um Player aplica auto quando screen show lista brightness.auto em suas capacidades do host, que um dispositivo declara apenas com um sensor de luz; um aplicativo que define o brilho do display prevalece enquanto sua página é exibida. A configuração é armazenada de qualquer forma, e screen show a lista como Display brightness. As regras de acesso de screen display-idle se aplicam.

Definir o modo de vídeo que o Player de uma tela coloca em sua saída, ou limpá-lo.

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 lista os modos que o Player pode definir agora, em Output modes the Player can set, e o modo em vigor. Depois que o Player os informa, um modo fora dessa lista é invalid_request, então escolha um que ele liste. Somente display.output muda. Um Player o aplica quando screen show lista display_output.mode em suas capacidades do host, que um player BrightSign declara; qualquer modo diferente de auto em outro Player responde display_output_unsupported, e limpar sempre funciona. O Player aplica um modo uma vez, pode reiniciar para isso e informa o modo alcançado. As regras de acesso de screen display-idle se aplicam.

Fazer o Player de uma tela assumir a entrada HDMI da TV por CEC, ou parar.

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

Somente display.cec muda. Um Player o aplica quando screen show lista display_power.cec_active_source em suas capacidades do host, que um player BrightSign declara; --on em outro Player responde display_cec_unsupported, enquanto --off e --clear sempre funcionam. O Player não envia nada enquanto uma programação do display ou uma sobrescrição mantém o display desligado, e uma falha de CEC nunca afeta a reprodução. screen show lista a configuração como Display CEC. As regras de acesso de screen display-idle se aplicam.

Fixar o Player de uma tela na tela, ou liberá-lo.

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 a fixação de tela do Android (screen pinning): a pessoa na tela confirma na primeira vez, e a barra de status, o início e os recentes ficam bloqueados enquanto o Player está fixado. O painel de configurações do operador pode sair do bloqueio até que o próximo manifesto ou reinício o aplique de novo. Um Player o aplica quando screen show lista kiosk_lock em suas capacidades do host; a configuração é armazenada de qualquer forma, e screen show lista Kiosk lock enquanto ele está ativo. O acesso Propose não pode alterá-la (insufficient_access).

Mostra, define ou limpa quando o backend reinicia o dispositivo de uma tela.

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"

No início de cada janela, no fuso horário da tela, o screenRIG emite o mesmo reinício que screen reboot, então "Mon-Sun 04:00-04:30" reinicia a tela às 04:00 locais todos os dias. commands em screen show o lista com source schedule, e screen show e reboot-schedule show imprimem next_reboot_at. Uma janela cujo fim é igual ou anterior ao início cruza a meia-noite, e uma janela sem horários cobre o dia inteiro. A saída salva de reboot-schedule show pode ser editada e enviada de volta com set --file:

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

Uma tela online recebe o reinício na hora. Uma tela offline o mantém na fila apenas até o fim da sua janela, de modo que um reinício nunca cai fora da janela: uma tela que volta depois dela não recebe nenhum. Um início dentro de uma lacuna de adiantamento do relógio dispara no primeiro minuto válido da janela, e uma repetição de recuo do relógio dispara uma vez por janela por data local. Um reinício programado nunca substitui um pedido por uma pessoa que ainda espera pela tela; a ocorrência é ignorada com screen.reboot_skipped (reboot_pending). A tela precisa de um Player que declare reboot; uma tela que perde reboot depois ignora cada janela e mantém sua programação. Alterar o fuso horário cancela os reinícios programados que ainda aguardam e move next_reboot_at para o novo fuso. Um reinício enviado por uma programação não gera alerta de offline, como em screen reboot. screen.reboot_schedule_changed registra cada definição ou remoção. Um arquivo é {enabled, windows}, ambos obrigatórios. Programações de reinício estão em todos os planos. Em uma frota, cada resultado é da própria tela: reboot_unsupported para uma tela cujo Player não consegue reiniciar.

Leia a disponibilidade diária de uma tela em dias 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 lista uma linha por dia UTC com estado registrado, do mais antigo ao mais recente: online_s, offline_s, availability (online durante o tempo registrado; null quando nada foi registrado), coverage (a fração do dia com estado registrado), intervals, e live para um dia que inclui o intervalo aberto até agora. Tempo sem estado registrado reduz coverage e nunca é considerado tempo de inatividade. Dias sem registros não têm linha.

Listar transições online e offline de uma tela, da mais recente para a mais antiga.

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 carrega at, state e detected_on_reconnect em um offline que o servidor notou somente quando a tela reconectou (at é então quando o contrato de presença terminou). O CLI segue next_cursor até o fim e responde a cada transição com next_cursor null, então estreite um intervalo longo com --since.

Listar a saúde reportada por uma tela ao longo do tempo, cada relatório ou um resumo por hora.

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 responde data.samples, cada relatório aceito moldado como o health de screen show sem stale. hour responde data.hours, um resumo por hora UTC: relatórios, temperatura máxima e média, pico de carga e proporção de memória, sinal Wi-Fi mais fraco, display_disconnected, e contagens máximas de falhas e reinícios do renderizador. O CLI segue next_cursor até o fim, então estreite um intervalo bruto longo ou use --resolution hour. Relatórios brutos chegam em segundos e resumos horários em cerca de 5 minutos.

Verifica se uma playlist cabe no armazenamento que o Player de uma tela reportou por último, antes de a playlist ser atribuída.

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

Não grava nada: nem atribuição, nem revisão de tela, nem evento. O acesso somente leitura basta, e uma tela aceita no máximo 30 verificações por minuto. data.fit é fits, partial (algumas páginas ficam de fora), none_fit (nada carrega) ou unknown (a tela nunca reportou armazenamento, ou o conteúdo da playlist não está pronto). data.excluded_page_count conta as páginas deixadas de fora, data.required_bytes é o que a playlist inteira precisa, data.capacity_bytes o que o Player reportou que pode usar, data.basis é reported_capacity e data.received_at é quando o Player reportou. Com fit unknown, as contagens de bytes e received_at são null. Um relatório com mais de 24 horas é marcado como desatualizado, mas ainda é usado. Quando a playlist não cabe, a resposta traz um aviso storage_full: libere armazenamento no dispositivo que executa o Player e verifique de novo. Cache e armazenamento explica o plano. Uma atribuição salva não confirma a reprodução.