d36ed142cfad43ed8bf413e473f59cea5544dba5
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Tobias Zimmermann
|
d36ed142cf |
Terminmarktmerkmale, Ollama-Erklärungen, schnelleres Lernen
Drei Erweiterungen aus der vorangegangenen Analyse. Lerngeschwindigkeit - background_sample_every_n_bars von 10 auf 5. Gemessen stammen nur rund 3 % der Beobachtungen aus echten Trades; diese Stichproben sind der wirksamste Hebel. Nicht weiter gesenkt, weil benachbarte Kerzen stark korreliert sind und sich die Label-Fenster überlappen - mehr Gradientenschritte heißt dort nicht mehr Information. Funding Rate und Open Interest als Merkmale (strategy.derivatives, standardmäßig aus) - Vier zusätzliche Merkmale vom Perpetual zum jeweiligen Spot-Paar. Gehandelt wird weiterhin Spot, die Kennzahlen kommen über einen zweiten ccxt-Client mit defaultType=future. - Die Zuordnung ist lookahead-frei: Für jede Kerze gilt nur der Wert, der zu diesem Zeitpunkt bereits veröffentlicht war. - Fällt eine Quelle aus oder deckt sie weniger als min_coverage ab, bleiben die Spalten neutral. Die Modelldimension bleibt dabei stabil. - Gemessene API-Grenzen bei Binance: Open Interest reicht 30 Tage zurück, 500 Zeilen je Abruf; Funding Rate über ein Jahr. Beide Merkmale sind deshalb einzeln abschaltbar. ERGEBNIS: kein Nutzen. Zwei Backtests mit identischen Kerzen und Seed - 5m/20 Tage: Rendite -1,79 % auf -1,90 %, Accuracy 51,2 % auf 50,4 %; 15m/28 Tage: Rendite -2,22 % auf -2,67 %, LogLoss praktisch unverändert. Die Anbindung arbeitet einwandfrei (100 % Datenabdeckung), das Modell gewichtet die neuen Merkmale aber nur mit 0,01 bis 0,09 gegenüber 0,39 für ema_spread. Die Funktion bleibt aus und ist dafür da, das auf anderen Zeiträumen selbst zu prüfen - nicht weil sie sich bewährt hätte. Ollama-Erklärungen (llm, standardmäßig aus) - Neuer Dashboard-Bereich und POST /control/explain. Das Modell bekommt den Zustand als Text und gibt Text zurück; es entscheidet nichts, beeinflusst keine Order und wird nie aus dem Handels-Loop heraus aufgerufen. Der System-Prompt untersagt Anlageempfehlungen und Kursprognosen. - Bewusst nicht als Entscheider: nicht reproduzierbar, kaum backtestbar, und es würde die Nachvollziehbarkeit des linearen Modells zerstören. - Beim Test an qwen3.8:27b zeigte sich ein echter Fehler: Reasoning-Modelle legen ihre Denkschritte in ein eigenes Antwortfeld und verbrauchten dafür das gesamte Token-Budget, response blieb leer. llm.think ist jetzt standardmäßig false, die Fehlermeldung nennt Ursache und Ausweg statt nur "leere Antwort", und für ältere Ollama-Versionen ohne das Feld gibt es einen Wiederholungsversuch ohne es. Bewusst nicht enthalten: News- und Google-Trends-Sentiment. Es fehlt eine Quelle mit Point-in-Time-Historie; ohne die lässt sich das Merkmal nicht backtesten. Nach dem Ergebnis oben wäre ein unvalidiertes Merkmal der falsche Schritt. test_stop_loss_bounds_the_worst_trade läuft jetzt mit strategy.name: rules. Er hing über die geänderte Voreinstellung an zufälligem Modellverhalten, geprüft werden soll aber die Stop-Logik. 270 Tests (36 neue), ruff sauber. Gegen echte Binance-Daten und eine laufende Ollama-Instanz geprüft, Dashboard-Bereich im Browser bedient. |
||
|
Tobias Zimmermann
|
db31bc93f7 |
Konfigurationsbereich auffindbar machen
Der Bereich war sichtbar, wurde aber übersehen: ein 12-Pixel-Knopf, der an der Überschrift klebte, während "Handel pausieren" und "Training starten" jeweils in einer eigenen Box mit normalgroßem Knopf sitzen. 71x26 px gegenüber 90x58 und 79x58 - das liest sich nicht als Bedienelement. Der Bereich sieht jetzt aus wie die beiden anderen: eigene Panel-Box, Knopf "Konfiguration bearbeiten" in gleicher Größe (114x58 px, 14px Schrift), daneben eine Zeile, die sagt, was dahintersteckt. Geöffnet heißt der Knopf "Konfiguration schließen". Zwei neue Tests halten die drei Haupt-Bedienelemente auf gleicher Linie: keine Inline-Styles, die Schrift oder Polsterung verkleinern, und jeder Knopf muss in einer Panel-Box stehen statt in einer Überschrift. 233 Tests (6 neue), ruff sauber. Im Browser durchgespielt: öffnen, 76 Felder, risk.cooldown_bars_after_exit geändert und sofort wirksam, schließen. |
||
|
Tobias Zimmermann
|
17fef9abe5 |
Konfigurationsbereich im Dashboard sichtbar machen
Der Abschnitt war für Benutzer unerreichbar: Er startet mit hidden, und sichtbar
gemacht hat ihn nur renderConfig() - die ausschließlich nach einem Klick auf
"anzeigen" lief, einen Knopf innerhalb des versteckten Abschnitts. Er konnte sich
also nie selbst einblenden. refresh() rief renderConfig nicht auf.
Die Sichtbarkeit entscheidet jetzt der Statuslauf, der ohnehin alle fünf Sekunden
durchläuft, anhand von trading.control_enabled.
Warum das durchgerutscht ist: Die Prüfung des Formulars lief über
getElementById("cfg-toggle").click(). Das funktioniert auch bei unsichtbaren
Elementen - die gesamte Konfigurationsoberfläche wurde damit über einen Knopf
bedient, den kein Mensch je gesehen hätte. Dieselbe Lücke wie beim vorigen
Dashboard-Fehler: Mechanik geprüft, Sichtbarkeit nicht.
Neuer Test: Für jeden <section ... hidden> wird geprüft, dass er im Statuslauf
sichtbar gemacht wird, also in refresh() oder einer der von dort gerufenen
render-Funktionen. Gegenprobe gelaufen - vor dem Fix meldet er config-section als
unerreichbar, nach dem Fix sind alle drei Abschnitte in Ordnung.
227 Tests (5 neue), ruff sauber. Im Browser ohne jeden Skriptklick geprüft: Der
Abschnitt erscheint nach dem Laden, der Knopf liegt mit 71x26 px im Dokumentfluss,
keine Blockade durch display, visibility, pointer-events oder opacity in der
Elternkette, und das Panel öffnet mit 76 Eingabefeldern.
|
||
|
Tobias Zimmermann
|
9f10f9000e |
Konfiguration im Dashboard änderbar machen
Neuer Abschnitt "Konfiguration" im Dashboard, aus dem pydantic-Schema erzeugt:
76 Felder in 13 Bereichen mit Kurzbeschreibung, typgerechtem Eingabefeld und den
Grenzen aus dem Modell. 70 davon sind änderbar, 45 greifen sofort, 31 sind als
neustartpflichtig markiert. Dazu GET und POST /control/config sowie
/control/config/reset.
Overlay statt Direktschreiben
- config.yaml ist im Container read-only eingehängt. Änderungen landen deshalb in
/data/config.overrides.yaml und werden beim Start über die Basiskonfiguration
gelegt. Rangfolge: YAML, dann ${ENV}, dann TRADEMIND__-Variablen, dann Overlay.
- Gespeichert wird nur, was vom Basiswert abweicht. Ein auf den Ausgangswert
zurückgestelltes Feld verschwindet wieder aus dem Overlay, damit spätere
Änderungen an config.yaml dort erneut durchschlagen.
- Beschädigte oder ungültige Overlays werden protokolliert und ignoriert, statt
den Start zu blockieren.
Übernehmen zur Laufzeit
- apply_config hängt die Laufzeitobjekte auf die neuen Teilkonfigurationen um
(Risiko, Strategie, Regelwerk, Lernmodell, Paper-Broker, Notifier, Log-Level).
- Was nur beim Aufbau ausgewertet wird - Börsenclient, Symbole, Timeframe,
Startkapital, Datenbank, Socket - meldet der Store als neustartpflichtig.
Nebenbei behoben: Der Handels-Loop las Abfrageintervall und Historienlänge nur
einmal vor der Schleife. Eine Änderung an poll_interval_seconds hätte nie
gegriffen; beide werden jetzt je Durchlauf frisch gelesen.
Drei Ausnahmen von "komplett", bewusst gesetzt
- exchange.api_key/api_secret/password/uid werden maskiert angezeigt und nicht
entgegengenommen. Sonst könnte jeder mit Zugriff auf den Port die
Börsenschlüssel auslesen oder austauschen.
- mode lässt sich zwischen paper und backtest umstellen, nicht auf live.
- live_confirmation ist nicht schreibbar.
Zusammen verhindern sie, dass sich der Bot über das Netz schrittweise auf
Echtgeldhandel umstellen lässt.
222 Tests (36 neue), ruff sauber. Darunter Prüfungen, dass Geheimnisse in keiner
Antwort auftauchen und dass Tippfehler in RESTART_REQUIRED oder NON_WRITABLE
auffallen. Im Browser durchgeklickt: Änderung sofort wirksam, neustartpflichtige
Felder korrekt gemeldet und nach Neustart aktiv, Zurücksetzen einzeln und
komplett, alle Schutzregeln mit HTTP 400 samt lesbarer Begründung.
|
||
|
Tobias Zimmermann
|
4551339632 |
Dashboard reparieren: Escape-Sequenz zerlegte das eingebettete Skript
Das Dashboard blieb bei "lädt ..." stehen und zeigte weder Kacheln noch die
Steuerungs-Abschnitte.
Ursache: _DASHBOARD ist ein Python-String. Der in
|
||
|
Tobias Zimmermann
|
d081edfbd3 |
Automatisierten Handel über das Dashboard starten und pausieren
Neuer Abschnitt "Automatisierter Handel" im Dashboard mit Zustandsanzeige und Start/Pause-Knopf, dazu GET und POST /control/trading. Funktioniert in beiden Modi, simuliert wie echt. Pausiert unterbindet ausschließlich neue Einstiege - Marktdaten, Signalauswertung, Labeling und Training laufen weiter, damit der Datenstrom ins Modell nie abreißt. Auf identischen Daten: aktiv 99 Beobachtungen bei 9 Trades, pausiert 90 Beobachtungen bei 0 Trades - der Unterschied sind genau die Trade-Labels, die ohne Handel nicht entstehen. - Offene Positionen bleiben unter Stop- und Ziel-Überwachung. Ein pausierter Bot lässt niemanden ungeschützt im Markt stehen. - Neu: trading.autostart (Standard true, bisheriges Verhalten) und trading.require_confirmation_for_live. Nebenbei behoben - Bei aktiver Notbremse (Tagesverlust, Drawdown) wurden bisher gar keine Signale mehr ausgewertet. Der Bot hörte damit ausgerechnet in der interessantesten Phase auf zu lernen. Jetzt läuft die Auswertung durch, nur der Kauf unterbleibt. - describe_config meldete "Steuerung möglich", während sie eine Zeile später abgeschaltet wurde. Übersicht und Schutzlogik teilen sich jetzt dieselbe Prüffunktion (control_effective / control_is_unsafe). Absicherung für Echtgeld - Starten im Live-Modus verlangt die Bestätigung START_LIVE_TRADING im Body (HTTP 428 ohne sie); das Dashboard fragt sie per Dialog ab. Pausieren geht immer ohne Bestätigung - anhalten muss schnell gehen. - Live-Modus mit offenem Port und ohne control_token wird nicht bedient: Die Steuerung wird beim Start abgeschaltet, der Bot läuft normal weiter. Sonst könnte jeder im Netz echten Handel starten. Bewusst nicht enthalten: ein Umschalter zwischen Paper und Live zur Laufzeit. Der bräuchte einen neuen Broker, andere Zugangsdaten und eine neue Kapitalbasis - und würde bedeuten, dass ein Web-Klick aus einer Simulation echten Handel macht. 174 Tests (21 neue), ruff sauber. Im gebauten Container geprüft: 401 ohne Token, 200 mit, idempotentes Pausieren, 400 bei kaputtem Payload, und im Live-Start mit ungültigen Dummy-Schlüsseln greift die Abschaltung der Steuerung. |
||
|
Tobias Zimmermann
|
3cd12b67aa |
Training über das Dashboard anstoßen
Neuer Abschnitt "Training" im Dashboard mit zwei Bedienelementen und den zugehörigen Endpunkten /control/train/history, /control/train/live und /control/training. Historisches Nachtraining - Kerzenanzahl je Symbol wählbar (500 bis 50 000), Fortschritt und Ergebnis werden im Dashboard angezeigt. - Läuft mit derselben Logik wie ein Backtest, aber ohne zu handeln, und speichert das Modell anschließend. - Handelsdurchlauf und Nachtraining teilen sich einen Mutex, damit sie nicht gleichzeitig auf Modell und Portfolio zugreifen. Die rechenintensive Schleife läuft in einem Worker-Thread, damit der Status-Server antwortbereit bleibt. - Ein zweiter Start wird abgelehnt, solange einer eingereiht ist oder läuft. Kontinuierliches Lernen - Schalter für das Online-Lernen im laufenden Betrieb. Ausgeschaltet handelt der Bot weiter, verändert das Modell aber nicht mehr. Label-Trennung - Vorgemerkte Labels tragen jetzt ein Tag. Ein Nachtraining darf die offenen Labels des Live-Betriebs weder auflösen noch verwerfen; ohne die Trennung würden sie gegen historische Kurse ausgewertet und das Modell mit falschen Ergebnissen gefüttert. - score() liest die Gewichte unter dem Lock, damit ein parallel laufendes Training keinen halb aktualisierten Vektor sichtbar macht. Absicherung - server.control_token (TRADEMIND_CONTROL_TOKEN) schützt alle Steuerbefehle über den Header X-TradeMind-Token; lesende Endpunkte bleiben offen. Ohne Token warnt der Bot beim Start, wenn der Port nicht nur lokal erreichbar ist. - server.enable_control: false entfernt die Routen vollständig. 153 Tests (25 neue), ruff sauber. Im gebauten Container geprüft: 202/409 beim Anstoßen, 401 ohne und mit falschem Token, +1099 Beobachtungen in 4,3 s bei weiterlaufendem Handels-Loop ohne Fehler. |
||
|
Tobias Zimmermann
|
65ed73977e |
Initial commit: TradeMind – Krypto-Trading-Bot mit Lernmodus
Per Podman deploybarer Bot, der Käufe und Verkäufe simuliert ausführt und sich aus den Ergebnissen weiter antrainiert. Aufbau - Einheitliche Bar-Verarbeitung für paper, backtest und live; ausgetauscht werden nur Datenquelle und Broker. - Börsenanbindung über ccxt: rund 100 Börsen allein über exchange.id erreichbar. Zugangsdaten kommen über ENV-Platzhalter, der Live-Modus ist doppelt abgesichert. - Paper-Broker mit Gebühren, Slippage, Börsenpräzision und Volumengrenzen. - Online trainierte logistische Regression bewertet jedes Einstiegssignal. Sie lernt aus realen Trade-Ergebnissen, aus Shadow-Labels aller Kandidaten – auch der abgelehnten – und aus Hintergrund-Stichproben; beim Kaltstart wird sie aus der Kurshistorie vorgelernt. - Risikomanagement: Positions- und Exposure-Grenzen, ATR-Stops, Cooldown sowie Tagesverlust- und Drawdown-Notbremsen. - SQLite-Persistenz, HTTP-Status mit Prometheus-Metriken und Dashboard, Webhooks. Deployment - Containerfile (zweistufig, non-root UID 10001), podman-compose, systemd-Quadlet. - Modell und Datenbank liegen im Volume /data und überleben Neustarts. 128 Tests, ruff sauber. Verifiziert gegen echte Marktdaten sowie im gebauten Container inklusive Healthcheck und Zustandswiederherstellung. |