Multi-timeframesystemen klinken eenvoudig: hogere timeframe voor richting en lagere voor entry. De verborgen moeilijkheid is tijd. Op een lager event kan de hogere candle nog open staan, historiek onvolledig zijn en elke bevestiging naar een andere marktsnapshot verwijzen.
Elf afgeronde records waren expliciet als multi-timeframewerk gemarkeerd. Ze omvatten trendfilters, fractalstructuur, indicatorovereenstemming, custom-timeframelogica, tradebeheer en beslissingsbomen met drie lagen. De gedeelde les was één klok en één definitie van geldige informatie.
Hoe de EA één beslissing neemt
De EA wacht op het afgesproken moment, leest de gekozen candles samen, past de regels in volgorde toe en neemt daarna één geregistreerde beslissing.
- 01Kies het startmomentWacht op het afgesproken event, zoals een nieuwe candle op het lagere timeframe.
- 02Kies de candlesGebruik per timeframe de afgesproken huidige of gesloten candle onder één tijdbeleid.
- 03Lees alles samenMaak één gecombineerd beeld in plaats van waarden uit verschillende momenten te mengen.
- 04Pas regels in volgorde toeControleer richting, setup, trigger, blokkeringen en verval in de afgesproken volgorde.
- 05Beslis eenmaalKeur de actie eenmaal goed of af en registreer daarna inputs en brokerresultaat.
Geef elk timeframe een rol
Een hogere timeframe kan regime, richting, structuur of niveau bepalen. Een middelste laag kan de setup beschrijven en een lagere de trigger. Problemen beginnen wanneer die rollen impliciet blijven of de lagere laag stilzwijgend de hogere overschrijft.
De specificatie benoemt rol en bevoegdheid. Een filter laat toe of blokkeert; een trigger timet een entry maar herdefinieert het regime niet tenzij de methode dat expliciet vraagt.
Leg het barbeleid vast
Bar nul is de open candle; bar één meestal de laatste voltooide candle. Na historiekload of aan een sessiegrens vraagt zelfs dat nuance. Een dagbar gelezen op een uurevent kan uren onveranderd blijven, of heel de dag wijzigen wanneer bar nul wordt gebruikt.
Closed-bar beleid verbetert vaak reproduceerbaarheid. Intrabar kan ook, maar ontwikkeling, backtest en live evaluatie moeten hetzelfde beleid beoordelen.
Bouw één snapshot
Voorwaarden na elkaar lezen zonder snapshot kan subtiele verschillen maken: een tick komt binnen of een indicator herberekent tussen twee reads. Kies daarom eerst het decision event, controleer data en lees elke waarde eenmaal met de bronbartijd.
De log kan dan tonen dat een dagfilter op één tijd gold, de uursetup later ontstond en de lagere trigger pas na verval kwam.
Definieer geheugen en verval
Sommige systemen eisen alle voorwaarden tegelijk. Andere laten een hogere setup gewapend tot een latere lagere trigger. Beide zijn mogelijk, maar geven andere trades.
Een blijvende toestand heeft een maximumleeftijd, reset en invalidatie nodig. Een nieuwe hogere bar moet de setup volgens een vaste regel vernieuwen, annuleren of als nieuwe kans behandelen.
Test tijdsgrenzen
Test vooral de eerste tick van een nieuwe bar, dagrollover, marktopening, zomertijd, weekendgap, ontbrekende historiek en terminalherstart. Daar kan een nette chart een andere livebeslissing verbergen.
Goed bewijs bevat brontimestamps en eenmaal-per-event controles. Het doel is niet winst bewijzen, maar aantonen dat de hiërarchie elke keer hetzelfde wordt geëvalueerd.
- Geef elk timeframe een vaste rol en bevoegdheid.
- Definieer barindex, timezone, update-event en datagereedheid.
- Lees een gesynchroniseerde snapshot en bewaar de tijd van elke toestand.
- Definieer bevestigingsgeheugen, maximumleeftijd, refresh, reset en invalidatie.
- Test bargrenzen, sessiewissels, herstart en ontbrekende historiek.
Vragen die je misschien hebt
Maken meer timeframes een EA veiliger?
Niet vanzelf. Ze kunnen context toevoegen, maar ook vertraging, conflicten en overfitting. Elk timeframe heeft een duidelijke taak nodig.
Moeten alle timeframes gesloten candles gebruiken?
Niet noodzakelijk. Belangrijk is een expliciet en consistent beleid dat in development, backtest en live wordt herhaald.
Waarom de bartijd bij elke toestand bewaren?
Zo is bewijsbaar welke informatie op het beslismoment beschikbaar was en zijn synchronisatiefouten sneller te vinden.
