Santé des appareils : commandes CLI

Redémarrer l’appareil d’un écran, ou les appareils d’une flotte.

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

Le Player redémarre l’appareil, pas seulement lui-même. Un écran en ligne reçoit le redémarrage tout de suite (state sent) ; un écran hors ligne le garde queued et le reçoit quand il revient en ligne avant expires_at, 24 heures après la demande sauf si --expires-in dit autrement. La réponse contient reboot_id, state et expires_at. Un redémarrage plus récent remplace un redémarrage encore en file. screen show liste les commands de l’écran : un redémarrage envoyé devient done dès que l’appareil signale avoir démarré, et screen command cancel en annule un encore en file. Dans une flotte, le reboot de chaque résultat porte le même state. Une requête refusée ou en échec, et une répétition exacte de la même requête, ne comptent pas dans la limite par écran. Du moment où un redémarrage est envoyé jusqu’à ce que l’appareil signale avoir démarré ou que dix minutes s’écoulent, l’écran n’ouvre aucune alerte screen_offline ou display_disconnected ; un avis pour l’une ou l’autre qui arrive à échéance à ce moment attend la fin de cette période plus son délai d’attente, et un avis crashing est ignoré comme planned_reboot. Une condition qui tient toujours ensuite s’ouvre normalement.

Vider les caches du Player d’un écran, ou des Players d’une flotte.

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

Le Player supprime ses médias téléchargés, ses paquets d’application et ses caches de données, conserve son jumelage, son identité et ses paramètres, puis récupère de nouveau le manifeste et le contenu ; l’écran peut afficher son état de chargement pendant que le contenu se remplit. Cela n’atteint qu’un Player qui déclare clear_cache. Un écran en ligne reçoit la requête aussitôt (state sent) ; un écran hors ligne la conserve queued et la reçoit quand il revient en ligne avant expires_at, 24 heures après la requête sauf indication contraire de --expires-in. La réponse porte command_id, command, state et expires_at. Un Player qui ne déclare pas la capacité répond 409 command_unsupported et rien n’est envoyé ; dans une flotte, cet écran échoue seul. screen show liste la commande sous commands et, une fois que le Player rapporte, la marque done ou failed avec un cause et un court detail : cleared quand les caches sont vidés et que la récupération a commencé, ou clear_failed quand un cache ne peut pas être vidé. Une commande envoyée sans rapport reste sent. Une commande plus récente du même type remplace une commande encore en file d’attente, et screen command cancel annule une commande encore en file d’attente. Dans une flotte, le command de chaque résultat porte le même state. Une flotte (plusieurs identifiants, --tag ou --folder) nécessite --yes. Une requête refusée ou échouée, et une relecture exacte de la même requête, ne comptent pas dans la limite de 2 requêtes par écran toutes les 10 minutes pour clear-cache, restart-app et update-software réunis.

Redémarrer l’application du Player d’un écran, ou des Players d’une flotte.

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

Le Player redémarre son application, pas l’appareil (un Player web recharge sa page) et rapporte depuis le processus redémarré. Cela n’atteint qu’un Player qui déclare restart_app ; screen reboot redémarre l’appareil. Un écran en ligne reçoit la requête aussitôt (state sent) ; un écran hors ligne la conserve queued et la reçoit quand il revient en ligne avant expires_at, 24 heures après la requête sauf indication contraire de --expires-in. La réponse porte command_id, command, state et expires_at. Un Player qui ne déclare pas la capacité répond 409 command_unsupported et rien n’est envoyé ; dans une flotte, cet écran échoue seul. screen show liste la commande sous commands et, une fois que le Player rapporte, la marque done ou failed avec un cause et un court detail : restarted, ou restart_failed quand le redémarrage ne peut pas démarrer. Une commande envoyée sans rapport reste sent. Une commande plus récente du même type remplace une commande encore en file d’attente, et screen command cancel annule une commande encore en file d’attente. Dans une flotte, le command de chaque résultat porte le même state. Une flotte (plusieurs identifiants, --tag ou --folder) nécessite --yes. Une requête refusée ou échouée, et une relecture exacte de la même requête, ne comptent pas dans la limite de 2 requêtes par écran toutes les 10 minutes pour clear-cache, restart-app et update-software réunis.

Mettre à jour le Player d’un écran vers la plus récente version, ou les Players d’une flotte.

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

