Use 'resetPairVariable' for pairs failing AutoConfig job filters

Gunbot's AutoConfig can manage per-pair variables when pairs pass filters (setPairVariable) and when they fail (resetPairVariable). The resetPairVariable action runs for each evaluated pair that does not meet the job's main filters (or filters2, etc.), letting you update non-qualifying pairs explicitly.

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.

setPairVariable vs. resetPairVariable for Individual Pairs

When an AutoConfig job (for example, manageOverrides) iterates through a list of pairs defined by pairs.include and pairs.exclude:

• For each pair, it evaluates the conditions in the filters (and filters2, etc.) objects.
• If a pair passes all conditions in at least one filter set:
  • The job's main action (e.g., applying overrides) is performed for that pair.
  • The setPairVariable block, if present, is executed for that pair, updating its specific variables.
• If a pair fails to pass all conditions in any filter set:
  • The job's main action is not performed for that pair.
  • The resetPairVariable block, if present, is executed for that pair, allowing you to set or update its specific variables to reflect its "non-passing" status.

This per-pair conditional execution makes resetPairVariable a precise tool for managing state.

Configuration Example

This example sets a per-pair variable isActiveTrend to true for "hot" pairs and resets it to false when a pair no longer meets the criteria.

{
  "trendStatusManager": {
    "enabled": true,
    "type": "manageOverrides2", // Type allows iteration over existing pairs and collects tickers
    "schedule": "*/10 * * * *",
    "pairs": {
      "exchange": "binance",
      "include": "USDT-" // Consider all USDT pairs
    },
    "filters": { // Conditions for a pair to be considered in an "active trend"
      "highVol": {
        "filterType": "minVolume24h",
        "minVol": 2000000
      },
      "highVolatility": {
        "filterType": "minVolatilityPct24h",
        "minVolatility": 5
      }
    },
    "setPairVariable": { // For pairs PASSING the filters
      "isActiveTrend": true,
      "trendStartTime": " new Date().getTime() " // Record when trend started for this pair
    },
    "resetPairVariable": { // User setting: For pairs FAILING the filters
      "isActiveTrend": false
      // We might choose not to clear 'trendStartTime' here, or set it to null,
      // depending on whether we want to remember when it was last active.
    }
    // This job might not apply any 'overrides' if its only goal is variable management.
  }
}

In the trendStatusManager job:

• It iterates through all USDT pairs on Binance.
• For each pair:
  • If it has volume > 2M AND volatility > 5% (passes filters):
    • setPairVariable executes: isActiveTrend for that pair becomes true, and trendStartTime is updated.
  • If it does NOT meet both conditions (fails filters):
    • resetPairVariable executes: isActiveTrend for that pair becomes false.

This ensures that the isActiveTrend variable for each pair accurately reflects its current status based on the latest filter evaluation.

Dynamic Values in resetPairVariable

Values in resetPairVariable can also be dynamic JavaScript expressions (string starting with a leading space), using context like this.pair and this.variables.

"resetPairVariable": {
  "failedFilterStreak": " ( (this.pairVariables[this.exchangeName]?.[this.pairName]?.failedFilterStreak || 0) + 1 ) ",
  "reasonForInactive": " 'Volume below threshold at ' + new Date().toLocaleTimeString() "
}

• failedFilterStreak: Increments a counter specific to this pair each time it fails the job's main filters.
• reasonForInactive: Stores a descriptive string for why the pair is now considered inactive by this job. (Note: this is a simplified example; determining the exact failing filter rule to populate this dynamically from within resetPairVariable itself is complex. Usually, the reason is implicit by the job's design.)

When using this.pair in resetPairVariable expressions, remember that the pair failed the main filters. Data still reflects the pair’s state at the time of failure, which can be useful for logging or setting failure-state variables.

Use Cases for resetPairVariable

1. Clearing status flags: If setPairVariable sets pairState: "active_buy_signal", resetPairVariable can set pairState: "monitoring" when conditions no longer hold.
2. Resetting counters: If setPairVariable increments successiveBuysForPair, resetPairVariable can reset it to 0 when the chain breaks.
3. Managing cooldown flags: resetPairVariable can clear isInCooldown: true when conditions allow.
4. Maintaining accurate state: Keeps per-pair variables aligned with current filter results.
5. Tagging non-qualifying pairs: Mark pairs that repeatedly fail key filters for review or later actions.

Key Differences and Considerations

• Execution condition: setPairVariable acts on filter pass (per pair); resetPairVariable acts on filter fail (per pair).
• Mutually exclusive per pair: For a given pair in a single job run, only one block executes (or neither if not present).
• No global fallback: Unlike resetVariable (global vars), resetPairVariable evaluates each failing pair individually.
• Purpose: setPairVariable defines an "active" state; resetPairVariable defines a default or inactive state.

resetPairVariable complements setPairVariable by keeping per-pair state aligned with whether a pair currently meets a job's filters.