Automat stáhne údaj na demu, ale v testeru nedostane stejnou odpověď. Nejprve ověřte dostupnost funkce, teprve pak síť a archiv. Dnešní revidovaná hodnota přiřazená starému rozhodnutí není původní znalost. Tento návod odděluje běhové prostředí, historické verze a provedení obchodu; ukázka nevolá skutečné API.

Proč fungující WebRequest nestačí pro backtest

Dokumentace MQL5 uvádí, že WebRequest nelze vykonat ve Strategy Testeru. Přidání adresy mezi povolená URL toto omezení neodstraní. Nezaměňujte nepodporovanou funkci s odmítnutým přihlášením, výpadkem sítě či běžnou odpovědí serveru mimo tester. Zaznamenejte konkrétní prostředí a chybu.

Chybějící externí pozorování nenahrazujte nulou: nula může být platný údaj, zatímco selhání znamená nedostupnost. Ani soubor s dnešní tabulkou historických hodnot nemusí řešit problém. Může obsahovat revize, které v okamžiku rozhodování ještě neexistovaly. Návrh prvního automatu proto rozděluje vstupy, rozhodnutí a realizaci.

Online a offline adaptér mají stejnou datovou smlouvu

Online adaptér zpracuje odpověď poskytovatele, testovací adaptér vybere uchovaný záznam dostupný k danému času. Oba předají rozhodovací logice platnou hodnotu, výslovnou nedostupnost nebo chybu. Je to navržená organizace programu, nikoli kompletní robot kompatibilní s libovolným API. Definujte význam pozorování, verze a času před psaním signálu.

Nezpracované odpovědi archivujte zvlášť od normalizované tabulky. Uchovejte zdroj, schéma, čas stažení a důkaz dostupnosti. Období, které údaj popisuje, není čas zveřejnění. Znáte-li pouze datum historické verze, nevymýšlejte přesnou hodinu UTC. Denní archiv sám nedokáže, co bylo známo uvnitř daného dne.

FRED rozlišuje informace dostupné dnes a informace známé v dřívějším období. Jde o příklad verzovaných ekonomických údajů, nikoli univerzální forexové API s přesnými intradenními časy každé publikace. MQL5 FileOpen pracuje v určeném souborovém prostoru; relativní cesta v testeru nemusí označovat běžnou složku terminálu. Ověřte úspěch otevření i čtení, nejen existenci názvu souboru.

Kterou verzi smí použít dřívější rozhodnutí

Vlastní historie tří odpovědí

Fiktivní GDP-model dne 1. října 2026 má všechny časy UTC. Nejde o skutečné zveřejnění HDP ani záznam konkrétního endpointu. availableAt určuje dostupnost v modelu, nikoli čas plnění pokynu. Revize nepřepíše znalost předchozího rozhodnutí.

Na malé obrazovce posouvejte tabulku vodorovně, abyste přečetli všechny sloupce.

Deklarované dostupné verze
availableAtrevisionvalue
2026-10-01T12:00:00Zinitial"1.0"
2026-10-01T13:00:00Zrevised"1.4"
2026-10-01T14:00:00Zunavailablenull

Pozdější verze není dřívější znalost

Revize mění pozdější, nikoli dřívější vstupFiktivní GDP-model dne 1. října 2026, všechny časy UTC. Vybíráme poslední způsobilý záznam, bez návratu před null.MODELOVÝ VÝPOČET12:00 initial: "1.0"12:30 → 1.013:00 revised: "1.4"13:30 → 1.414:00 unavailable: null14:30 → nedostupné
Revize mění pozdější, nikoli dřívější vstup. Fiktivní GDP-model dne 1. října 2026, všechny časy UTC. Vybíráme poslední způsobilý záznam, bez návratu před null.

Časová podmínka je availableAt ≤ decisionAt. Deklarované časy musí mít samostatný důkaz původu.

12:00 initial: "1.0"
12:30 → 1.0 – Ještě neznáme revizi ze 13:00.
13:00 revised: "1.4"
13:30 → 1.4 – Nová verze je již způsobilá.
14:00 unavailable: null
14:30 → nedostupné – Nevkládáme nulu ani starší 1.4.

Ve 12:30 vybereme 1.0, ve 13:30 hodnotu 1.4 a ve 14:30 výslovně nedostupný stav. Nevracíme se automaticky k předchozí 1.4 a nevytváříme nulu. Hypotetická podmínka hodnota nad 1.2 je ve 12:30 nepravdivá; podstrčená pozdější revize by rozhodnutí obrátila při stejných cenách. Nástroj sám však nepočítá signál ani výnos.

