Pine Script & TradingView-Alerts

alertcondition() stellt Bedingungen eines Indikators bereit, alert() unterstützt dynamische Nachrichten und Strategien liefern zusätzlich Order-Fill-Ereignisse, die für die Automatisierung genutzt werden können.

Prüfe die serverseitige Alert-Instanz und nicht nur den aktuellen Chart. Alerts verwenden einen gespeicherten Snapshot. Auch Repainting, Ablaufdatum, Laufzeitfehler und Frequenzlimits können fehlende Alerts erklären.

TradingView führt den serverseitig gespeicherten Snapshot von Skript, Eingaben, Symbol und Zeitrahmen aus, der beim Erstellen des Alerts vorhanden war. Spätere Änderungen am Chart aktualisieren diesen Alert nicht. Erstelle ihn neu, sobald sich Logik oder Kontext ändern.

Once Per Bar kann während einer Echtzeitkerze reagieren; Once Per Bar Close wartet auf das Schlussupdate. Verwende bestätigte Kerzen, wenn die Strategie eine Bestätigung verlangt, und Intrabar-Verhalten nur, wenn die Logik bewusst für Echtzeitupdates entwickelt und getestet wurde.

Repainting bedeutet, dass vergangene oder historisch dargestellte Ergebnisse von dem abweichen können, was in Echtzeit vorhanden war. Für die Automatisierung ist entscheidend, ob sich genau die Daten, die den Live-Alert ausgelöst haben, später ändern oder auf historischen Kerzen nicht reproduzieren lassen.

Mit calc_on_every_tick=true wird eine Strategie bei jedem neuen Echtzeitupdate neu berechnet und nicht nur beim Kerzenschluss. Historische Kerzen enthalten nicht denselben vollständigen Tickstrom, weshalb Live-Verhalten und Verhalten nach dem Neuladen voneinander abweichen können.

Order-Fill-Alerts lösen aus, wenn der Brokeremulator von TradingView eine Strategieorder ausführt, und entsprechen daher häufig besser der Automatisierung von Strategieausführungen. alert() ist flexibler für beliebige Laufzeitlogik und dynamische Nachrichten.

TradingView stoppt einen normalen beziehungsweise skriptbasierten Alert automatisch, wenn er innerhalb von drei Minuten mehr als 15-mal auslöst. Hochfrequente Logik muss die Alert-Frequenz selbst begrenzen, statt von einem unbegrenzten Weiterlaufen auszugehen.

Nutze eindeutige Zustandswechsel, Abkühlzeiten und eine passende Alert-Frequenz, statt Nachrichten pauschal zu unterdrücken. TradingView kann einen Skript-Alert stoppen, wenn er innerhalb von drei Minuten mehr als 15-mal auslöst. Hochfrequente Systeme benötigen daher eine bewusst entworfene Ereignislogik.

Erstelle und prüfe den Ersatz-Alert, bevor du den alten stilllegst. Verhindere jedoch, dass beide gleichzeitig ausführungsaktiv sind. TradingView-Alerts laufen als gespeicherte Snapshots; eine Änderung am Chart-Skript aktualisiert einen bestehenden Alert nicht.

Ja. Ein neu erstellter Alert entfernt den bisherigen serverseitigen Alert nicht automatisch. Wenn beide denselben Ausführungsweg ansprechen, können sie unabhängig voneinander auslösen und doppelte Befehle erzeugen.

Vergib für Strategie-Releases, Alert-Instanzen und Webhook-Schemas eindeutige Versionsnummern. So belegen Support und Audit-Protokolle, welche Logik ein Live-Signal erzeugt hat, und stille Inkompatibilitäten nach Skriptänderungen werden vermieden.

Manchmal, aber nur wenn das Echtzeitverhalten beabsichtigt, dokumentiert und getestet ist. Ein repaintendes Skript kann für den Live-Einsatz geeignet sein, obwohl historische Charts oder Backtests kein verlässlicher Nachweis für das tatsächliche Echtzeitgeschehen sind.

request.security() kann auf Echtzeitkerzen unbestätigte Werte des höheren Zeitrahmens liefern, die sich nach der Bestätigung unterscheiden. TradingView dokumentiert für nicht repaintende HTF-Werte ein Muster mit einem Versatz um eine Kerze und barmerge.lookahead_on.

barstate.isconfirmed ist auf historischen Kerzen und beim letzten Update einer Echtzeitkerze wahr. Damit lässt sich ein Signal des Chart-Zeitrahmens bis zur Kerzenbestätigung verzögern. TradingView weist jedoch darauf hin, dass es innerhalb von request.security() nicht als Bestätigungsmechanismus funktioniert.

calc_on_order_fills lässt eine Strategie nach einer Orderausführung neu berechnen, sodass sie sofort auf simulierte Positionsänderungen reagieren kann. Die Option kann zugleich unrealistisches historisches Verhalten erzeugen und erfordert deshalb einen sorgfältigen Vergleich zwischen Live-Handel und Backtest.

process_orders_on_close erlaubt dem TradingView-Brokeremulator, eine Strategieorder bereits beim Schlusstick der Signalkerze statt auf der nächsten verfügbaren Kerze auszuführen. TradingView warnt, dass eine externe Live-Ausführung diesen Fill besonders am Sitzungsende eventuell nicht nachbildet.

Chart-Marker, Alert-Auswertung und Live-Brokerausführung können unterschiedliche Zeitpunkte und Preise verwenden. Echtzeit-Updates, Strategieausführung, Bid-/Ask-Spread, Latenz und Slippage können deshalb berechtigte Abweichungen verursachen.

Nach dem Neuladen werden Echtzeitkerzen zu historischen Kerzen und verlieren ihre ursprüngliche Folge von Intrabar-Updates. Tickabhängige, repaintende oder reine Echtzeitlogik kann daher im historischen Verlauf ein anderes Verhalten anzeigen.

varip erhält Werte zwischen Ausführungen innerhalb derselben Echtzeitkerze und umgeht damit das normale Pine-Rollback. Historische Kerzen können diese Intrabar-Ausführungsfolge nicht nachbilden; von varip abhängige Backtests können deshalb irreführend sein.

Bar Magnifier verwendet Daten eines niedrigeren Zeitrahmens, um die historischen Fill-Annahmen des Brokeremulators zu verbessern. Dadurch lassen sich mehrdeutige Intrabar-Abfolgen von Orders besser auflösen, eine echte Brokerausführung wird jedoch weiterhin nicht nachgebildet.

Pyramiding steuert aufeinanderfolgende Ergänzungen durch strategy.entry() in derselben Richtung. Wird jeder daraus entstehende Alert zu einem neuen Live-Einstieg, kann beabsichtigtes oder versehentliches Pyramiding das cTrader-Exposure vervielfachen.