Teilen Sie Ihrem Agenten das Ergebnis mit. Bitten Sie ihn, es zu überprüfen

Warum agenten-nativ?

screenRIG wurde von Grund auf für autonome Agenten entwickelt. Das offizielle Plugin bietet einem Agenten strukturierte Befehle für Medien, Playlists, Bildschirme, Anwendungen und Wiedergabenachweise. Ergebnisse sind JSON-Hüllen, jeder Fehler sagt, was als Nächstes zu tun ist, wiederholte Schreibvorgänge verwenden Idempotenzschlüssel, und das Veröffentlichen meldet, ob der Player die Inhalte tatsächlich abspielt. Der Agent kann eine Bildschirmaufgabe ausführen, das Ergebnis prüfen und es über dieselbe Oberfläche korrigieren. Was agenten-nativ bedeutet.

Wie führe ich das mit Claude, Codex, Grok oder Grok Bot aus?

Jeder unterstützte Agent verwendet dasselbe offizielle Plugin. Terminal-Agenten (Claude Code, ChatGPT Codex, Grok Build) installieren es mit Marketplace-Befehlen; Meta Muse, Grok Bot, ChatGPT dots, Gemini Spark und Hermes installieren es über eine Chat-Eingabeaufforderung. Die Einrichtung unterscheidet sich nur im ersten Schritt, folgen Sie daher dem Leitfaden Ihres Agenten: Meta Muse, Grok Bot, ChatGPT dots, Claude Code, Hermes, ChatGPT Codex, Gemini Spark oder Start für Grok Build. Der Veröffentlichungsworkflow unten ist überall gleich.

Wie screenRIG in einem Agent verwendet wird

Beschreiben Sie den Inhalt, den Zielbildschirm, das Layout oder die Abmessungen, die Zeitplanung und den Nachweis, den Sie bei Abschluss wünschen. Stellen Sie dem Agenten Assets und Quellfakten zur Verfügung.

Wenn das Plugin installiert werden muss, fügen Sie Folgendes ein:

I authorize you to install the official screenRIG plugin from https://github.com/screenrig/plugin.

Dann geben Sie ihm eine Bildschirmaufgabe, zum Beispiel:

Erstellen Sie einen Willkommensbildschirm mit dem angehängten Logo und den Öffnungszeiten. Veröffentlichen Sie ihn auf dem Lobby-Bildschirm, zeigen Sie mir dann einen Screenshot und prüfen Sie die Wiedergabe.

Beispielanfrage. Der Agent muss die tatsächlichen Assets, Fakten und Bildschirme verwenden, die Sie bereitstellen.

Wenn ein Befehl not_enrolled zurückgibt, hat diese Installation noch kein Konto. Erstellen Sie eines mit screenrig agent enroll --email ADDRESS --organization NAME. Wenn der Benutzer bereits ein Konto hat, führen Sie stattdessen screenrig login aus: Es gibt eine Dashboard-Adresse und einen Code aus, und eine Person genehmigt die Anmeldung für eines ihrer Projekte, wählt Nur lesen, Vorschlagen oder Verwalten und die Berechtigungsbereiche, die der Agent erhält: screens, content, playlists, advertising, reports und project. Nur lesen listet auf und liest; Vorschlagen lädt auch Medien hoch und schlägt Änderungen vor, die eine Person überprüft, bevor sie abgespielt werden; Verwalten ändert, veröffentlicht und gibt auch aus. Ein Befehl außerhalb der genehmigten Bereiche gibt 403 forbidden zurück, und eine Änderung aus einer Nur-Lesen-Sitzung gibt 403 insufficient_access zurück. Wie die Anmeldung funktioniert. Andere Fehler beim ersten Lauf sind in Wenn der erste Lauf fehlschlägt abgebildet.

Aufgabe vorbereiten

Quell-Assets und Fakten für den Agenten verfügbar halten. Den vorgesehenen Player, Abmessungen, Zeitplanung und Abschlusskriterien identifizieren. Der Veröffentlichungsworkflow ist bei unterstützten Agenten gleich; Installationsunterschiede sind in Start.

Für Kiosk-Apps verwenden Sie das Browser-SDK. Für Zeitpläne und Tagesabschnitte geben Sie die Zeitzone des Bildschirms und die vorgesehenen Zeitfenster an.

Was der Agent fortlaufend tut

