Signal Logic

The service trades the Pine Reversal signal (file.txt Section 11) — the labels that read Buy Chance / Sell Chance. The Supertrend ▲/▼ entry (Section 5) is ported and tested but does not fire an order unless _InstrumentPipeline is switched back to SupertrendSignalStrategy in code.

Reversal — Buy Chance / Sell Chance


rev_src = rsi(close, REVERSAL_SENSITIVITY)      # 14
BUY  ("Buy Chance")  = crossover (rev_src, REVERSAL_OVERSOLD)    # 25
SELL ("Sell Chance") = crossunder(rev_src, REVERSAL_OVERBOUGHT)  # 75

Side	Chart label	Condition
BUY	Buy Chance	RSI crosses up through oversold (25)
SELL	Sell Chance	RSI crosses down through overbought (75)

rev_src is Wilder’s RSI — the Pine builds it from ta.rma of the up/down changes rather than calling ta.rsi, with guards so an all-gains window reports 100 and all-losses reports 0.

Crossing is the trigger, not the level. RSI merely sitting below 25 produces nothing; it has to cross back up through it.

Service defaults: REVERSAL_SENSITIVITY=14, REVERSAL_OVERSOLD=25, REVERSAL_OVERBOUGHT=75, TARGET_TF_MINUTES=5.

On TradingView, these labels are gated behind enableReversal, which ships false. Tick Reversal Signal under IPDA Settings to see what the service trades — see Pine Script.

Exits (hard targets only)

RSI yields no price level, so there is no indicator-derived stop. USE_HARD_TARGETS must stay true — the service refuses to start otherwise. SL/TP are fixed pip distances (STOP_LOSS_PIPS=40, TAKE_PROFIT_PIPS=50 on forex) sent as distances to mt5-trader. RISK_REWARD is inert. See Hard Targets.

Supertrend port (not live)


supertrend(close, sensitivity=5.5, atrLen=11)
sma = ta.sma(close, 13)
BUY  = crossover(close, supertrend)  and close >= sma
SELL = crossunder(close, supertrend) and close <= sma

SUPERTREND_* and SMA_LEN sit at the Pine defaults and are unused unless the strategy class is switched in service.py. That path can still use absolute Supertrend stops when hard targets are off — the live reversal path cannot.

Opposite-direction signals

There is no flip logic. If a position is open and the opposite signal fires, the service submits a new market order and lets the broker decide: a hedging account holds both, a netting account offsets. Nothing is closed first.

No confluence

Unlike LuxAlgo, IPDA does not gate entries with overlays or vetoes. An RSI cross is the full trigger — then the session gate decides whether to execute or only notify.

Mid-candle policy: fire once, then lock

A signal can appear on any poll while a target candle is still forming and may change before it closes (repainting). This service:

Emits the first signal seen for a bucket
Then locks that bucket — at most one entry per target candle

TradingView’s alert uses alert.freq_once_per_bar_close, so it only confirms at the close. A label that appears two minutes into a 5M bar and disappears before the bar closes still produces a live trade here.


TARGET_TF bucket (5 minutes)
│
├─ poll t=0:00  forming bar ── no signal
├─ poll t=0:15  forming bar ── BUY fires  ──▶ lock bucket, session check, submit or notify
├─ poll t=0:30  forming bar ── would flip? ── ignored (locked)
└─ poll t=0:45  … until next bucket (:05)

Keep POLL_INTERVAL_SECONDS < 60s so mid-candle firing can occur within the forming bar.

Mid-candle fire-once-lock means a signal that would have disappeared by bar close still gets submitted (when in session). Expect divergence vs a chart that only marks closed-bar signals.

Deterministic `signal_id` (UUIDv5)

The signal_id is a deterministic UUIDv5 of (symbol, bucket start, direction), keyed as ipda:{symbol}:{bucket}:{direction}.

A transport retry replays idempotently against mt5-trader instead of creating a duplicate or a 409 idempotency_conflict.