Target AutoConfig actions to pairs with a specific strategy name

Gunbot's AutoConfig can manage various aspects of your trading pairs, including their assigned strategies and overrides. A common requirement is to apply certain AutoConfig actions—like changing overrides or switching strategies—only to pairs that are currently configured with a specific trading strategy. AutoConfig provides the strategyName filter type for this exact purpose.

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.

Filtering by Assigned Strategy

Many AutoConfig jobs, such as manageOverrides or changeStrategy, operate on pairs that are already part of your Gunbot configuration. The strategyName filter allows these jobs to be selective, targeting only those pairs that are currently set up to use a particular trading strategy.

This is powerful because it means you can:

• Fine-tune parameters for all pairs running, for example, your "scalper" strategy.
• Transition pairs from an "accumulation" strategy to a "profit_take" strategy based on certain conditions.
• Apply risk-off overrides to all pairs using an aggressive strategy during volatile market times.

Configuring the strategyName Filter

To use this filter:

1. Define a filter rule within your AutoConfig job's filters (or filters2, etc.) object.
2. Set the filterType to "strategyName".
3. Provide one more key-value pair. The key here is arbitrary (a name for your rule, like checkStrat), but the value must be the string name of the strategy you want to target. The comparison is case-insensitive.

Example: Suppose you want to apply a new set of overrides to all pairs on Binance that are currently using the "stepgrid" strategy.

{
  "updateStepGridPairs": {
    "enabled": true,
    "type": "manageOverrides",
    "schedule": "0 2 * * *", // Runs daily at 2 AM
    "pairs": {
      "exchange": "binance",
      "include": "USDT-" // Consider all USDT pairs on Binance
    },
    "filters": {
      "isUsingStepGrid": { // Your descriptive name for this filter rule
        "filterType": "strategyName",
        "anyKeyNameForThisRule": "stepgrid" // The value is the strategy name to match
                                           // "stepgrid", "StepGrid", "STEPGRID" will all match.
      }
      // You can add other filters here; all must pass for the action
    },
    "overrides": { // Overrides to apply if 'isUsingStepGrid' (and any other filters) pass
      "STOP_LIMIT": 1.5, // Example: adjust stop limit
      "GAIN": 0.7
    }
  }
}

In the isUsingStepGrid filter:

• "filterType": "strategyName" specifies the kind of check.
• "anyKeyNameForThisRule": "stepgrid": AutoConfig looks at the value "stepgrid". For each pair the job evaluates, it checks the strategy assigned to that pair in your config.js. If the assigned strategy name, when compared case-insensitively, matches "stepgrid", this filter rule passes for that pair. The key "anyKeyNameForThisRule" is just a placeholder; its name doesn't affect the filter's logic, only its value does.

If the updateStepGridPairs job evaluates USDT-BTC on binance, and USDT-BTC is currently configured with the stepgrid strategy, the isUsingStepGrid filter passes for USDT-BTC. If USDT-ETH is using spotgrid, the filter fails for USDT-ETH.

Use Cases and Scenarios

1. Bulk Override Updates for a Strategy Type:

   • If you decide that all your emotionless strategy pairs need a tighter STOP_LIMIT, a manageOverrides job with a strategyName filter targeting "emotionless" can apply this change globally to those pairs.

2. Conditional Strategy Switching:

   • An AutoConfig job of type changeStrategy can be used to switch pairs from "strategyA" to "strategyB". The strategyName filter would target "strategyA". Other filters in the set would define the conditions under which this switch should occur (e.g., market volatility drops below a threshold).

   // Conceptual part of a 'changeStrategy' job
   "filters": {
     "currentlyStrategyA": {
       "filterType": "strategyName",
       "currentStrategy": "strategyA"
     },
     "marketIsCalm": { /* ... some other filter ... */ }
   },
   "strategy": "strategyB" // The new strategy to assign

3. Phased Rollout or Testing:

   • If you're introducing a new strategy, "newStrategyX", you might initially assign it to a few pairs manually. An AutoConfig job could then specifically target pairs running "newStrategyX" to apply experimental overrides or monitor their performance via setPairVariable.

4. Cleaning Up or Migrating Old Strategies:

   • If you're deprecating an old strategy, say "oldStrat", a changeStrategy job can find all pairs still using "oldStrat" and switch them to a newer, preferred strategy.

Important Considerations

• Job Type Relevance: The strategyName filter is most relevant for job types that operate on existing pairs in your configuration, like manageOverrides, changeStrategy, and removePairs. It's less directly applicable to addPairs (which assigns a strategy to new pairs) or collectData.
• Exact Strategy Name: Ensure the strategy name provided in the filter value matches the name as defined in your strategies block in config.js (though the comparison is case-insensitive).
• Combination with Other Filters: The strategyName filter can be combined with any other filter types (ticker-based, state-based, custom, variable-based) within the same filter set. All filters in the set must pass for the job's action to be applied.
• Overrides vs. Base Strategy: This filter checks the assigned strategy name for the pair. It doesn't directly check if specific parameters within that strategy have been overridden for the pair. To check specific active parameters (which could be from base strategy or overrides), you'd typically use a custom filter and inspect this.pair.whatstrat or this.config.pairs[this.exchange]Name[this.pairName].override.

The strategyName filter is a valuable tool for targeted automation in AutoConfig, allowing you to manage groups of pairs based on their active trading logic. This helps in maintaining consistency, rolling out changes efficiently, and implementing sophisticated, strategy-aware management workflows.