Le Player vérifie maintenant la plus récente version du Player et l’installe là où sa plateforme lui permet de se mettre à jour lui-même ; un Player web met à jour son service worker, puis se recharge. Cela n’atteint qu’un Player qui déclare update : un Player installé depuis un magasin ou géré par un gestionnaire d’appareils se met à jour par ce canal. Un écran en ligne reçoit la requête aussitôt (state sent) ; un écran hors ligne la conserve queued et la reçoit quand il revient en ligne avant expires_at, 24 heures après la requête sauf indication contraire de --expires-in. La réponse porte command_id, command, state et expires_at. Un Player qui ne déclare pas la capacité répond 409 command_unsupported et rien n’est envoyé ; dans une flotte, cet écran échoue seul. screen show liste la commande sous commands et, une fois que le Player rapporte, la marque done ou failed avec un cause et un court detail : up_to_date quand la plus récente version s’exécute déjà, updated une fois la nouvelle version démarrée, ou, en cas d’échec, update_check_failed, download_failed, install_failed ou no_update_channel. Une commande envoyée sans rapport reste sent. Une commande plus récente du même type remplace une commande encore en file d’attente, et screen command cancel annule une commande encore en file d’attente. Dans une flotte, le command de chaque résultat porte le même state. Une flotte (plusieurs identifiants, --tag ou --folder) nécessite --yes. Une requête refusée ou échouée, et une relecture exacte de la même requête, ne comptent pas dans la limite de 2 requêtes par écran toutes les 10 minutes pour clear-cache, restart-app et update-software réunis.

Annuler une commande encore en file d’attente pour un écran hors ligne.

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

screenrig screen command cancel scr_01EXAMPLESCREEN00000000 rbt_01EXAMPLEREBOOT00000000

Elle annule un reboot, reload, clear_cache, restart_app ou update qui attend un écran hors ligne, afin qu’il ne soit jamais envoyé. Seule une commande en file d’attente peut être annulée. Une commande déjà envoyée (sent ou done) répond 409 resource_conflict avec "The command was already sent.", une commande qui n’est plus en file d’attente (expired, cancelled ou superseded) répond 409 resource_conflict avec "The command is no longer queued.", et un ID que l’écran ne répertorie pas répond 404 not_found. La réponse est l’écran avec la commande cancelled, et la révision de l’écran ne change pas.

Allumez ou éteignez l’afficheur d’un écran, ou ceux d’une flotte, maintenant, ou effacez cette substitution.

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 est la forme abrégée de screen display set ID ; clear n’accepte ni --power, ni --until, ni --for. screen display est une substitution manuelle de l’horaire d’affichage. Sans --until ni --for, elle se termine à la prochaine limite de l’horaire ; un changement ultérieur d’horaire d’affichage ou de fuseau horaire déplace cette fin à la nouvelle limite. Sans limite dans les huit prochains jours, par exemple sans horaire activé, elle tient jusqu’à screen display clear ou un remplacement. screen display clear termine la substitution, donc l’horaire d’affichage s’applique à nouveau ; sans cela, l’affichage est activé.

L’enregistrement d’une substitution n’attend pas le Player. display.override_status compare un rapport d’affichage plus récent avec elle : matches, mismatch, pending, stale ou unknown ; matches décrit le rapport, pas l’exécution de la commande. L’avertissement display_power_mismatch nomme un rapport récent qui diffère et display_power_unconfirmed indique qu’un rapport plus récent exploitable est nécessaire ; vérifiez donc screen show avant de prendre une capture d’écran. display_scrim_only signifie que le Player ne contrôle qu’une superposition noire : on la retire et n’envoie aucune commande de réveil matériel. Un écran d’un dossier protégé refuse une modification de l’affichage (protected_target).

Afficher, définir ou effacer quand l’afficheur d’un écran est allumé.

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 horaire d’affichage est {enabled, windows}, les deux obligatoires, et windows liste de 1 à 16 fenêtres où l’affichage est allumé, dans le fuseau horaire de l’écran ; en dehors de toute fenêtre, l’affichage passe en veille. Le Lecteur l’évalue sur l’appareil, donc cela continue de fonctionner hors ligne. Une fenêtre dont end est à ou avant son start traverse minuit, et une fenêtre sans start ni end couvre toute la journée. enabled: false conserve les fenêtres et laisse l’afficheur allumé. display-schedule show répond avec display_schedule (null s’il n’y en a pas) et l’état display de l’écran. Sa sortie enregistrée peut être modifiée puis renvoyée avec set --file. Un écran d’un dossier protégé refuse une modification de son horaire d’affichage (protected_target).

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

screen show --human affiche Display: avec la puissance demandée, sa source (surcharge manuelle, horaire d’affichage ou défaut) et jusqu’à quand dans le fuseau horaire de l’écran, les fenêtres d’horaire, et la puissance rapportée par le Player, marquée périmée après 35 minutes sans rapport.

Réglez le volume d’un écran, ou mettez-le en sourdine, sur un écran ou sur une flotte.

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

