admin/Ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
Ai/trade_web/docs/TRADING_COCKPIT_DOKUMENTATION.md
T

12 KiB
Raw Permalink Blame History

Trading Cockpit Dokumentation

Stand: 2026-05-24

Diese Dokumentation beschreibt den aktuellen technischen Stand der Trading-Cockpit-Web-App, die aus dem alten trade.txt/Tkinter-Programm in eine Python/Flask-Webanwendung umgebaut wurde.

Kurzstatus

Die App ist als Web-Cockpit lauffähig und auf pDocker deployed:

http://192.168.178.113:5050

Aktuelle Kernfunktionen:

  • Live-Analyse über Binance-Spot-Kerzen
  • Demo-Fallback, wenn Datenquellen nicht erreichbar sind
  • Long- und Short-Signale
  • Entscheidungsampel mit Entry, Stop, Ziel, R/R, Score und Confidence
  • technische Indikatoren
  • Makro- und Marktstrukturfilter
  • Forecast-Ansicht mit Lernkurve
  • Backtesting mit Gebühren, Spread und Slippage
  • Optimizer mit Fortschritt, Quality-Gate, Out-of-sample und Walk-forward
  • Paper-Orders
  • Exchange-Guard, der echte Orders standardmäßig blockiert
  • Docker/pDocker Betrieb

Start

Lokal:

cd /Users/metacube/Projects/Git/trade_web
python3 -m pip install -r requirements.txt
python3 app.py

Dann öffnen:

http://127.0.0.1:5050

Docker lokal:

docker compose build
docker compose up -d
docker compose ps
docker compose logs -f trading-web

Deployment

Zielsystem:

pDocker: 192.168.178.113
App-Pfad: /data/compose/trade_web
URL: http://192.168.178.113:5050
Container: trading-web

Deployment-Script:

./deploy_pdocker.sh

Beim manuellen Deployment wird config.json nicht überschrieben, wenn nur Codeänderungen ausgeliefert werden sollen. Die laufende Server-Konfiguration bleibt dadurch erhalten.

Git Ablage

Lokales Entwicklungsrepo:

/Users/metacube/Projects/Git/trade_web

GitHub-Ziel:

Repository: metacube2/Ai
Pfad: trade_web/
URL: https://github.com/metacube2/Ai/tree/main/trade_web

Hinweis:

  • Das lokale trade_web-Repo bleibt als eigenständiges Arbeitsrepo bestehen.
  • Auf GitHub wird der Projektstand im bestehenden Repository metacube2/Ai unter dem Unterordner trade_web/ abgelegt.
  • Das lokale Ai-Repo unter /Users/metacube/Projects/Git/Ai kann unabhängig davon eigene offene Änderungen enthalten und wird für trade_web nicht automatisch verändert.

Architektur

Wichtige Dateien:

app.py                    Flask API und Routen
trading_engine.py         Indikatoren, Signalmodell, Forecast, Backtest, Optimizer
exchange.py               Exchange Safety Guard
storage.py                SQLite Persistenz
templates/index.html      HTML Layout
static/app.js             Frontend-Logik und SVG Charts
static/styles.css         UI Design
config.json               Symbol, Signalmodus, Risiko, Execution Safety
test_trading_engine.py    Regressionstests fuer Kernlogik
docker-compose.yml        Containerbetrieb
Dockerfile                Image Build

Persistenz:

/app/data/trade_web.sqlite3

Gespeichert werden:

  • Backtest-Runs
  • Optimizer-Runs
  • Paper-Orders

UI Workflow

Tabs:

  • Analyse: Ampel, Signal, Timeframes, Makro, Korrelationen
  • Forecast: Forecast-Pfad, Unsicherheitsband, Lernkurve
  • Optimieren: Backtest, Optimizer, Konvergenz, Historie
  • Risiko: Risk-Plan, Health, Paper-Orders
  • Methodik: Signalformel und TradingView-Formelcheck

Die Hauptampel zeigt:

  • Entscheidung: Kaufen, Short, Beobachten, Short beobachten oder Warten
  • Entry
  • Stop
  • Ziel
  • Risk/Reward
  • Score
  • Confidence
  • Signalblocker

Datenquellen

Technische Analyse:

  • Binance Spot Klines
  • Timeframes: 15m, 30m, 4h, 1d

Makro/Marktstruktur:

  • DXY/UUP Proxy
  • SPY/QQQ Risk-on/Risk-off
  • TLT als Zinsdruck-/Realzins-Proxy
  • BTC-Dominanz und Stablecoin-Liquiditaet ueber CoinGecko
  • Funding Rate und Open Interest ueber Binance Futures
  • News/Event-Risiko ueber RSS-Keyword-Scan

Wenn externe Daten nicht erreichbar sind, wird neutral oder mit Demo-Fallback weitergerechnet. Die App soll nicht blockieren, nur weil eine externe Quelle langsam ist.

Indikatoren

Berechnet werden:

  • RSI 14
  • MACD 12/26/9
  • EMA20
  • EMA50
  • SMA200
  • Volumen gegen SMA20
  • Support/Resistance aus den letzten 30 Kerzen
  • Fibonacci-Level
  • W-Pattern
  • Trendstatus
  • Korrelationen gegen Benchmark-Assets

