Vom Prototyp zu HIVE: was ich beim zweiten Versuch anders gemacht habe

Vor gut einem Jahr habe ich hier beschrieben, wie ich für Floorball Köniz Bern den LED-Screen in der Halle mit Live-Daten bespiele: Spielstand, Aufstellungen, Torschützen, Sponsoren. Damals war das ein funktionierender Prototyp, und ich war ziemlich zufrieden mit mir.

Dann lief dieses System zwei Saisons lang produktiv — 24/25 und 25/26, jedes Heimspiel. Und zwei Saisons Dauerbetrieb sind ein anderer Lehrer als ein gelungener Testabend. Sie zeigen dir nicht, ob deine Idee funktioniert. Sie zeigen dir, was sie dich jede Woche kostet.

Im Frühling habe ich das Ganze deshalb neu gebaut. Das Ergebnis heisst HIVE und hat seine Premiere im Herbst, wenn die neue Saison startet.

Dieser Artikel ist weniger eine Produktvorstellung als eine Liste von Dingen, die ich dabei gelernt habe. Einige davon sind mir peinlich, weil sie im Rückblick offensichtlich wirken. Genau die haben mich am meisten weitergebracht.

Kurz zur Orientierung

Damit die Beispiele einzuordnen sind, hier das Grundgerüst. HIVE besteht aus vier Teilen, die einen Spieltag von der Datenquelle bis auf den Screen tragen:

Swiss-Unihockey-API
        │
        ▼
  hive.beee.live            ◄──  Vereinsinhalte (Fotos, Sponsoren, Videos)
  Das Herzstück: sammelt, veredelt, liefert
        │
        ▼
  Companion-Modul           ◄──  Stream Deck (die Tasten des Bedieners)
  Der Dirigent: sagt, was wann läuft
        │
        ▼
  Template-Engine im Browser
  Die Bühne: über 20 animierte Anzeigemodule
        │
        ▼
      OBS  ──►  LED-Screen in der Halle

Dazu kommt seitlich HIVE Scorepad: eine kleine App, die das Anzeigepult am Zeitnehmertisch anzapft und Spielstand, Uhr und Strafzeiten weitergibt.

Version 1 hatte dieselbe Grundidee, aber andere Bausteine: vMix als Ausgabesoftware, eine selbst gebaute Zwischenschicht auf Kirby CMS und Bitfocus Companion als Steuerpult. Was dazwischen liegt, sind die folgenden sechs Lektionen.

Lektion 1: Eine Schnittstelle ist ein Rohstoff, kein Produkt

Diese hatte ich schon 2025 formuliert, und sie hat sich seither nur bestätigt — also fange ich mit ihr an.

Swiss Unihockey stellt eine öffentliche Schnittstelle bereit, über die alle Spielpläne, Resultate, Aufstellungen und Tabellen abrufbar sind. Das ist grossartig, und mein erster Reflex war: dann ist der grösste Teil der Arbeit ja schon getan.

War er nicht. Eine solche Schnittstelle ist gebaut, um Daten korrekt herauszugeben, nicht um sie anzuzeigen. Sie weiss nichts über den Kurznamen und die Farben des Vereins, nichts über die Sponsoren, nichts über die Starting 6 und nichts über den Staff. Und weil das Hauptaugenmerk der Vereine auf dem Hub liegt, pflegen längst nicht alle ihre Daten dort zuverlässig — womit die Vereine faktisch zwei Datenquellen aktuell halten müssen.

Die eigentliche Arbeit liegt deshalb in der Zwischenschicht: einer eigenen Webanwendung, die die Ligadaten holt, als eigene Struktur ablegt und dann im Browser mit Vereinsinhalten anreichern lässt. Erst am Ende gibt sie alles wieder aus — diesmal in genau der Form, die ein Spieltag braucht.

Was ich mitnehme: Wenn ich künftig abschätze, wie lange ein Projekt mit einer fremden Datenquelle dauert, zähle ich die Anbindung nicht mehr als Aufwand. Der Aufwand ist die Übersetzung von „korrekt" nach „brauchbar".

