Filter AutoConfig pairs based on a global variable's value

Gunbot's AutoConfig supports stateful automation through global variables. Variables set by other jobs can be used as filter conditions with built-in filterType options.

Use the AutoConfig wizard

Nearly every option that follows can be set without editing files by hand.
Click the ⋮ (three-dots) menu ➜ AutoConfig, step through the wizard, and press Save; it will write a correct autoconfig.json for you.

Global Variables as Filter Conditions

Global AutoConfig variables (managed via setVariable/resetVariable actions and stored in autoconfig-variables.json) can be used directly in filters with dedicated filterType options:

• variableExact: Passes if the global variable's current value is exactly equal to the specified value.
• variableBiggerThan: Passes if the global variable's current value is numerically greater than the specified value.
• variableSmallerThan: Passes if the global variable's current value is numerically smaller than the specified value.
• variableNotExist: Passes if the specified global variable does not exist in autoconfig-variables.json or is undefined.

Configuring Global Variable Filters

Define a filter rule inside your job’s filters (or filters2, etc.) object. The rule name can be anything. Inside the rule:

1. Set filterType to one of the four types listed above.
2. Add another key-value pair where:
   • The key is the exact global variable name.
   • The value is what you compare against (for variableExact, variableBiggerThan, variableSmallerThan). For variableNotExist, the value is typically an empty string or placeholder because only the key’s existence matters.

Example: Assume you have a global variable tradingEnabledSystemWide set to true or false by another job. You want an addPairs job to run only when this flag is true.

{
  "pairAdderWhenSystemEnabled": {
    "enabled": true,
    "type": "addPairs",
    "schedule": "*/10 * * * *",
    "pairs": {
      "exchange": "binance",
      "include": "USDT-"
    },
    "filters": {
      "isTradingEnabledGlobally": {
        "filterType": "variableExact", // Specify the filter type
        "tradingEnabledSystemWide": true // User defined global variable name and the value to check for
      },
      "standardVolumeFilter": {
        "filterType": "minVolume24h",
        "minVolume": 750000
      }
    },
    "strategy": "spotgrid"
  }
}

In the isTradingEnabledGlobally filter:

• "filterType": "variableExact" indicates the type of check.
• "tradingEnabledSystemWide": true tells AutoConfig to look for tradingEnabledSystemWide and pass the filter only when the value is exactly true.

The addPairs job proceeds only if isTradingEnabledGlobally and standardVolumeFilter both pass.

Example with variableBiggerThan: Suppose a global variable riskScore (ranging 0-100) is updated by a market analysis job. An aggressive strategy job should run only if riskScore is above 70.

{
  "aggressiveStrategyActivator": {
    // ... job settings ...
    "filters": {
      "isRiskScoreHigh": {
        "filterType": "variableBiggerThan",
        "riskScore": 70 // Pass if this.variables.riskScore > 70
      }
      // ... other filters ...
    }
    // ... actions ...
  }
}

Example with variableNotExist: Activate a setup job only if a certain initialization flag has not yet been set.

{
  "initialSetupJob": {
    // ... job settings ...
    "filters": {
      "isFirstRun": {
        "filterType": "variableNotExist",
        "initialSetupCompleteFlag": "" // Value here is a placeholder, presence of key matters
      }
    },
    "setVariable": { // Action if filter passes
      "initialSetupCompleteFlag": true
    }
    // ... other setup actions ...
  }
}

This initialSetupJob passes isFirstRun (and runs its actions, including setting initialSetupCompleteFlag) only if that global variable does not exist. On subsequent runs, the variable exists and the filter fails.

Benefits and Use Cases

• Stateful automation: One job sets a flag or counter, and later jobs react to it.
• Global control switches: Enable or disable behaviors across multiple jobs with one variable (e.g., enableAggressiveMode: true/false).
• Simplified logic: Built-in filters are more concise and less error-prone than writing a custom JavaScript filter just to read this.variables.myVar === someValue.
• Inter-job communication: Jobs can signal each other by modifying shared global variables.
• Mode management: Store modes like "bull_market_mode" or "bear_market_mode" and have jobs switch behavior based on the current value.

Important Considerations

• Variable existence and type:
  • For variableBiggerThan and variableSmallerThan, the global variable should hold a numerical value. Comparing a string or boolean with a number can produce unexpected results because of JavaScript type coercion.
  • If a variable checked by variableExact, variableBiggerThan, or variableSmallerThan does not exist, the filter generally fails (undefined does not compare predictably). Use variableNotExist to explicitly check for non-existence.
• Setting variables: These filters only read global variables. To change them, use setVariable or resetVariable actions in a job.
• Clarity: Many interconnected globals can make AutoConfig harder to trace. Use clear variable names and document stateful workflows.