Pokud strategie záměrně používá poslední známou hodnotu, určete zvláštní pravidlo včetně dovoleného stáří a příčiny absence. Tato varianta s null takový návrat neprovádí. Změnu politiky po zhlédnutí lepšího výsledku nesmíte označit za nezměněný test. Backtest musí mít popsané i zacházení s chybějícími vstupy.

Co přesně zkontroluje místní přehrávač

Vložte JSON objekt s číselným version: 1 a polem events. Každá událost má právě availableAt, observation, value a revision. Čas vyžaduje YYYY-MM-DDTHH:mm:ssZ bez zlomků sekund a jiného offsetu. observation je řetězec do 128 znaků, revision do 64; value je číselný text s desetinnou tečkou do 128 znaků nebo null, bez převodu na Number.

Přehrání tehdy dostupných informací

Náš studijní příklad běží místně v prohlížeči: nepřipojuje se k účtu ani API, neodesílá vstupy a trvale je neukládá. Nezadávejte hesla ani osobní údaje.

Formát a omezení modelu

version: 1; events: 1–200 objektů s přesně těmito poli availableAt, observation, value, revision. availableAt: YYYY-MM-DDTHH:mm:ssZ. observation: textový řetězec do 128 znaků; revision: textový řetězec do 64 znaků; value: číslo jako text s desetinnou tečkou (nejvýše 128 znaků), nebo null. Chybějící hodnota není nula.

Vybere se poslední verze, jejíž availableAt není pozdější než okamžik rozhodnutí. Dva záznamy se stejnými observation a availableAt jsou nejednoznačné a blokují analýzu. JSON: 64 KiB, 8 úrovní, 2000 hodnot. Časy jsou deklarace: stránka neověří skutečný čas zveřejnění.

Rozsah je 1–200 událostí, JSON do 64 KiB, hloubka osm úrovní a nejvýše 2 000 hodnot. Samostatný decisionAt používá stejný UTC formát. Vybírá se poslední verze stejného pozorování s availableAt nejpozději v okamžiku rozhodnutí, tedy i přesně na hranici. Před první verzí není hodnota dostupná. Dva záznamy se shodným observation a availableAt jsou nejednoznačné a blokují analýzu; pořadí vložení je nerozhodne. Štítek revision není číselné pořadové číslo.

Ukázka běží v prohlížeči nad vloženými daty, nepřipojuje účet ani API, nepřenáší zadání a trvale je neukládá. Nevkládejte hesla či osobní údaje. Platný JSON nepotvrzuje pravost archivu ani skutečný čas vydání. I správný výběr reprodukuje chybná data, pokud dnešní revizi opatříte časem původní publikace. Při souběžných bězích používejte neměnnou kopii a v záznamu běhu identifikujte skutečný dataset, ne pouze endpoint.

Nový samostatný CZK model: předpokládejme další pozorování EURCZK-model. Původní hodnota 25.00 je dostupná ve 12:00, revize 25.20 ve 13:00, obě téhož smyšleného dne v UTC. Pro rozpočet 10 000 EUR ve 12:30 dává tehdy známý údaj 250 000 Kč; revize by dala 252 000 Kč, rozdíl 2 000 Kč. Není to realizovatelná kotace ani zisk. Hodnota 25.20 přiřazená rozhodnutí ve 12:30 je časový únik, nikoli lepší směna.

Ve 13:00 už model revizi připouští. Zpozdí-li se skutečné získání dat, musí vaše smlouva dostupnosti toto zpoždění zohlednit; samotný přehrávač je neodhadne. Platné tržní ceny, komise, objem a reakce serveru patří do jiné vrstvy. Pythonový backtest rozvíjí časové spojování, kalendář pak revize a původ oznámení.

Postup před hodnocením výsledků automatu

  1. Určete datovou smlouvu a oddělte online od offline adaptéru. Chybějící historické verze výslovně označte; dnešní odpověď není archiv dřívější znalosti.
  2. Projděte jednu událost před prvním vydáním, mezi vydáním a revizí i po null. Zkontrolujte přesnou hranici času a konfliktní shodné časy.
  3. Ověřte čtený soubor v testeru, uchovejte jeho verzi s reportem a porovnejte vybrané záznamy. Potom samostatně prověřte signály, provedení a náklady bez pokusných živých obchodů.