Lektion 2: Die Kosten liegen nicht im Bauen, sondern im Ändern

Das war die unangenehmste Erkenntnis der zwei Saisons.

In Version 1 lebten die Grafiken in der Ausgabesoftware. Wer eine Farbe, eine Schrift oder ein Layout ändern wollte, klickte sich durch Dialoge. Eine neue Anzeigeart bedeutete einen halben Abend.

Beim Bauen fällt das nicht auf — man baut es ja nur einmal. Auffällig wird es beim zwanzigsten Mal: wenn ein Verein sein Logo anpasst, wenn eine Zahl zwei Stellen mehr braucht, wenn jemand mitten in der Saison eine neue Anzeige will. Jede Änderung kostete etwa so viel wie die erste. Es gab keine Lernkurve, weil es nichts zu lernen gab — es war jedes Mal dieselbe Klickarbeit.

Heute ist jedes Anzeigemodul eine einzelne Datei, die drei Dinge mitbringt: ihr Aussehen, eine Anleitung, wie sie Daten einsetzt, und eine Choreografie fürs Ein- und Ausblenden. Ganz normale Webtechnik, animiert mit GSAP, auf einer Fläche von 1920 × 1080 Pixeln — also genau ein Full-HD-Bild, das OBS als Browserfenster einliest.

Der Unterschied ist grösser, als er klingt. Ein neues Modul ist jetzt eine neue Datei, kein Umbau am System. Aktuell sind es über zwanzig: Gameday-Ankündigung, Teamvergleich, Direktbegegnungen, Topscorer, Aufstellung, Starting Six, Tabelle, Schiedsrichter, Torschütze samt Assistgeber, Strafen, Zuschauerzahl, Penaltyschiessen, Bestplayer, Spielerprofil mit Statistik, Resultat, nächste Heimspiele, Match-Sponsor, eigene Videos und Bilder, Scoreboard.

Was ich mitnehme: Bei der Wahl einer Technologie frage ich inzwischen nicht mehr „wie schnell komme ich damit zum ersten Ergebnis", sondern „was kostet die fünfzigste Änderung". Das sind zwei völlig verschiedene Fragen, und ich hatte jahrelang nur die erste gestellt.

Lektion 3: Grosse Datenmengen brauchen eine Warteschlange, nicht mehr Geduld

Eine Liga mit allen Teams, allen Spielen und allen Spielerprofilen bedeutet einige hundert Abfragen. Mein erster Versuch war der naive: alles in einem Durchgang abarbeiten.

Das Ergebnis war eine Zeitüberschreitung. Der Server bricht mitten in der Arbeit ab und lässt einen halb gefüllten Datenstand zurück. Mein Reflex war, das Zeitlimit hochzuschrauben — was das Problem nur nach hinten verschiebt, bis es beim nächsten Wachstum wieder auftaucht. Und das Unangenehmste: ein halb gefüllter Datenstand sieht auf den ersten Blick in Ordnung aus. Es fällt am Spieltag auf.

Die Lösung ist eine Warteschlange. Der Sync läuft in zwei Phasen. In der ersten holt das System die grossen Brocken — Teams und Spielpläne — und schreibt für jedes einzelne Spielerprofil eine Notiz in eine Warteliste. In der zweiten Phase arbeitet ein Hintergrundprozess diese Liste in Häppchen von zehn Aufträgen ab, immer wieder, bis sie leer ist. Scheitert ein Auftrag, wird er bis zu dreimal neu versucht und danach als fehlerhaft markiert — statt den ganzen Durchlauf mitzunehmen.

Statt zu versuchen, das ganze Buffet in einem Bissen zu essen, gibt es also einen Kellner, der Teller für Teller bringt. Die vollständige Aktualisierung dauert damit ein paar Minuten statt Sekunden. Aber sie läuft durch, nachts, unbeobachtet.