Un écran a un seul volume : un niveau de 0 à 100 et une sourdine. La mise en sourdine conserve le niveau, donc la réactivation du son le rétablit. Un écran en ligne applique le changement aussitôt ; un écran hors ligne applique la dernière demande à son retour, et une demande plus récente remplace la précédente. Un changement fait plus tard dans le menu des paramètres propre au Player l’emporte jusqu’à la prochaine screen volume, et changer le niveau à cet endroit annule la sourdine. screen show rapporte volume avec le dernier changement requested et, sous reported, le level et le muted atteints par le Player et hardware : true quand le niveau atteint la sortie de l’appareil ou du panneau, false quand il s’agit du gain propre au Player ; stale passe à true après 35 minutes sans rapport. Seul un Player qui déclare la capacité volume l’applique : tout autre écran répond 409 volume_unsupported (code de sortie 5) et rien n’est enregistré. Un écran archivé répond screen_archived et un écran encore en attente de jumelage répond resource_conflict. Un écran dans un dossier protégé refuse la modification (protected_target), et dans une flotte un seul écran protégé fait refuser toute la requête. La page d’écran du tableau de bord offre le même contrôle de volume.

Assombrir un écran après un temps sans utilisation, ou désactiver cette option.

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

L’écran s’assombrit après --after secondes sans toucher ni touche ou, lorsque --wake liste presence, sans personne devant l’écran. Tant qu’il est sombre, le Player met la lecture en pause, sans diffusion ni publicité, et signale l’alimentation de l’afficheur éteinte ; un événement de réveil rallume l’écran aussitôt et la lecture reprend, et le toucher qui réveille un écran sombre n’est pas transmis à la page. Un horaire d’affichage ou une substitution qui garde le panneau éteint l’emporte, tout comme une application qui détient device.display tant que sa page est à l’écran. Seul display.idle change. Un Player l’applique lorsque screen show liste display_power.idle dans ses capacités d’hôte ; le paramètre est enregistré dans les deux cas, et screen show le liste comme Display idle. L’accès Propose ne peut pas le modifier (insufficient_access), et un écran dans un dossier protégé le refuse (protected_target).

Définir si la luminosité d’un écran suit le capteur de lumière de l’appareil.

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

Seul display.brightness change. Un Player applique auto lorsque screen show liste brightness.auto dans ses capacités d’hôte, qu’un appareil déclare seulement avec un capteur de lumière ; une application qui règle la luminosité de l’afficheur l’emporte tant que sa page est affichée. Le paramètre est enregistré dans les deux cas, et screen show le liste comme Display brightness. Les règles d’accès de screen display-idle s’appliquent.

Définir le mode vidéo que le Player d’un écran applique à sa sortie, ou l’effacer.

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 liste les modes que le Player peut régler maintenant, sous Output modes the Player can set, et le mode en vigueur. Une fois que le Player les a signalés, un mode hors de cette liste est invalid_request ; choisissez-en un qu’il liste. Seul display.output change. Un Player l’applique lorsque screen show liste display_output.mode dans ses capacités d’hôte, qu’un lecteur BrightSign déclare ; tout autre mode que auto sur un autre Player répond display_output_unsupported, et l’effacement fonctionne toujours. Le Player applique un mode une seule fois, peut redémarrer pour le faire, et signale le mode atteint. Les règles d’accès de screen display-idle s’appliquent.

Faire prendre au Player d’un écran l’entrée HDMI du téléviseur par CEC, ou cesser de le faire.

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

Seul display.cec change. Un Player l’applique lorsque screen show liste display_power.cec_active_source dans ses capacités d’hôte, qu’un lecteur BrightSign déclare ; --on sur un autre Player répond display_cec_unsupported, alors que --off et --clear fonctionnent toujours. Le Player n’envoie rien tant qu’un horaire d’affichage ou une substitution maintient l’afficheur éteint, et un échec CEC n’affecte jamais la lecture. screen show liste le paramètre comme Display CEC. Les règles d’accès de screen display-idle s’appliquent.

Épingler le Player d’un écran à l’écran, ou le libérer.

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 utilise l’épinglage d’écran Android : la personne devant l’écran confirme la première fois, et la barre d’état, l’accueil et les applications récentes sont bloqués tant que le Player est épinglé. Le panneau de paramètres de l’opérateur peut quitter le verrouillage jusqu’à ce que le prochain manifeste ou redémarrage l’applique de nouveau. Un Player l’applique lorsque screen show liste kiosk_lock dans ses capacités d’hôte ; le paramètre est enregistré dans les deux cas, et screen show liste Kiosk lock tant qu’il est activé. L’accès Propose ne peut pas la modifier (insufficient_access).

Afficher, définir ou effacer le moment où le backend redémarre l’appareil d’un écran.

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"

