Dokumentation

Berichte und Exporte

Berichte lesen die Aggregate des Projekts: Verfügbarkeits-Rollups, Alarmverlauf, Bildschirmzustand und Auslieferung direkter Kampagnen. Sie durchsuchen nie Rohereignisse. Jeder Bericht ist eine Tabelle, die als JSON, CSV, XLSX oder PDF geschrieben wird, und jeder Bericht kann nach Zeitplan per E-Mail gesendet werden.

Rollups nach Ordner und Tag

fleet_health, uptime, publishing und alerts fassen die Flotte nach Ordner, Bildschirm oder Tag über einschließlich UTC-Tage zusammen. Eine Ordnerzeile zählt jeden Bildschirm darin und in allen Unterordnern, und die erste Zeile ist das ganze Projekt. Tags sind die zweite Gruppierung: Ein Bildschirm zählt in jedem Tag, den er trägt.

BerichtWas eine Zeile aussagt
fleet_healthBildschirme, jetzt online, Verfügbarkeit, offene Alarme, im Zeitraum begonnene Alarme, heiß, Display getrennt, abstürzend und wie viele Bildschirme ihren aktuellen Inhalt spielen
uptimeOnline- und Offline-Stunden, Verfügbarkeit und erfasste Abdeckung
publishingBildschirme mit aktuellem Inhalt, Inhalt in Aktualisierung, Inhalt mit Handlungsbedarf und ohne Inhalt
alertsJetzt offene und im Zeitraum begonnene Alarme, nach Bedingung
alert_logEine Zeile pro im Zeitraum begonnenem Alarm: der Bildschirm, die Bedingung, wann er begann und endete und wer ihn quittiert hat
proof_of_playWiedergaben der direkten Kampagnen eines Sponsors oder Werbetreibenden je Kampagne, Medium und Bildschirm, mit Summen

GET /api/reports/{kind} erstellt einen Bericht. from und to sind UTC-Tage (Standard: die letzten 30 Tage); group_by ist folder (Standard), screen oder tag; folder_id beschränkt den Bericht auf einen Ordner und alles darin, mit direct=true auf den Ordner und seine direkten Unterordner oder, nach Bildschirm gruppiert, auf die Bildschirme direkt darin; tag behält Bildschirme mit diesem Tag. Eine Ordnerzeile trägt id, parent_id und depth, damit ein Client die Gliederung aus den Zeilen zeichnet. Die Verfügbarkeit ist die Online-Zeit im Verhältnis zur erfassten Zeit, und die erfasste Abdeckung sagt, für welchen Teil des Zeitraums die Bildschirme einen Zustand gemeldet haben.

Die Seite Zustand des Dashboards legt diese Rollups als Bildschirmordner aus: Jeder Ordner öffnet sich zu seinen Unterordnern und Bildschirmen, jeder Bildschirm zu seinem Reiter Zustand.

CSV, XLSX und PDF

Jede Berichtsroute akzeptiert format=csv, xlsx oder pdf und antwortet mit einem Anhang derselben Zeilen: die neuen Berichte, 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, die Werbe-Auslieferungs-, Füll- und Ausgabenberichte und der Bericht einer direkten Kampagne. Ein seitenweiser Bericht wird vollständig geschrieben, bis zu 50.000 Zeilen; truncated zeigt an, wenn er nur die ersten Zeilen enthält.

Die XLSX-Datei ist ein einzelnes Blatt mit Titel und Zeitraum über einer fixierten Kopfzeile, Zahlen als Zahlen und fetten Summen. Das PDF ist eine schlichte Aufstellung mit dem Namen screenRIG, dem Projekt, für das sie bestimmt ist, Titel und Zeitraum, einer Tabelle, deren Kopf sich auf jeder Seite wiederholt, den Summen und den Seitenzahlen, versandfertig. Die CSV beginnt mit den Spaltenbezeichnungen und entschärft eine Textzelle, die eine Tabellenkalkulation als Formel ausführen würde.

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.csv

Wiedergabenachweis für einen Sponsor oder Werbetreibenden

proof_of_play summiert die Wiedergaben der direkten Kampagnen des Projekts. Eine Wiedergabe zählt, wenn der Bildschirm meldet, dass das Medium auf dem Bildschirm zu Ende gespielt wurde. Benennen Sie eine Kampagne mit campaign_id oder alle Kampagnen eines Sponsors oder Werbetreibenden mit advertiser (sein genauer Name, Groß- und Kleinschreibung egal). Jede Zeile ist eine Kampagne, eine Mediendatei und ein Bildschirm mit Wiedergaben, gespielten Stunden, erstem und letztem Tag und, wenn der Bildschirm eine Reichweitenschätzung hat, geschätzten Impressionen. Das PDF ist der Nachweis zum Versenden.

E-Mail-Zeitpläne

Ein Berichtsabonnement nennt eine Berichtsart und ihre Filter, einen Rhythmus, ein Dateiformat und die Projektmitglieder, die ihn erhalten. POST /api/report-subscriptions legt eines an; eine Organisation hat höchstens 50 über alle ihre Projekte (report_subscription_limit_reached).