Der Agent lädt vorhandene Medien hoch, generiert vollständige präsentierbare Designs, platziert eingebaute Karten für sich ändernden Text oder veröffentlicht Live-Video, Webseiten und Anwendungen. Anschließend bereitet er eine Playlist mit playlist init vor und veröffentlicht sie mit screen publish. Um eine bestehende Playlist zu ändern, verwenden Sie playlist show --output und playlist update. Siehe CLI-Workflow-Referenz.

Verwenden Sie die Ganzseiten-Generierung für Poster und Menüs. Verwenden Sie eine eingebaute Karte für Text, Tabellen und Tafeln, die sich ändern. Animation ändert die Wahl nicht. Lesen Sie den Leitfaden zur Erstellungsauswahl.

Für Anwendungen verwenden Sie emit, wenn der Agent auf ein benanntes Ereignis reagieren soll, log für Diagnosen und kv für Zustände, die über Releases hinweg bestehen bleiben. Lesen Sie die SDK-Referenz.

Wie steuert der Agent eine Flotte?

Versehen Sie Bildschirme nach Zweck mit Tags und legen Sie sie nach Ort in Ordnern ab, richten Sie dann das Tag oder den Ordner aus. Wenn ein Player gekoppelt ist, benennt der Agent den Bildschirm und versieht ihn mit Tags: screen pair CODE, dann screen tag scr_ID --add Lobby,Floor2. Jeder Bildschirm trägt bis zu 16 Tags und liegt in höchstens einem Ordner (screen move scr_ID --folder sfd_ID).

1. 01

   Einmal veröffentlichen. playlist create erstellt die Playlist und screen assign --tag Lobby --playlist-id ID weist alle aktiven Lobby-Bildschirme mit einer Flottenaktion darauf hin.

2. 02

   Handeln Sie für die Flotte. screen reload, screen toast und screen tag verwenden denselben --tag oder mehrere Bildschirm-IDs. Ein Flottenbefehl ist eine berechnete Aktion ohne Begrenzung der Bildschirmanzahl. Die CLI folgt automatisch begrenzten Ergebnissseiten und wartet, bis die Kontrollbudgets zurückgesetzt sind, wobei derselbe Aktionsschlüssel beibehalten wird. Die Antwort listet jeden Bildschirm als ok oder mit seinem eigenen Problem auf, sodass der Agent genau meldet, welche Bildschirme fehlgeschlagen sind, und nach ID darauf reagiert.

3. 03

   Verifizieren Sie auf dem Bildschirm. screen screenshot --tag Lobby --output lobby-shots erfasst jeden markierten Bildschirm in einem Verzeichnis. Prüfen Sie jedes Bild, bevor Sie melden, dass die Flotte aktualisiert wurde.

4. 04

   Auf Verbindungsabbrüche achten. Halten Sie events follow geöffnet. screen.offline erscheint, sobald ein Bildschirm 60 Sekunden offline war, und screen.online wenn er zurückkehrt; beide sind im Listen-Stream kostenlos.

Flottenbefehle lesen.

Wie steuert der Agent Tageszeiten und Übernahmen?

Ein Playlist-Zeitplan ändert, was ein Bildschirm nach Tageszeit abspielt; eine Kampagne schaltet eine ganze Flotte innerhalb ihrer Datumsgrenzen oder Uhrzeiten auf eine Playlist um; eine Übernahme unterbricht alles für eine Ankündigung und endet von selbst.

1. 01

   Bildschirm nach Tageszeit segmentieren. Erstellen Sie pro Tageszeit eine Playlist mit playlist create und behalten Sie eine Standardzuweisung mit screen assign bei. Stellen Sie sicher, dass der Bildschirm eine Zeitzone hat. Schreiben Sie die Einträge in eine Datei und führen Sie screen schedule set scr_ID --file dayparts.json aus, oder --tag Cafe für jeden Café-Bildschirm. screen show meldet effective_playlist mit source und until, damit der Agent bestätigen kann, welche Tageszeit aktiv ist und wann sie wechselt.

