Dein EA lädt auf dem Demokonto eine API-Antwort, erhält im Tester aber keine entsprechende Eingabe. Prüfe zuerst die Verfügbarkeit der verwendeten Funktion in dieser Umgebung. Eine fehlende Testfunktion, eine unterbrochene Verbindung, eine abgelehnte Anmeldung und eine gültige Antwort mit fehlendem Datenwert sind verschiedene Zustände. Sie dürfen nicht dieselbe Ersatzentscheidung auslösen.

Warum ein funktionierender WebRequest nicht genügt

Nach der MQL5-Dokumentation kann WebRequest im Strategietester nicht ausgeführt werden. Einen Endpunkt zur Liste erlaubter Terminal-URLs hinzuzufügen, hebt diese Einschränkung nicht auf. Ein gewöhnlicher Online-Aufruf und ein historischer Test brauchen deshalb unterschiedliche Datenwege.

Benötigt eine Regel eine externe Wirtschaftsbeobachtung, darf ein fehlgeschlagener Abruf nicht stillschweigend die Zahl 0 liefern. Null kann ein echter Messwert sein; eine fehlende Antwort bezeichnet unbekannte Information. Eine Datei statt HTTP löst das Problem ebenfalls nicht, wenn sie revidierte Werte enthält, die zum damaligen Entscheidungszeitpunkt noch unbekannt waren. Definiere Beobachtung, Version, Wert, Verfügbarkeitszeit und Verhalten bei fehlenden Daten vor der Signalregel.

Online- und Offline-Adapter trennen

Der Online-Adapter verarbeitet eine Anbieterantwort. Der Testadapter wählt einen archivierten Datensatz aus, der zur Entscheidungszeit verfügbar war. Beide liefern der Entscheidungslogik denselben Ergebnisvertrag: gültiger Wert, ausdrückliche Nichtverfügbarkeit oder Fehler. Diese Aufteilung ist ein vorgeschlagener Entwurf, kein vollständiger Handelsroboter und keine Zusage universeller API-Kompatibilität.

Bewahre Rohantworten getrennt von aufbereiteten Testeingaben auf. Dokumentiere Quelle, Schemaversion, Abrufzeit und Beleg der Verfügbarkeit. Die Periode, auf die sich etwa ein BIP-Wert bezieht, ist keine Veröffentlichungszeit. Kennst du nur einen Vintage-Tag, erfindest du daraus keine genaue UTC-Stunde. Ein tägliches Archiv begründet für sich keine intratägige Verfügbarkeit.

FRED beschreibt Echtzeitperioden für den Unterschied zwischen heute und früher bekanntem Wissen. Das ist ein Beispiel versionierter Daten und keine universelle Forex-API. Für eine intratägige Untersuchung musst du die Chronologie des konkreten Anbieters gesondert klären.

FileOpen arbeitet in einer definierten Datei-Sandbox, beim Testen im entsprechenden Agentenverzeichnis. Ein relativer Pfad verweist daher nicht automatisch auf den normalen Terminalordner. Prüfe Öffnen und Lesen ausdrücklich; eine fehlende Datei darf nicht als leere, vermeintlich vollständige Historie gelten.

Welche Version darf eine frühere Entscheidung verwenden?

Unser fiktives GDP-model hat am 1. Oktober 2026 drei Ereignisse: um 12:00 UTC den Erstwert „1.0“, um 13:00 UTC die Revision „1.4“ und um 14:00 UTC einen Eintrag mit null. Diese Zeiten sind frei definierte Modellannahmen und keine echten BIP-Veröffentlichungen. availableAt bezeichnet die Modellverfügbarkeit, nicht die Ausführungszeit einer Order.

Damals bekannte Version statt heutiger RevisionAlle fiktiven Modellereignisse liegen am 1. Oktober 2026 in UTC. availableAt steuert nur die Eingabeauswahl.RECHEN- UND LERNBEISPIEL12:00 UTC: Erstwert 1.012:30 → 1,013:00 UTC: Revision 1.413:30 → 1,414:00 UTC: null14:30 → nicht verfügbar
Damals bekannte Version statt heutiger Revision. Alle fiktiven Modellereignisse liegen am 1. Oktober 2026 in UTC. availableAt steuert nur die Eingabeauswahl.

Eine spätere Revision ändert den früheren Informationsstand nicht; null bleibt fehlend.

12:00 UTC: Erstwert 1.0
12:30 → 1,0 – 14:30 Uhr in Europe/Berlin an diesem Tag
13:00 UTC: Revision 1.4
13:30 → 1,4 – 15:30 Uhr in Europe/Berlin an diesem Tag
14:00 UTC: null
14:30 → nicht verfügbar – Kein Rückgriff, keine Umwandlung in 0

Um 12:30 UTC wird „1.0“ gewählt, um 13:30 UTC „1.4“. Um 14:30 UTC gilt der jüngste zulässige Eintrag mit null: nicht verfügbar. Unser Modell fällt weder auf „1.4“ zurück noch ersetzt es die Information durch 0. Eine erfundene Regel „Wert größer als 1,2“ wäre um 12:30 falsch. Der Einsatz der späteren 1,4 würde diese Entscheidung umkehren, selbst bei identischen Kursdaten. Das zeigt einen Informationsfehler, keinen Strategieertrag.

Für deutsche Leser: Am gewählten Modelltag entsprechen 12:30 UTC und 13:30 UTC in Europe/Berlin 14:30 beziehungsweise 15:30 Uhr. Das Werkzeug erwartet trotzdem ausdrücklich UTC mit Z. Übertrage diese zweistündige Differenz nicht pauschal auf Wintertage.

