Interface Example (Alert Creation / TRALADAL Condition)

TRALADAL interface example screenshot

1) What TRALADAL is and what it is not

https://www.tradingview.com/script/oc2K8Hkq-TradingView-Alert-Adapter-for-AlgoWay
TRALADAL is an open-source TradingView strategy that acts as a universal adapter between indicator signals and automated execution through AlgoWay.

The adapter focuses on three operational goals:

  • Convert indicator outputs into a backtestable strategy, so you can measure win rate, drawdown, and profit factor objectively.
  • Use the same entry/exit logic to produce structured alerts.
  • Embed execution parameters (routing and risk fields) into the alert payload for AlgoWay.

TRALADAL does not generate trading ideas and does not provide “signals” by itself. It evaluates inputs you connect (sources/values) and translates them into consistent strategy actions.

2) High-level architecture

TRALADAL is built around an input source–based model. Instead of hardcoding indicators, it reads values from user-selected input.source fields. This allows the adapter to work with:

  • event outputs (1 / non-zero values, arrows, shape streams),
  • continuous lines (EMA, VWAP, RSI, MACD, custom lines),
  • invite-only or locked indicators (because you only need their plotted/streamed output).

Internally, the strategy uses a three-layer logic model:

  1. Signal — the primary entry trigger (the “reason” to trade).
  2. Confirmation — directional validation (the “permission” to trade).
  3. Filter — noise reduction (the “environment check”).

Each layer can be enabled independently, and layers can be combined using AND / OR logic, allowing multi-indicator systems without writing Pine code.

3) Execution modes

TRALADAL supports two execution philosophies:

3.1 Strategy Mode (Backtest-first)

  • Risk rules (SL/TP/Trailing) are applied inside Strategy Tester.
  • The goal is to measure system quality, not to produce a “live-ready” payload.
  • Alerts can still be emitted, but Strategy Tester becomes the primary truth source.

3.2 Alert Mode (Automation-first)

  • Strategy decisions are converted into a structured alert payload.
  • Risk parameters are embedded into the JSON message and executed by AlgoWay.
  • The goal is consistent live execution across platforms through a unified payload.

4) Signal pipeline (Signal → Confirmation → Filter)

4.1 Core boolean states

TRALADAL reduces your connected indicator outputs into booleans:

  • long_signal and short_signal
  • long_confirm and short_confirm
  • filter_ok (or separate long/short filters)

The adapter then computes final permissions:

final_long_ok  = long_signal  AND/OR long_confirm  AND filter_ok
final_short_ok = short_signal AND/OR short_confirm AND filter_ok
                        

4.2 Recommended combination logic

This section describes recommended patterns you can apply depending on what your indicator outputs represent.

Pattern A — Strict gate (recommended for multi-indicator systems)

  • Signal is a precise trigger (entry arrow / crossover event).
  • Confirmation is a trend permission (EMA slope, MACD sign, higher timeframe regime).
  • Filter is volatility / session / spread safety.
final_long_ok  = SignalLong  AND ConfirmLong AND FilterOK
final_short_ok = SignalShort AND ConfirmShort AND FilterOK
                        

Pattern B — Flexible triggers (when signal is “soft”)

  • Signal is not a strict event, but a condition that can remain true for many bars (e.g., RSI > 50).
  • Confirmation adds specificity (crossover, pivot, structural break).
final_long_ok  = (SignalLong OR ConfirmLong) AND FilterOK
final_short_ok = (SignalShort OR ConfirmShort) AND FilterOK
                        

Pattern C — Layer disabling (minimal setup)

Minimal setup for quick testing:

  • Only Signal is used.
  • Confirmation and Filter are disabled.
final_long_ok  = SignalLong
final_short_ok = SignalShort
                        

Minimal setup is useful for: verifying that you wired the correct sources, confirming that long/short polarity is correct, and validating alert firing frequency.