2. 02

   Führen Sie eine Kampagne über eine Flotte aus. Für Mittagsmenüs in jedem north-Store schaltet campaign create --name Lunch --playlist-id pl_LUNCH --tag north --window mon-fri@11:00-14:00 jeden Bildschirm zu seiner eigenen Ortszeit um 11:00 Uhr um und um 14:00 Uhr zurück, und ein Bildschirm, der später mit north getaggt wird, erhält sie ebenfalls. Jeder Bildschirm benötigt eine Standard-Playlist und eine Zeitzone. campaign screens cmp_ID listet jeden Bildschirm auf, den die Kampagne erreicht, mit seinem Status (playing, pending, waiting mit next_start, outranked, blocked), und campaign explain scr_ID sagt, warum ein Bildschirm sie nicht abspielt. Verwenden Sie --from und --until für die Datumsgrenzen einer Aktion, --monthly, --date und --except für monatliche und einmalige Termine, --on-touch für eine Ebene, die abgespielt wird, solange jemand den Bildschirm bedient, und --priority, wenn zwei Kampagnen gleichzeitig gelten können. Kampagnenänderungen erfordern Manage-Zugriff.

3. 03

   Übernehmen Sie im Notfall oder bei einem Start. screen takeover --tag Lobby --playlist-id pl_NOTICE --for 30m --reason "Fire drill" legt eine Playlist auf jedem Lobby-Bildschirm vor Kampagnen, Zeitplänen und Zuweisungen ab. Verwenden Sie --until für ein festes Ende oder --until none, um sie bis screen takeover clear --tag Lobby zu halten.

4. 04

   Verifizieren und beobachten. Fordern Sie screen screenshot --tag Lobby an, sobald die Übernahme live ist, und verfolgen Sie screen.takeover_started, screen.takeover_ended und screen.playlist_switched im Ereignisprotokoll. screen.playlist_unavailable bedeutet, dass eine geplante Playlist nicht angezeigt werden konnte.

Planungs- und Übernahmebefehle lesen und die Kampagnenbefehle. Um viele Bildschirme aus einer Tabelle zu planen, verwenden Sie Zeitplan-Import.

Entwürfe, Test und Hochstufen, Verlauf

Eine Änderung an dem, was abgespielt wird, kann als Entwurf beginnen, zuerst einige Testbildschirme erreichen, vor ihrer Ausführung geprüft und aus ihrem Verlauf zurückgeholt werden.

1. 01

   Entwurf anlegen. campaign create --paused erstellt eine Kampagne, die keinen Bildschirm erreicht, und "paused": true an einem Zeitplaneintrag in einer screen schedule set-Datei macht dasselbe für diesen Eintrag. Ein Entwurf liegt auf keinem Bildschirm-Stapel, und der Kalender zeigt ihn gestrichelt.

2. 02

   Vor der Änderung prüfen. campaign preview nimmt die Flags von campaign create oder campaign update, und screen schedule preview scr_ID --file FILE nimmt die Zeitplandatei. Keiner von beiden schreibt etwas. Jeder listet die Bildschirme, die die Ebene gewinnen oder verlieren würden, und den Kalender davor und danach über eine Woche oder mit --calendar-from und --calendar-to bis zu 93 Tage. campaign preview cmp_ID --publish zeigt vorab, wie ein Entwurf veröffentlicht würde.

3. 03

   Testen. campaign publish cmp_ID --test-folder sfd_TEST oder --test-screen scr_A,scr_B hebt die Pause des Entwurfs nur für diese Bildschirme auf. Prüfen Sie sie mit screen screenshot. campaign publish cmp_ID ohne Testoption schickt ihn an seine eigene Zielgruppe.

4. 04

   Hochstufen. campaign promote cmp_ID --revision N gibt der Kampagne die Zielgruppe ihrer Entwurfsrevision N, der pausierten Revision, die campaign revisions cmp_ID auflistet, sodass sie die echten Bildschirme erreicht.

5. 05

   Verlauf lesen und wiederherstellen. campaign revisions cmp_ID und screen schedule revisions scr_ID listen jede Version auf, die neueste zuerst. campaign restore cmp_ID --revision N und screen schedule restore scr_ID --revision N kopieren eine frühere als neue Revision nach vorn und lassen die anderen unverändert. Eine Zeitplan-Wiederherstellung aus einer Propose-Sitzung wartet auf die Genehmigung einer Person, wie screen schedule set; eine Kampagnen-Wiederherstellung erfordert Manage-Zugriff.

Das Dashboard bietet dieselben Bedienelemente: Eine Verlaufsansicht listet Änderungen mit Wiederherstellen und Zurückverschieben, und Veröffentlichen, Übernehmen oder Wiederherstellen zeigt sein Davor und Danach zur Bestätigung.

