Dokumentation

Flottenverbindungen: CLI-Befehle

Flottenverbindungen für Geräteverwaltungen anlegen und Medien, Playlists, Zeitpläne und Bildschirme einer anderen Plattform in screenRIG übernehmen.

Jeder Befehl läuft wie in der CLI-Referenz beschrieben: globale Flags, JSON-Ausgabe, Beendigungscodes, Revisionen und Wiederholungen.

Migration

migrate überträgt Medien, Playlists, Layouts, Zeitpläne und Bildschirme Ihrer bisherigen Signage-Plattform in das Projekt. Es läuft in der CLI auf Ihrem Rechner: Der Schlüssel der Plattform wird aus --credentials FILE mit NAME=VALUE-Zeilen gelesen, geht nur an diese Plattform und wird nie gespeichert, ausgegeben, protokolliert oder an screenRIG gesendet, das nur gewöhnliche Schreibvorgänge für Medien, Playlists, Flottenlinks, Kampagnen und Bildschirme sieht. migrate vendors listet die Plattformen auf, die es liest, und der Fallback files liest einen Ordner oder .zip mit Medien einer beliebigen anderen Plattform.

Führen Sie die Schritte der Reihe nach aus: migrate vendors (was eine Plattform annimmt), migrate scan (das Konto lesen und melden, was übernommen werden kann und was nicht; es braucht keine Anmeldung bei screenRIG), migrate apply --dry-run (der Plan), migrate apply (braucht Manage-Zugriff), dann migrate pair für jeden Bildschirm.

--dir DIR ist das Migrationsverzeichnis, standardmäßig ./screenrig-migration-VENDOR, erstellt mit dem Modus 0700. Es enthält scan.json (den Scan und seinen Bericht), map.json (welches Objekt aus welchem alten Element geworden ist, gebunden an diese API-URL, dieses Projekt, diesen Anbieter und dieses Quellkonto) und staging/ (laufende Downloads). apply und pair verwenden das eine screenrig-migration-*-Verzeichnis im Arbeitsverzeichnis oder nehmen --dir entgegen; in einem Verzeichnis läuft immer nur einer von beiden.

ProblemcodeBeendenBedeutung
migration_dir_mismatch2Das Verzeichnis wurde für ein anderes Projekt, eine andere API-URL, einen anderen Anbieter oder ein anderes Quellkonto erstellt. Verwenden Sie einen anderen Wert für --dir.
vendor_refused3Die Plattform hat den Schlüssel abgelehnt. Erstellen Sie einen schreibgeschützten Schlüssel (migrate vendors VENDOR zeigt, wie), korrigieren Sie die Datei --credentials und führen Sie denselben Befehl erneut aus.
vendor_not_found4Die Plattform hat mit 404 geantwortet. --url ist meist falsch.
vendor_rate_limited7Die Plattform begrenzt die Anfragen mit diesem Schlüssel. Führen Sie den Befehl später erneut aus.
vendor_file_gone8Die Adresse einer Mediendatei ist abgelaufen oder geschützt. Ein erneuter Lauf von migrate scan aktualisiert sie, und --files liefert eine Datei, die weiterhin fehlschlägt.
vendor_file_stalled8Ein Medien-Download ist stumm geblieben. Führen Sie apply erneut aus.
vendor_bad_response9Die Plattform hat eine Antwort gesendet, die die CLI nicht verwenden kann.
vendor_unavailable9 oder 10Die Plattform war nicht erreichbar oder schlug weiterhin fehl.

migrate vendors#

Listet die Plattformen auf, die migrate liest, was jede annimmt und wie man ihren schreibgeschützten Schlüssel erstellt.

migrate vendors [VENDOR]
ParameterTypErforderlichStandardNotizen
VENDORstringneinjede PlattformDie ID einer Plattform. Eine ID, die nicht aufgelistet ist, ergibt usage_error (Exit 2) und nennt die vorhandenen IDs.
screenrig migrate vendors
screenrig migrate vendors files

