Drei Städte, drei Datenquellen, eine Frage: Wann muss ich los?

In jeder meiner drei Wohnungen stellt sich dieselbe Frage: Wann muss ich los?

Gebaut habe ich die Antwort dreimal — zuerst in Meran, dann in Kapfenberg, zuletzt in Wien. Jedes Mal nach demselben Vorbild, jedes Mal mit einer anderen Datenquelle, und jedes Mal ist mir an einer anderen Stelle ein Fehler unterlaufen.

Die Fehler sind der interessante Teil, weil sie sich nicht wiederholt haben. Sie sind gewandert.

Dreimal dieselbe Idee, dreimal andere Technik

	Gebaut	Quelle
Meran	09.08.2026	Südtirolmobil, EFA-Schnittstelle
Kapfenberg	30.08.2026	Verbundlinie Steiermark, dieselbe EFA-Schnittstelle
Wien	06.09.2026	offene Echtzeitdaten der Wiener Linien, eigenes Format

Zwei Standorte teilen sich ein Protokoll, der dritte nicht. Das ist der Normalfall in Österreich und Italien: Es gibt kein gemeinsames Format, aber es gibt zwei große Lager — und wenn man Glück hat, fällt der zweite Standort ins selbe.

Kapfenberg war deshalb in einem Nachmittag fertig. Wien brauchte einen Neubau.

Die eine Idee, die den Unterschied macht

Alle drei Monitore haben eine Eigenschaft, die man in keinem Haltestellenaushang findet: Sie kennen den Fußweg.

Jeder Sensor weiß, wie lange man zu seiner Haltestelle braucht, und nimmt Abfahrten, die näher liegen, gar nicht erst in die Liste auf.

Ein Zug, der in 8 Minuten geht, während man 15 Minuten zum Bahnhof braucht, ist keine Information, sondern eine Falle.

Das klingt klein und ändert alles. Ein gewöhnlicher Abfahrtsmonitor zeigt die nächste Abfahrt. Ein nützlicher zeigt die nächste erreichbare.

Wo die Zeit steht, ist eine Entscheidung

Der Fußweg steckt im Sensor, nicht in der Anzeige. Damit gilt er für jede Karte und jede spätere Automatik gleich, und es gibt genau eine Stelle zum Ändern.

Die Karten schreiben den Wert nur noch in die Überschrift — und lesen ihn dafür aus dem Sensor aus. So kann die Beschriftung nicht von der Filterung abweichen. Ein Monitor, der „15 Minuten Fußweg“ in der Überschrift stehen hat und nach 10 filtert, ist schlimmer als keiner.

Und eine Folge, die ich nicht bedacht hatte

Am Bahnhof blieben von 18 abgefragten Bussen nach dem Filter nur drei übrig. Dort fährt in der ersten Viertelstunde schlicht viel weg.

Die Abfragegrenzen mussten deutlich hoch — bis 34 Abfahrten bei einer Haltestelle. Wer den Fußweg verlängert, muss sie mitziehen, sonst leert sich die Karte. Das ist kein Fehler des Filters, sondern seine logische Folge.

Drei Fallen in den Templates

Alle drei haben mich Zeit gekostet, und alle drei sind unsichtbar: Die Konfigurationsprüfung läuft sauber durch.

Erstens: Variablen werden nicht verfolgt. Der erste Entwurf baute die Liste in einem Variablenblock und las sie nur über den Namen. Prüfung sauber, Rohdaten voll — und die Sensoren blieben dauerhaft leer. Home Assistant leitet die Auslöser für eine Neuberechnung aus den Entitäten ab, die im Zustand selbst vorkommen. Steht der Zugriff nur in einer Variablen, kennt der Sensor keine Quelle und rechnet nie neu. Die Schleife gehört direkt in den Zustand — auch wenn man sie dadurch zweimal schreibt.

Zweitens: die Quelle sortiert nach Fahrplan, nicht nach Echtzeit. An einem Abend stand ein Bus mit drei Minuten Verspätung vor dem pünktlichen, der zur selben Minute fuhr. Tatsächlich fuhr der pünktliche zuerst. Die Sensoren sortieren deshalb selbst — nach dem Feld, das die Verspätung schon enthält.

Drittens: Zahlen kommen als Zeichenketten. Eine Sortierung danach ergibt "1" < "12" < "4". Erst in eine Zahl wandeln, dann sortieren.

Und ein Nachtrag, der nicht in die Dreierliste passte, aber dieselbe Sorte ist: Attribute müssen Zeichenketten sein. Ein numerischer Wert wurde stillschweigend verworfen — die Prüfung lief durch, das Attribut fehlte einfach im Zustand.

Der Fehler, den ich zweimal gemacht habe

Jetzt der eine, der tatsächlich gewandert ist.

