← Chat Archive

The four bot systems registered on bot.openalgo (from /home/ubuntu/bots/dashboard/bot_systems.yaml): 1. Renko Xover (Raw) — renko_vidya Path: /home/ubuntu/bots/renko_vidya_bot Service: renko-vidya-bot@<symbol> SMA(2) × VIDYA(20) Renko crossover 2. Xover + Daily Trend Filter — daily_vidya Path: /home/ubuntu/bots/daily_vidya_bot Service: daily-vidya-bot@<symbol> Zone-filtered VIDYA — line in stone, per-symbol broker 3. Intraday Breakout (2-Loss Halt) — google_lipi_vidya Path: /home/ubuntu/bots/google_daily_lipi_vidya Service: google-daily-lipi-vidya@<symbol> 2-brick Renko + LIPI/anchor boundaries, intraday, 2 lots 4. Xover Fut + Hedge — crossover_lipi_vidya Path: /home/ubuntu/bots/crossover_lipi_vidya Service: crossover-lipi-vidya@<symbol> Margin-optimized 5-min VIDYA × LIPI Anchor crossover (Options + Futures) All 4 are active: true. Want me to check which instances are currently running per system?

They trade different instruments off different signals. The short version: Bot 2 — Xover + Daily Trend Filter (daily_vidya_bot) - Instrument: OPTIONS ONLY. Buys 1-2 lots of OTM1 Call or Put, monthly expiry. No futures. - Signal: SMA(2) × VIDYA(20) crossover on Renko bricks (same core signal as bot 1), gated by yesterday's daily VIDYA anchor ±0.5% zone. In-zone = hold, no new entries; clear-long zone = calls only, clear-short zone = puts only. - Exit: opposite crossover flips it out (and reverses). A ₹1,500/lot SL is reported in alerts but never placed — exit-on-flip is the risk control. - State: fully stateless. Broker positionbook = truth, no state files. Bot 4 — Xover Fut + Hedge (crossover_lipi_vidya) - Instrument: FUTURES + an OTM1 option bought as a hedge, always as a PAIR. Long future + long put (bullish), or short future + long call (bearish). - Signal: 5-min VIDYA(20) crossing the LIPI VIDYA anchor — a different crossover than bot 2's SMA×VIDYA. - Execution: staggered leg sequence with 2-sec gaps, ordered to capture exchange margin benefit (option hedge goes on before the future leg; on reversal, future squares off first). If the option leg is rejected, the flow aborts so you never end up with a naked future. - Exit: hard combined-P&L stop of ₹3,000 across both legs, monitored every poll. Hit → square off future first, then option, then halt for the day. - State: keeps a disk state file (last_crossover_ts) to avoid re-firing the same crossover. So: bot 2 is a pure options buyer with a trend-zone filter and flip-based exits; bot 4 is a hedged futures system with margin-optimized staggered entries and a hard rupee stop-loss that halts the day.

Read both bot.py files fully (775 and 816 lines). Here's what the code actually says — a few things differ from the docs: SIGNAL — what triggers a trade Bot 2 (daily_vidya): SMA(2) vs VIDYA(20) on Renko bricks, both values fetched from the chart API (/api/renko-signal). Entry fires only on a STATE CHANGE — one in-memory boolean self._last_sma_above compared between 60s polls. Flip the boolean → signal. No flip → no trade, even if conditions look perfect. Bot 4 (crossover_lipi): Renko VIDYA(20) vs the LIPI anchor (yesterday's daily VIDYA). But despite the name, it does NOT wait for a crossover event. In check_and_trade, if the bot is FLAT and vidya_now > anchor → it enters XOVER immediately (is_auto_entry = True). It's a state comparison, not an edge detector. The last_crossover_ts dedup is bypassed by is_auto_entry in exactly the flat/reversal cases. DATA SOURCES — opposite philosophies Bot 2: zero local DB reads. Everything computed comes from the chart API over HTTP; broker API touched only at trade time. Bot 4: reads SQLite directly — get_renko_vidya() opens <symbol>_5min.db, groups 5-min candles into daily closes, builds Renko bricks and computes VIDYA itself (imports signal_engine.py, which is dead code in bot 2). get_lipi_anchor() reads <symbol>_daily_vidya.db directly. Chart API is only a fallback. So bot 4 violates the "fetch from chart API, never self-compute" rule that bot 2 follows — and note its VIDYA is computed on DAILY closes grouped from 5-min data, a different series than bot 2's intraday renko-signal VIDYA. INSTRUMENTS & EXECUTION Bot 2: one option leg. BUY 1 lot OTM1 CE or PE, NRML LIMIT at LTP×1.03. On opposite signal: exit, sleep 2s, reverse. Max lots checked against live positionbook. Bot 4: two legs, staggered with 2s gaps. XOVER = buy OTM1 PE then buy future; XUNDER = buy OTM1 CE then short future. On reversal it squares off future first, then option, then re-enters (4 orders, ~6s). If the option entry leg is rejected, the flow aborts before the future leg — no naked futures. RISK CONTROLS Bot 2: no real stop-loss. sl_amount is only printed in alerts. Exit-on-flip is the only risk control. Plus entry gates: anchor freshness guard (≤3 days old), zone filter (±0.5% around anchor blocks entries), direction enforcement (CALL only in CLEAR_LONG, PUT only in CLEAR_SHORT). Bot 4: hard combined SL — option P&L + future P&L ≤ −₹3,000 (from live positionbook) → square off future first, then option, set halted=True for the day. Also has optional target profit (tp_inr), entry cutoff (14:55, no new entries after), and EOD squareoff at 15:15 if enable_eod_squareoff. Plus market-hours guard (09:15–15:20, Mon–Fri) — bot 2 has no time checks at all. STATE Bot 2: fully stateless. No files. Crash/restart → next poll reassesses from broker truth. Bot 4: day-state JSON at state/day_<name>.json — halted, mode (FLAT/XOVER/XUNDER), last_crossover_ts. Mode and last_crossover_ts carry forward across days for positional carryover. One practical consequence: bot 2 can sit flat for hours in-zone waiting for a fresh SMA×VIDYA flip; bot 4 will enter the moment it starts flat on the right side of the anchor — restart it mid-day flat and it trades on the next poll.