iRSI() does not open an order at the end of a time frame

Question

First of all I am pretty new at EA coding, second I have looked for a related post on the MT4 forum itself and on mighty google.

Now I wrote a simple EA to open an order if certain conditions are met, one of which is double RSI_1 = iRSI( NULL, PERIOD_H1, 14, PRICE_CLOSE, 0 ) > 70.

Well, as you can see in the attachment, the order was opened not at the close price of the candle, but higher, according to the picture it should have opened at the next candle on the right.

I would think, according to the documentation, that by using price_close the rsi would get calculated at the close price for the time frame selected, but it doesn't look that way.

What am I missing?

How can I fix it?

Answer 1

Q: What am I missing?

MT4-Terminal, a programmable, client-side trading access-device uses ( for historical reasons ) a time-reversed-indexing of registers, that store actual / historical values { open, high, low, close, volume } for respective time-units ( specific in duration for each TimeFRAME ).

Other values get "derived"/calculated from these cardinal values ( either by "pre-defined" ( implemented ) indicators { iRSI(), iMFI(), ... } or programmatically by your MQL4-code ).

The first common issue is, that time passes... ( obvious..., but surprisingly, there are some artificial side-effects in PriceDOMAIN, that surprisingly originate from TimeDOMAIN, introduced by the historical simplifications for the fastest possible handling of pricing data in real-time, that cause troubles alike your idea stroke into ).

Once aNewBarEVENT appears, a very special case happens ( always )...

Registers open[0] == high[0] == low[0] == close[0] & volume[0] == 1

As the time passes on and via subsequent anFxMarketEVENT arrivals into your MT4-Terminal software both volume[0] > 1 grows & register close[0] gets newer and newer value(s) ( typically other than open[0] )

That mechanism thus "complicates" any decision making bound to "just-present" value of close[0], as the next arrival of anFxMarketEVENT ( a new Ask/Bid prices from Broker ) moves the register value to some other value, than might have been used in previous (milli-)second.

This way your code may have started some activity right in the moment ( a derived ) value of iRSI( ..., PRICE_CLOSE, ... ) was indeed > 70, however during the remaining time till anEndOfBAR the subsequent close[0] prices went in such a direction, that the last value of iRSI() upon "leaving" the Bar was way less than 70 ... ( as you seem to try to depict in your ( cropped w/o scales ) PrintScreen )

The second issue seems with aPriceDOMAIN distance of the markers "above" the candle close[aBarPTR] level.

A LONG trade was entered at a price given by both the Bid == close[0] & Spread, nevertheless the graph shows candle prices as Bid-based prices, so in case the visual distance equals to Spread at the time of XTO ( where Spread value might be of a constant or variable size, depending on your Broker Terms & Conditions ), the position of a LONG trade entry is fair & correct.

A third issue that may be but need not be valid in this case is that MT4-Terminal feature called a Strategy Tester was not quite fair & handy in handling a multi-TimeFRAME calculations during back-testing. Some years ago, our team simply gave up to use in-built functions and started to use our own register-handling so as to maintain our own, independent, multi-TimeFRAME values we could really rely on.

Q: How can I fix it?

Due to the nature of handling the hot-[0]-bar events, your code needs some other filter(s) or additional indicators, that do not lag ( do not add additional latency & skew in time, when a trading decision gets triggered ) and do not get flutter ( repeating triggering during the same bar ).

MQL4 gives some tools for doing that, if in a need to get more, one may resort to additional external facilities ( a fully distributed multi-agent grid/cloud/GPU-based computing ).

So, enjoy the great world of FX/MT4.

All these possibilities are at your fingertips.