Eine tägliche Watchlist automatisieren: ein zeitgesteuertes Skript, das Daten abruft, Signale berechnet und einen Bericht schreibt, plus Fallstricke bei API-Schlüsseln und Rate-Limits

Was Sie lernen werden

• Wie Sie Notebook-Zellen zu einem Skript mit Funktionen, einem Einstiegspunkt main() und einer Konfigurationsdatei umbauen.
• Wie Sie API-Schlüssel aus dem Code heraushalten und Rate-Limits mit Wartezeiten und exponentiellem Back-off bewältigen.
• Wie Sie einen Bericht schreiben, der um 07:30 Uhr morgens nützlich ist: eine Ranglistentabelle, einige Hinweise und ein Zeitstempel.
• Wie Sie das Skript mit cron oder der Windows-Aufgabenplanung zeitgesteuert ausführen und was Sie protokollieren sollten, damit stille Fehler nicht unbemerkt bleiben.

Erklärung

Ein Notebook dient dem Erkunden; ein Skript wiederholt jeden Tag dieselbe Aufgabe, ohne dass Sie zusehen. Die Indikatoren (Lektion 6) und die Signallogik (Lektionen 7 und 8) bleiben gleich; alles um sie herum ändert sich.

Aufbau des Skripts

Teilen Sie die Arbeit in Funktionen mit jeweils einer Aufgabe auf: load_config(), fetch(ticker), compute_signals(df), build_report(rows) und main(). Die Absicherung if __name__ == '__main__': main() erlaubt es, die Datei auszuführen und ihre Funktionen zugleich in Tests zu importieren. Halten Sie Watchlist, Parameter und Ausgabeordner in config.yaml oder config.json fest, damit sie sich ändern lassen, ohne den Code zu bearbeiten.

API-Schlüssel und Geheimnisse

Schreiben Sie niemals einen Schlüssel in Quellcode oder in ein Notebook, das Sie weitergeben oder in Git committen könnten. Lesen Sie ihn mit os.environ['DATA_API_KEY'] aus einer Umgebungsvariablen oder einer .env-Datei (das Paket python-dotenv lädt .env) und tragen Sie .env in .gitignore ein. Behandeln Sie den Schlüssel wie ein Passwort und erneuern Sie ihn, falls er bekannt wird.

Rate-Limits, Wiederholungen und Back-off

Ein Rate-Limit ist die maximale Zahl an Anfragen, die ein Anbieter pro Minute oder Tag zulässt; wird es überschritten, kommt ein HTTP-Fehler 429 zurück oder, schlimmer, leere Daten ohne Fehler. Takten Sie die Schleife mit time.sleep(60 / max_per_minute). Bei vorübergehenden Fehlern (429, 500, Zeitüberschreitungen) wiederholen Sie mit exponentiellem Back-off: 1 s warten, 2 s, 4 s, 8 s, dann aufgeben und den Ticker als fehlend protokollieren. Wiederholen Sie niemals in einer engen Schleife; so werden Schlüssel gesperrt.

• def fetch_with_retry(ticker, tries=4, base=1.0):
• for n in range(tries):
• try:
• return fetch(ticker)
• except TransientError as e:
• wait = base * 2 ** n
• log.warning('%s: %s, neuer Versuch in %.0fs', ticker, e, wait)
• time.sleep(wait)
• log.error('%s: Abbruch', ticker)
• return None

Speichern Sie Roh-Downloads zwischen (data/raw/TICKER_YYYY-MM-DD.parquet): Ein zweiter Lauf am selben Tag liest die Datei, statt Kontingent zu verbrauchen, und Sie behalten einen Prüfpfad dessen, was das Skript gesehen hat.

Validierung vor den Signalen

Daten kommen häufiger fehlerhaft an, als Sie erwarten: ein fehlender letzter Balken, ein veraltetes Datum, ein Schlusskurs von 0, ein nicht adjustierter Split. Prüfen Sie, dass das letzte Datum dem erwarteten Handelstag entspricht, dass die letzten 20 Zeilen kein NaN enthalten und dass die heutige absolute Rendite unter einer Plausibilitätsschwelle wie 50 % liegt. Fehler landen in einem Abschnitt „Datenprobleme“ des Berichts, statt aufgrund eines fehlerhaften Kurses ein Kaufsignal zu erzeugen.

Der Bericht

Schreiben Sie eine Markdown- oder HTML-Datei mit dem Zeitstempel des Laufs und dem Datum der Daten, einer nach Ihrem Ranking sortierten Tabelle (zum Beispiel Abstand zum 50-Tage-SMA in ATR-Einheiten), den neuen Signalen seit gestern (verglichen mit der gespeicherten Signaldatei des Vortags) und den Datenproblemen. Speichern Sie ihn als reports/watchlist_2026-10-30.md, damit die Historie erhalten bleibt; Charts pro markiertem Ticker (Lektion 10) sind optional.