5) Entry logic — what “entry” means in TRALADAL

5.1 Entry types

TRALADAL can represent entries in two practical forms:

  • Event-based entry — the entry is a single bar trigger (e.g., arrow prints, crossover happens).
  • State-based entry — the entry condition is a persistent state (e.g., RSI > 50 for 20 bars).

5.2 How to avoid repeated entries

If your input sources represent states, you must ensure that the adapter triggers only when the state changes, otherwise you can get repeated alerts on every bar.

Recommended practice:

  • Use event signals whenever possible (crosses, transitions, “1” markers).
  • If your indicator only provides a state, convert it into a transition at the indicator level if possible.
  • If you cannot change the indicator, use strict Confirmation as the “event” layer.

6) Exit logic — the “Task: Flat” concept

6.1 Exit is not always “stop-loss / take-profit”

TRALADAL separates two concepts:

  • Risk exits: SL / TP / Trailing (pips-based).
  • Logic exits: explicit “Flat” signals (neutral state or close trigger).

6.2 Flat triggers (logical close)

A “Flat” task can be triggered by one of these families:

  • Neutral signal — the system becomes neutral and must close open positions.
  • Opposite signal — a reverse triggers close + new entry.
  • Explicit close source — a dedicated close signal line / value from an indicator.

6.3 Exit policies

In automated execution you must choose one clear policy:

Policy 1 — Reverse on opposite signal

  • When a short entry triggers while long is open, close long and open short.
  • Payload typically sends task = sell (and AlgoWay handles the reversal according to webhook mode).

Policy 2 — Flat on neutral, enter on fresh signal

  • When the system goes neutral, close current position.
  • Only open a new position when a new entry trigger fires.

Policy 3 — Flat only (no reverse)

  • Opposite signal does not open a new position immediately.
  • It only closes the current position (risk reduction mode).

Recommended for multi-indicator systems: Policy 2, because it avoids whipsaw flips when two indicators disagree on consecutive bars.

7) Risk parameters (pips) and what they mean

TRALADAL supports risk fields typically used in AlgoWay automation:

  • Stop Loss (pips)
  • Take Profit (pips)
  • Trailing Stop (pips)

7.1 Minimal values

Minimal values depend on:

  • instrument volatility,
  • spread / commission,
  • timeframe and signal frequency.

7.2 Practical recommendations

  • Use SL that is larger than typical spread spikes for the instrument.
  • Use TP that is not smaller than your average excursion, otherwise you clip winners.
  • Use trailing only when your system demonstrates trend persistence; otherwise trailing increases noise exits.

8) Multi-indicator setups — recommended wiring patterns

8.1 Two-indicator classic (Trigger + Trend)

Recommended:

  • Signal: your precise entry trigger (arrow/crossover)
  • Confirmation: trend regime (EMA direction, MACD sign, higher timeframe state)
  • Filter: session/time/volatility guard

8.2 Three-indicator system (Trigger + Trend + Momentum)

Recommended:

  • Signal: breakout / arrow
  • Confirmation: trend filter
  • Filter: momentum confirmation (e.g., histogram sign) OR volatility constraint

8.3 Many indicators at once (avoid “OR soup”)

If you combine many indicators, avoid “OR everywhere”. This creates frequent entries with low quality.

Recommended:

  • Keep Signal as a single primary trigger.
  • Put all “permissions” into Confirmation and combine them with AND.
  • Keep Filter strict and simple (one or two checks max).

9) Alert mechanics — how payload is formed and sent

9.1 TradingView alert type

In the TradingView alert dialog, TRALADAL is designed to be used with:

  • Condition: TRALADAL (strategy)
  • Option: alert() function calls only

9.2 Payload principles

The payload must be:

  • deterministic (same inputs → same JSON),
  • explicit (task must be Buy / Sell / Flat),
  • platform-aware (routing field must exist),
  • risk-aware (SL/TP/Trailing must be included only when enabled).