TradingView/Pine-Abgleich:

  • RSI entspricht ta.rsi(close, 14) mit Wilder-RMA
  • MACD entspricht ta.macd(close, 12, 26, 9)
  • EMA entspricht ta.ema(close, length)
  • SMA entspricht ta.sma(close, length)

Ein echter 1:1-Vergleich mit TradingView ist nur moeglich, wenn Symbol, Boerse, Timeframe und Kerzenschlusszeit identisch sind.

Signalmodell

Das Signalmodell ist bidirektional:

  • bullish Setup -> Long/BUY-Kandidat
  • bearish Setup -> Short/SELL-Kandidat

Moegliche Signaltypen:

STRONG_BUY
BUY
WEAK_BUY
NONE
WEAK_SELL
SELL
STRONG_SELL

Long-Geometrie:

Entry = aktueller Preis
Stop  = Support
Ziel  = Resistance
R/R   = (Ziel - Entry) / (Entry - Stop)

Short-Geometrie:

Entry = aktueller Preis
Stop  = Resistance
Ziel  = Support
R/R   = (Entry - Ziel) / (Stop - Entry)

Ein Signal wird nur aktiv, wenn:

  • Score die Schwelle erreicht
  • Risk/Reward positiv und ausreichend ist
  • Modusfilter erlaubt
  • Makrofilter nicht blockiert
  • Entry/Stop/Ziel geometrisch korrekt sind

Signalmodi

balanced:

  • weniger streng
  • mehr Signale
  • gut fuer Exploration und Backtestvergleich

high_precision:

  • verlangt Multi-Timeframe-Bestaetigung
  • verlangt hoeheres R/R
  • blockiert ueberkaufte Longs bzw. ueberverkaufte Shorts

lux_style:

  • trend-, momentum-, volumen- und breakout-orientiert
  • long und short getrennt geprueft
  • keine LuxAlgo-Kopie und keine proprietaere LuxAlgo-Logik

Aktuelle Logikfixes

Gefundene und behobene Fehler:

  • Das System konnte zuerst nur Long-Signale ausgeben. Bearishe Setups wurden dadurch faelschlich NONE/Warten.
  • Short-Signale wurden ergaenzt: WEAK_SELL, SELL, STRONG_SELL.
  • Short-R/R wird jetzt korrekt mit Stop oberhalb und Ziel unterhalb berechnet.
  • Paper-Orders und Risk-Plan kennen jetzt BUY und SELL.
  • RSI unter 50 wurde vorher teilweise long-gruen bewertet. Jetzt ist RSI < 50 bearish, RSI > 50 bullish.
  • RSI bei konstantem Markt war falsch moeglich als 100. Jetzt ist flacher RSI korrekt 50.
  • Backtest konnte 1d-Daten mit Zukunftsblick verwenden. Jetzt werden Tageskerzen nur bis zur aktuellen Backtest-Kerze verwendet.
  • Lux/Precision Backtest wurde durch fehlende 15m/30m-Historie zu hart blockiert. Im historischen 4h-Backtest wird dafuer ein 4h-Proxy verwendet.

Backtesting

API:

/api/backtest
/api/backtest?symbols=BTCUSDT,ETHUSDT&candles=360&horizon=12

Der Backtest simuliert:

  • Long- und Short-Trades
  • Entry
  • Stop
  • Target
  • Timeout-Exit
  • Gebuehren
  • Slippage
  • Spread

Metriken:

  • Trades
  • Wins/Losses
  • Winrate
  • Total Return
  • Average Trade
  • Profit Factor
  • Max Drawdown
  • Equity Curve
  • Drawdown Curve
  • Sample Trades

Chart:

  • Candlestick-Daten
  • Entry-Linien
  • Stop-Linien
  • Target-Linien
  • Trade-Marker

Wichtig: Historische Makrodaten sind nur als Proxy-Schicht vorhanden. Technischer Backtest ist nutzbar, Makro-Historie ist keine vollstaendige institutionelle Makro-Rekonstruktion.

Optimizer

Der Optimizer testet Parameterkombinationen:

  • Signal-Schwellen
  • R/R-Schwellen
  • RSI-Schwellen
  • Indikatorgewichte
  • Symbolparameter

Bewertet wird mit:

  • Training Score
  • Out-of-sample Score
  • Walk-forward Score
  • Quality-Gate
  • Robustheitsreport
  • Monte-Carlo-Unterseite
  • Verlustserien
  • Konvergenzverlauf

Ein Vorschlag wird nur uebernehmbar, wenn das Quality-Gate bestanden ist.

Forecast

Forecast-Ansicht:

  • historische 4h-Kerzen
  • Forecast-Pfad
  • Unsicherheitsband
  • Lernkurve
  • Forecast-Fehler je Lernfenster

Der Forecast ist statistisch:

  • Drift aus den letzten Returns
  • Volatilitaet aus den letzten Returns
  • Unsicherheitsband ueber Volatilitaet und Horizont