FeldBedeutung
kindfleet_health, uptime, publishing, alerts, alert_log oder proof_of_play
filtersDie Filter des Berichts außer den Tagen: group_by, folder_id, direct, tag, campaign_id, advertiser
schedulecadence daily, weekly (weekday) oder monthly (day_of_month, 1 bis 28), hour 0 bis 23 und eine IANA-timezone
formatpdf, xlsx oder csv, als Anhang der E-Mail
recipientsProjektmitglieder, benannt per user_id oder per E-Mail-Adresse des Mitglieds

Jeder Lauf deckt den Zeitraum davor in UTC-Tagen ab: bei einem täglichen Lauf den Vortag, bei einem wöchentlichen die sieben Tage davor und bei einem monatlichen den ganzen Monat davor, nach dem Kalender der Zeitzone des Zeitplans. Empfänger sind Mitglieder des Projekts, bei jedem Versand erneut geprüft: Alle anderen werden beim Schreiben des Abonnements abgelehnt, und ein Mitglied, das geht oder dessen Adresse nicht bestätigt ist, erhält ihn nicht mehr. Der Anhang ist höchstens 8 MiB groß.

Ein fehlgeschlagener Lauf wird nach 15 Minuten, 1 Stunde und 4 Stunden wiederholt und wartet dann auf den nächsten Termin. Das Abonnement zeigt last_status (delivered oder failed), last_error, die vom letzten Lauf abgedeckten Tage und next_run_at. POST /api/report-subscriptions/{id}/send sendet es jetzt für den Zeitraum, den ein Lauf jetzt abdecken würde, ohne den Zeitplan zu verschieben, und antwortet mit dem Abonnement und dem Ergebnis dieses Versands.

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_ID

Die Seite Berichte des Dashboards hat dieselben Zeitpläne unter E-Mail-Zeitpläne.

Ein ganzes Projekt exportieren

screenrig project export DIR schreibt die Projektdaten in offenen Formaten in ein Verzeichnis. Prüfe das Ergebnis jedes Abschnitts, bevor du die Kopie zur Wiederherstellung verwendest.

PfadEnthält
export.jsonDas Format (screenrig.export/v1), wann sie erstellt wurde, das Ergebnis jedes Abschnitts und jede Datei mit Größe und SHA-256
project.json, tags.jsonDas Projekt und seine Tags mit ihren Bildschirmen
screens/screens.json, folders.json und schedules.json (Ebenen, Übernahme und Anzeigezeitplan jedes Bildschirms)
playlists/Jede Playlist und jede Revision, als JSON
campaigns.json, advertising/direct-campaigns.jsonKampagnen und direkte Kampagnen
cards/, sources.json, applications.json, triggers.jsonKarten mit ihren Daten, Datenquellenkonfiguration, Anwendungsmetadaten und Alarmauslöser
applications/APP_ID/kv.jsonPersistente K/V-Einträge jeder Anwendung: base64-Werte, Inhaltstypen, Byteanzahl, SHA-256 und Revisionen
notifications.json, webhooks.json, alert-mutes.json, report-subscriptions.jsonBenachrichtigungen, Webhooks, Stummschaltungen und Zeitpläne
media/files/ und media/manifest.jsonDie originalen Mediendateien und von jeder die ID, den Namen, den Typ, die Größe und den SHA-256
data/CSV für Wiedergaben, Wiedergabesummen, tägliche Verfügbarkeit, Verfügbarkeit je Bildschirm und Alarme
log/events.jsonlDas Ereignisprotokoll des Projekts, ein JSON-Ereignis pro Zeile
log/audit.jsonl, log/audit-head.jsonDas Audit-Protokoll, ein JSON-Eintrag pro Zeile, und sein Kettenkopf

Bewahre die ursprünglichen Anwendungsarchive zusammen mit den Exporten auf, um Releases wiederherzustellen, auch ältere in Playlists festgelegte Versionen. Ausgelassene Anwendungsinhalte erscheinen im Abschnitt für Anwendungsdateien und setzen data.complete:false mit export_application_content_omitted, auch mit --no-media. Ein erneuter Export aktualisiert die Metadaten.

Anwendungs-K/V wird sowohl mit --no-media als auch mit --since vollständig kopiert. Schlägt das Auflisten der K/V-Einträge oder das Lesen eines Werts fehl, schlägt der Abschnitt applications mit export_section_failed fehl und setzt data.complete:false. Behebe den Lesefehler und führe den Export erneut aus, um die Kopie zu aktualisieren.

Zugangsdaten sind nie in der Kopie: der Signaturschlüssel und die Empfangsadresse eines Webhooks, die Chat- oder Pager-Zugangsdaten einer Benachrichtigung und die Geheimnisse einer Datenquelle bleiben draußen (die Datei behält den Ursprung des Empfängers und die Namen der Geheimnisse). Ein erneuter Lauf ist sicher: JSON-Dateien werden ganz neu geschrieben, eine bereits vollständige Mediendatei bleibt erhalten, und ein teilweiser Download setzt bei den vorhandenen Bytes fort. Jede Mediendatei wird vor dem Behalten gegen den SHA-256 des Projekts geprüft. --no-media überspringt die Mediendateien und --since DAY beginnt die CSV-Daten und das Ereignisprotokoll an einem Tag. Jede Anfrage ist eine abgerechnete API-Anfrage, und Medien-Downloads sind Egress.