← Chat Archive

Here's a comprehensive overview of your **LT 3-Candle Renko VIDYA Trading Bot**: --- ## What It Is A **trend-following options bot** for **LT (Larsen & Toubro)** futures that trades ATM options using a 2-candle breakout setup, guided by a daily VIDYA-based bias. It runs as a systemd service (`lt_3candle_bot.service`) on your VPS. --- ## Core Strategy ### 1. Daily Bias (VIDYA) - At **9:15 AM market open**, compares LT futures price against **VIDYA** (computed from 5-brick close-based Renko on daily OHLC) - **GREEN** (price > VIDYA) → look for **CALL** entries - **RED** (price < VIDYA) → look for **PUT** entries - Bias is **fixed for the entire day** — no mid-day flip ### 2. Entry Signal (2-Candle Setup) - Monitors **15-min candles** built from 5-min data - **GREEN bias**: Tracks candle-1's low. If candle-2 closes without breaking below it → **BUY ATM CALL** - **RED bias**: Tracks candle-1's high. If candle-2 closes without breaking above it → **BUY ATM PUT** - If a break happens, the breaking candle becomes the new candle-1 (rolling window) ### 3. Exit Triggers | Trigger | Check Frequency | Condition | |---------|----------------|-----------| | **2-candle level break** | Every 15-min close | Price closes below/above the SL level | | **₹1000 loss** | Every 2-min poll | Option premium loss ≥ ₹1000 | | **Trailing SL** | Every 2-min poll | Once profit ≥ ₹1600, exit if profit falls by ₹800 from peak | | **EOD squareoff** | 15:15 Fridays | Force-close before weekend | --- ## Key Parameters | Parameter | Value | |-----------|-------| | Symbol | LT26MAY26FUT (NFO) | | Lot size | 175 | | Strike step | 20 points | | Order type | LIMIT (BUY at LTP+5, SELL at LTP-5) | | Product | NRML (carries overnight, Mon-Thu) | | Max position | 2 lots | | Max orders | 2 per direction per 3-hour window | | Windows | W1: 9:15–12:15, W2: 12:15–15:30 | | Poll interval | 2 minutes | --- ## Dual Broker Setup | Broker | Role | |--------|------| | **Kotak** | Live trading — quotes, orders, positions | | **Flattrade** | Historical data — daily OHLC + 5-min intraday candles | > This split exists because Kotak lacks a candle history API. Flattrade feeds all Renko/VIDYA and 15-min candle data. --- ## Data Flow Architecture ``` Flattrade → 5-min candles → SQLite DB → build 15-min candles → 2-candle window logic ↓ Kotak ←—————— orders/positions/quotes ←—— entry/exit decisions ``` - **Local SQLite DB** (`lt_3candle.db`) stores 5-min and 15-min candles - Incremental fetch — only new 5-min candles are pulled each poll - Stale feed detection: alerts if no new candles for 20+ minutes --- ## Safety Features 1. **Broker position check** before every order — max 2 lots hard enforced 2. **Orphan position detection** — alerts if broker has positions bot doesn't know about 3. **Exit failure protocol** — 2 retries, then hedges with opposite ATM option 4. **Overnight position resume** — verifies broker position at next market open 5. **Candle feed health checks** — BOD seed empty alert + stale feed alert --- ## State Persistence - **State file**: `state/lt_3candle_state.json` — position, bias, window counters, 2-candle tracking - **Candle DB**: `lt_3candle.db` — all historical candles - On restart: replays stored 15-min candles to restore window state, verifies positions with broker --- ## Telegram Alerts Sends formatted alerts for: entry, exit (with P&L), skipped setups, trailing SL activation, exit failures, orphan positions, stale feeds, and errors. --- ## Files in the Bot Directory | File | Purpose | |------|---------| | `lt_3candle_bot.py` | Main bot (1,069 lines) | | `lt_3candle_eod.py` | EOD VIDYA computation + DB init | | `backtest.py` | Backtesting engine | | `fetch_historical_candles.py` | Historical data fetcher | | `broker_pnl.py` / `verify_openalgo.py` | Broker verification utilities | | `lt_3candle.db` | SQLite candle database | | `state/lt_3candle_state.json` | Runtime state | | `logs/` | Bot, EOD, systemd logs | --- ## Current Config (from code) ```python SYMBOL_FUT = "LT26MAY26FUT" # May 2026 expiry EXPIRY_DATE = "26MAY26" LOT_SIZE = 175 STRIKE_STEP = 20 PRODUCT = "NRML" POLL_INTERVAL = 120 # 2 minutes SL_LOSS_RS = 1000 TRAILING_SL_TRIGGER = 1600 TRAILING_SL_DRAWDOWN = 800 ``` --- Want me to dive deeper into any part — the VIDYA calculation, the 2-candle logic, the trailing SL, the backtest results, or how the dual-broker setup works?