Zeitsteuerung und Logging

Unter Linux und macOS führt cron Befehle nach Zeitplan aus: 30 6 * * 1-5 /path/venv/bin/python /path/watchlist.py >> /path/logs/cron.log 2>&1 läuft an Wochentagen um 06:30 Uhr; unter Windows erledigt die Aufgabenplanung dasselbe über einen Dialog. Verwenden Sie den vollständigen Pfad zum Python der virtuellen Umgebung (Lektion 1), denn Scheduler aktivieren keine Umgebungen. Protokollieren Sie mit dem Modul logging in eine Datei: Start, abgerufene Ticker, gefundene Signale, Ende. Fehlt ein Eintrag für heute, ist der Scheduler fehlgeschlagen. Computer gehen in den Ruhezustand, Netzwerke fallen aus, Endpunkte ändern sich; ein Skript, das Sie nicht kontrollieren, ist keine Automatisierung.

Durchgerechnetes Beispiel

Hypothetisches Beispiel: eine Watchlist mit 40 europäischen und US-Aktien, ein kostenloser Datentarif mit einem Limit von 5 Anfragen pro Minute und 500 pro Tag (erfundene Zahlen; prüfen Sie die aktuellen Bedingungen Ihres Anbieters).

1. Taktung. 40 Ticker bei 5 pro Minute = 40 / 5 = mindestens 8 Minuten. Das Skript wartet 12 Sekunden zwischen den Aufrufen. Bei einem Start um 06:30 Uhr liegen die Daten gegen 06:40 Uhr vor.
2. Kontingent. Ein Lauf verbraucht 40 von 500 täglichen Aufrufen (880 im Monat bei 22 Handelstagen). Ein Fehler, der alle 10 Minuten einen neuen Lauf startet, würde 240 Aufrufe pro Stunde verbrauchen und die Obergrenze nach etwa zwei Stunden erreichen; ein Festplatten-Cache beseitigt dieses Risiko.
3. Back-off. Zwei Ticker liefern beim ersten Versuch HTTP 429. Wiederholungen nach 1, 2 und 4 Sekunden gelingen beim zweiten Versuch; die zusätzliche Zeit beträgt im schlimmsten Fall 1 + 2 + 4 + 8 = 15 Sekunden pro Ticker, der Lauf endet also immer noch innerhalb des Budgets von 10 Minuten.
4. Bericht. Regel: „Schlusskurs kreuzt den 50-Tage-SMA nach oben bei einem RSI(14) unter 60“. Die gestrige Datei hatte 3 aktive Signale; der heutige Lauf findet 5, davon 2 neue. Der Bericht listet zuerst die 2 neuen Werte auf, dann die 3 fortbestehenden, und 1 Ticker unter „Datenprobleme“, weil sein letzter Balken zwei Tage alt ist.

Nicht berücksichtigt: Dies sagt nichts darüber aus, ob das Signal profitabel ist; es macht lediglich die tägliche Vorbereitung zuverlässig und wiederholbar.

Häufiger Fehler

Übungsaufgabe

Auf Papier: Ihr Anbieter erlaubt 30 Anfragen pro Minute und 2,000 pro Tag. Sie möchten eine Watchlist mit 150 Tickern einmal um 06:00 Uhr abarbeiten und 20 Prioritäts-Ticker zwischen 09:00 und 17:30 Uhr (MEZ) alle 30 Minuten aktualisieren. (a) Welche Mindestwartezeit zwischen Aufrufen hält das Limit pro Minute ein? (b) Wie viele Aufrufe verbraucht ein ganzer Tag? Liegt das innerhalb des Tageskontingents? (c) Der Lauf um 06:00 Uhr meldet 150 abgerufene Ticker, aber alle Signale sind identisch mit gestern. Nennen Sie zwei Prüfungen, die Ihnen zeigen, ob die Daten aktuell sind.

Kernaussagen

• Skripte brauchen Funktionen, eine Konfigurationsdatei, eine main()-Absicherung und Logging; Notebooks nicht.
• Halten Sie Schlüssel in Umgebungsvariablen oder .env; takten Sie Anfragen passend zum Limit, wiederholen Sie mit exponentiellem Back-off, geben Sie dann auf und protokollieren Sie.
• Validieren Sie Datumsangaben und Zeilenzahlen, bevor Sie Signale berechnen; speichern Sie Roh-Downloads zwischen.
• Planen Sie die Ausführung mit cron oder der Aufgabenplanung unter Verwendung des vollständigen Pfads zum Python der virtuellen Umgebung, und prüfen Sie täglich das Log.

Nächster Schritt

Lektion 13 fügt alles zu einem vollständigen Research-Notebook-Projekt zusammen, von den Daten bis zum Bericht, und prüft es mit einer Checkliste gegen Look-Ahead-Bias und Überanpassung.