Es arbeitet offline und braucht keine Anmeldung. data.vendors enthält für jede Plattform id und name; inputs, mit den flags, die sie annimmt (jeweils mit flag und required, und values für eine Region) und den credentials-Zeilen, die ihre Schlüsseldatei enthält (name, secret, required und help); connect, die Schritte, die einen schreibgeschützten Schlüssel erzeugen; maps, was übernommen wird; skips, was nicht; docs; und example, ein funktionierender migrate scan-Befehl. Plattformen sind nach ID sortiert, files zuletzt. files nimmt einen Ordner oder .zip und eine optionale Zeitzone entgegen und braucht keinen Schlüssel.

migrate scan#

Liest ein Signage-Konto und meldet, was übernommen werden kann und was nicht. Es schreibt scan.json und sendet nichts an screenRIG.

migrate scan --from VENDOR [--url ADDRESS] [--region REGION] [--timezone ZONE] [--files PATH]
    [--credentials FILE] [--dir DIR]
ParameterTypErforderlichStandardNotizen
--from VENDORstringjakeineDie zu lesende Plattform: eine ID aus migrate vendors oder files.
--url ADDRESSstringpro PlattformkeineDie Adresse einer selbst gehosteten Plattform.
--region REGIONstringpro PlattformkeineDie Region eines gehosteten Kontos, für eine Plattform mit Regionen.
--timezone ZONEstringneinkeineEin IANA-Zeitzonenname wie America/Toronto, gesetzt auf jedem Bildschirm, dessen alte Plattform keinen nennt. Ohne ihn folgt ein Bildschirm der Zone, die sein Player meldet.
--files PATHPfadpro PlattformkeineEin Ordner oder .zip. Mit --from files enthält er die Medien; bei einer anderen Plattform enthält er die Originale, die die API dieser Plattform nicht herausgeben kann, zugeordnet zu ihren Medien nach Dateiname.
--credentials FILEPfadpro PlattformkeineDie Schlüsseldatei: NAME=VALUE-Zeilen mit den Namen, die migrate vendors VENDOR auflistet. Leerzeilen und #-Kommentare werden übersprungen, und ein Wert darf in einem Paar Anführungszeichen stehen. Ein erforderlicher Name, der in der Datei fehlt, ergibt usage_error (Exit 2) und nennt ihn.
--dir DIRPfadnein./screenrig-migration-VENDORDas Migrationsverzeichnis.
screenrig migrate scan --from files --files ./signage-media
screenrig migrate scan --from files --files ./signage-media.zip --dir ./old-signage --timezone America/Toronto

Eine Option, die die Plattform nicht annimmt, oder eine, die sie braucht und die fehlt, ergibt usage_error (Exit 2) und nennt, was die Plattform annimmt. Keine Option nimmt den Schlüssel selbst entgegen. Ein neuer Scan ersetzt scan.json und behält map.json, und er endet mit 0, wenn er abgeschlossen ist, auch wenn einige Elemente nicht übernommen werden können.

data ist der Bericht: vendor, label, scanned_at, found und importable (Zählungen von media, playlists, layouts, schedules, groups und screens), not_imported (jeweils mit kind, source_id, name, reason und meist einem Schritt next), lossy (jeweils mit kind, source_id, name und was unterwegs geschieht: change), notes, dir und scan_file. Eine Datei, die die Plattform herausgibt, wird unter apply heruntergeladen. Eine Datei, die sie nicht herausgibt oder nur als neu codierte Kopie liefert, wird nach Namen in --files zugeordnet; gibt es keinen oder mehrere Treffer, steht sie in not_imported oder lossy mit dem Schritt, der sie behebt.

--from files braucht keinen Schlüssel. Es liest jede Bild-, Video- und Audiodatei anhand ihres Inhalts, nicht ihrer Endung. Eine optionale Datei playlists.csv im Stammverzeichnis hat die Spalten playlist, file (ein Pfad oder ein eindeutiger Dateiname), duration (Sekunden) und order; ohne sie wird jeder Ordner mit Medien zu einer Playlist in natürlicher Reihenfolge der Dateinamen, und die Dateien im Stammverzeichnis bilden eine nach dem Ordner oder der ZIP-Datei benannte Playlist. Eine optionale Datei screens.csv hat name, group (mehrere, getrennt durch ;), playlist und timezone, und jede Zeile wird zu einem Wartebildschirm, dessen Gruppen zu Tags werden. Andere Dateien und verschlüsselte ZIP-Einträge stehen in not_imported. Ein files-Scan hat keine Zeitpläne: Erstellen Sie sie mit campaign create, sobald die Playlists existieren.