Now I have the full picture. Let me break this down clearly: --- ## 1. How P&L is Calculated in the Script There are **two different P&L calculations** — one for **live monitoring** (SL checks) and one for **exit reporting**. Both have a **critical flaw**. --- ### A. Live P&L Monitoring (SL Checks) — Lines 812, 827 ```python # check_rs_sl() — line 812 loss = (pos['entry_price'] - opt_ltp) * LOT_SIZE # check_trailing_sl() — line 827 pnl = round((opt_ltp - pos['entry_price']) * LOT_SIZE, 0) ``` **What `entry_price` actually is:** Look at line 727 in `execute_entry()`: ```python "entry_price": opt_ltp, # ← this is the QUOTED LTP, NOT the fill price ``` And `opt_ltp` comes from line 712: ```python opt_ltp = self.get_option_ltp(sym) # ← live market quote at signal time ``` **The Problem:** | What happens | Value | |-------------|-------| | Bot sees option LTP = ₹50 | `opt_ltp = 50` | | Bot places BUY LIMIT at `50 + 5 = ₹55` | Order price = 55 | | `entry_price` stored = **₹50** (the quote, not the fill) | State = 50 | | Actual fill might be at ₹53 | Broker fill = 53 | **So the live P&L calculation is:** ``` P&L = (current_LTP - 50) × 175 # uses QUOTED price, not actual fill ``` **NOT:** ``` P&L = (current_LTP - 53) × 175 # uses actual average fill price ``` --- ### B. Exit P&L Reporting — Line 761 ```python # execute_exit() — line 761 pnl = round((opt_ltp - pos['entry_price']) * LOT_SIZE, 0) ``` Same problem — uses `entry_price` (quoted LTP at entry time), **not the broker's actual average fill price**. And look at line 773 — the Telegram message: ```python f"@ ₹{opt_ltp - LIMIT_OFFSET:.1f} | Reason: {reason} | P&L: ₹{pnl:+.0f}" ``` It reports the **order price** (`opt_ltp - 5`) in the message, but the P&L is computed using `opt_ltp` (the quote before the -5 offset), not the actual fill. --- ## 2. The Core Issue: `entry_price` ≠ Actual Fill Price The bot stores the **quoted LTP** as `entry_price`, not the **broker-reported average price** of the filled order. **What it should do (but doesn't):** After confirming the order filled (line 722-723): ```python qty = self.get_broker_qty(sym) if qty and qty >= LOT_SIZE: # It should ALSO fetch the average price from broker here # But it doesn't — it just stores the quote ``` The `broker_pnl.py` script shows the **correct** way to calculate P&L (line 114): ```python pnl = round((ltp - avg) * qty, 2) # uses broker's average_price ``` But the main bot **never fetches `average_price`** from the positionbook after entry. --- ## Summary Table | Aspect | What the Bot Actually Does | What It Should Do | |--------|---------------------------|-------------------| | **Entry price stored** | `opt_ltp` = quoted LTP at signal time | Broker's `average_price` from positionbook after fill | | **Live SL check (₹1000)** | `(entry_price - current_LTP) × 175` | `(avg_fill - current_LTP) × 175` | | **Trailing SL** | `(current_LTP - entry_price) × 175` | `(current_LTP - avg_fill) × 175` | | **Exit P&L reported** | `(exit_LTP - entry_price) × 175` | `(exit_avg - entry_avg) × 175` | | **Error magnitude** | Up to ±₹875 (₹5 × 175 lots) per leg | Zero — uses actual fills | --- ## Example of the Discrepancy | Scenario | Bot's P&L | Actual P&L | Difference | |----------|-----------|------------|------------| | Entry: quoted ₹50, filled ₹53, Exit: quoted ₹60, filled ₹58 | `(60 - 50) × 175 = ₹1,750` | `(58 - 53) × 175 = ₹875` | **₹875 off** | | Entry: quoted ₹50, filled ₹48, Exit: quoted ₹40, filled ₹38 | `(40 - 50) × 175 = -₹1,750` | `(38 - 48) × 175 = -₹1,750` | Exact (coincidence) | | Entry: quoted ₹50, filled ₹52, Exit: quoted ₹45, filled ₹43 | `(45 - 50) × 175 = -₹875` | `(43 - 52) × 175 = -₹1,575` | **₹700 off** | The error is **unpredictable** because it depends on: 1. How far the limit order (`LTP+5`) actually fills from the quoted LTP 2. How far the exit limit order (`LTP-5`) actually fills --- ## The Fix After confirming the entry fill, the bot should fetch the position from the broker and store the **actual average price**: ```python # After line 723 (qty confirmed), add: position_data = self.client.positionbook() # Find the position for sym, extract 'average_price' actual_avg = ... # from broker response self.state['position'] = { ... "entry_price": actual_avg, # ← use broker's average, not quote ... } ``` Same for exit — the P&L should use the broker-reported average prices for both entry and exit, or at minimum use the actual entry average. --- **Bottom line:** The bot's P&L is an **estimate based on quoted prices**, not actual realized P&L. For a ₹1000 SL threshold on a 175-lot position, a ₹5 quote-vs-fill discrepancy translates to ₹875 — almost the entire SL budget. The trailing SL (₹1600 trigger, ₹800 drawdown) is also affected by this estimation error. Do you want me to show you exactly how to patch the `execute_entry()` method to fetch and store the actual average fill price from the broker?

Done. I've updated the design document with two changes: **1. New Section 15 — "P&L Calculation — Known Limitation ⚠️"** This documents the exact problem: - How `entry_price` is currently stored (quoted LTP, not actual fill) - The impact on all three P&L calculations (₹1000 SL, trailing SL, exit reporting) - A concrete example showing ₹875 error on a single trade - The correct formula from `broker_pnl.py` for reference - The fix needed (fetch `average_price` from broker positionbook after fill) **2. New TODO item 18.4 — "Fix P&L Calculation to Use Actual Fill Price"** Added to the pending changes list with: - Task description - Why it matters (₹875 error on ₹1000 SL budget) - Impact scope (all three P&L methods) - Reference back to Section 15.0 I also renumbered the subsequent sections (16→17, 16.1→18.1, etc.) to keep the document consistent. The `.md` file now permanently records this issue so anyone reading the design doc — including future you — knows the P&L is an estimate, not realized, and understands the magnitude of the error.