Lesen Sie die Kampagnenbefehle und die Zeitplanbefehle.

Wie meldet der Agent den Nachweis der Wiedergabe?

Jeder sichtbare Start eines Bildes oder Videos ist ein Wiedergabeprotokoll, sodass der Agent einem Client, Werbetreibenden oder Prüfer die genauen Wiedergaben für einen Zeitraum übergeben kann.

1. 01

   Wählen Sie den Zeitraum aus. Ein Bericht umfasst bis zu 31 Tage Wiedergaben, gefiltert nach --screen-id, --media-id oder --tag. Verwenden Sie RFC 3339 Zeitpunkte für Kalenderzeiträume oder Altersangaben wie 7d.

2. 02

   Exportieren. screenrig playback plays --format csv --from 2026-09-01T00:00:00Z --to 2026-10-01T00:00:00Z --tag Lobby --output september-lobby.csv schreibt eine Zeile pro Wiedergabe in eine berechnete Anfrage. screenrig playback list --format csv --day-from 2026-09-01 --day-to 2026-09-30 fügt die Tagesgesamtwerte hinzu.

3. 03

   Prüfen und übergeben. Der Umschlag meldet rows, bytes und sha256; zitieren Sie sie mit der Datei. Wenn der Stream unterwegs fehlschlägt, folgen Sie error.next, das den Rest des Bereichs in eine zweite Datei exportiert.

Wiedergabebefehle lesen.

Wie priorisiert der Agent die Gesundheit und legt die Displayzeiten fest?

Gesundheitsberichte und Displaysteuerung ermöglichen es dem Agenten, Bildschirme nach Feierabend ohne Personal vor Ort laufen und dunkel zu halten.

1. 01

   Triage. screenrig alerts list zeigt, was gerade offen ist, ein Alarm pro Bildschirm und Bedingung, und screenrig screen list --human markiert in der HEALTH-Spalte Bildschirme, die Aufmerksamkeit benötigen. screenrig screen show scr_ID liefert den vollständigen Bericht: Display-Verbindung, Temperatur, Akku, Laufzeit, Abstürze und ob der Bericht veraltet ist. Er nennt auch die wahrscheinliche Ursache des letzten Ausfalls, wenn screenRIG sie bestimmen kann: Das Gerät wurde neu gestartet, der Player wurde neu gestartet oder ist abgestürzt, das Netzwerk des Bildschirms oder eine Unterbrechung bei screenRIG. screenrig alerts ack ID quittiert einen Alarm, an dem jemand arbeitet, und alerts snooze ID --for 4h stellt ihn für 4 Stunden zurück. Erstellen Sie eine Benachrichtigung für screen_offline, display_disconnected, running_hot, not_playing und crashing, damit eine Meldung diese Arbeit startet.

2. 02

   Beheben Sie es in der am wenigsten störenden Reihenfolge. screen reload aktualisiert Inhalte. Deklariert der Player restart_app, startet screen restart-app scr_ID die Player-Anwendung neu; deklariert er clear_cache, leert screen clear-cache scr_ID seine Caches und lädt Inhalte erneut herunter; deklariert er reboot, startet screen reboot scr_ID das Gerät neu; eine Flotte braucht --yes. Ein Offline-Bildschirm erhält jeden davon, wenn er innerhalb von 24 Stunden zurückkehrt. Für einen wiederkehrenden Neustart lässt screenrig screen reboot-schedule set --tag Cafe --window "Mon-Sun 04:00-04:30" screenRIG jeden Bildschirm zu Beginn des Fensters in seiner eigenen Zeitzone neu starten; ein zu diesem Zeitpunkt offline befindlicher Bildschirm behält den Neustart nur, bis das Fenster endet, und ein Neustart, der innerhalb von zehn Minuten abgeschlossen ist, löst keinen Offline-Alarm aus. screen update-software scr_ID installiert die neueste Player-Version, wenn der Player update deklariert. Ein getrenntes Display braucht meist jemanden vor Ort; sagen Sie das im Bericht.