migrate apply#

Importiert, was der Scan gefunden hat: Medien, Playlists und Layouts, Wartebildschirme und Kampagnen. Ein erneuter Lauf ist unbedenklich.

migrate apply [--dir DIR] [--dry-run] [--only KINDS] [--folder ID] [--canvas WIDTHxHEIGHT]
    [--credentials FILE] [--concurrency N] [--no-transcode]
ParameterTypErforderlichStandardNotizen
--dir DIRPfadneindas eine ./screenrig-migration-*-VerzeichnisDas Migrationsverzeichnis, das scan.json enthält.
--dry-runbooleanneinausLiest das Projekt und gibt den Plan aus. Es schreibt nichts und braucht keinen Schlüssel.
--only KINDSstringneinalle vierDurch Kommas getrennt, jeder Wert höchstens einmal: media, playlists, screens, schedules.
--folder IDstringneinein neuer Ordner mit dem Namen Imported from und dem Namen der PlattformEin vorhandener Medienordner (mfd_…) für die importierten Medien.
--canvas WIDTHxHEIGHTstringnein1920x1080Die Leinwand einfacher Playlists, jede Seite mindestens 16 Pixel. Ein Layout behält seine eigene Größe.
--credentials FILEPfadneinkeineDie Schlüsseldatei, die nur gelesen wird, wenn eine Mediendatei von der Plattform heruntergeladen wird.
--concurrency Nintegernein4Gleichzeitig importierte Medien, 1 bis 8.
--no-transcodebooleanneinausLaden Sie die Quelldaten unverändert hoch, wie media upload es tut.
screenrig migrate apply --dry-run
screenrig migrate apply --dir ./screenrig-migration-files
screenrig migrate apply --only media,playlists --concurrency 2

apply importiert der Reihe nach: Medien in einen Ordner, Playlists und Layouts, pro altem Bildschirm einen Wartebildschirm und pro Zeitplan, den Kampagnen ausdrücken können, eine Kampagne. Die Plattform wird nur noch zum Herunterladen von Mediendateien gelesen. Eine Playlist hat pro Element eine Seite: Bilder und Videos füllen die Leinwand, eine Webadresse wird zu einer iframe-Seite, Audio wird zum Soundtrack und eine verschachtelte Playlist wird eingebettet. Ein Layout wird zu einer Playlist auf einer eigenen Leinwand mit einer Seite pro Element seiner Hauptzone. Ein Zeitplan, der sich monatlich, jährlich, stündlich oder minütlich oder an einem nummerierten Wochentag des Monats wiederholt, kann keine Kampagne werden: scan listet ihn in not_imported auf.

--dry-run liest nur das Projekt und antwortet mit data.plan (für media, playlists, layouts, screens und schedules: die Zählungen create, reuse, recreate, waiting und fail), data.items, data.bytes zum Herunterladen, data.placeholders-Zählungen und data.project, die verwendeten Flottenlinks und Kampagnen im Vergleich zu ihren Höchstwerten von 50 und 100. Der Fortschritt geht als JSON-Zeilen an stderr (migrate_progress mit phase, done und total) oder mit --human als Text. Ein erneuter Lauf verwendet wieder, was noch existiert, erstellt alles neu, was Sie gelöscht haben, und ändert nie, was er erstellt hat. Ein echter Lauf antwortet mit data.applied (dieselben Zählungen), data.waiting (Elemente, die auf Medien oder eine nicht importierte Playlist warten, jeweils mit reason), data.failed, data.placeholders (ein Eintrag pro altem Bildschirm mit source_id, name und state: linked, unlinked, paired, finished oder waiting), data.tags und data.folder_id.

