Pipsgrowth EX12058 MultiIndicatorConfluence

Pipsgrowth EX12058 ForexSmartBotBridge is not a strategy Expert Advisor in the conventional sense. It is a thin MT5-resident command executor: a permanent listener that sits on the chart, opens a known text file on every tick and timer beat, parses a line of pseudo-MQL4 syntax written there by an external process, and translates that line into a real broker order. The header comment makes the design intent explicit ("File-based bridge EA for MT5 <-> Python communication"), and the 13-function surface area is built entirely around that single workflow. There are no indicator handles, no on-bar calculations, no signal scoring, no regime classifier, and no OnTester block — the strategy logic lives outside the EA, in whatever Python (or other) process is writing the command file, and the EA's job is just to make the broker execute it cleanly.

The listening side is double-redundant. OnTick() throttles a CheckForCommands() call to once every 500 milliseconds via GetTickCount(); OnTimer() — set up in OnInit() with EventSetTimer(1) — does the same with a 1-second gate. Whichever fires first opens the file ForexSmartBot_Command.txt from the MT5 sandboxed MQL5/Files directory using FILE_READ|FILE_TXT|FILE_ANSI, reads the lines, executes each one, then FileDelete()s the file so the next call sees a clean slate. If no line was read on the first pass, the code rewinds to offset 0 and tries once more. This pair of redundant triggers is what makes the bridge feel like a socket to a Python client even though it is literally just disk I/O.

ExecuteCommand() is a hand-rolled mini-dispatch table. The dispatcher keys off StringFind() probes for the substrings "OrderSend", "CloseAll", "GetBalance", "GetPositions", and "GetPrice". OrderSend is the only path that opens a position: it expects a payload of the form OrderSend(SYMBOL,BUY/SELL,QUANTITY,SL=value,TP=value), splits on the left paren to peel the function name off, then StringSplit()s the parameter list on commas. SL and TP are optional and the parser walks the parameter array from index 3 looking for the key=value tokens. If the caller did not supply an SL, the bridge synthesizes one at 2% beyond the entry — price * 0.98 for a buy, price * 1.02 for a sell. If no TP was supplied it synthesizes one at 3% in the favourable direction (price * 1.03 for a buy, price * 0.97 for a sell). All three numbers are NormalizeDouble()'d to the symbol's digit count before being passed to CTrade.

The order execution path goes through a CTrade instance configured at OnInit(): SetExpertMagicNumber(22212058) is fixed (and is the only way the bridge's orders are distinguishable from manual trades on the account), SetDeviationInPoints(30) sets a 30-point slippage tolerance against the IOC filling mode selected via SetTypeFilling(ORDER_FILLING_IOC). The IOC mode is the important choice: in a file-bridge scenario the price in the command is a snapshot from when Python wrote the file, and FOK or IOC is the safer fill mode for stale prices because it does not queue. SubmitOrder() is a parallel programmatic entry point that re-clamps volume to symbolInfo.LotsMin()/LotsMax() and MathFloor(volume/lot_step)*lot_step — a safety net for when the external caller sends an invalid lot size — but the Python-driven path does not use it; the file-bridge path relies on the order being correct upstream.

The SL/TP defaults deserve attention because they are not pips-based — they are price-percent-based. A 2% SL on XAUUSD at $2,000 is $40, on a 5-digit broker that is 400 points. The 3% TP is $60, 600 points. On a 5-digit FX pair at 1.1000, the SL lands at 1.0780 (220 pips) and the TP at 1.1330 (330 pips). This is meaningful: it means a single Python command intended for a gold chart will produce a wildly different dollar risk on a EURUSD chart, and a single command intended for FX will produce a tiny absolute stop on gold. Anyone wiring the bridge to multiple symbols must translate the SL/TP numerics per symbol, not send a raw price.

The non-trading commands are the second half of the contract. GetBalance() writes the AccountInfoDouble(ACCOUNT_BALANCE) value to ForexSmartBot_Balance.txt using FILE_WRITE|FILE_TXT. GetPositions() serializes the live position book as a JSON-ish array (the code uses string concatenation rather than CJSONEncoder, so the output is a string built char-by-char with all positions comma-separated inside a [ ] envelope, each with ticket/symbol/type/side/volume/entry_price/current_price/sl/tp/profit/timestamp fields). GetPrice() writes symbolInfo.Bid() to ForexSmartBot_Price.txt. CloseAll(SYMBOL) walks PositionsTotal() in reverse and routes each ticket through TryClose_EX12058() with the magic filter, optionally sending the literal string "ALL" to flatten everything on the account regardless of symbol.

The closing and modification paths use the same retry wrapper convention as the rest of the EX12 family. TryClose_EX12058(ulong ticket) loops up to 3 times, calls trade.PositionClose(ticket), checks for TRADE_RETCODE_DONE or TRADE_RETCODE_DONE_PARTIAL, and on a transient REQUOTE/TIMEOUT/PRICE_OFF/PRICE_CHANGED retcode it Sleep(200) and retries. TryClosePartial_EX12058 is identical against trade.PositionClosePartial(). TryModify_EX12058 loops 3 times against trade.PositionModify(ticket, sl, tp) with a shorter 100ms Sleep and a smaller retcode set (REQUOTE, TIMEOUT only). These wrappers are used by the bridge's own CloseAll path and also exist for any future caller that wants to wire a modify or partial-close command into the same protocol.

Inputs are minimal because the logic is external. The Connection group has ServerHost="127.0.0.1", ServerPort=5555, and EnableLogging=true — note that the host and port are only echoed in the OnTimer() heartbeat Print() and are not used to open a real socket. The code is explicitly a file-based bridge, not a ZeroMQ bridge, despite the SimulateZeroMQResponse() helper that returns canned JSON for ping/price/balance/equity/symbol_info/historical_data/order/close_all/positions — that function is a stub for a future socket-based variant. The Identity group has MagicNumber=22212058, InpTradeComment="Psgrowth.com Expert_12058", SymbolSuffix="m" (Exness convention), and DefaultSymbols="XAUUSDm,EURUSDm,USDJPYm,GBPUSDm" as the default watch list. The suffix is concatenated onto any symbol the Python caller passes without one, which is what makes the bridge work on Exness's m-suffixed symbol naming.

The order in which Python should drive this EA is straightforward: drop the EA on any chart (the EA does not care about timeframe or symbol — it operates against the symbols passed in the commands), write OrderSend(...) lines into ForexSmartBot_Command.txt, optionally poll ForexSmartBot_Balance.txt, ForexSmartBot_Positions.txt, and ForexSmartBot_Price.txt for state. Because the bridge FileDelete()s the command file after every successful read, a single command per file is the safe pattern — write a line, let the EA consume it, then write the next one. The bridge will sit there idle when the file is missing, so it has no idle CPU cost beyond the GetTickCount() math on each tick.

This is a different category of EA from a trading system. Run a backtest of EX12058 in the MT5 strategy tester and the result will be a flat equity curve with no trades — the tester does not write command files for the EA to consume. The right way to validate it is to run a Python loop in demo, watch the logs, and confirm that the orders it sends match what the bridge executed on the account. The bridge is honest about that: its header makes no claim of strategy logic, and the body of the code is a single-purpose dispatch table.