In Wien hatte ich aus einer Messung geschlossen, die Quelle liefere höchstens etwa fünf Abfahrten je Linie. Das stand in der Doku und im Kopf des Dashboards.

Falsch. Am nächsten Mittag nachgemessen:

	je Linie und Richtung	Reichweite
Nacht, 15-Minuten-Takt	3–5	—
Mittag, 7-Minuten-Takt	7	bis etwa eine Stunde voraus

Über elf Linien gemessen: immer höchstens sieben, und immer etwa eine Stunde weit. Die Grenze ist nicht die Anzahl, sondern das Zeitfenster. Bei einem 15-Minuten-Takt passen in eine Stunde eben nur vier.

Ich hatte nachts gemessen — und damit das Nachtfenster.

Derselbe Fehler war mir in Kapfenberg schon unterlaufen, wo ich an einem Sonntag den Sonntagsfahrplan gemessen und für den Normalfall gehalten hatte. Und wieder fiel es erst auf, als jemand zu einer anderen Tageszeit hinsah.

Die Lehre ist unbequem, weil sie Geduld verlangt: Eine Messung an einem Verkehrsnetz ist erst dann eine Messung, wenn sie zu mehreren Tageszeiten stattgefunden hat. Alles andere ist eine Momentaufnahme, die wie ein Befund aussieht.

Der Hase

Auf allen drei Dashboards läuft ein kleiner Hase. Er springt jede Minute eine Zeile weiter, quer über alle Karten.

Er hat genau einen Zweck: Er zeigt, dass die Anzeige noch lebt. Ein eingefrorener Abfahrtsmonitor sieht aus wie ein funktionierender — die Zeiten stehen ja da. Erst wenn sich nichts mehr bewegt, merkt man es, und dann hat man den Bus verpasst.

Zweimal falsch gerechnet

In Kapfenberg verteilt er sich auf 24 feste Plätze: vier Karten zu je sechs Zeilen. Das setzt voraus, dass jede Karte immer sechs Zeilen hat.

In Wien hat sie das nicht. Eine Karte kam in der ersten Nacht auf eine einzige Zeile.

Erster Versuch: zweistufig — erst die Karte wählen, dann die Zeile innerhalb ihrer Länge. Das löst das Längenproblem und fällt auf die Nase, sobald eine Karte leer ist:

  Haltestelle · Linie (7 min Fußweg)
  nichts mehr erreichbar

Hasen: 0

Der Hase war rechnerisch auf der Karte, die gerade nichts anzuzeigen hatte. Auf dem ganzen Dashboard war keiner.

Derselbe Denkfehler wie in Kapfenberg, nur eine Ebene höher: eine Karte auswählen, ohne zu wissen, ob sie etwas anzuzeigen hat.

Und wie er aufgefallen ist

Das ist der Teil, den ich mir gemerkt habe.

Aufgefallen ist es nur, weil beim Rendern gezählt wurde — eine Zeile, die ausgibt, wie viele Hasen auf dem Dashboard stehen.

Angesehen hätte man es nicht. Ein fehlender Hase sieht aus wie ein Hase, der gerade woanders ist.

Die Lösung ist jetzt eine Rechnung über alle Karten zusammen: Jede Karte liest die Längen aller Listen und legt die Plätze aneinander. Damit landet der Hase immer dort, wo tatsächlich eine Zeile steht.

Was ich dir rate

1. Filtere nach dem Fußweg, nicht nach der Uhrzeit. Die nächste Abfahrt ist selten die, die du brauchst. Die Zeit gehört in den Sensor, nicht in die Beschriftung.
2. Miss zu mehreren Tageszeiten. Jede Verkehrsschnittstelle verhält sich nachts anders als mittags, sonntags anders als werktags. Ich bin zweimal darauf hereingefallen.
3. Sortiere selbst. Wenn die Quelle nach Fahrplan sortiert, steht der verspätete Bus vor dem pünktlichen. Das Feld mit der Echtzeit ist das richtige.
4. Bau ein Lebenszeichen ein. Irgendetwas, das sich sichtbar bewegt. Ein Dashboard mit eingefrorenen Zahlen ist gefährlicher als ein leeres.
5. Und zähl, was du renderst. Ein Fehler, der nur beim Hinsehen auffallen würde, fällt nicht auf.

Und was heißt das?

Dreimal dasselbe zu bauen klingt nach Verschwendung. Es war das Gegenteil: Der zweite Bau dauerte einen Nachmittag, weil das Protokoll dasselbe war. Der dritte brauchte eine neue Quelle, aber alle Entscheidungen standen schon — Fußwegfilter, eigene Sortierung, Lebenszeichen.

Was sich nicht übertragen ließ, waren die Annahmen. Jede Stadt hat ihr eigenes Verhalten, und genau dort, wo ich aus dem einen Ort auf den anderen geschlossen habe, lag der Fehler.

Die Idee ist übertragbar. Die Messung nicht.