3. 03

   Außerhalb der Geschäftszeiten Strom einstellen. Öffnungszeiten in eine Datei schreiben und screenrig screen display-schedule set --tag Cafe --file hours.json ausführen; der Player schaltet das Display außerhalb dieser Zeiten aus, auch offline. Für eine einmalige Aktion überschreibt screen display scr_ID --power on --for 2h den Zeitplan bis zur nächsten Grenze oder der angegebenen Zeit. screen display-idle scr_ID --after 300 --wake touch,presence dunkelt einen Bildschirm ab, den niemand nutzt, und schaltet ihn wieder ein, wenn jemand ihn berührt oder herantritt.

4. 04

   Bestätigen. screen show meldet die vom Player erreichte Display-Leistung, screen.display_changed und screen.reboot_requested erscheinen im Ereignisprotokoll, und der Befehl in commands endet mit done oder failed samt Ursache.

5. 05

   Glas prüfen. screenrig screen show scr_ID gibt Playlist stalled aus, wenn ein Bildschirm online ist und aktuelle Inhalte hat, aber länger als seine Schleife erlaubt kein Bild- oder Videostart bei screenRIG eingegangen ist, und Blank screen oder Frozen picture, wenn die Screenshots, die screenRIG über einen die ganze Schleife abdeckenden Durchlauf aufgenommen hat, alle einfarbig oder alle dasselbe Bild waren. Eine Benachrichtigung für loop_stalled, glass_blank oder glass_frozen meldet es, und screen screenshot zeigt, ob ein einzelnes Bild einfarbig ist, was für sich allein kein Urteil ist. Die Prüfungen sagen nichts über einen Bildschirm, dessen Display aus ist, der unter einer Übernahme steht, der ein einzelnes Standbild oder eine Videowand zeigt oder dessen Player keine Wiedergabenummern sendet; ein ruhiger Bildschirm ist also kein Beweis dafür, dass er abspielt.

Gerätebefehle für Gesundheit und Stromversorgung lesen.

Wie werde ich benachrichtigt oder wie wecke ich einen Agenten, wenn etwas passiert?

Eine Benachrichtigung sendet E-Mails an Personen, postet in Slack, Teams, PagerDuty oder Telegram oder sendet eine signierte HTTPS-Anfrage, wenn ein Bildschirm offline geht, seine Anzeige verliert, zu heiß läuft, vom Akku versorgt wird, seine Inhalte nicht speichern kann, bei einem Inhaltsupdate hängen bleibt, statt abzuspielen einen Fehler zeigt, ständig abstürzt, in seiner Playlist nicht mehr weiterkommt, schwarz wird oder einfriert. Eine Person erfährt davon, oder ein Agent beginnt zu arbeiten, ohne dass jemand einen Stream beobachtet. Jedes Projekt sendet seinem Eigentümer bereits eine E-Mail, wenn ein Bildschirm 10 Minuten offline war, und Benachrichtigungs-E-Mails und Bildschirmhinweise sind kostenlos.

Drei oder mehr Bildschirme, die innerhalb von fünf Minuten in denselben Zustand geraten und ein Netzwerk, einen Standort, ein Modell, eine Player-Version oder ein Tag teilen, ergeben in einer E-Mail oder einer Chat- oder Pager-Nachricht eine einzige Benachrichtigung und eine einzige Wiederherstellungsmeldung, die nennt, was sie teilen und wie viele es sind; ein signierter Webhook sendet weiterhin einen POST pro Bildschirm. Eine Wiederherstellungsnachricht sagt nur dann, dass ein Bildschirm zurück ist, wenn screenRIG es gesehen hat: Wird ein hängender, schwarzer oder eingefrorener Bildschirm lediglich nicht mehr geprüft, weil er offline ging oder seine Anzeige ausgeschaltet wurde, wird der Alarm geschlossen und keine Wiederherstellungsnachricht gesendet.

1. 01

   Eine Person per E-Mail benachrichtigen. screenrig notifications create --email owner --conditions screen_offline,display_disconnected schickt eine E-Mail an den Projektinhaber; fügen Sie nach owner die Benutzer-IDs von Projektmitgliedern hinzu, um sie einzubeziehen. --tag Lobby beschränkt die Benachrichtigung auf getaggte Bildschirme, und eine Meldung wartet --hold Minuten (standardmäßig 10), sodass eine kurze Wiederverbindung ruhig bleibt. Eine Behebungs-E-Mail folgt, sobald der Bildschirm wieder in Ordnung ist. Jede E-Mail enthält einen Abmeldelink, der nur für ihren Empfänger gilt, und mit screenrig notifications resubscribe ID --user USER_ID erhält eine Person wieder E-Mails. Um stattdessen einen Agenten oder ein anderes System zu wecken, verwenden Sie einen Webhook.

