Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Share exit signal from one pair to another #10141

Closed
darioneto opened this issue Apr 28, 2024 · 7 comments
Closed

Share exit signal from one pair to another #10141

darioneto opened this issue Apr 28, 2024 · 7 comments
Labels
Question Questions - will be closed after some period of inactivity. Strategy assistance Help with a strategy

Comments

@darioneto
Copy link

Describe your environment

  • Operating system: Docker
  • Python Version: ___Python 3.12.2
  • CCXT version: ____ccxt==4.2.87
  • Freqtrade Version: _docker-2024.4-dev-15cbca51

Your question

Could you please advise the best method to evaluate conditions for exit and share exist signal from one pair to use it with different pair as exit condition.

@darioneto darioneto added the Question Questions - will be closed after some period of inactivity. label Apr 28, 2024
@stash86
Copy link
Contributor

stash86 commented Apr 28, 2024

Use one or more global variable(s)

@darioneto
Copy link
Author

thanks, do you think I could find any relevant doc which describes this process in more details?

@xmatthias xmatthias added the Strategy assistance Help with a strategy label Apr 28, 2024
@xmatthias
Copy link
Member

Not really - and i don't think it's something we should be adding to the documentation, either.

You'll usually want to treat pairs independently (why would a good running pair be sold because a random other pair is doing badly?).

What you might be looking for is informative pairs - which can get you signals from a specific, key pair (btc / eth) into every dataframe - signaling a potential longer-term trend reversal.
Selling pairA based on how PairB's trade is performing will not be a good strategy i'd think.

@darioneto
Copy link
Author

yeah pretty much, the reason is to utilize already evaluated and generated signal from a key pair and then "forward/reuse" it on SOL for instance. So you'd recommend using informative pairs method moving forward?

@xmatthias
Copy link
Member

i'd say so, yes

while you could use get_analyzed_dataframe() - you can't rely on what you get within populate_* methods due to the evaluation order.
Pairs with an open trade usually evaluate first - pairs without later - so when it's turn for PairA - you can't be sure if SOL already evaluated or not, so you might get the current info - or past info - depending on the evaluation sequence.

@darioneto
Copy link
Author

withough example chances are very low to figure it out, anyways thanks for suggestions , maybe next year I could get it to work lol

@xmatthias
Copy link
Member

well there's plenty of examples in the documentation about informative pairs (which is the approach i'd strongly recommend to go with this to avoid problems).
It's however up to you to read these (make sure to expand the "colored boxes" - which do include several examples) 😆

Please understand that we'll not provide tailor-suited examples for individual usecases - it's a process of learning and adapting the examples for your needs...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question Questions - will be closed after some period of inactivity. Strategy assistance Help with a strategy
Projects
None yet
Development

No branches or pull requests

3 participants