Custom_entry_price works not as expected?

[snussik]

Describe your environment

• Operating system: Win 11
• Python Version: 3.12.2
• CCXT version: 4.2.87
• Freqtrade Version: freqtrade 2024.4-dev-e6da491ca

Fantom deals while using custom_entry_price() callback

The strategy that I use finds "Long" & "Short" zones and creates entry signals on every candle:

def populate_entry_trend(self, dataframe: DataFrame, metadata: dict) -> DataFrame:
      long_direction = dataframe[f"Long_{Direction.LONG.value}"] == 1
      ...

then in custom_entry_price callback I return needed price and wait, that the order will be executed on that price:

def custom_entry_price(....):
      ...
     if self.longs and side == Direction.LONG.value:
         return dataframe[f"entry_price_{Direction.LONG.value}"].iat[-1]
    ...

but in fact, while plotting backtest results I see that orders executed on the price that was not reached (blue line is the entry_price level):

It that expected behaviour?

[Axel-CH]

If you need to update a custom entry price, please use the "adjust_entry_price()" callback.
Once a custom entry price is set there is tree outcome possible : order time out, order filled or order replaced by "adjust_entry_price()"

[xmatthias]

I think you'll need to re-specify what you THINK happens.
custom_entry_price is called when the order is placed (once). If you have no additional logic (and no unfilledtimeout settings) - then that order will stay there "until filled", cancelled - or updated through adjust_entry_price().

I'd also want to point out that plot-dataframe (the command that you've used) is considered deprecated - and will plot orders at the price they're placed - not where they're filled.

I'd instead recommend to use freqUI - for backtesting, started with freqtrade webserver - which will provide you with better plotting capabilities.

[snussik]

@Axel-CH yep. Just tried to add adjust_entry_price callback. Found that it works for me only if custom_entry_price was before used. And also, in usage example side == 'long' but in my case side variable returns buy.

@xmatthias In webserver backtest results nothing changed. I get entry price that was not in cande range:

[xmatthias]

Please look at that particular trade in the trade list (freqUI has this, too).

A long order will NOT fill if it's outside of the order - though if you don't handle it differently - it'll probably fill at the 12:00 candle - and immediately sell as it reaches the exit condition for that, too.

The "trade open date" however will stay at the original trade entry date (when the order was placed) - which is the location where the initial marker will be drawn.

[snussik]

@xmatthias I dont think that I do something different in strategy. This is the source

And this is the backtest result output for this trade, that was got buy this promt: freqtrade backtesting --strategy StFiboStrategy --breakdown month --enable-protections --export signals --timerange 20240101-20240414 on the SOL/USDT:USDT (binance):