Eine Gruppe wird zu einem Tag aus Buchstaben und Ziffern, nummeriert, wenn er mit einem Tag kollidiert, den ein anderer Bildschirm trägt. Eine Kampagne zielt auf die Tags der Gruppen und Bildschirme, die ihr Zeitplan nennt, mit ihren Daten, Tagen, Uhrzeiten und ihrer Priorität. Eine Kampagne liest ihre Daten und Uhrzeiten in der eigenen Zeitzone jedes Bildschirms und braucht eine Standard-Playlist (no_default_playlist): scan vermerkt die Bildschirme, denen sie fehlt, und screen assign setzt sie nach der Kopplung.

Ein Wartebildschirm ist ein Flottenlink für einen Bildschirm, der den alten Namen, die Gruppen als Tags und die Playlist trägt. Eine Organisation enthält höchstens 50 Flottenlinks über alle ihre Projekte; die übrigen sind unlinked in data.placeholders und warten auf einen Player-Code (migrate pair). Ein Player, der einen Link öffnet, wird zu einem Bildschirm, und ein erneuter Lauf von apply gibt ihm den alten Namen und die Zeitzone und löscht den Link. apply gibt nie eine Flottenlink-URL aus: fleet-links show tut es.

Ein fehlschlagendes Element behält ok true mit data.failed (jeweils mit key, name, code, status und detail) und die Warnung migration_items_failed; die Elemente, die davon abhängen, warten, und der Exit-Code folgt dem Status des letzten Fehlers. Eine Mediendatei, die allein fehlschlägt (eine abgelaufene Adresse, eine Antwort, die keine Datei ist, ein Download, der stumm bleibt), lässt nur dieses Medium fehlschlagen; bei einer abgelaufenen Adresse führen Sie migrate scan erneut aus. Eine Ablehnung, die sich für jedes Element wiederholen würde (quota_exceeded, campaign_limit_reached, insufficient_access, pending_review, die Ablehnung des Schlüssels durch die Plattform, eine verlorene Verbindung), beendet den Lauf mit data.stopped (code, detail und next) und dem Exit-Code dieses Problems. Beheben Sie die Ursache und führen Sie denselben Befehl erneut aus: Er setzt dort fort, wo er angehalten hat.

migrate pair#

Koppelt einen Player-Code mit einem Wartebildschirm und übernimmt dessen alten Namen, Playlist, Zeitzone und Tags.

migrate pair <CODE...> --screen ID_OR_NAME [--dir DIR]
ParameterTypErforderlichStandardNotizen
<CODE...>stringjakeineDer Code, den der Player anzeigt, etwa ABC 234: sechs Zeichen aus 23456789ABCDEFGHJKMNPQRSTUVWXYZ, in Groß- oder Kleinschreibung. Leerzeichen und Bindestriche dazwischen werden ignoriert, daher braucht er keine Anführungszeichen.
--screen ID_OR_NAMEstringjakeineDer Wartebildschirm: seine Quell-ID oder sein genauer alter Name. Bei einem Namen, den zwei Bildschirme teilen, werden ihre IDs aufgelistet.
--dir DIRPfadneindas eine ./screenrig-migration-*-VerzeichnisDas Migrationsverzeichnis.
screenrig migrate pair ABC 234 --screen "Front desk"
screenrig migrate pair ABC234 --screen 3 --dir ./old-signage

Führen Sie zuerst migrate apply aus: Die Kopplung braucht die Zuordnung und die Playlist, die dabei entstanden sind. pair beansprucht den Code für den Bildschirm unter seinem alten Namen, setzt seine Playlist, Zeitzone und das Feld migrated_from, setzt seine Tags, löscht den Link des Wartebildschirms und zeichnet das Ergebnis auf. data enthält source_id, name, screen_id, steps (paired, updated, tagged, link deleted, recorded), next und, wenn dieser Lauf den Code beansprucht hat, public_url. Jeder Schritt wird aufgezeichnet, sobald er abgeschlossen ist, sodass ein erneuter Lauf zu Ende bringt, was eine unterbrochene Kopplung offen gelassen hat. Ein bereits gekoppelter Bildschirm ergibt resource_conflict (Exit 5) und nennt ihn. Der Player schließt die Kopplung ab, sobald er das nächste Mal den Dienst kontaktiert; screen show meldet dann state active.

Weitere Befehlsgruppen