Demo-Flüge von echten Flügen unterscheiden

Demo-Flüge von echten Flügen unterscheiden

Jemand geht am Display vorbei und sagt, die Flüge sähen falsch aus, erfunden, oder genau wie gestern. Dieser Artikel zeigt euch, wie ihr belegt, ob auf dem Bildschirm wirklich Demo-Daten laufen, nennt die fünf Situationen, die dazu führen, und geht – genauso wichtig – die Symptome durch, die nach Demo-Daten aussehen, aber ganz andere Ursachen haben. Die meisten Meldungen, die uns erreichen, gehören zur zweiten Sorte.

Fangt mit dem Test an, er dauert eine Minute und klärt die Frage. Alles danach setzt voraus, dass ihr die Antwort schon kennt.

Der einzige verlässliche Test

Das Display holt seine Flüge von /api/flights/<hotelId>, und diese Antwort sagt unmissverständlich, welche Art von Daten sie enthält. Öffnet die Display-URL an einem beliebigen Rechner, drückt F12, wechselt auf den Reiter Network, filtert nach flights, ladet die Seite neu und klickt die Anfrage an. Schaut im Antwort-Body auf die Felder der obersten Ebene:

Zwei Dinge an dieser Anfrage führen euch in die Irre, wenn euch niemand warnt. Erstens schlägt sie nie fehl. Selbst wenn das Display bis auf Demo-Flüge zurückfällt, antwortet die Route mit HTTP 200 und success: true – ihr werdet also nie eine rote Zeile im Network-Tab sehen. Der Rückfall ist von außen unsichtbar, solange ihr den Body nicht lest. Zweitens werden die Meldungen, die den Rückfall protokollieren, auf dem Server geschrieben und nicht im Browser: Der Reiter Console hilft bei dieser Frage nicht weiter.

Warum die Flüge selbst nichts verraten

Der naheliegende Reflex ist, nach dem zu urteilen, was auf dem Display steht. Das funktioniert hier nicht, und es lohnt sich zu wissen, warum – bevor ihr zwanzig Minuten damit verbringt.

Die Demo-Flüge sind bewusst überzeugend gebaut. Sie tragen echte Airlines und echt wirkende Nummern – OS 501 bei Austrian Airlines, LH 1234 bei Lufthansa, LX 456 bei Swiss, W6 2345 bei Wizz Air – samt Terminal, Gate und Gepäckband. Eine Flugnummer ist deshalb der denkbar schlechteste Anhaltspunkt.

Auch ihre Zeiten stehen nicht fest. Jeder Demo-Flug wird im Moment der Anfrage frisch gegen die aktuelle Uhr erzeugt, ein Abflug liegt also immer fünfundzwanzig oder fünfunddreißig Minuten in der Zukunft, egal wann ihr hinschaut. Eingefroren wirkt das Display ihretwegen nie. Auch die Status sind gemischt: Manche sind planmäßig, einer ist mit fünfzehn Minuten Verspätung in der Luft, und auf einer Ankunftstafel sind einige schon gelandet. Es gibt keine verräterische Reihe identischer pünktlicher Einträge.

Der Zeitstempel Zuletzt aktualisiert in der Fußzeile taugt als Beweis genauso wenig. Er wird gesetzt, sobald eine Antwort eintrifft – unabhängig davon, was in dieser Antwort stand.

Was Demo-Flüge tatsächlich auslöst

Es gibt genau fünf Fälle. Nichts anderes im Produkt schaltet das Display auf Demo-Daten.

Achtet darauf, was nicht auf dieser Liste steht. Die Flug-Route liest euren Abonnementstatus nie. Ein abgelaufenes, gekündigtes oder überfälliges Abonnement schaltet das Display nicht auf Demo-Flüge um, und eine offene Rechnung zu bezahlen ändert nichts an dem, was der Bildschirm zeigt. Der Abonnementstatus steuert den Zugang zu Funktionen – zusätzliche Folien, Wetter, Analysen, Branding – und die öffentliche API, nicht die Flugtafel.

Das gelbe Abzeichen Demo-Modus in der Display-Fußzeile hängt an demo: true und erscheint deshalb ausschließlich auf dem demo-Display. In den vier Fällen, die euch wirklich hierher führen, trägt der Bildschirm überhaupt keine Kennzeichnung. Sein Fehlen beweist nichts – nehmt stattdessen den Network-Test.

Symptome, die keine Demo-Daten sind

Wenn die Antwort echte Daten meldet und das Display trotzdem falsch aussieht, liegt es meist an einem dieser Punkte.

Die Flüge sind echt, aber alt. Wenn der Aufruf beim Flugdatenanbieter scheitert – abgelaufener Schlüssel, Störung beim Anbieter, Zeitüberschreitung –, springt das System nicht sofort auf Demo-Daten. Es liefert zuerst das letzte erfolgreiche Ergebnis aus, das bis zu vierundzwanzig Stunden vorgehalten wird. Das Display zeigt also weiter echte Flüge eines echten Flughafens, nur zunehmend veraltet. Deshalb verhält sich ein *ungültiger* API-Schlüssel anders als ein *fehlender*: Ein fehlender Schlüssel bringt euch sofort Demo-Flüge, ein falscher dagegen die echten Flüge von gestern, bis der Cache leerläuft.

Das Display scheint sich nicht zu aktualisieren. Wie oft Flugdaten neu geholt werden, hängt vom Tarif ab: sechzig Minuten bei Basic, dreißig bei Pro, fünf bei Premium. Ein Konto ohne erkannten Tarif bekommt sechzig Minuten. Bei Basic ist eine Stunde ohne sichtbare Änderung genau das, was der Tarif vorsieht – und mit Abstand der häufigste Grund, warum jemand annimmt, der Bildschirm hänge auf vorgefertigten Daten fest.