9.3 Example payload (reference format)

The exact field names must match the TRALADAL code. This is a reference example used in AlgoWay-style routing:

{
  "uuid": "YOUR_WEBHOOK_UUID",
  "platform": "metatrader5",
  "symbol": "{{ticker}}",
  "task": "buy",
  "risk": 1.0,
  "sl_pips": 25,
  "tp_pips": 50,
  "trail_pips": 0,
  "comment": "TRALADAL"
}
                        

IMPORTANT: The “Inputs (Menu)” section below is where each input is mapped to: a) internal strategy variables, b) payload fields, c) recommended ranges. To make it 100% exact, paste the full Pine source code from “Source code”.

10) Inputs (Menu) — Full Technical Reference

This section is intentionally structured as a full “menu-by-menu” reference. Each row explains:

  • the input name as it appears in the script,
  • what it does technically,
  • how it changes the final JSON payload,
  • minimal and recommended values,
  • usage notes for multi-indicator systems.

10.1 AlgoWay Routing & Identification

Input (Menu Name) Type Technical Role Payload Impact Minimal / Recommended
Webhook UUID (placeholder) string Identifies which AlgoWay webhook should receive the alert. This must match the webhook you created in AlgoWay. Sets uuid field in JSON. Minimal: non-empty string.
Recommended: copy/paste exact UUID from AlgoWay dashboard.
Platform (placeholder) enum Selects the destination connector behavior (MT5 / cTrader / TradeLocker / Crypto exchange etc.). Sets platform field in JSON. Minimal: one valid platform value.
Recommended: keep one platform per alert route.
Symbol Mapping / Override (placeholder) string Overrides TradingView ticker with broker/exchange symbol when they differ. Affects symbol field in JSON. Minimal: empty (use TV ticker).
Recommended: set mapping only when required.

10.2 Signal Sources (Primary Entry Triggers)

Input (Menu Name) Type Technical Role Payload Impact Minimal / Recommended
Long Signal Source (placeholder) source The indicator output line/value that defines a bullish trigger. Can be event-based (1) or value-based. Controls when task becomes buy. Minimal: connect to any output that represents long trigger.
Recommended: connect to event output (single-bar trigger).
Short Signal Source (placeholder) source The indicator output line/value that defines a bearish trigger. Controls when task becomes sell. Minimal: connect to any output that represents short trigger.
Recommended: connect to event output (single-bar trigger).
Signal Threshold / Comparator (placeholder) float / enum Defines how source values become a boolean (e.g., > 0, == 1, cross). Changes the timing and frequency of buy/sell tasks. Minimal: keep default comparator.
Recommended: use strict comparators for non-event sources.

10.3 Confirmation (Directional Validation)

Input (Menu Name) Type Technical Role Payload Impact Minimal / Recommended
Enable Confirmation (placeholder) bool Turns on/off the confirmation layer entirely. When OFF, confirmation does not gate task. Minimal: OFF for quick wiring test.
Recommended: ON for live automation.
Long Confirmation Source (placeholder) source A value/line that must validate a bullish entry (trend permission). Gates task=buy in final_long_ok. Minimal: connect to trend sign or slope.
Recommended: higher-timeframe trend permission.
Short Confirmation Source (placeholder) source A value/line that must validate a bearish entry. Gates task=sell in final_short_ok. Minimal: connect to trend sign or slope.
Recommended: higher-timeframe trend permission.
Confirm Combine Logic (placeholder) enum Defines if Signal and Confirmation are combined by AND or OR. Changes when buy/sell is allowed. Minimal: AND.
Recommended: AND (strict gate).

10.4 Filter (Noise Reduction)

