Cumuls par dossier et par étiquette
fleet_health, uptime, publishing et alerts regroupent le parc par dossier, écran ou étiquette sur des jours UTC inclusifs. Une ligne de dossier compte chaque écran qu'il contient et que contiennent ses sous-dossiers, et la première ligne est le projet entier. Les étiquettes sont le second regroupement : un écran compte dans chaque étiquette qu'il porte.
| Rapport | Ce que dit une ligne |
|---|---|
fleet_health | Écrans, en ligne maintenant, disponibilité, alertes ouvertes, alertes déclenchées pendant la période, chaud, afficheur déconnecté, en plantage et nombre d'écrans qui diffusent leur contenu à jour |
uptime | Heures en ligne et hors ligne, disponibilité et couverture enregistrée |
publishing | Écrans avec contenu à jour, contenu en cours de mise à jour, contenu nécessitant de l'attention et sans contenu |
alerts | Alertes ouvertes maintenant et déclenchées pendant la période, par condition |
alert_log | Une ligne par alerte déclenchée pendant la période : l'écran, la condition, le début et la fin, et la personne qui l'a prise en charge |
proof_of_play | Diffusions des campagnes directes d'un commanditaire ou annonceur par campagne, média et écran, avec les totaux |
GET /api/reports/{kind} génère un rapport. from et to sont des jours UTC (par défaut : les 30 derniers jours); group_by vaut folder (par défaut), screen ou tag; folder_id limite le rapport à un dossier et à tout ce qu'il contient, et avec direct=true au dossier et à ses sous-dossiers directs ou, regroupé par écran, aux écrans qui s'y trouvent directement; tag ne garde que les écrans portant cette étiquette. Une ligne de dossier porte id, parent_id et depth, afin qu'un client dessine l'arborescence à partir des lignes. La disponibilité est le temps en ligne sur le temps enregistré, et la couverture enregistrée indique la part de la période où les écrans ont signalé un état.
La page Santé du tableau de bord présente ces cumuls selon les dossiers d'écrans : chaque dossier s'ouvre sur ses sous-dossiers et ses écrans, et chaque écran sur son onglet Santé.
CSV, XLSX et PDF
Chaque route de rapport accepte format=csv, xlsx ou pdf et répond avec une pièce jointe contenant les mêmes lignes : les nouveaux rapports, GET /api/uptime/daily, GET /api/screens/{id}/uptime, GET /api/screens/{id}/health/history, GET /api/health/trend, GET /api/alerts, GET /api/playback, GET /api/playback/plays, GET /api/playback/totals, GET /api/playback/completeness, les rapports de diffusion, de remplissage et de dépenses publicitaires et le rapport d'une campagne directe. Un rapport paginé est écrit en entier, jusqu'à 50 000 lignes; truncated indique quand il ne contient que les premières lignes.
Le fichier XLSX est une feuille unique avec le titre et la période au-dessus d'un en-tête figé, les nombres comme nombres et les totaux en gras. Le PDF est un relevé sobre avec le nom screenRIG, le projet visé, le titre et la période, un tableau dont l'en-tête se répète à chaque page, les totaux et les numéros de page, prêt à envoyer. Le CSV commence par les libellés de colonnes et neutralise une cellule de texte qu'un tableur exécuterait comme une formule.
screenrig reports show fleet_health --group-by folder --format pdf --output fleet-health.pdf
screenrig reports show proof_of_play --advertiser "Acme Corp" --from 2026-10-01 --to 2026-10-31 --format pdf --output acme.pdf
screenrig project uptime --format xlsx --output uptime.xlsx
screenrig alerts list --state all --format csv --output alerts.csvPreuve de diffusion pour un commanditaire ou un annonceur
proof_of_play totalise les diffusions des campagnes directes du projet. Une diffusion compte quand l'écran signale que le média s'est terminé à l'écran. Nommez une campagne avec campaign_id, ou toutes les campagnes d'un commanditaire ou annonceur avec advertiser (son nom exact, sans égard à la casse). Chaque ligne est une campagne, un fichier média et un écran avec ses diffusions, ses heures diffusées, ses premier et dernier jours et, quand l'écran porte une estimation d'audience, les impressions estimées. Le PDF est le relevé à envoyer.
Envois par courriel planifiés
Un abonnement à un rapport désigne un type de rapport et ses filtres, une cadence, un format de fichier et les membres du projet qui le reçoivent. POST /api/report-subscriptions en crée un; une organisation en compte au plus 50, tous projets confondus (report_subscription_limit_reached).
| Membre | Sens |
|---|---|
kind | fleet_health, uptime, publishing, alerts, alert_log ou proof_of_play |
filters | Les filtres du rapport autres que les jours : group_by, folder_id, direct, tag, campaign_id, advertiser |
schedule | cadence daily, weekly (weekday) ou monthly (day_of_month, 1 à 28), hour de 0 à 23 et un timezone IANA |
format | pdf, xlsx ou csv, joint au courriel |
recipients | Membres du projet, désignés par user_id ou par l'adresse courriel du membre |
Chaque envoi couvre la période qui le précède, en jours UTC : la veille pour un envoi quotidien, les sept jours précédents pour un envoi hebdomadaire et le mois entier précédent pour un envoi mensuel, selon le calendrier du fuseau horaire de l'horaire. Les destinataires sont des membres du projet, vérifiés de nouveau à chaque envoi : toute autre personne est refusée à l'écriture de l'abonnement, et un membre qui part, ou dont l'adresse n'est pas vérifiée, cesse de le recevoir. La pièce jointe fait au plus 8 MiB.
Un envoi qui échoue est repris après 15 minutes, 1 heure et 4 heures, puis attend la prochaine occurrence. L'abonnement indique last_status (delivered ou failed), last_error, les jours couverts par le dernier envoi et next_run_at. POST /api/report-subscriptions/{id}/send l'envoie maintenant pour la période qu'un envoi couvrirait maintenant, sans déplacer son horaire, et répond avec l'abonnement et le résultat de cet envoi.
screenrig reports subscriptions create --name "Monday fleet health" --kind fleet_health \
--cadence weekly --weekday monday --hour 7 --timezone America/Los_Angeles \
--format pdf --recipients ann@example.com,usr_ID
screenrig reports subscriptions list
screenrig reports subscriptions send rsub_IDLa page Rapports du tableau de bord propose les mêmes horaires sous Envois planifiés par courriel.
Exporter un projet entier
screenrig project export DIR écrit les données du projet dans un répertoire en formats ouverts. Vérifiez le résultat de chaque section avant d’utiliser la copie pour la récupération.
| Chemin | Contient |
|---|---|
export.json | Le format (screenrig.export/v1), la date de création, le résultat de chaque section et chaque fichier avec sa taille et son SHA-256 |
project.json, tags.json | Le projet et ses étiquettes avec leurs écrans |
screens/ | screens.json, folders.json et schedules.json (les niveaux, la prise de contrôle et l'horaire d'affichage de chaque écran) |
playlists/ | Chaque liste de lecture et chaque révision, en JSON |
campaigns.json, advertising/direct-campaigns.json | Campagnes et campagnes directes |
cards/, sources.json, applications.json, triggers.json | Cartes avec leurs données, configuration des sources de données, métadonnées des applications et déclencheurs d’alerte |
applications/APP_ID/kv.json | Entrées K/V persistantes de chaque application : valeurs en base64, types de contenu, nombre d’octets, SHA-256 et révisions |
notifications.json, webhooks.json, alert-mutes.json, report-subscriptions.json | Notifications, webhooks, mises en sourdine et horaires |
media/files/ et media/manifest.json | Les fichiers médias originaux, avec l'identifiant, le nom, le type, la taille et le SHA-256 de chacun |
data/ | CSV pour les diffusions, les totaux de lecture, la disponibilité quotidienne, la disponibilité par écran et les alertes |
log/events.jsonl | Le journal des événements du projet, un événement JSON par ligne |
log/audit.jsonl, log/audit-head.json | Le journal d’audit, une entrée JSON par ligne, et sa tête de chaîne |
Conservez les archives originales des applications avec les exports pour récupérer les versions, y compris celles fixées par d’anciennes listes de lecture. Les omissions de contenu sont signalées dans la section des fichiers d’application et définissent data.complete:false avec export_application_content_omitted, y compris avec --no-media. Une nouvelle exécution actualise les métadonnées.
Les données K/V des applications sont copiées intégralement avec --no-media comme avec --since. Si la lecture de la liste K/V ou d’une valeur échoue, la section applications échoue avec export_section_failed et définit data.complete:false. Corrigez l’erreur de lecture et relancez l’export pour actualiser la copie.
Les identifiants ne figurent jamais dans la copie : la clé de signature et l'adresse de réception d'un webhook, l'identifiant de clavardage ou de téléavertisseur d'une notification et les secrets d'une source de données en sont exclus (le fichier garde l'origine du récepteur et les noms des secrets). Une réexécution est sûre : les fichiers JSON sont réécrits en entier, un fichier média déjà complet est conservé et un téléchargement partiel reprend là où il s'est arrêté. Chaque fichier média est vérifié selon le SHA-256 que détient le projet avant d'être conservé. --no-media ignore les fichiers médias et --since DAY démarre les données CSV et le journal des événements à un jour donné. Chaque requête est une requête d'API facturée, et les téléchargements de médias sont de la sortie de données.