{
                    "pair": "SOL/USDT:USDT",
                    "stake_amount": 511.66616233,
                    "max_stake_amount": 511.66616233,
                    "amount": 3,
                    "open_date": "2024-04-12 05:00:00+00:00",
                    "close_date": "2024-04-12 12:00:00+00:00",
                    "open_rate": 170.5553874431871,
                    "close_rate": 172.774,
                    "fee_open": 0.0002,
                    "fee_close": 0.0002,
                    "trade_duration": 420,
                    "profit_ratio": 0.012603042383288457,
                    "profit_abs": 6.44984004,
                    "exit_reason": "take_profit_long",
                    "initial_stop_loss_abs": 1.706,
                    "initial_stop_loss_ratio": -0.99,
                    "stop_loss_abs": 1.706,
                    "stop_loss_ratio": -0.99,
                    "min_rate": 169.293,
                    "max_rate": 172.821,
                    "is_open": false,
                    "enter_tag": "Long enter",
                    "leverage": 1,
                    "is_short": false,
                    "open_timestamp": 1712898000000,
                    "close_timestamp": 1712923200000,
                    "orders": [
                        {
                            "amount": 3,
                            "safe_price": 170.5553874431871,
                            "ft_order_side": "buy",
                            "order_filled_timestamp": 1712923200000,
                            "ft_is_entry": true,
                            "ft_order_tag": "Long enter"
                        },
                        {
                            "amount": 3,
                            "safe_price": 172.774,
                            "ft_order_side": "sell",
                            "order_filled_timestamp": 1712923200000,
                            "ft_is_entry": false,
                            "ft_order_tag": "take_profit_long"
}

Is is possible to look at the examples of code where:

1. Pending limit order created (entry price much higher (for short) or lower (for long) than current orderbook price).
2. This pending order treated properly (entry price adjusting) following the trend.

It can be made with higher (@informative) and lower timeframes in a classic way, but lower tf create much more load while testing and h_opting.

[xmatthias]

Well that output does confirm what i said above.

I'll use epoch timestamps here - you can use https://www.epochconverter.com/ to convert these times eventually - but the "actual date" is not really relevant for this.

The trade is opened at 1712898000000 - and the order fills at 1712923200000.
The trade also closes at 1712923200000 - which means it fills the entry, then places the exit (and fills the exit) - in the same candle - which in the above screenshot - is the red candle with the long lower wick.

Charts do draw the trade open timestamp - and will use the order fill timestamp for subsequent adjustment orders (there is no symbol for the open order fill time).

This might be slightly confusing - but i'd want to avoid plotting yet another indicator on the chart when the open order fills - as i do consider orders that are open for longer than 1 candle as an edge-case - and in most cases - it'd strongly pollute the charts with pointless information.

I'm open to suggestoins on how to improve this - but the only thing i came up with is yet another symbol - which i'd not know how to show to make it clear at a glance that one is the trade placement, while the other is the fill.

Essentially - bot behavior is correct - and the order does not fill outside of any candle (as said before, we make sure that's not going to happen).

[snussik]

@xmatthias So let me be sure that I've understand you correctly:
on the chart abowe, the long mark points to initial trade (order) setting. All other entry price adjustments that lead to order execution 7 candles later and it's actual fill are not seen.
If it is true, adding order fill symbol would be great. I think that some arrowups and arrowdowns from https://glyphicons.com/ could fit well.

[xmatthias]

To be quite frank, i don't think your strategy (the one from freqUI) does "price adjustments" - at least i see no sign of it (not in the chart, nor in the trade object's prices).

Your initial open-rate is 170.55 - and that's also the price the entry order fills.

---

As mentioned above - there's no plans on adding an additional symbol at this point - as the chart is already showing WAY too many symbols if you have a decently active strategy.

Having an order open (and hence, it's capital tied to this particular position, potentially taking away opportunities from other trades) for 7 hours (like in the above case) is a very rare edge-case - one that freqtrade will surely support - but we'll not do special cases for in the charts - which would then lead to very messy charts for most other strategies.

[snussik]

@xmatthias It surely does adjustments:

Log of triggered finctions 🔻

==== CUSTOM ENTRY PRICE ====
Proposed rate:  99.655
Custom rate:  99.37411999999999
Trade:  None
==== ADJUST ORDER ENTER ====
Order(id=1, trade=1, order_id=1, side=buy, filled=0, price=99.374, status=open, date=2024-01-05 12:20:00)
==== CUSTOM ENTRY PRICE ====
Proposed rate:  100.734
Custom rate:  99.37411999999999
Trade:  Trade(id=1, pair=SOL/USDT:USDT, amount=33.00000000, is_short=False, leverage=10, open_rate=99.37400000, open_since=2024-01-05 12:20:00)
==== ADJUST ORDER ENTER ====
Order(id=2, trade=1, order_id=2, side=buy, filled=0, price=99.37411999999999, status=open, date=2024-01-05 12:25:00)
==== ADJUST ORDER ENTER ====
Order(id=2, trade=1, order_id=2, side=buy, filled=0, price=99.37411999999999, status=open, date=2024-01-05 12:25:00)
==== ADJUST ORDER ENTER ====
Order(id=2, trade=1, order_id=2, side=buy, filled=0, price=99.37411999999999, status=open, date=2024-01-05 12:25:00)
==== ADJUST ORDER ENTER ====
Order(id=2, trade=1, order_id=2, side=buy, filled=0, price=99.37411999999999, status=open, date=2024-01-05 12:25:00)
==== ADJUST ORDER ENTER ====
Order(id=2, trade=1, order_id=2, side=buy, filled=0, price=99.37411999999999, status=open, date=2024-01-05 12:25:00)
==== ADJUST ORDER ENTER ====
Order(id=2, trade=1, order_id=2, side=buy, filled=0, price=99.37411999999999, status=open, date=2024-01-05 12:25:00)
==== ADJUST ORDER ENTER ====
Order(id=2, trade=1, order_id=2, side=buy, filled=0, price=99.37411999999999, status=open, date=2024-01-05 12:25:00)
==== CUSTOM ENTRY PRICE ====
Proposed rate:  100.55
Custom rate:  99.50811999999999
Trade:  Trade(id=1, pair=SOL/USDT:USDT, amount=33.00000000, is_short=False, leverage=10, open_rate=99.37400000, open_since=2024-01-05 12:20:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== ADJUST ORDER ENTER ====
Order(id=3, trade=1, order_id=3, side=buy, filled=0, price=99.50811999999999, status=open, date=2024-01-05 13:00:00)
==== CUSTOM ENTRY PRICE ====
Proposed rate:  100.719
Custom rate:  99.22131999999999
Trade:  Trade(id=1, pair=SOL/USDT:USDT, amount=33.00000000, is_short=False, leverage=10, open_rate=99.37400000, open_since=2024-01-05 12:20:00)
==== ADJUST ORDER ENTER ====
Order(id=4, trade=1, order_id=4, side=buy, filled=0, price=99.22131999999999, status=open, date=2024-01-05 14:00:00)
==== ADJUST ORDER ENTER ====
Order(id=4, trade=1, order_id=4, side=buy, filled=0, price=99.22131999999999, status=open, date=2024-01-05 14:00:00)
==== ADJUST ORDER ENTER ====
Order(id=4, trade=1, order_id=4, side=buy, filled=0, price=99.22131999999999, status=open, date=2024-01-05 14:00:00)
==== ADJUST ORDER ENTER ====
Order(id=4, trade=1, order_id=4, side=buy, filled=0, price=99.22131999999999, status=open, date=2024-01-05 14:00:00)
==== ORDER FILLED =====
Trade(id=1, pair=SOL/USDT:USDT, amount=31.00000000, is_short=False, leverage=10, open_rate=99.22132000, open_since=2024-01-05 12:20:00)

The problem is that there is no evidence (on the chart and on the backtesting results) that strategy has some issues with open/close in one candle.

Backtested 2024-01-05 00:00:00 -> 2024-01-06 00:00:00 | Max open trades : 1
=============================================================== STRATEGY SUMMARY ==============================================================
|       Strategy |   Entries |   Avg Profit % |   Tot Profit USDT |   Tot Profit % |   Avg Duration |   Win  Draw  Loss  Win% |      Drawdown |
|----------------+-----------+----------------+-------------------+----------------+----------------+-------------------------+---------------|
| STFStrategy |         1 |           5.78 |            17.790 |           1.78 |   2:00:00 |     1     0     0   100 | 0 USDT  0.00% |
===============================================================================================================================================

As you can see average duration is 2 hours as its calculated from open to close timestamp of the trade.
But in reality orders happen in one candle:

Backtesting results 🔻

{
    "trades": [
        {
            "pair": "SOL/USDT:USDT",
            "stake_amount": 307.586092,
            "max_stake_amount": 3075.86092,
            "amount": 31,
            "open_date": "2024-01-05 12:20:00+00:00",
            "close_date": "2024-01-05 14:20:00+00:00",
            "open_rate": 99.22131999999999,
            "close_rate": 99.835,
            "fee_open": 0.0002,
            "fee_close": 0.0002,
            "trade_duration": 120,
            "profit_ratio": 0.05782567550320494,
            "profit_abs": 17.78993082,
            "exit_reason": "take_profit_long",
            "initial_stop_loss_abs": 89.399,
            "initial_stop_loss_ratio": -0.99,
            "stop_loss_abs": 89.399,
            "stop_loss_ratio": -0.99,
            "min_rate": 99.003,
            "max_rate": 99.852,
            "is_open": false,
            "enter_tag": "Long entry",
            "leverage": 10,
            "is_short": false,
            "open_timestamp": 1704457200000,
            "close_timestamp": 1704464400000,
            "orders": [
                {
                    "amount": 31,
                    "safe_price": 99.22131999999999,
                    "ft_order_side": "buy",
                    "order_filled_timestamp": 1704464400000,
                    "ft_is_entry": true,
                    "ft_order_tag": ""
                },
                {
                    "amount": 31,
                    "safe_price": 99.835,
                    "ft_order_side": "sell",
                    "order_filled_timestamp": 1704464400000,
                    "ft_is_entry": false,
                    "ft_order_tag": "take_profit_long"
                }
            ]
        }
    ]
}

I've noticed that hyperopt functions try to make distance between entry and stoploss tight in order to make orders happen in one candle. That gives awesome results on the paper but totally wrong. And without having the possibility to see such cases on the chart or on backtest results can be really confusing.

It could be great to have backtest parameter All orders / One candle orders: 120 / 80 - so such deviant strategy behaviour can be easily seen.

[xmatthias]

It surely does adjustments:

It may do for other trades, or it may do now after modifications - but it does not do that for the Trade shared above - which does an entry order of 3 SOL at 170 - and an exit order of 3 SOL for slightly more than that - which will close the trade.

Also the price for the trade we talked about above is not what you're sharing now (price 170 vs. price 99).
Obviously things may have changed in your strategy - and so will the plots.
Please understand that we'll not be able to follow this without proper explanation.

It could be great to have backtest parameter All orders / One candle orders: 120 / 80 - so such deviant strategy behaviour can be easily seen.

I'm not entirely sure what you'd expect from this.

The "problem" is the pricing (seemingly without timeout) way off spot, which results in the order remaining open for pretty long (hence tying up assets - potentially missing on other trades).
That's something that your strategy asked for.
if you don't want it to exit immediately, then it'd be best to have a check for this as part of the strategy / custom_exit logic. Freqtrade will not check such things if you're using custom_exit

[snussik]

@xmatthias

I'm not entirely sure what you'd expect from this.

If strategy opens and closes inside the same candle - then smth. wrong with the strategy. But large amount of such deals influences winrate percent significantly and optimisation functions push parameters to that side. So it could be useful to show the % of "flash" onecandle trades in their total amount.

[xmatthias]

I think that's nitpicking on your actual result - not something that's generally applicable - at least I'm not convinced it is.

What if the trade sells 1 candle later?
You'd not see it as "flash one candle trade" - but it's still not really what you'd expect I'd think - and you'd also not really see it better.

Also optimization functions are something that you pick when starting a hyperopt run.
Some will focus on short trade duration - others on profit, drawdown, different metrics, ... - so what you're seeing is that the loss function you picked (most likely ShortTradeDurHyperOptLoss) tries to aim for short trade duration.
It's however a user pick of doing so - not "optimization aims for this".

[snussik]

@xmatthias the purpose of the method I use is to try make entry not on the candle's open price (as in backtesting assumptions written) but to "catch" lower price of the lower wick. The calculations are made based on the prev candle prices.

Ideally - without using lower timeframes as it is more heavy calculated.
So in "Long" range i have to open-cancel trades on each candle if not fulfilled or adjust entry price several times. Basically, I don't understand, why it's less conventional than cancelling orders by timeout and "re-enter".

The problem with "flash one candle trade" that happen the same time is that it's something wrong with them. It backtesting assumptions is written that:

Low happens before high for stoploss, protecting capital first

I doubt that, as sometimes with 100% of the "flash one candle trades" I get 98% winrate on backtest. And as I cant visually define exact trade fulfilment on the chart (as we've found out earlier) sometimes I see that low was "lower" than my stoploss but it wasn't triggered.

And as I see, this was exactly "flash one candle trade" as "order_filled_timestamp" values are the same:

{
                    "pair": "SOL/USDT:USDT",
                    "stake_amount": 267.7910669,
                    "max_stake_amount": 267.7910669,
                    "amount": 13,
                    "open_date": "2023-05-10 13:00:00+00:00",
                    "close_date": "2023-05-10 17:15:00+00:00",
                    "open_rate": 20.59931283863375,
                    "close_rate": 20.837,
                    "fee_open": 0.0002,
                    "fee_close": 0.0002,
                    "trade_duration": 255,
                    "profit_ratio": 0.011134062065694577,
                    "profit_abs": 2.98219868,
                    "exit_reason": "take_profit_long",
                    "initial_stop_loss_abs": 0.206,
                    "initial_stop_loss_ratio": -0.99,
                    "stop_loss_abs": 20.474,
                    "stop_loss_ratio": -0.006119799350106203,
                    "min_rate": 20,
                    "max_rate": 20.838,
                    "is_open": false,
                    "enter_tag": "Long entry",
                    "leverage": 1,
                    "is_short": false,
                    "open_timestamp": 1683723600000,
                    "close_timestamp": 1683738900000,
                    "orders": [
                        {
                            "amount": 13,
                            "safe_price": 20.59931283863375,
                            "ft_order_side": "buy",
                            "order_filled_timestamp": 1683738900000,
                            "ft_is_entry": true,
                            "ft_order_tag": ""
                        },
                        {
                            "amount": 13,
                            "safe_price": 20.837,
                            "ft_order_side": "sell",
                            "order_filled_timestamp": 1683738900000,
                            "ft_is_entry": false,
                            "ft_order_tag": "take_profit_long"
                        }
                    ]
                }

Backtested 2023-05-01 00:00:00 -> 2023-05-30 00:00:00 | Max open trades : 1
=============================================================== STRATEGY SUMMARY ==============================================================
|       Strategy |   Entries |   Avg Profit % |   Tot Profit USDT |   Tot Profit % |   Avg Duration |   Win  Draw  Loss  Win% |      Drawdown |
|----------------+-----------+----------------+-------------------+----------------+----------------+-------------------------+---------------|
| STFStrategy |         6 |           0.60 |             5.682 |           0.57 |       13:17:00 |     6     0     0   100 | 0 USDT  0.00% |
===============================================================================================================================================

[xmatthias]

Low happens before high for stoploss, protecting capital first

I doubt that, as sometimes with 100% of the "flash one candle trades" I get 98% winrate on backtest. And as I cant visually define exact trade fulfilment on the chart (as we've found out earlier) sometimes I see that low was "lower" than my stoploss but it wasn't triggered.

you can't "spot-pick" backtesting assumptions claiming they don't apply while ignoring others.

This assumption mainly aims for trailing stops - as they could "update" the stoploss to a higher value, causing the actual stop value to be exagerated - which is what this aims to prevent.

If your strategy does a "custom exit" however - then this will be favored over a stop (with the assumption that your signal triggered before the low).

Exit-signal is favored over Stoploss, because exit-signals are assumed to trigger on candle's open

Since your trade had an exit signal (either conventional, in dataframe, or via custom_exit) (easily visible, since it actually exited with a custom reason) - this signal is favored over the stoploss - as is also pretty clearly documented.

[snussik]

@xmatthias
but if Low happens before high then exit signal priority over the stoploss doesn't matter: low, that happened earlier, should triger stoploss earlier that exit_signal ot the consecutive candle

[xmatthias]

Well in your above case - you're not in the trade until that candle.
So the trade opens on that green wick - and exits on the same candle on exit signal (so stoploss does NOT apply - as there is an explicit exit signal (through custom_exit()).

---

The backtesting assumptions must be treated as a whole. You cannot take one line and think "well that's gonna apply to me - no matter what the other points say".

As the list says - "Low happens before high for stoploss, protecting capital first".
This means - it applies ONLY to stoploss. you cannot pick partial words just because you like them, but not the rest of the sentence.

Another point (higher up in the same list list) says:
"Exit-signal is favored over Stoploss, because exit-signals are assumed to trigger on candle's open"

This explains that a regular exit signal triggered by a strategy signal (-> not stoploss) will be favored over stoploss.

So if a "regular exit signal" happens - then the logic that's used for stoplosses (which is where the "low happens before high" comes from) is irrelevant - as the strategy did an explicit exit.

Please don't pick individual lines from the backtesting assumptions list - but try to read and understand all of them (in full, not just partial lines).

ALL lines will apply - even if you may not like them (which seems to be the case from your recent messages).

They have been created this way to try and avoid the most common gotchas and problems.
That doesn't mean there isn't any or that you can't try to circumvent these - which is why they're explained - so users can take their own judgement to try to not get fooled by them.
Obviously that's easier when using callbacks - where freqtrade won't control the full logic- which is why they're considered a slightly advanced feature.

[snussik]

@xmatthias I think that the main confusing thing for me is what exactly happens when the order is placed : ).
Cause: sometimes 'trade' == 'order', sometimes - not. It's seen exactly, that actually there is no full limit orders support. It's used for decreasing market fees for entry. But all orders are treated as of market type: Entry signal == Order (Market) == Trade executed.

But, as I understand, it matters when backtest assumptions rules are applied.

So if a "regular exit signal" happens - then the logic that's used for stoplosses (which is where the "low happens before high" comes from) is irrelevant - as the strategy did an explicit exit.

That's exactly what I wrote earlier: if all that happens inside one candle - you get wrong results - huge amount of "flash one candle trades" and high winrate numbers. But its wrong.

I think that if actual order fullfiment (entry and exit) happens inside one candle - SL must flash first, as its written in assumptions. As its is not "consecutive" candle, yet.

[xmatthias]

trade == order is simply a plain wrong statement - not sure where you're trying to go with that.
Please read the freqtrade terminology to learn about terminology freqtrade is using if this is confusing for you.

An order is either an entry - or an exit - never both at the same time.
It's one part of each trade - but it's never the same - and one trade will always consist of at least 2 orders (so trade == order can never be correct).

But all orders are treated as of market type

I don't see what makes you think this - and it's clearly not true.
You've even shown that yourself above - otherwise you wouldn't have had the misbelieve about the fact that an order would fill outside of a candle (which it won't).

---

That telegram message got a point - which can easily be changed (though i don't see how it relates to this issue - which is about your problems with backtesting).

---

I think that if actual order fullfiment (entry and exit) happens inside one candle - SL must flash first, as its written in assumptions. As its is not "consecutive" candle, yet.

I disagree. it's a 50/50 chance of either of the things happening first.
The reason to consider an explicit exit first is that this is often used as an "early stop". we don't want to penalize people for doing this by applying the stoploss rate.
Your strategy is gaming backtesting the other way - which is documented - and a problem in your strategy.

It's exploiting an edge-case - but i don't see us adding different execution logic based on "this is the first candle".
Chances of the candle going one or the other way are no different than when you're 20 candles into a trade.

---

To get improved backtesting accuracy, you should use --timeframe-detail. It'll give you intra-candle movements (down to 1m - if that's what you desire).
It'll have the same rules applied - but at the detail timeframe - increasing backtesting accuracy.

[snussik]

@xmatthias

you should use --timeframe-detail.

it's a great tool, but I cant find how I can use it with hyperopt. That's why I use 2 timeframes, but the backtest results differ a lot.

[xmatthias]

it's a great tool, but I cant find how I can use it with hyperopt.

well - like - the same way? (freqtrade hyperopt --help will reveal that) ;)
hyperopt does support --timeframe-detail too - though it'll slow down your hyperopt by ... quite a ton - so it's not an option i'd recommend for hyperopt (you'll need to limit your parallelity most likely - to cope with the increased memory usage) - but technically - it's possible just as it is for backtesting.

[snussik]

@xmatthias

hyperopt does support --timeframe-detail

You're totally right! I just should have use two dashes instead one in promt )))