WeatherStar 4000+: Ein 90er-Jahre-Wetterlook auf Basis der NOAA-API

Eine Nachschöpfung, keine perfekte Emulation

WeatherStar 4000+ ist eine webbasierte Projekt, das den Look der lokalen Wettervorhersage des Weather Channel aus den 1990er Jahren zurückbringen möchte, mit blauen und orangen Grafiken und einem ähnlichen Ablauf. Die README stellt klar, dass dies keine perfekte Emulation der WeatherStar-4000-Hardware ist, die diese Grafiken damals erzeugte; sie verweist für eine genauere Nachbildung auf den WS4000 Simulator. Stattdessen legt das Projekt Wert auf eine einfache Oberfläche mit möglichst wenig Konfigurationsaufwand und ändert einige Bildschirme, weil die heutigen Vorhersagedaten mehr oder weniger Informationen enthalten als die Version aus den 90ern. Der Autor nennt als Motivation Nostalgie und sein Interesse an Wetter, besonders an schweren Stürmen; das Projekt ist auch ein kreatives Ventil und hält seine Programmierfähigkeiten für den Beruf fit. Eine Live-Version läuft unter https://weatherstar.netbymatt.com. Das Repository wurde im August 2020 aus der Arbeit von Mike Battaglia geforkt; die README würdigt in den Danksagungen dessen Beitrag, einschließlich der Wetteranzeigen und Hintergrundgrafiken.

Eine Codebasis zum Lernen

Das Repository ist bewusst Open Source, kommentiert und so library-arm wie möglich gehalten, damit Leute, die Programmierung lernen, direkt einsteigen können. Es verwendet die REST-API von api.weather.gov, ES6-Funktionen wie Pfeilfunktionen, Promises, async/await, Klassen und JavaScript-Module; async/await wird für das parallele Laden aller Vorhersageressourcen genutzt. API-Code und UI-Code sind getrennt, die Datumsanalyse übernimmt die Bibliothek luxon, und es gibt praktisches Caching für API-Raten und statische Assets. Das HTML ist handgeschrieben, CSS wird mit SASS verwaltet, und eine Linting-Bibliothek hält den Codestil konsistent. Gulp und Webpack reduzieren über die Build-Integration die Anzahl der Skripte, die der Browser laden muss. Die README präsentiert diese Entscheidungen als Beispiel dafür, wie verbreitete Internet-Technologien zusammenarbeiten, nicht als Empfehlung für einen bestimmten Produktionsstack.

Schnellstart und Ausführungsmodi

Der Schnellstart setzt voraus, dass Node installiert ist. Die dokumentierten Befehle sind git clone https://github.com/netbymatt/ws4kp.git, cd ws4kp, npm install und npm start; danach öffnet man http://localhost:8080. Der Entwicklungsmodus liefert einzelne JavaScript-Moduldateien aus, was das Debuggen erleichtert. Für den Produktionsmodus muss man erst npm run build ausführen und dann mit DIST=1 npm start minimierte und zusammengeführte Bundles ausliefern. Die Umgebungsvariable STATIC=1 deaktiviert den Node-Proxy-Cache: STATIC=1 npm start startet den Entwicklungsserver ohne Cache, und STATIC=1 DIST=1 npm start simuliert die statische Docker-Bereitstellung. Bei Docker gibt es ghcr.io/netbymatt/ws4kp für statische Bereitstellung und ein Dockerfile.server für die Serverbereitstellung. Die README nennt keine konkreten Leistungszahlen oder Antwortzeiten für diese Modi.

Serverbereitstellung gegenüber statischer Bereitstellung

Zwei Bereitstellungsmodi sind dokumentiert. Die Serverbereitstellung umfasst einen Node.js-Server mit Caching-Proxy, serverseitiger Deduplizierung von Anfragen und Caching sowie Beobachtbarkeit und Logging für die Wetter-API; sie wird von npm start, DIST=1 npm start und Dockerfile.server verwendet. Die statische Bereitstellung ist rein clientseitig: nginx liefert statische Dateien aus, und jeder Browser sendet API-Anfragen direkt an die Wetterdienste. Das Caching übernimmt der Browser; diese Variante wird bei statischem Hosting und dem Standard-Dockerfile eingesetzt. Die statische Bereitstellung ist im Betrieb leichter, verlagert aber den gesamten API-Verkehr auf jeden Client. Wenn mehrere Clients auf einen lokalen Server zugreifen, empfiehlt die README die Serverbereitstellung. Sie sagt nicht, dass die statische Variante schneller ist, sondern beschreibt nur die unterschiedlichen Einsatzbereiche.

Änderungen gegenüber der Originalhardware