2. 02

   In einem Chat oder Pager posten. screenrig notifications create --slack - --conditions screen_offline postet in einen Slack-Kanal, und --teams, --pagerduty und --telegram tun dasselbe für Teams, PagerDuty und Telegram. Slack nimmt die URL eines eingehenden Webhooks, Teams die URL eines Workflows-Webhooks, PagerDuty einen Routing-Schlüssel der Events-API v2 und Telegram ein Bot-Token mit --telegram-chat CHAT_ID. Ein - liest die Zugangsdaten aus einer Zeile von stdin, damit sie nicht im Shell-Verlauf landen; screenRIG versiegelt sie und zeigt nur einen maskierten destination_hint. Jeder Ausfall postet einmal pro Bildschirm, PagerDuty öffnet einen einzigen Vorfall dafür, und die Wiederherstellung folgt, nachdem diese Nachricht gesendet wurde, und löst den Vorfall auf. screenrig notifications test ID postet eine Testnachricht; bei PagerDuty öffnet es ein Informationsereignis und löst es sofort wieder auf.

3. 03

   Empfänger ausführen. Jeder HTTPS-Endpunkt, den Sie auf Port 443 oder 8443 kontrollieren: ein kleiner Dienst, eine serverlose Funktion oder der eingehende Trigger Ihrer Agenten- oder Bot-Plattform. Er überprüft ScreenRig-Signature mit dem Webhook-Geheimnis, dedupliziert anhand von ScreenRig-Event-Id und antwortet innerhalb von 10 Sekunden mit 2xx.

4. 04

   Abonnieren. screenrig notifications create --webhook https://HOST/PATH --conditions screen_offline,crashing gibt das Signaturgeheimnis einmal zurück; speichern Sie es im Geheimnisspeicher des Empfängers. Fügen Sie --events application.event hinzu, um auch rohe Projekt-Ereignisse zu erhalten. screenrig notifications test ID sendet einen signierten Test-POST, um den Zustellweg zu prüfen.

5. 05

   Übergabe. Der Empfänger startet einen Agentenlauf mit der Meldung als Aufgabe: Er löst einen geplanten oder bedarfsorientierten Agentenjob aus oder postet die Meldung in den Chat, wo Grok Bot oder ein anderer Agent mit dem screenRIG-Plugin arbeitet. Zum Beispiel: „Bildschirm scr_LOBBY ging um 14:02 offline. Prüfen und melden.“ Der Agent arbeitet dann wie gewohnt über das Plugin mit screen show, screen reload und einem Screenshot.

6. 06

   Gesund halten. screenrig notifications deliveries ID listet jeden Versuch auf und nennt, warum eine Meldung nicht gesendet wurde. Eine Benachrichtigung, die 72 Stunden in Folge fehlschlägt, wird deaktiviert; screenrig notifications update ID --enable setzt beim aktuellen Ereignis fort. --snooze 2h pausiert Meldungen während Wartungsarbeiten.

7. 07

   Bildschirme für Wartungsarbeiten stummschalten. screenrig alerts mute --tag Lobby --for 2h --note "Rewiring" verhindert bis zu 30 Tage lang, dass die Alarme dieser Bildschirme Aufmerksamkeit verlangen und dass eine Benachrichtigung sie meldet. screenrig alerts mutes listet auf, was stummgeschaltet ist, und screenrig alerts unmute ID beendet eine Stummschaltung vorzeitig.

8. 08

   Nach Schweregrad, Zeiten und Zielgruppe filtern. Eine geöffnete Meldung ist error für screen_offline und warning für alles andere; --min-severity warning verwirft alles unterhalb dieser Stufe, und --severity not_playing=error stuft eine Bedingung höher ein. --active-hours "Mon-Fri 08:00-22:00" --timezone America/Los_Angeles hält eine Meldung zurück, die außerhalb dieser Zeiten fällig wird, bis das nächste Fenster öffnet (eine Bedingung, die vorher endet, sendet nichts), oder überspringt sie mit --outside-hours drop; eine behobene Meldung folgt immer einer gesendeten. --all-tags level2,overhead deckt nur Bildschirme mit beiden Tags ab, und --audience akzeptiert die vollständigen Regeln einer Kampagnen-Zielgruppe. E-Mails, Slack und Telegram zeigen den Schweregrad, und ein Webhook-Body enthält ihn.

