← Chat Archive

I’ll investigate both bots, verify whether they are actually live, and trace recent order/quote activity. Let me set up the task list and start the inspection.

## Debug Report: TradeBot / OpenAlgo Bots ### TL;DR **Neither of the two bots (`claude_bot` and `bespoke_bot`) is placing live orders right now.** - `claude_bot` is running, but it starts with trading **DISABLED** and requires a Telegram `/start trading` command. It is also configured with **expired June 2026 futures symbols** that no longer exist in OpenAlgo. - `bespoke_bot` is **inactive** because its systemd service still points to an old directory path. Other bots on the same OpenAlgo instances (TradeBot, RenkoVIDYA, DailyVIDYA) ARE successfully placing orders. --- ### 1. Bot Service Status | Bot | Service | Status | Since | |-----|---------|--------|-------| | `claude_bot` | `claude_bot.service` | **active (running)** | Wed 15 Jul 2026 09:05 IST | | `bespoke_bot` | `bespoke_bot.service` | **inactive (dead)** | — | `bespoke_bot` fails to start because the service file points to `/home/ubuntu/Claude_bot_bespoke/...` but the actual code is at `/home/ubuntu/bots/Claude_bot_bespoke/...`. The `WorkingDirectory` and `ExecStart` paths are stale. --- ### 2. Why `claude_bot` Is Not Trading I traced the live log file `/home/ubuntu/bots/Claude_bot/logs/claude_bot_20260715.log` (filename is pinned to the service start date). Two independent blockers are preventing any order flow: #### A. Trading is DISABLED by default In `unified_strategy.py:2117`: ```python self.global_pause = threading.Event() self.global_pause.set() # start DISABLED; user must send /start trading ``` At startup the bot sends a Telegram message: > “Trading is *DISABLED* — broker logins OK, watching indicators. Send `/start trading` when ready to trade.” The main loop (`unified_strategy.py:1917`) simply sleeps while the pause event is set, so no LTP fetch, no signal calculation, and no order placement occurs. There is **no record of `/start trading`** in the logs. #### B. Configured symbols are expired / non-existent `config.py` uses June 2026 futures: ```python DLF_SMMA: symbol_fut = "DLF30JUN26FUT" INFY_SMMA: symbol_fut = "INFY30JUN26FUT" INDUSINDBK: symbol_fut = "INDUSINDBK30JUN26FUT" ``` June 30 expiry was **32 days ago**. I verified in both Shoonya and Flattrade `openalgo.db` `symtoken` tables that these symbols **do not exist**. Current nearest NFO futures are: | Stock | Current nearest NFO future | |-------|-----------------------------| | DLF | `DLF25AUG26FUT` (exp 25-Aug-2026) | | INFY | `INFY25AUG26FUT` | | INDUSINDBK | `INDUSINDBK25AUG26FUT` | At the July 15 restart the bot logged repeated `400 BAD REQUEST` responses for `/api/v1/quotes`, `/api/v1/history`, and `/api/v1/positionbook` against those expired symbols. Even if `/start trading` were sent, the quote/history calls would continue to fail. #### Evidence from order logs Recent entries in the broker `order_logs` tables are from other strategies (`TradeBot`, `RenkoVIDYA`, `DailyVIDYA`). No `claude_dlf_smma`, `claude_infy_smma`, or `claude_indusindbk_smma` orders appear. --- ### 3. Other Observations - `health_monitor.sh` still references the old path `/home/ubuntu/Claude_bot` (no `/bots/`). That cron job is likely non-functional. - The `claude_bot` log file is named `claude_bot_20260715.log` because the filename is computed once at import time. The service has not been restarted since July 15, so new days keep appending to the old file. - Today is Saturday, 2026-08-01, so the market is closed anyway; no live order can be placed until Monday. --- ### 4. Recommended Fixes 1. **Update futures symbols in `config.py`** to the current nearest NFO expiry: - `DLF25AUG26FUT` - `INFY25AUG26FUT` - `INDUSINDBK25AUG26FUT` - Also update `HAL_SMMA` (currently disabled) and `expiry_date` fields. 2. **Decide whether trading should start automatically** or stay manual: - If you want it auto-armed on startup, change `self.global_pause.set()` to `self.global_pause.clear()` in `unified_strategy.py:2117`. - If you want manual control, send `/start trading` to the Telegram bot after market open. 3. **Fix `bespoke_bot` service paths** in `/etc/systemd/system/bespoke_bot.service`: - `WorkingDirectory=/home/ubuntu/bots/Claude_bot_bespoke` - `ExecStart=/usr/bin/python3 /home/ubuntu/bots/Claude_bot_bespoke/bespoke_strategy.py` - Also update log paths and run `systemctl daemon-reload && systemctl start bespoke_bot`. 4. **Restart `claude_bot`** after the symbol/config fixes so it re-initializes with a fresh log file and valid symbols. 5. **Fix `health_monitor.sh`** path references from `/home/ubuntu/Claude_bot` to `/home/ubuntu/bots/Claude_bot`. Would you like me to apply these fixes now?