Input (Menu Name) Type Technical Role Payload Impact Minimal / Recommended
Enable Filter (placeholder) bool Turns on/off the filter layer entirely. When OFF, filter does not gate tasks. Minimal: OFF for first test.
Recommended: ON for noisy instruments.
Filter Source (placeholder) source A condition input that must be “OK” for entries (volatility/session/spread proxy). Blocks buy/sell tasks when filter fails. Minimal: connect to a stable condition.
Recommended: volatility regime filter.
Filter Comparator (placeholder) float / enum Defines what “filter ok” means (e.g., > 0, == 1). Changes blocking behavior. Minimal: keep default.
Recommended: use strict equality for event filters.

10.5 Risk & Positioning

Input (Menu Name) Type Technical Role Payload Impact Minimal / Recommended
Stop Loss (pips) (placeholder) int/float Defines SL distance in pips for risk exits. Sets sl_pips in JSON when enabled. Minimal: 0 (disabled).
Recommended: instrument-dependent, must exceed spread spikes.
Take Profit (pips) (placeholder) int/float Defines TP distance in pips for risk exits. Sets tp_pips in JSON when enabled. Minimal: 0 (disabled).
Recommended: align to system expectancy.
Trailing (pips) (placeholder) int/float Defines trailing stop in pips. Sets trail_pips in JSON when enabled. Minimal: 0 (disabled).
Recommended: enable only for trend systems.
Risk / Size (placeholder) float / enum Defines sizing rule alignment between strategy and alerts. Sets risk (or size field) in JSON. Minimal: use default strategy sizing.
Recommended: keep consistent with AlgoWay side sizing rules.

10.6 Exit & Flat behavior

Input (Menu Name) Type Technical Role Payload Impact Minimal / Recommended
Enable Flat Task (placeholder) bool Enables explicit flat (close) tasks based on logic exits. Allows task to become flat. Minimal: OFF for entry-only tests.
Recommended: ON for realistic automation.
Close Source (placeholder) source A dedicated input that triggers a close condition. Converts close event into task=flat. Minimal: none (disabled).
Recommended: use if your indicator provides explicit close/exit markers.
Reverse Policy (placeholder) enum Defines how opposite signals are handled (reverse vs flat vs ignore). Changes task emission order and flat behavior. Minimal: reverse.
Recommended: flat-on-neutral, reverse-on-confirmed.

To make every row above 100% exact (names, group labels, defaults, and field mapping), paste the Pine source code from the “Source code” tab. Then this table becomes a literal code-to-documentation mapping, with no placeholders.

11) Practical setup guide (with multiple indicator scenarios)

11.1 Minimal setup (fast validation)

  1. Connect Long Signal Source and Short Signal Source to your indicator outputs.
  2. Disable Confirmation and Filter.
  3. Set SL/TP/Trailing to 0.
  4. Create alert: TRALADAL → alert() function calls only.

11.2 Recommended setup (live automation)

  1. Use strict AND gate: Signal AND Confirmation AND Filter.
  2. Use Confirmation as trend permission.
  3. Use Filter as environment guard.
  4. Enable Flat tasks for correct close behavior.

11.3 If you run several indicators at once

  • Avoid OR across many sources (too many entries).
  • Keep Signal as one “trigger” source.
  • Put additional conditions into Confirmation and Filter (AND).
  • Use Flat-on-neutral to prevent flip spam.

12) Final mapping: Signals → Tasks (Buy / Sell / Flat)

System State Condition Task Emitted Meaning for AlgoWay
Bull Entry final_long_ok becomes true buy Open/maintain long according to webhook mode
Bear Entry final_short_ok becomes true sell Open/maintain short according to webhook mode
Neutral Close close condition or neutral state triggers flat Close position (full close)

13) Next step (to finalize exact Inputs list)

Send the full Pine source code from the TRALADAL “Source code” tab. Then this page will be updated to:

  • list every input with its exact menu name and group,
  • describe the exact internal variables (step-by-step),
  • document the exact JSON field names and formatting logic,
  • explain exact entry/exit evaluation order as implemented in the code.