9. 09

   Auf stille Ausfälle achten. Eine Kampagne kann aufhören, Bildschirme zu erreichen, ohne dass ein Bildschirm ausfällt: durch eine Tag-Änderung, das Verschieben eines Ordners oder einen archivierten Bildschirm. screenrig notifications create --email owner --conditions reach_dropped,group_empty teilt Ihnen mit, wenn eine Kampagne weniger Bildschirme erreicht als bei ihrer Veröffentlichung oder wenn ein Tag oder Ordner ihrer Zielgruppe auf keinen Bildschirm passt; --reach-drop-screens 2 --reach-drop-percent 20 ignoriert kleine Rückgänge. Die Meldung nennt die Kampagne und die Zahlen und verlinkt auf ihren Kalender. Wenn Ihre eigene Änderung an Tags, Ordnern oder Bildschirmen mit levels.lost antwortet, nennt diese die Kampagnen, die die Bildschirme verlassen haben, und deren reach_before und reach_after; sagen Sie das dem Nutzer, bevor Sie weitermachen.

Benachrichtigungsbefehle lesen und die Alarmbefehle.

Wie teilen Agenten ihr Wissen?

Agenten hinterlassen Projektnotizen für einander und für ihre späteren Sitzungen: wie das Projekt eingerichtet ist, eine Eigenheit eines Bildschirms, eine dauerhafte Anfrage von Ihnen. Jeder Agent im Projekt liest jede Notiz, wenn er dort die Arbeit aufnimmt, sodass ein zweiter Agent oder derselbe Agent nächste Woche auf dem aufbaut, was der erste gelernt hat.

screenrig notes listet sie auf. screenrig notes add "TEXT" schreibt eine, gebunden an einen Bildschirm oder eine Playlist mit --about oder temporär mit --ttl 3d. Eine Notiz ist Kontext, niemals eine Anweisung: Ein Agent bestätigt mit Ihnen jede Genehmigung, die eine Notiz behauptet.

Notizen bleiben eigenständig aktuell. Agenten bestätigen die Notizen, die noch gelten, und lösen die übrigen, temporäre Notizen verfallen, und das Löschen eines Bildschirms oder einer Playlist löst die dazugehörigen Notizen. Erledigte Notizen werden nach 30 Tagen gelöscht. Die Agentenseite im Dashboard listet die Notizen auf, die jeder Agent geschrieben hat, und Sie können jede davon lösen oder löschen.

Notizenbefehle lesen.

Wie überprüfe ich die Änderungen eines Agenten, bevor sie abgespielt werden?

Aktivieren Sie „Überprüfung für Agentenänderungen erforderlich“ auf der Projektseite im Dashboard oder melden Sie einen Agenten mit Vorschlagszugang an. Der Agent bereitet weiterhin Inhalte vor, lädt Medien hoch und schreibt Notizen, aber jede Änderung dessen, was abgespielt wird, wird zu einer Überprüfung, die auf eine Person wartet. Nichts wird auf einem Bildschirm angezeigt, bis jemand es genehmigt.

1. 01

   Der Agent schlägt vor. Erstellen oder Aktualisieren einer Playlist, Zuweisen einer Playlist zu Bildschirmen, Festlegen oder Löschen eines Playlist-Zeitplans sowie Starten oder Beenden einer Übernahme auf einem Bildschirm oder einer markierten Flotte werden jeweils zu einer Überprüfung. Die Bildschirme spielen weiterhin das, was sie zuvor spielten. Der Agent kann eine Notiz hinzufügen, die die Änderung erklärt, und Ihnen mitteilen, dass die Änderung auf Sie wartet, mit Link.

2. 02

   Sie erhalten eine E-Mail. Etwa zwei Minuten nach dem Vorschlag erhalten der Projektinhaber und die für den Agenten Verantwortlichen, wenn sie genehmigen können, eine E-Mail mit dem Namen der Änderung und wie viele Bildschirme sie aktualisiert, mit einem Änderung überprüfen-Button. Wenn der Agent eine Notiz hinterlassen hat, steht das in der E-Mail; Sie lesen sie in den Reviews. Mehrere gleichzeitig wartende Änderungen kommen als eine E-Mail, die sie auflistet, mit einem Reviews öffnen-Button, und eine Reihe von Bearbeitungen an einer Änderung sendet eine E-Mail für die neueste Version. Das Öffnen des Links genehmigt nichts.