Wenn deine Strategie bei fehlenden Neuigkeiten den letzten bekannten Wert behalten soll, definiere eine andere Richtlinie mit zulässigem Alter und begründetem Umgang mit der Lücke. Unsere Variante mit explizitem null implementiert diesen Rückgriff bewusst nicht. Eine nach dem Ergebnis eingeführte Ersatzregel macht aus einem erneuten Lauf keine unveränderte Untersuchung.

Den lokalen Replayer kontrollieren

Füge ein JSON-Objekt mit numerischer version 1 und einem events-Array ein. Jedes Ereignis hat genau availableAt, observation, value und revision. availableAt braucht YYYY-MM-DDTHH:mm:ssZ ohne Nachkommasekunden und ohne andere Offsets. observation und revision sind Text; value ist Zahlentext mit Dezimalpunkt oder null. Obwohl Fließtext „1,4“ schreibt, bleibt der technische Testwert deshalb „1.4“ und wird nicht in Number umgewandelt.

Damals verfügbare Informationen wiedergeben

Das Lehrbeispiel läuft lokal im Browser. Es verbindet sich mit keinem Konto und keiner API, versendet keine Eingaben und speichert sie nicht dauerhaft. Gib keine Passwörter oder personenbezogenen Angaben ein.

Format und Modellgrenzen

version: 1; events: 1 bis 200 Objekte mit genau den Feldern availableAt, observation, value, revision. availableAt: YYYY-MM-DDTHH:mm:ssZ. observation: Text mit bis zu 128 Zeichen; revision: Text mit bis zu 64 Zeichen; value: Zahlentext mit Dezimalpunkt (bis zu 128 Zeichen) oder null. Fehlend ist nicht die Zahl 0.

Ausgewählt wird die letzte Version, deren availableAt nicht nach der Entscheidungszeit liegt. Zwei Einträge mit gleicher observation und gleicher availableAt sind mehrdeutig und blockieren die Analyse. JSON-Grenzen: 64 KiB, 8 Ebenen, 2.000 Werte. Zeiten sind Angaben; die Seite überprüft keine tatsächliche Veröffentlichung.

Der Vertrag erlaubt 1 bis 200 Ereignisse, maximal 64 KiB JSON, acht Ebenen und 2.000 Werte. observation und value dürfen bis zu 128 Zeichen, revision bis zu 64 enthalten. decisionAt gibst du separat im gleichen UTC-Format ein. Ausgewählt wird je Beobachtung die neueste Version mit availableAt ≤ decisionAt. Vor der ersten Version ist nichts verfügbar; genau an der Grenze ist sie verfügbar. Zwei Einträge derselben Beobachtung mit gleicher Verfügbarkeitszeit sind mehrdeutig und werden abgelehnt. Das Revisionslabel ist kein numerischer Zeitfolgezähler.

Die Übung läuft lokal ohne Konto, API-Schlüssel, Datenabruf oder dauerhafte Speicherung deiner Eingaben. Du kannst das Ergebnis als TXT herunterladen. Ohne JavaScript bleiben Rechenbeispiel und Erklärung lesbar. Gültiges JSON belegt aber weder echte Daten noch korrekte Zeitstempel. Wer spätere Revisionen mit dem ursprünglichen Zeitpunkt etikettiert, erhält eine formal richtige Auswahl auf falscher Grundlage.

Eingaben vor dem Handelsresultat prüfen

Verfolge einen Modellwert vor dem Erstereignis, zwischen Erstwert und Revision sowie nach ausdrücklicher Nichtverfügbarkeit. Prüfe zusätzlich die genaue Zeitgrenze und widersprüchliche Einträge. Bewahre für echte Forschung Herkunft und Zeitpräzision auf; nicht archivierte Versionen bleiben eine Einschränkung.

Parallele Testagenten brauchen eine feste Datenkopie. Überschreibe sie nicht während der Untersuchung mit einer aktuellen API-Antwort. Der Laufnachweis unter Backtest-Vergleich bezeichnet den tatsächlich erhaltenen Datensatz, nicht bloß den Endpunktnamen.

Das Python-Backtesting vertieft zeitbasierte Verknüpfungen. Die Auswahl externer Informationen ist von Bid/Ask, Kosten, Mengen und Positionszustand getrennt. Vergleiche zuerst einzelne Entscheidungen ohne Orderausführung. Korrekte Versionsauswahl erklärt Eingaben; sie bestätigt weder realistische Trades noch künftige Profitabilität.

  1. Verfolge im lokalen Replayer einen Modellwert vor dem Erstereignis, zwischen Erstwert und Revision sowie nach ausdrücklicher Nichtverfügbarkeit. Notiere jeweils Entscheidungszeit, verfügbare Version und Ergebnis; das Beispiel 1,0 zu 1,4 prüft Informationsauswahl, ohne daraus ein wirkliches BIP oder profitable Orders zu machen.
  2. Prüfe zusätzlich die genaue Zeitgrenze und widersprüchliche Einträge und bewahre Herkunft sowie Zeitpräzision der echten Daten auf. Dokumentiere eine fehlende archivierte Version als Einschränkung; eine heutige API-Antwort darf nicht unbemerkt die festen Daten eines historischen oder parallel laufenden Tests ersetzen.
  3. Verbinde den Laufnachweis mit dem tatsächlich erhaltenen Datensatz und vergleiche zunächst einzelne Entscheidungen ohne Orderausführung. Prüfe Bid/Ask, Kosten, Mengen und Positionszustand anschließend gesondert; korrekte Versionsauswahl erklärt den damaligen Input, bestätigt aber weder realistische Fills noch die wirtschaftliche Tragfähigkeit der Methode.