Bedingung, Ereignis und Wartezeit auseinanderhalten
Angenommen, eine Bedingung lautet: Preis strikt größer als 100. Die Werte 101, 102 und 103 erfüllen sie alle. Sie belegen jedoch keine drei Aufwärtskreuzungen. Für diesen Leitfaden definieren wir eine solche Kreuzung als gültigen vorherigen Wert kleiner oder gleich 100, gefolgt von einem gültigen Wert über 100. Gleichheit zählt hier ausdrücklich zur unteren Seite.
Eine Wiederholungsregel kann eine weitere Aktion erlauben, solange die Bedingung erfüllt bleibt. Eine Kreuzungsregel verlangt dagegen einen neuen Übergang. Beide können zusätzlich eine Wartezeit vorsehen. Auch TradingView unterscheidet Vergleichsoperatoren und Alarmhäufigkeit; daraus folgt keine Integration mit SharkRule.
Halte fest, was die Wartezeit startet: Freigabe einer Order, Ausführung oder Abschluss einer Position sind unterschiedliche Ereignisse. Freqtrade beschreibt CooldownPeriod je Handelspaar nach einem Ausstieg. Das ist dessen Verhalten, weder eine allgemeine Definition noch ein Beleg für den Timerbeginn bei SharkRule.
Die Regeln des Rechenbeispiels zuerst festlegen
Alle Zeiten, Preise und Beträge sind fiktiv und keine Empfehlung für ein Asset oder eine Einstellung. Die Papierübung umfasst eine Regel und ein unbenanntes Spot-Handelspaar. Wir verwenden aktuelle, zeitlich geordnete Beobachtungen in Einheiten der Kurswährung und UTC-Zeiten. Nur die aufgeführten Zeilen werden ausgewertet. Die erste legt den vorherigen Zustand fest, ohne eine Kreuzung zu erzeugen. Es werden keine echten Orders gesendet.
Ein Einstieg ist nur bei einer neuen Aufwärtskreuzung von 100 erlaubt, frühestens 120 Sekunden nach dem letzten erlaubten Einstieg. Genau 120 Sekunden reichen aus. Jede Freigabe reserviert sofort 25 für den Kauf und 1 für Kosten, startet die Wartezeit und verbraucht einen von höchstens zwei Einstiegen dieses Durchlaufs. Das kumulierte Budget beträgt 60 einschließlich Kostenreserven. Das sind erfundene Übungsregeln, keine SharkRule-Standardwerte.
Eine blockierte Kreuzung wird protokolliert und verworfen, nicht vorgemerkt. Jede gültige Beobachtung aktualisiert den vorherigen Preis, auch während der Wartezeit. Blockierte Kandidaten starten diesen Timer nicht neu. Wir nehmen an, dass Berechtigungen und alle weiteren Prüfungen erfüllt sind und kein früherer Orderausgang ungeklärt ist. Gezählt werden Freigaben und reservierte Beträge, keine Börsenannahmen oder Ausführungen.
Signalprotokoll: sechs erfüllte Bedingungen, zwei Freigaben
| Uhrzeit UTC | Preis | Über 100? | Neue Aufwärtskreuzung? | Entscheidung |
|---|---|---|---|---|
| 09:59:59 | 99 | Nein | Anfangszustand | Keine Aktion |
| 10:00:00 | 101 | Ja | Ja | Einstieg 1 erlaubt; 26 reservieren |
| 10:00:30 | 102 | Ja | Nein | Bedingung bleibt erfüllt; kein neues Ereignis |
| 10:01:00 | 99 | Nein | Nein | Wieder unter der Schwelle |
| 10:01:30 | 101 | Ja | Ja | Erst 90 Sekunden vergangen; verwerfen |
| 10:02:00 | 102 | Ja | Nein | 120 Sekunden vergangen, aber keine neue Kreuzung |
| 10:03:00 | 99 | Nein | Nein | Wieder unter der Schwelle |
| 10:03:30 | 101 | Ja | Ja | 210 Sekunden vergangen; Einstieg 2 erlaubt; 26 reservieren |
| 10:06:00 | 99 | Nein | Nein | Wieder unter der Schwelle |
| 10:06:30 | 101 | Ja | Ja | 180 Sekunden vergangen; Anzahl und Budget blockieren Einstieg 3 |
Zählung prüfen, ohne das Budget zurückzusetzen
Zehn Beobachtungen enthalten sechs Werte über 100 und vier Aufwärtskreuzungen. Drei Kreuzungen erfüllen die zeitliche Vorgabe: Um 10:00:00 gibt es keinen früheren Einstieg, um 10:03:30 sind seit Einstieg 1 insgesamt 210 Sekunden vergangen und um 10:06:30 seit Einstieg 2 weitere 180 Sekunden. Nur die ersten beiden erfüllen zusätzlich Anzahl- und Ausgabenlimit.
Jeder Einstieg bindet 25 + 1 = 26. Zwei binden 2 × 26 = 52; übrig bleiben 60 − 52 = 8. Ein dritter würde den Betrag auf 78 erhöhen, also um 18 über das Budget von 60, und zugleich das Limit von zwei Einstiegen überschreiten. Längeres Warten beseitigt keine dieser beiden Grenzen. Die Kosteneinheit ist eine fiktive Reserve, keine tatsächliche Börsengebühr; echte Kosten und Verpflichtungen müssen abgeglichen werden.
Um 10:02:00 könnte eine andere Regel mit weiterhin erfüllter Bedingung ihren zweiten Einstieg erlauben, bei gleicher Wartezeit und verfügbaren Limits. Unsere Kreuzungsregel kann das nicht: Das Ereignis von 10:01:30 wurde verworfen, und 101 → 102 ist keine weitere Kreuzung. Gespeicherte Ereignisse wären eine dritte Regelvariante mit Ablaufzeit und erneuter Prüfung. Aus einem Countdown lässt sich eine solche Warteschlange nicht ableiten.
Häufige Fehler bei Wiederholungen und Wartezeiten
Wer jede Abfrage als neues Ereignis zählt, vervielfacht Aktionen bei einer dauerhaft erfüllten Bedingung. Wer nach Ablauf eines Cooldowns sofort eine Aktion erwartet, übersieht bei einer Kreuzungsregel den erforderlichen neuen Übergang. Auch ein Start oberhalb der Schwelle braucht eine festgelegte Initialisierung: Die erste Beobachtung allein beweist keine Kreuzung.
Eine doppelte Zustellung desselben Ereignisses ist etwas anderes als eine spätere Beobachtung zum gleichen Preis. Notiere Ereigniskennung oder Beobachtungszeit und Regelversion. Ein Duplikat kann nach Ablauf der Wartezeit eintreffen. Ein Neustart darf frühere Ereignisse, Timer, Einstiegszähler und Ausgabenverpflichtungen nicht stillschweigend löschen.
Fehlende Daten sind kein falscher Messwert, der die Bedingung zurücksetzt. Eine scheinbare Kreuzung nach einer Lücke verlangt eine Prüfung der dokumentierten Datenwiederherstellung. Pendeln beobachtete Preise um 100, können außerdem mehrere echte Kreuzungen entstehen. Eine Wartezeit begrenzt die Häufigkeit, nicht die Qualität eines Signals.
Ein Timeout beweist keinen Orderfehlschlag. Binance verlangt die Prüfung eines ungewissen Orderstatus. Bei SharkRule muss eine ungeklärte Binance-Übermittlung weitere Binance-Übermittlungen blockieren. Bewahre Originalorder und Ausgabenvermerk während des Abgleichs auf; verstrichene Zeit hebt diese Sperre nicht auf.
Checkliste für die Wiederholungsregel
- Börse, Handelspaar, Eingabewert, Vergleich und Auswertungszeitpunkt festhalten. Gleichheit und erste Beobachtung definieren. Dauerhaft erfüllte Bedingung von neuer Kreuzung unterscheiden.
- Geltungsbereich der Wartezeit klären: einzelne Regel, Handelspaar oder gesamtes Konto. Start, Einheit und exakte Grenze notieren. Andere Regeln teilen den Timer nicht zwangsläufig.
- Festlegen, ob Signale während der Wartezeit verworfen oder mit Ablaufzeit und erneuter Prüfung gespeichert werden. Prüfen, ob blockierte Signale die Wartezeit neu starten.
- Maximale Einstiege, kumuliertes Budget, Kosten und offene Verpflichtungen aufschreiben. Für jeden Zähler den erlaubten Rücksetzzeitpunkt klären. Neustart, Verkauf oder Timerablauf schaffen nicht automatisch neue Ausgabenfreigaben.
- Eine kurze Papierfolge mit dauerhaft wahrer Bedingung, Rückkehr unter die Schwelle sowie Kreuzungen während und nach der Wartezeit durchgehen. Doppelte Zustellung, Datenlücke und ausgeschöpftes Budget ergänzen.
- Erwartete Entscheidungen mit verfügbaren Aktivitäten vergleichen. Blockierten Kandidaten, Sendefreigabe, Börsenannahme und Ausführung unterscheiden. Ungeklärte Ergebnisse bis zur Prüfung als ungeklärt behandeln.
Grenzen der Prüfung und dein nächster Schritt
Die Übung zeigt, ob eine formulierte Regel ihre Wiederholungsvorgaben einhält. Sie ermittelt keine profitable Wartezeit. Warten kann Bewegungen auslassen; Wiederholungen können Gebühren und Engagement erhöhen. Verluste, Slippage, Teilausführungen, ausbleibende Ausführungen und Börsenausfälle bleiben möglich. Eine Simulation garantiert keine echten Ausführungen.
Öffne die deutsche SharkRule-Übersicht für Binance unter Quellen und prüfe Kaufbetrag und maximale Käufe vor einem ausdrücklichen Start. Sie nennt auch Cooldowns für individuelle Regeln. Vergleiche die tatsächlich für deinen Shark angezeigten Kontrollen mit dem Arbeitsblatt; die Übersicht legt weder den Timerbeginn noch Kreuzungslogik oder Behandlung blockierter Signale dieses Beispiels fest.
Verfügbare Regeln und Berechtigung hängen vom aktuellen Dashboard, Konto und Standort ab. Eine Börsenverbindung startet keinen Handel. SharkRule ist unabhängige Software, ohne Verbindung zu oder Unterstützung durch Binance. Wir bieten keine Finanz- oder Anlageberatung; erklärt werden Abläufe, keine empfohlenen Assets, Allokationen, Positionsgrößen oder Trades.
Häufige Fragen
Bedeutet Cooldown genau einen Trade je Signal?
Für sich allein nicht. Ein Cooldown verlangt eine Wartezeit gemäß der jeweiligen Regel. Eine weiterhin erfüllte Bedingung kann danach eine weitere Aktion erlauben; eine Kreuzungsregel benötigt einen neuen Übergang. Ein separates Einstiegslimit begrenzt die Gesamtzahl.
Was passiert mit einer Kreuzung während der Wartezeit?
Das bestimmt die dokumentierte Regel. Hier wird sie verworfen, während der vorherige Preis aktualisiert wird. Eine gespeicherte Kreuzung benötigt Ablaufzeit und erneute Prüfung. Eine spätere Ausführung darfst du nicht voraussetzen.
Erneuert Pausieren und Neustarten das Budget?
Gehe nicht davon aus. Prüfe gespeicherte Zähler, offene Orders und kumulierte Verpflichtungen. Eine neue Sitzung belegt keinen freien Ausgabenrahmen. Ist das Verhalten nach einem Neustart unbekannt, fehlen Informationen.
Sind zwei Minuten die passende Wartezeit?
Die 120 Sekunden machen nur die Rechnung nachvollziehbar. Diese Dauer ist keine Empfehlung; weniger Aktionen belegen kein besseres Ergebnis. Kläre zuerst Eingaben, Timerbeginn und weiterhin geltende Grenzen deiner Regel.
Offizielle Dokumentation und Quellen
Mit KI-Unterstützung anhand der verlinkten offiziellen Dokumentation erstellt. Die Beispiele sind hypothetisch; es wurden keine Live-Konten getestet oder Renditen verglichen.
- SharkRule: Binance-Regelprüfung, Kaufbetrag und maximale Käufe
https://sharkrule.com/de/binance-trading-bot/ - TradingView: Vergleichsoperatoren und Alarmhäufigkeit
https://de.tradingview.com/support/solutions/43000763312/ - Freqtrade: CooldownPeriod je Handelspaar nach einem Ausstieg
https://www.freqtrade.io/en/stable/plugins/#cooldown-period - Binance Spot: Timeout und unbekannter Ausführungsstatus
https://developers.binance.com/en/docs/products/spot/rest-api