Was ich mitnehme: Ein Prozess, der langsam ist und Fehler einzeln behandelt, ist einem schnellen, der gelegentlich komplett scheitert, immer vorzuziehen. Und: „Limit erhöhen" ist keine Lösung, sondern eine Vertagung.

Lektion 4: Baue das Testwerkzeug zuerst

Diese Lektion hat mich am meisten Zeit gekostet, bevor ich sie verstanden habe.

In der Halle steht ein Anzeigepult von Bodet, mit dem das Zeitnehmerteam Spielzeit, Spielstand, Perioden, Timeouts und Strafen bedient. Es kann seine Daten übers Netzwerk senden — aber in einem eigenen Protokoll, roh, byteweise. Steuerzeichen für Anfang und Ende einer Nachricht, eine Prüfsumme, und einzelne Bits, aus denen hervorgeht, ob gerade eine Zweiminuten- oder eine Zehnminutenstrafe läuft.

So etwas versteht man nicht am Schreibtisch. Man braucht ein laufendes Spiel. Und ein laufendes Spiel gibt es alle zwei Wochen für neunzig Minuten, in einer Halle voller Menschen, die nicht darauf warten, dass ich etwas ausprobiere.

Ich habe erst eine Weile versucht, live zu debuggen. Das war der Fehler. Was tatsächlich funktioniert hat: die App kann den Datenstrom eines echten Spiels mitschneiden und später wieder abspielen. Ein Spiel wird zu einer Datei, und diese Datei läuft am Küchentisch.

Fast alles, was ich heute über dieses Protokoll weiss, kommt aus solchen Mitschnitten — nicht aus Dokumentation. Und dieses Feature, das man auf keinem Screen je sieht, hätte ich besser als erstes gebaut statt als drittes.

Was ich mitnehme: Wenn die Realität nur selten und unter Stress zugänglich ist, ist das Werkzeug, das sie einfängt, kein Nebenprodukt. Es ist die Voraussetzung. Ich frage mich bei neuen Projekten inzwischen früh: wie komme ich an einen wiederholbaren Ausschnitt der Wirklichkeit?

Lektion 5: Saubere Daten wollen plötzlich an mehrere Orte

Diese Lektion habe ich nicht erarbeitet — sie ist mir passiert.

Ich hatte die Pult-Anbindung für den Hallenscreen gebaut. Einen weiteren Nutzen zieht daraus auch jemand anderes: das Livestream-Team.

Wer ein Spiel streamt, zeigt im Bild ebenfalls Spielstand und Spielzeit. Bisher führte das Stream-Team diese Werte selbst, in seiner eigenen Software, von Hand — parallel zum Zeitnehmertisch. Und weil zwei Menschen zwei Uhren nie gleich starten und stoppen, lief die Uhr im Stream nach jedem Unterbruch neben der Hallenzeit. Also nachkorrigieren: bei jeder Strafe, bei jedem Drittelsende, bei jedem Timeout.

Dass dieselben Daten, die ich schon aufbereitet hatte, dieses Problem nebenbei lösen, ist mir erst im Gespräch aufgefallen. Heute gehen sie gleichzeitig an den Hallenscreen und an die Streaming-Software, direkt in deren Grafiken. Eine Quelle, das Pult. Halle und Stream zeigen zwangsläufig dasselbe.

Was ich mitnehme: Sobald Daten einmal saubergemacht sind, entstehen Verwendungen, die im Pflichtenheft nicht vorkamen. Das ist ein Argument dafür, die Aufbereitung als eigene Schicht zu bauen und nicht in die Anzeige zu verdrahten — und ein Argument dafür, mit den Leuten zu reden, die am selben Abend im selben Gebäude ein ähnliches Problem haben.

Lektion 6: Bedienbarkeit ist das Feature, das ein Werkzeug zum System macht

Und hier die Lektion, die eigentlich über allen anderen steht.

Zwei Saisons lang war der grösste Schwachpunkt meines Systems nicht der Code. Es war ich. Das meiste Wissen steckte in meinem Kopf: welche Reihenfolge, welcher Klick, was zu tun ist, wenn etwas hängt. Wenn ich an einem Heimspiel nicht in der Halle war, war der Screen im besten Fall halb bespielt.

