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.
| Bericht | Was eine Zeile aussagt |
|---|---|
fleet_health | Bildschirme, jetzt online, Verfügbarkeit, offene Alarme, im Zeitraum begonnene Alarme, heiß, Display getrennt, abstürzend und wie viele Bildschirme ihren aktuellen Inhalt spielen |
uptime | Online- und Offline-Stunden, Verfügbarkeit und erfasste Abdeckung |
publishing | Bildschirme mit aktuellem Inhalt, Inhalt in Aktualisierung, Inhalt mit Handlungsbedarf und ohne Inhalt |
alerts | Jetzt offene und im Zeitraum begonnene Alarme, nach Bedingung |
alert_log | Eine Zeile pro im Zeitraum begonnenem Alarm: der Bildschirm, die Bedingung, wann er begann und endete und wer ihn quittiert hat |
proof_of_play | Wiedergaben 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).
| Feld | Bedeutung |
|---|---|
kind | fleet_health, uptime, publishing, alerts, alert_log oder proof_of_play |
filters | Die Filter des Berichts außer den Tagen: group_by, folder_id, direct, tag, campaign_id, advertiser |
schedule | cadence daily, weekly (weekday) oder monthly (day_of_month, 1 bis 28), hour 0 bis 23 und eine IANA-timezone |
format | pdf, xlsx oder csv, als Anhang der E-Mail |
recipients | Projektmitglieder, 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.
| Pfad | Enthält |
|---|---|
export.json | Das Format (screenrig.export/v1), wann sie erstellt wurde, das Ergebnis jedes Abschnitts und jede Datei mit Größe und SHA-256 |
project.json, tags.json | Das 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.json | Kampagnen und direkte Kampagnen |
cards/, sources.json, applications.json, triggers.json | Karten mit ihren Daten, Datenquellenkonfiguration, Anwendungsmetadaten und Alarmauslöser |
applications/APP_ID/kv.json | Persistente K/V-Einträge jeder Anwendung: base64-Werte, Inhaltstypen, Byteanzahl, SHA-256 und Revisionen |
notifications.json, webhooks.json, alert-mutes.json, report-subscriptions.json | Benachrichtigungen, Webhooks, Stummschaltungen und Zeitpläne |
media/files/ und media/manifest.json | Die 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.jsonl | Das Ereignisprotokoll des Projekts, ein JSON-Ereignis pro Zeile |
log/audit.jsonl, log/audit-head.json | Das 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.