3. 03

   Entscheiden in Reviews. Die Dashboard-Seite Reviews listet alle wartenden Änderungen, mit den bereits entschiedenen darunter. Eine Playlist-Änderung zeigt die Live- und vorgeschlagenen Playlists nebeneinander, mit Seiten markiert als Hinzugefügt, Geändert oder Entfernt. Genehmigen setzt sie auf die Bildschirme; Änderungen anfordern sendet dem Agenten Ihre Notiz, damit er überarbeiten und erneut vorschlagen kann; Ablehnen schließt sie mit Ihrem Grund. Wenn eine neue Playlist und deren Bildschirmzuweisung zusammen warten, bietet die Genehmigung der Playlist an, auch die Zuweisung zu genehmigen. Eine Änderung bei einer großen Flotte wird im Hintergrund fertig angewendet, und die Review zeigt das Ergebnis für jeden Bildschirm, sobald es eintrifft.

4. 04

   Der Agent verfolgt nach. Der Agent liest die Entscheidung mit screenrig reviews show ID oder seinem Ereignis, überarbeitet nach Änderungswunsch oder Ablehnung und überprüft die Bildschirme nach Genehmigung.

Der Projektinhaber kann immer genehmigen, und jedes Mitglied kann es, sofern der Inhaber Kann genehmigen für es nicht auf der Seite Personen ausschaltet. Die Agenten eines Mitglieds, das nicht genehmigen kann, arbeiten höchstens mit Propose. Ein Vorschlag wird veraltet, wenn sich die Live-Playlist nach seiner Erstellung ändert; der Agent schlägt erneut auf Grundlage der neuen Version vor. Das Genehmigen einer Playlist-Änderung wird außerdem veraltet, wenn ihre tag-, folder- oder all-Selektoren nun Medien abspielen würden, die sie beim Vorschlag nicht sah. Ein als geschützt markierter Ordner schickt jede Änderung, die seine Bildschirme erreicht, an eine zweite genehmigende Person; siehe Berechtigungen nach Bildschirmordner.

Medienänderungen warten ebenfalls. Ein neuer Upload wird in Tag-, Ordner- und Alle-Playlists erst abgespielt, nachdem eine Person ihn genehmigt hat, und wenn ein Agent genehmigte Medien umtaggt oder verschiebt, spielen Bildschirme diese weiterhin als genehmigt, bis die Änderung genehmigt ist. Jedes Element erhält eine eigene Überprüfung, die seine Tags und Ordner vor und nach der Änderung zeigt und die Playlists auflistet, denen es beitreten oder die es verlassen würde, sowie die Anzahl der erreichten Bildschirme. Genehmigung wendet die Änderung auf alle an; Ablehnung oder Änderungsanforderung setzt ein umgetaggtes oder verschobenes Element auf den genehmigten Zustand zurück, und ein abgelehnter Upload bleibt von den Bildschirmen fern. Eine Ersatzdatei oder wiederhergestellte Version freigegebener Medien wartet ebenso, und die alte Datei wird weiter abgespielt, bis eine Person freigibt. Werbenetzwerke überprüfen die Creatives der Käufer auf derselben Überprüfungsseite. Zugriffsebenen und Überprüfungseinstellungen · Überprüfungsbefehle.

Was als vollständig gilt

Bestätigen Sie, dass die beabsichtigte Playlist dem beabsichtigten Bildschirm oder jedem Bildschirm der Flotte zugewiesen ist. Fordern Sie einen Screenshot an, einen pro markiertem Bildschirm für eine Flotte, prüfen Sie Wiedergabedaten und überprüfen Sie relevante Ereignisse, einschließlich aller screen.offline. Berichten Sie, was diese Beobachtungen ergeben und welche Unsicherheiten verbleiben. Eine Änderung, die auf Überprüfung wartet, ist noch nicht auf dem Bildschirm: Berichten Sie den Überprüfungslink und prüfen Sie erneut, nachdem eine Person entschieden hat.

Ein erfolgreicher Befehl ist ein Schritt in diesem Beweis. Er allein beweist nicht, dass ein physischer Bildschirm das beabsichtigte Ergebnis angezeigt hat.

Film / Wie Ihr Agent erkennt, dass er spielt

1:17