Das ist mir lange als Kompliment durchgegangen — „ohne mich läuft's nicht" fühlt sich schmeichelhaft an. Es ist aber einfach ein Designfehler.

Der Neubau hat deshalb eine Bedienung bekommen, die nichts erklärt, sondern zeigt. Zwischen Mensch und Grafiken sitzt ein selbst geschriebenes Modul für Bitfocus Companion, die Software, mit der sich ein Stream Deck steuern lässt — dieses Kästchen mit den beleuchteten Tasten. Der Bediener sieht keine Konsole, sondern beschriftete Tasten.

Und das Modul tut mehr, als Befehle weiterzuleiten. Es holt die Spieldaten und legt sie als Variablen ab, sodass eine Taste nicht „Spieler 7" heisst, sondern den Namen des Spielers trägt, der heute die Nummer 7 hat. Es färbt die Tasten in die Vereinsfarbe des Gegners, samt automatisch berechneter Schriftfarbe, damit die Beschriftung auf hellem wie dunklem Hintergrund lesbar bleibt. Es meldet während eines Videos zurück, wie viele Sekunden noch laufen. Und es überwacht den Ordner mit den Grafiken, sodass sich eine Anzeige beim Entwickeln von selbst neu lädt — was die Arbeit pro Modul spürbar verkürzt hat.

Was ich mitnehme: Der Punkt, an dem aus einem Werkzeug ein System wird, ist nicht die schönste Anzeige. Es ist der Moment, in dem jemand anderes einen Spieltag fahren kann, ohne mich anzurufen. Diesen Punkt hätte ich zwei Jahre früher zum Ziel machen sollen.

Die Meta-Lektion: wann ein Neubau gerechtfertigt ist

Ich baue nicht gern neu. Ein Neubau ist Arbeit, die von aussen wie Stillstand aussieht: monatelang entsteht etwas, das am Ende dasselbe kann wie vorher.

Zwei Saisons haben mir das Kriterium geliefert, das ich vorher nicht hatte. Es ist nicht „der Code ist unschön" — das ist er immer. Es ist: jede Änderung kostet so viel wie die erste. Wenn die Kosten pro Änderung nicht sinken, ist die Struktur falsch, und kein Fleiss holt das auf. Genau da war ich.

Umgekehrt hätte ich früher nicht neu bauen sollen. Die zwei Saisons Betrieb sind der Grund, warum ich diesmal wusste, was zu bauen ist. Der Prototyp war kein Fehler — er war die Recherche.

Was noch offen ist

Ehrlichkeitshalber: HIVE hat seine Premiere noch vor sich. Ein Teil ist erprobt — die Pult-Anbindung lief in der Saison 25/26 an den Heimspielen mit. Der Rest ist gebaut, getestet und noch nie unter dem Druck einer vollen Halle gelaufen.

Ich rechne damit, dass die Saison mir eine siebte Lektion beibringt, die in diesem Artikel fehlt. Wenn es so weit ist, schreibe ich sie auf.

Und jetzt

Der eigentliche Unterschied zu vor einem Jahr ist nicht die Technik, sondern der Charakter der Sache. HIVE ist keine Lösung für einen Verein mehr, sondern ein System, das für andere einrichtbar ist: Ligadaten kommen automatisch, Vereinsinhalte werden im Browser verwaltet, Anzeigen lassen sich auf das Design des Vereins bringen, und wer ein Bodet-Pult in der Halle hat, bekommt Spielstand und Uhr automatisch dazu — auf den Screen und in den Stream.

Floorball Köniz Bern ist der Verein, mit dem alles entstanden ist; zwei Spielzeiten Live-Betrieb stecken in dem, was jetzt startet. Wenn du in einem Verein bist, der seinen Hallenscreen ernst nehmen will: hive.beee.live, oder schreib mir direkt.

Entwickelt von YOLU — Jonathan Hess