You’re right — I jumped to the old bots instead of the one you named. Let me look at the actual TradeBot service/dashboard behind `https://tradebot.openalgo.theworkpc.com/`.

## Debug Report: `https://tradebot.openalgo.theworkpc.com/` The dashboard is **running**, and two TradeBot instances are active: | Instance | Service | Status | Broker | Config | |----------|---------|--------|--------|--------| | `crudeoilm` | `tradebot@crudeoilm.service` | active (running 13h) | Kotak | RSI `gt` value 28, OTM1 options, 2 lots | | `crudeoilm_shoonya` | `tradebot@crudeoilm_shoonya.service` | active (running 13h) | Shoonya | RSI `xunder` value 70 (+70%), renko, 2 lots | They **were placing real orders on Friday 31 July 2026 evening** for MCX crude oil options via Kotak, but **right now (Saturday 1 Aug) they are not trading** because of two independent blockers. --- ### 1. Kotak (`crudeoilm`) — positionbook fails due to invalid session token The bot's logic requires a successful broker positionbook sync **before every trade decision**. Since 1 Aug it has been logging: ```text Positionbook fetch failed — position unknown, preserving in-memory state ``` I traced this to the Kotak OpenAlgo gateway. Direct API call returns HTTP 500: ```json {"message": "'data'", "status": "error"} ``` Kotak service journal shows the real cause repeated every minute: ```text ORDER API Response: {"stCode":100022,"errMsg":"invalid session token","stat":"error in neo-login-check-api"} Error processing positions data: 'data' ``` So the **Kotak broker login/session token has expired**. The bot cannot verify positions, therefore it refuses to place new orders (correct defensive behavior per the code). Quotes/optionsymbol work fine, but `positionbook` and `orderbook` need a valid session. Result: `crudeoilm` is **live but blocked** — no new orders until Kotak is re-logged in. --- ### 2. Shoonya (`crudeoilm_shoonya`) — waiting for crossover that has not happened This bot is in `wait_crossover` mode with: - `signal_a = rsi` - `signal_b = value` (threshold 70) - `condition = xunder` with `+70.0%` buffer The log repeats: ```text POLL CRUDEOILM rsi=71.43 value=70.00 cond=xunder(+70.0%) — waiting for xunder price=8120.0 pos=FLAT qty=0 mode=WAITING bot_type=buy_exit fired=False ``` It has been waiting since 31 Jul 23:42. The condition requires **RSI to cross below 70 × 1.70 = 119** (because `xunder_pct` uses `val_b * (1 - pct/100)`? Actually the code for `xunder_pct` uses `val_b * (1 - pct/100)` which would be 70 * 0.30 = 21 — but the log says "value=70.00 cond=xunder(+70.0%)" and reason is "waiting for xunder". Wait, let me re-read: in the config it's `condition: xunder`, `condition_pct: 70.0`. The `_evaluate_condition` for `xunder_pct` uses `val_b * (1 - pct/100)` → threshold = 70 * 0.30 = 21.0. But the log prints `value=70.00` because signal_b is "value" and threshold is 70. The code path for `xunder` (not `xunder_pct`) is being taken because `condition` is `xunder`, and `condition_pct` is only applied for `xunder_pct`. Actually looking at the code: ```python threshold = val_b * (1 + pct / 100.0) if c in ("gt_pct", "xover_pct") else \ val_b * (1 - pct / 100.0) if c in ("lt_pct", "xunder_pct") else 0 ``` For `c == "xunder"` the threshold is 0. So `condition_pct` is **ignored** unless condition is `xunder_pct`. The config says `condition: xunder` with `condition_pct: 70.0` — this is almost certainly a dashboard bug or config confusion. The bot is waiting for a plain RSI cross below 70, which hasn't happened (RSI is ~71.4). Also positionbook fetch fails frequently for Shoonya too (read timeout), though it did succeed earlier. --- ### 3. Evidence of real trading on Friday Kotak `order_logs` confirms TradeBot placed actual orders: | Time | Action | Symbol | Qty | Price | |------|--------|--------|-----|-------| | 2026-07-31 20:57:41 | BUY CE | CRUDEOILM17AUG268200CE | 20 | ₹505.85 | | 2026-07-31 21:01:58 | BUY CE | CRUDEOILM17AUG268200CE | 20 | ₹509.85 | | 2026-07-31 22:54:15 | SELL | CRUDEOILM17AUG268150CE | 20 | ₹452.0 | | 2026-07-31 22:59:03 | SELL | CRUDEOILM17AUG268150CE | 20 | ₹449.2 | | 2026-07-31 23:07:35 | SELL | CRUDEOILM17AUG268200CE | 20 | ₹427.4 | Some entries were rejected/missed. The state file shows only one order payload (it overwrites on each trade). The last order logged was the SELL at 23:07. --- ### 4. Key code issue causing stale/frozen RSI The Shoonya log shows RSI stuck at `71.43` for **hours**. Looking at `fetch_indicators` in `bot.py`: ```python r = requests.get(f"{CHART_API}/api/indicators/{symbol}", params=params, timeout=10) ``` It always passes `days=None`. The chart API response has `"ts":"2026-07-31 23:25:00"` — that is the last timestamp in its data. The chart API may be returning stale data on weekends/off-market hours. So the bot is not getting fresh real-time signals. Also note: today is Saturday and MCX evening session may be closed, so no new candles anyway. --- ### 5. Summary | Bot | Is it placing orders in real time? | Why | |-----|------------------------------------|-----| | `crudeoilm` (Kotak) | **No right now** | Kotak session token expired → positionbook/orderbook fail → bot cannot sync positions, so it blocks all trades. | | `crudeoilm_shoonya` | **No right now** | Config condition is `xunder` with threshold 70 but RSI stuck ~71.4; plus `condition_pct: 70` is not being applied. Also Shoonya positionbook read timeouts. | Both bots **were live-trading on Friday evening**. They are correctly refusing to trade while they cannot verify broker state or the signal condition. --- ### 6. What you should do 1. **Re-login Kotak** in the OpenAlgo web UI (or however you normally refresh the broker session). After login, the positionbook will work and `crudeoilm` can trade again. 2. **Review the Shoonya config** in the dashboard: - If you meant RSI crossing below 70 with a 70% buffer, set `condition: xunder_pct` (not `xunder`). - If you meant plain RSI < 70, current behavior is correct and it will fire when RSI drops. - Also check whether `threshold: 70` or `condition_pct: 70` is what you actually want. 3. **Check Shoonya connectivity** — the read timeouts on positionbook suggest either Shoonya service load or an expired session there too. 4. **Note weekend/off-market caveat**: today is Saturday. Even after fixing the above, you may not get fresh candles/prices until the next trading session. Would you like me to fix the Shoonya config, or restart/relogin the Kotak OpenAlgo service?