Au début de chaque fenêtre, dans le fuseau horaire de l’écran, screenRIG émet le même redémarrage que screen reboot, de sorte que "Mon-Sun 04:00-04:30" redémarre l’écran à 04:00 heure locale chaque jour. commands dans screen show le liste avec source schedule, et screen show et reboot-schedule show affichent next_reboot_at. Une fenêtre dont la fin est égale ou antérieure au début passe minuit, et une fenêtre sans heures couvre toute la journée. La sortie enregistrée de reboot-schedule show peut être modifiée et renvoyée avec set --file :

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

Un écran en ligne reçoit le redémarrage tout de suite. Un écran hors ligne ne le garde en file que jusqu’à la fin de sa fenêtre, de sorte qu’un redémarrage ne tombe jamais en dehors de la fenêtre : un écran qui revient après celle-ci n’en reçoit aucun. Un début situé dans le saut de l’heure d’été part à la première minute valide de la fenêtre, et une répétition du retour à l’heure normale part une fois par fenêtre et par date locale. Un redémarrage planifié ne remplace jamais un redémarrage demandé par une personne qui attend encore l’écran ; l’occurrence est ignorée avec screen.reboot_skipped (reboot_pending). L’écran a besoin d’un Player qui déclare reboot ; un écran qui perd reboot par la suite ignore chaque fenêtre et conserve son horaire. Changer le fuseau horaire annule les redémarrages planifiés encore en attente et déplace next_reboot_at vers le nouveau fuseau. Un redémarrage envoyé par un horaire ne déclenche aucune alerte hors ligne, comme sous screen reboot. screen.reboot_schedule_changed consigne chaque définition ou effacement. Un fichier est {enabled, windows}, les deux obligatoires. Les horaires de redémarrage sont offerts avec tous les forfaits. Dans une flotte, chaque résultat est propre à l’écran : reboot_unsupported pour un écran dont le Player ne peut pas redémarrer.

Lire la disponibilité quotidienne d’un écran sur des jours 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 liste une ligne par jour UTC avec un état enregistré, du plus ancien au plus récent : online_s, offline_s, availability (en ligne pendant la période enregistrée ; null quand rien n’a été enregistré), coverage (la part de la journée avec un état enregistré), intervals, et live pour un jour incluant l’intervalle ouvert jusqu’à maintenant. Le temps sans état enregistré réduit coverage et n’est jamais un temps d’arrêt. Les jours sans enregistrement n’ont pas de ligne.

Lister les transitions en ligne et hors ligne d’un écran, les plus récentes d’abord.

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 porte at, state et detected_on_reconnect sur un hors ligne que le serveur a remarqué seulement quand l’écran s’est reconnecté (at est alors la fin de son bail de présence). La CLI suit next_cursor jusqu’à la fin et répond à chaque transition avec next_cursor null, donc restreignez une longue plage avec --since.

Lister la santé rapportée par un écran au fil du temps, chaque rapport ou un résumé par heure.

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 répond data.samples, chaque rapport accepté ayant la forme de health de screen show sans stale. hour répond data.hours, un résumé par heure UTC : rapports, température maximale et moyenne, charge maximale et ratio mémoire, signal Wi-Fi le plus faible, display_disconnected, et nombre maximal de plantages et de redémarrages du moteur de rendu. La CLI suit next_cursor jusqu’à la fin, donc restreignez une longue plage brute ou utilisez --resolution hour. Les rapports bruts arrivent en quelques secondes et les résumés horaires en environ 5 minutes.

Vérifie si une liste de lecture tient dans le stockage que le Player d’un écran a rapporté en dernier, avant que la liste ne soit affectée.

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

Elle n’écrit rien : ni affectation, ni révision d’écran, ni événement. L’accès en lecture seule suffit, et un écran accepte au plus 30 vérifications par minute. data.fit est fits, partial (certaines pages sont écartées), none_fit (rien ne se charge) ou unknown (l’écran n’a jamais rapporté son stockage, ou le contenu de la liste de lecture n’est pas prêt). data.excluded_page_count compte les pages écartées, data.required_bytes est ce dont toute la liste de lecture a besoin, data.capacity_bytes ce que le Player a rapporté pouvoir utiliser, data.basis est reported_capacity et data.received_at est le moment où le Player a rapporté. Avec fit unknown, les nombres d’octets et received_at valent null. Un rapport de plus de 24 heures est marqué périmé, mais reste utilisé. Quand la liste de lecture ne tient pas, la réponse porte un avertissement storage_full : libérez du stockage sur l’appareil qui exécute le Player, puis vérifiez de nouveau. Cache et stockage explique le plan. Une affectation enregistrée ne confirme pas la lecture.