Die README listet mehrere bewusste Änderungen auf. Das Radar zeigt jetzt den Zeitstempel des Bildes. Ein neues stündliches Diagramm zeigt Temperatur, Bewölkung und Niederschlagswahrscheinlichkeit für die nächsten 36 Stunden. Eine stündliche Vorhersage für die nächsten 24 Stunden ist im Stil der Reisevorhersage verfügbar, standardmäßig aber deaktiviert, weil sie das stündliche Diagramm dupliziert. Der SPC-Outlook-Bildschirm zeigt die Wahrscheinlichkeit schweren Wetters für die nächsten drei Tage und erscheint nur, wenn sich der Standort innerhalb eines hervorgehobenen Risikobereichs befindet. Lokale und erweiterte Vorhersagen enthalten mehr Tage als das ursprüngliche Format. Die ursprüngliche, urheberrechtlich geschützte Musik wurde durch KI-generierte Tracks ersetzt, die im Repository enthalten sind; weitere Tracks liegen im Begleit-Repository ws4kp-music. Die Meeresvorhersage und die ursprüngliche flavors-Reihenfolge fehlen; die Reihenfolge der Anzeigen ist fest, und einzelne Bildschirme lassen sich über Kontrollkästchen ein- und ausschalten. Die Reisevorhersage ist standardmäßig aus, damit neue Benutzer zuerst lokale Informationen sehen.

Permalinks, Kioskmodus und Standardumgebungen

Ausgewählte Anzeigen, die Vorhersagestadt und die Breitbild-Einstellung bleiben zwischen Sitzungen erhalten. Auf der Seite gibt es Copy Permalink oder Get Permalink, um eine URL mit allen ausgewählten Anzeigen und dem Standort zu erzeugen, die man teilen oder als Lesezeichen speichern kann. Ausgelassene Einstellungen fallen auf Standardwerte zurück. Ein Kontrollkästchen für den Kioskmodus füllt den Viewport, ohne den echten Vollbild- oder Kioskmodus des Browsers zu aktivieren; innerhalb der Seite gibt es keinen Weg, diese Ansicht zu verlassen, erst das Neuladen der Seite führt zurück. Der Kioskmodus lässt sich auch durch Anhängen von &kiosk=true an einen Permalink starten. Für den integrierten Express-Server können Umgebungsvariablen mit dem Präfix WSQS_ verwendet werden, um Standard-Query-Parameter zu setzen; zum Beispiel entspricht travel-checkbox=true aus einem Permalink der Umgebungsvariable WSQS_travel=true. Docker liest diese Variablen beim Start und erzeugt eine Redirect-HTML-Seite. Das Einstellungsfeld umfasst Abspielgeschwindigkeit, Standard- oder Breitbildmodus, Hochformat-Enhanced (als in Arbeit beschrieben), Scanlines, Einheiten und Lautstärke.

Musik, Anpassung und Betriebshinweise

Die Hintergrundmusik ist standardmäßig stummgeschaltet, aber die App versucht, sie abzuspielen, wenn sie beim letzten Besuch aktiviert wurde; die Autoplay-Richtlinien der Browser gelten weiterhin, und die README verlinkt die Dokumentation von Chrome und Firefox. Sie nennt außerdem die Query-Parameter mediaPlaying und mediaVolume, um Wiedergabestatus und Lautstärke vorab zu setzen. Im Express-Servermodus scannt der Server das Verzeichnis ./server/music nach .mp3-Dateien und erstellt playlist.json. Beim statischen Hosting fällt die Wiedergabe auf eine Verzeichnissuche zurück, wenn playlist.json fehlt; die nginx-Konfiguration setzt dabei einen X-Weatherstar-Header. Custom Hooks liegen unter server/scripts/custom.js und custom.mjs, mit einer Beispieldatei, die umbenannt werden muss. Mit aktivierter RSS-Textfunktion lässt sich im unteren blauen Balken eigener Text scrollen; mehrere Zeichenketten können mit einem Pipe-Zeichen getrennt werden. Die README sammelt Community-Links zu FFmpeg-Streaming, einem Raspberry-Pi-Setup und Channels-DVR-Integration. Der Autor bittet darum, Ausfälle von api.weather.gov nicht als Issue zu melden, und weist darauf hin, dass die Umrechnung in metrische Einheiten nicht für alle Textprodukte gilt. Der Haftungsausschluss sagt, die Seite solle bei lebensbedrohlichem Wetter nicht verwendet werden. Die Android-Wrapper-App befindet sich in einer geschlossenen Beta; eine iOS-native App gibt es nicht, weil der Autor keine Apple-Geräte besitzt. Die Lizenz ist MIT und erlaubt Nutzung, Kopie, Modifikation und Verbreitung unter Bedingungen, sagt aber über Support, Garantie oder Eignung nichts über den Standard-Haftungsausschluss hinaus.

Redaktionelles Fazit

WeatherStar 4000+ ist ein Nostalgieprojekt, das ehrlich sagt, dass es eine Nachschöpfung und keine Reproduktion ist. Der Quellcode ist an die nur in den USA verfügbare NOAA-API gebunden, dokumentiert zwei Bereitstellungspfade und lässt über Permalinks, Custom Hooks und ausgetauschte Musikdateien Raum für Anpassungen. Es erhebt keinen Anspruch auf Genauigkeit oder Sicherheit: Die README sagt ausdrücklich, die Seite nicht bei lebensbedrohlichem Wetter zu verwenden, und die MIT-Lizenz stellt die Software ohne Gewähr bereit.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository