Alert scripting is a good way to create more complex alerts without feeling limited by the number of conditions or their limited reusability. This page covers the syntax of scripted alerts as well as showcasing typical use cases for alert scripting.

​
Building Simple Conditions

Users can define a simple condition over a single line in the tex area “Condition Input Field”. In order to build effective conditions, we will need to reference specific data using placeholders and compare this data with each other using operators. For example, we could define the following condition: 
{close} > {close[14]}
Here we have the following elements:
  • {close} placeholder, referencing the current closing price value
  • Greater than operator >, testing if the value to its left is greater than the value to its right
  • {close[14]} refer to the value of the closing price ({close}) 14 bars ago (defined by the historical referencing operator [14])
This simple condition is True if the current closing price is higher than the closing price 14 bars ago.

​
Combining Conditions

Creating slightly more complex conditions can involve combining individual ones into a single one, allowing us to retain more precise events or on the contrary, loosen our condition rules.

​
Combination using and

Using the operator and allows to require more than one “sub-conditions” to be valid for the whole to be true. For example, we could reuse our previous condition but be more strict such that we only want to know when the current closing price is greater than the closing price 14 bars ago when it is between 1pm and 3pm (exchange timezone). To do this we can simply add another sub-condition leading to: 
{close} > {close[14]} and {hour} >= 13 and {hour} <= 15
and is similar to using the custom alert creator and having multiple enabled conditions using the same step number.
Another example where we can combine multiple conditions is to detect FVG’s, for the case of a bullish FVG we have the following requirements:
  • current low price is higher than the high price two bars ago
  • previous closing price is higher than the high price two bars ago
We can use alert scripting to detect bullish FVG’s from this combination of conditions as follows: 
{low} > {high[2]} and {close[1]} > {high[2]}

​
Combination using or

Sometimes we might be interested in getting alerted about two specific different conditions, without having to create two specific alerts. This is where or can be useful, requiring only one of the defined sub-conditions to be true in order for the alert to trigger. For example, we could want to be alerted either on a strong bullish confirmation signal, or when the Smart Trail turns bullish, this could be easily achieved using the following script: 
{bullish_confirmation+} or {bullish_smart_trail} and not {bullish_smart_trail[1]}
Here {bullish_confirmation+} is true when we have a strong bullish confirmation signal. {bullish_smart_trail} when the Smart Trail is bullish, with the whole {bullish_smart_trail} and not {bullish_smart_trail[1]} being true when the Smart Trail is currently bullish while the previous Smart trail is not bullish.
or takes precedence over and. You can think of this as a way to split a whole condition into multiple sub-conditions.For example if we have {A} and {B} or {C} > 0 or {D} and {E}, the precedence of or would split this conditions leading to {A} and {B}, {C} > 0, and {D} and {E}.Each of these individual sub-conditions would be evaluated individually, if one of them is true, then our whole condition is true.

​
Sequencing and Using Steps

Users can create sequences of conditions, triggering an alert when the last step is triggered. Steps are made using linebreaks, with each conditions over a new line being a step. When a step is valid, the next step condition located on the line below will be evaluated at the next bar. Once the last step is evaluated and is true, the sequence is completed which can trigger an alert (if set) and will switch to the first defined step on the next bar.
This is similar in practice to how the custom alert creator works.
For example, we can define a sequence consisting of the following conditions:
  • Step 1: High price is lower than the previous high price
  • Step 2: Low price is lower than the previous low price
  • Step 3: Closing price is lower than the opening price
Leading to the following script: 
{high} < {high[1]}
{low} < {low[1]}
{close} < {open}
For clarity you can assign conditions over a single line to a variable defined at the start.
condition1 = ...
condition2 = ...
condition3 = ...
Do note that the variable cannot be referenced.

​
Invalidation

Invalidation refers to going back to evaluating the first step of a sequence of conditions when one or more specific conditions are true.
Invalidation takes place prior to evaluating steps.
Invalidation conditions can be defined using the @invalidate action: 
@invalidate() = ...
If the condition assigned to the @invalidate action is true, we will go back to evaluating the sequence of conditions to step 1.
multiple invalidation conditions can be defined separately for clarity:
@invalidate() = ...
@invalidate() = ...
@invalidate() = ...

​
Step Specific Invalidation

It is possible to apply invalidation conditions to specific steps, this is done using the step parameter in the @invalidate action. To illustrate this, we can reuse our previous sequence of conditions: 
{high} < {high[1]}
{low} < {low[1]}
{close} < {open}
Maybe that we don’t want the closing price to be greater than the opening price as long as the second step is the one being evaluated, this can be achieved by simply as follows: 
{high} < {high[1]}
{low} < {low[1]}
{close} < {open}

@invalidate(step=1) = {close} > {open}
Here step=1 refer to the second step needing to be the one being evaluated in the sequence to apply the invalidation condition {close} > {open}.
With steps, 0 refers to the first step because it is 0 indexed.

​
Invalidate on Step Evaluation Duration

Sometimes we might not want to keep evaluating one or multiple steps for an excessive number of bars, and instead prefer having each step being triggered with a short interval in between. This can easily be done using invalidation and the placeholder barssince_step, which quantify the number of bars that elapsed since a step has started being evaluated or since invalidation took place. For example, we can invalidate a sequence of conditions if the amount elapsed since a step is greater than 5 bars: 
{high} < {high[1]}
{low} < {low[1]}
{close} < {open}

@invalidate() = {barssince_step} > 5

​
Global Filters

It is possible to define a single global condition that will be applied to all defined steps conditions using the action @filter. 
@filter() = ...
This can be useful to avoid repeated sub-conditions in your step conditions. For example, if we have: 
{high} < {high[1]} and {volume} > 500
{low} < {low[1]} and {volume} > 500
{close} < {open} and {volume} > 500
We can instead use a global filter to avoid repeating {volume} > 500, leading to: 
{high} < {high[1]}
{low} < {low[1]}
{close} < {open}

@filter() = {volume} > 500

​
Step Specific Filtering

It is possible to apply filters to specific steps, this is done using the step parameter in the @filter action. 
{high} < {high[1]}
{low} < {low[1]}
{close} < {open}

@filter(step=1) = {volume} > 500
Here step=1 refer to the second step where our filtering condition {volume} > 500 will be applied.

​
Visualizing Scripted Alerts Conditions

In order to make sure the scripted alert corresponds to the desired result and that it triggers as expected, users can visualize when the alert would have triggered using the “Highlight On Chart” setting. Enabling this setting will display a series of squares located at the top or bottom of the chart. When the condition is true the square will be colored in blue or the selected color from the setting.
Users can control the location of this highlighter on the chart trough the dropdown menu.“Top” and “Bottom” locations are available, while the Oscillator Matrix toolkit also includes a “Center” option.“None” will hide the scripted alert highlighting.

​
Setting Scripted Alerts

Once a scripted alert is defined, we can create an alert using it as a condition by enabling the “Scripted Alert” setting in the “Any alert() Function Call” settings group located at the bottom of the toolkit settings. Then we can create the alert by clicking on the alert menu, selecting the toolkit in the condition dropdown, and making sure the dropdown below has “any alert() function call” selected.

​
Comments

To make a scripted alert easier to read, users can add comments by starting a line with //. Comments will be ignored when a scripted alert is evaluated. For example: 
// Step 1: candle color becomes green
{barcolor} > 0 and not {barcolor[1]} > 0

// Step 2: candle color is red
{barcolor} < 0