Das ist keine Garantie und kein Deep-Learning-Modell. Die Lernkurve zeigt, ob das gewaehlte Fenster historisch weniger Fehler erzeugt.

Risk-Plan

Berechnet wird:

  • Entry
  • Stop
  • Target
  • Richtung
  • Risiko pro Trade
  • Positionsgroesse
  • Notional
  • Blocker

Risk-Konfiguration in config.json:

{
  "risk_per_trade_pct": 0.5,
  "max_position_pct": 25,
  "max_daily_loss_pct": 2,
  "max_drawdown_pct": 12,
  "max_open_positions": 3,
  "cooldown_after_losses": 3,
  "slippage_bps": 5,
  "spread_bps": 4,
  "taker_fee_bps": 10,
  "maker_fee_bps": 6
}

Paper-Trading

Paper-Order Endpunkte:

GET  /api/paper/orders
POST /api/paper/order

Paper-Orders speichern:

  • Symbol
  • Side: BUY oder SELL
  • Quantity
  • Entry
  • Stop
  • Target
  • Risk Amount
  • Signal
  • Risk Plan

Live-Exchange-Sicherheit

Echte Orders sind bewusst blockiert.

Default:

{
  "mode": "paper",
  "kill_switch": true,
  "allow_live_orders": false,
  "require_manual_confirm": true,
  "api_key_env": "",
  "api_secret_env": ""
}

Exchange-Guard:

GET  /api/exchange/status
POST /api/exchange/order

Vor echtem Live-Trading waeren noetig:

  • Testnet zuerst
  • API-Key ohne Withdrawal-Rechte
  • Secret-Verwaltung ueber ENV/Secret Store
  • Tick-Size/Step-Size/Min-Notional Regeln
  • Order-Limits
  • Positionslimits
  • Reconnect- und Retry-Handling
  • Rate-Limit-Handling
  • Audit-Log
  • manuelle Freigabe oder klarer Autotrade-Modus

Aktuell ist der Live-Connector vorbereitet, sendet aber keine echten Exchange-Orders.

API Uebersicht

GET  /
GET  /api/config
POST /api/config
GET  /api/analyze
GET  /api/backtest
GET  /api/forecast
GET  /api/optimize
POST /api/optimize/start
GET  /api/optimize/status/<job_id>
POST /api/optimize/cancel/<job_id>
POST /api/optimize/apply
GET  /api/history
GET  /api/health
GET  /api/paper/orders
POST /api/paper/order
GET  /api/exchange/status
POST /api/exchange/order

Tests

Vorhandene Tests:

test_trading_engine.py

Aktuell abgedeckt:

  • SMA/EMA/RSI/MACD Basics
  • RSI bei flachem Markt
  • Returns, Performance, Korrelation
  • Long/Short-R/R gegen Signaloutput
  • bearish Setup wird STRONG_SELL

Ausfuehrung, wenn pytest installiert ist:

python3 -m pytest test_trading_engine.py

Fallback ohne pytest:

python3 - <<'PY'
import test_trading_engine as tests
for name in sorted(dir(tests)):
    if name.startswith("test_"):
        getattr(tests, name)()
        print(name, "ok")
PY

Syntaxchecks:

python3 -m py_compile app.py trading_engine.py storage.py exchange.py test_trading_engine.py
node --check static/app.js

Bekannte Grenzen

Die App ist ein Analyse- und Paper-Trading-System, kein garantierter Profit-Bot.

Bekannte Grenzen:

  • kein vollstaendiger historischer News-/Funding-/Dominanz-Datensatz im Backtest
  • Forecast ist einfach-statistisch
  • kein produktiver WSGI-Server, aktuell Flask/Werkzeug im Container
  • keine echte Binance/Bitget-Orderausfuehrung aktiv
  • keine persistente Candle-Cache-Schicht
  • Optimizer kann bei vielen Symbolen langsam werden
  • keine Purged/Embargoed Cross-Validation
  • keine Liquidation-Heatmap
  • kein professioneller Wirtschaftskalender

Empfohlene naechste Schritte

Prioritaet hoch:

  • Gunicorn/Waitress statt Flask Dev Server
  • Candle-Cache in SQLite
  • mehr Regressionstests fuer Long/Short/Backtest
  • UI-Anzeige fuer Long- und Short-Kandidat nebeneinander

Prioritaet mittel:

  • historische Funding/OI-Daten
  • historische BTC-Dominanz und Stablecoin-Liquiditaet
  • Export von Backtests als CSV/JSON
  • gespeicherte Optimizer-Jobs mit Resume

Prioritaet niedrig:

  • Bitget-Connector
  • echte Exchange-Ausfuehrung mit Testnet
  • fortgeschrittene Forecast-Modelle

Wichtige Sicherheitsregel

Live-Trading darf erst aktiviert werden, wenn Testnet, Key-Scope, Order-Limits, Fehlerhandling und manuelle Freigabe sauber umgesetzt und getestet sind.

Bis dahin bleibt das System bewusst bei Analyse, Backtest, Optimierung und Paper-Trading.

Reference in New Issue View Git Blame Copy Permalink