← Chat Archive

I don't have immediate context about which two trading bots you're referring to. Let me search my past conversations to see if we've been working on comparing trading bots.

Let me try a broader search:

Yes! I found it. We were comparing the three trading bot brokers on your VPS this morning. The main comparison was **Kotak vs. Shoonya/Flattrade** — and I identified some critical differences. Here's the quick recap: **5 Critical Differences Found:** 1. **Authentication** — Kotak uses two-step (mobile + TOTP + MPIN), while Shoonya/Flattrade use simple API tokens 2. **JSON Response Format** — Kotak wraps responses in `{"stat": "ok/not_ok", "data": {...}}`, others return direct responses. **Active bug found** at line 28 of order_data.py (KeyError 'data') 3. **Token Field Name** — Kotak uses `"tok"`, others use `"token"` 4. **WebSocket** — Kotak uses proprietary 54KB binary library (HSWebSocketLib), others use standard WebSocket 5. **Nginx SSL Config** — Kotak has SSL directives in wrong order (after location blocks instead of before) I also found that your trading bots (claude_bot and lt_3candle_bot) are currently only connected to Shoonya and Flattrade — they skip Kotak entirely because of these stability issues. The detailed findings are saved in `/home/ubuntu/docs/KOTAK-CRITICAL-DIFFERENCES.md` and in my session memory. Do you want me to dive deeper into any of these differences, or help fix the active bugs I found?

Good question. Let me search for how historical data fetching is implemented on both brokers.

That found Groww data. Let me search more specifically for Shoonya and Kotak historical data methods:

Now let me look at the Shoonya and Kotak historical data implementations:

Good! Now let me check Kotak's historical data method:

Perfect! Now I have found a CRITICAL DIFFERENCE. Let me read Kotak's actual implementation:

Excellent! Now let me create a comprehensive comparison document. Let me also check Flattrade quickly to be thorough:

Perfect! Now I have a complete picture. Let me create a comprehensive analysis document:

Now let me update my memory with this critical finding:

Let me consolidate and replace the memory entry:

Perfect! Now let me give you a clean summary: --- ## HISTORICAL DATA FETCHING: Complete Breakdown ### **SHOONYA** ✅ Full Support - **Daily Data**: `/NorenWClientAPI/EODChartData` endpoint - **Intraday**: `/NorenWClientAPI/TPSeries` endpoint - **Intervals**: 1m, 3m, 5m, 10m, 15m, 30m, 1h, 2h, 4h, D (10 options) - **Response**: Direct array/dict with fields (into, inth, intl, intc, intv, oi) - **Timestamp**: Epoch for daily, string "DD-MM-YYYY HH:MM:SS" for intraday --- ### **FLATTRADE** ✅ Full Support - **Daily Data**: `/EODChartData` endpoint - **Intraday**: `/TPSeries` endpoint - **Intervals**: 1m, 5m, 15m, 30m, 1h, D (6 options - fewer than Shoonya) - **Response**: Same structure as Shoonya (into, inth, intl, intc, intv, oi) - **Timestamp**: Same format as Shoonya **Key Difference from Shoonya**: Endpoint paths shorter, fewer interval options --- ### **KOTAK** ❌ NO Support (Broker API Limitation) - **Daily Data**: NONE - `get_history()` returns empty DataFrame - **Intraday**: NONE - `get_supported_intervals()` returns empty dict - **Status**: Stub implementation at lines 546-565 of `kotak/api/data.py` - **Impact**: - Cannot backtest strategies - Cannot build SMMA, RSI, VIDYA indicators - Only viable for live execution of pre-built strategies --- ## Why This Matters for Your Bots **claude_bot** (SMMA / 2RSI) ← Needs historical data for SMMA calculation **lt_3candle_bot** (Renko/VIDYA) ← Needs historical data for Renko/VIDYA calculation Both only work on **Shoonya + Flattrade**, NOT Kotak. --- I've saved the full technical analysis to `/home/ubuntu/docs/HISTORICAL-DATA-COMPARISON.md` with code references, endpoint details, and field mappings.

Let me check what's happening with that URL.

The browser timed out. Let me check the Nginx status and logs from the VPS:

Aha! Service is running but there's a **Session Expired** error. Let me check the Nginx status:

Nginx is running. Let me check if there's a connectivity issue by testing the socket:

Socket exists. Let me check Nginx config and error logs:

Let me check the access log:

Let me test the service directly with curl:

Ah! Port 5000 is not listening. Let me check what port Shoonya is actually running on:

I see port 8765 and 8767 but not 8766 (Flattrade). Let me check with sudo to see which service owns them:

Let me check the Nginx config for Shoonya specifically:

Let me see the main app section:

The Nginx config looks correct. The issue is that the Gunicorn socket should be receiving the connection. Let me check if the Gunicorn process is actually listening:

The socket isn't being used! Let me restart the Shoonya service:

Good! It restarted. Now let me test the connection again:

Excellent! Shoonya is **now working** ✅ Let me check the other brokers too:

Perfect! All three are now working. Let me verify with the browser:

Great! The page is loading. Let me wait for it to fully load:

Let me document what I found and provide a summary:

--- ## Summary **Issue**: https://shoonya.openalgo.theworkpc.com/ was timing out **Root Cause**: - Gunicorn process was running but had stale connections - Shoonya broker API session expired (Session Key invalid) - Socket became unresponsive even though process was still alive - Nginx couldn't proxy through the socket → timeout **Fix Applied**: ``` sudo systemctl restart openalgo-shoonya-openalgo.theworkpc.com-shoonya.service ``` **Result**: ✅ Now Working! - Shoonya: https://shoonya.openalgo.theworkpc.com/ - Flattrade: https://flattrade.openalgo.theworkpc.com/ - Kotak: https://kotak.openalgo.theworkpc.com/ This is a common issue with long-running services. I've documented it in `/home/ubuntu/docs/SHOONYA-SERVICE-DOWNTIME-REPORT.md` with prevention recommendations (health checks + automated restarts).