Der Flughafen ist falsch, die Flüge aber echt. Wenn für ein Hotel kein Flughafen konfiguriert ist, fällt das Display nicht auf Demo-Daten zurück – es fällt auf Wien zurück und holt echte Wiener Abflüge. Gäste, die Flüge zu Flughäfen melden, zu denen im Haus niemand fliegt, sehen meistens genau das. Flughäfen liegen unter Portal → Flughäfen, wo euer Tarif einen enthält und weitere hinzugebucht werden können; welcher davon auf einem bestimmten Bildschirm läuft, wählt ihr im Display-Editor unter Flughafen und Zeit.

Der Bildschirm zeigt die Einstellungen eines anderen Bildschirms. Flughafen, Hotelname und Layout werden inzwischen pro Bildschirm konfiguriert, und die Display-URL trägt den zugehörigen Bildschirm als ?display=<displayId> mit. Öffnet ihr /display/<hotelId> ohne diesen Parameter, lädt das Display denjenigen aktiven Bildschirm, der zuletzt konfiguriert wurde – echte Flüge, in sich korrekt, aber vom Flughafen des falschen Bildschirms. Kopiert die URL aus dem Portal, statt sie abzutippen: Portal → Displays hat in jeder Zeile ein Kopiersymbol, und Portal → Displays → Bildschirm öffnen → Vorschau & URL zeigt dieselbe Adresse im Feld Display-URL. Ist eine eigene Domain verifiziert, lautet diese Adresse einfach https://<eure-domain>.

Das Display ist leer statt falsch. Ein Bildschirm, den ihr mit dem Ein/Aus-Symbol in seiner Zeile unter Portal → Displays abgeschaltet habt, liefert eine leere Tafel mit dem Kennzeichen inactive: true. Mit dem Datenweg ist alles in Ordnung – der Bildschirm ist aus.

Schaut ins Portal, bevor ihr zum Bildschirm lauft

Portal → Displays beantwortet die Frage „zeigt dieser Bildschirm überhaupt etwas Aktuelles“ schneller als jedes Browser-Werkzeug. Jeder Bildschirm trägt einen Status: Läuft, Offline, Nie geöffnet für einen, der im Portal existiert, dessen URL aber noch nie auf einem Gerät geladen wurde, und Ausgeschaltet für einen, den ihr deaktiviert habt.

Diese Angaben beruhen auf einem Lebenszeichen, das der Bildschirm alle fünf Minuten sendet, und ein Bildschirm gilt erst nach zwölf Minuten Stille als offline. Der Abstand ist Absicht – zwei ausgefallene Signale plus etwas Luft –, weil sonst eine einzelne verlorene Anfrage beim Neuladen oder ein kurzer Netzwerkaussetzer einen völlig gesunden Lobby-Bildschirm als ausgefallen melden würde. Umgekehrt heißt das: Ein Bildschirm, den ihr gerade ausgesteckt habt, steht noch ein paar Minuten auf Läuft.

Die Abrechnung sitzt nicht mehr in der Seitenleiste, sondern im Menü hinter eurem Profilbild unter Abrechnung; dort steht auch der Abonnementstatus. Die Seite hat eine einzige Schaltfläche Abonnement verwalten, die euch ins Stripe-Kundenportal übergibt, wo Verlängerungen, Kündigungen und Kartenwechsel stattfinden. Das lohnt sich, wenn euer Abonnement wirklich Aufmerksamkeit braucht – erwartet nur nicht, dass sich dadurch die Flugtafel ändert.

Selbst gehostete Instanzen

Zwei Umgebungsvariablen entscheiden, ob echte Flüge überhaupt möglich sind. AVIATIONSTACK_API_KEY ist die Zugangskennung für den Flugdatenanbieter; ohne sie liefert jede Anfrage Demo-Flüge. POSTGRES_URL wird noch früher geprüft: Ist keine Datenbank konfiguriert, liefert die Route Demo-Flüge, bevor sie euer Hotel überhaupt nachschlägt.

Der Flugdatenanbieter wird vom Server aufgerufen, nicht vom Bildschirm. Ein Display-Gerät im Hotelnetz muss nur lobbyflight.com über Port 443 erreichen; es spricht nie mit api.aviationstack.com, und es gibt keinen Grund, dafür etwas zu öffnen. Ausgehender Zugriff auf den Anbieter wird dort gebraucht, wo die Anwendung läuft, und dieser Aufruf geht über einfaches HTTP auf Port 80.

Noch etwas fürs Selbst-Hosten: Fehlt STRIPE_SECRET_KEY, behandelt die Funktionsprüfung jede Funktion als verfügbar. Lokal ist das bequem – und verwirrend, sobald ihr die Tarifgrenzen eines Kunden nachstellen wollt.

Prüfen, ob echte Daten auch stimmen

Sobald die Antwort echte Daten ausweist, bleibt die Frage, ob sie zur Wirklichkeit passen. Öffnet die offizielle Website des Flughafens, auf den der Bildschirm eingestellt ist, und vergleicht die Flugnummern mit dem Display. Sie stammen aus dem Echtzeit-Feed des Anbieters und sollten übereinstimmen. Stimmen die Nummern, aber die Zeiten nicht, liegt es an einer Zeitzone und nicht an der Datenquelle.

Nächste Schritte