Hello,
Please, add support the following timeframes for OHLC: 3m 5m, 10m, 15m, 30m, 4h, 8h, 12h, 1w
@YuriyTigiev hi! Which particular exchange do you mean? The set of supported OHLCV timeframes depends on the exchange in question.聽For example, if the exchange API does not provide 3m candles 鈥撀爓e cannot invent them out of thin air.
@YuriyTigiev let us know if this does not answer the question:
I saw the solution https://github.com/ccxt/ccxt/issues/2514 before I wrote.
Can you include standard package the emulation of all possible timeframes for the case if an exchange doesn't support some of them?
@YuriyTigiev
Can you include standard package the emulation of all possible timeframes for the case if an exchange doesn't support some of them?
But... it is included already, I mean, it uses the parseTimeframe
base method that supports all timeframes.
ccxt==1.18.1226
I'm getting an error when I'm trying to use 4h
try:
ohlc = self.exchange.fetchOHLCV(symbol = pair, timeframe = '4h', since = since, limit = days)
except Exception as ex:
logging.error(ex)
[2019-10-09 07:52:07,613] ERROR - '4h'
@YuriyTigiev which exchange is it?
I'm working with bitmex
@YuriyTigiev yeah, but with BitMEX, the has['fetchOHLCV'] property is not emulated, but true, that means, the only timeframes we can really get are the timeframes supported by the exchange, that is:
'timeframes': {
'1m': '1m',
'5m': '5m',
'1h': '1h',
'1d': '1d',
},
So, in general, if exchange.has['fetchOHLCV'] === 'emulated'
, then you can use whatever timeframe you want, including the 4h
, but due to reasons explained in the Manual, the OHLCV emulation has its own limitations, because it's based on most recent trades, so, we do not recommend using higher order timeframes:
If, however, the exchange.has['fetchOHLCV'] === true
, then this means, that the timeframes for OHLCV are not emulated from trades and are "true" (taken from the exchange OHLCV endpoint directly). In this case we can only query the timeframes supported by the exchange in question (listed in the exchange.timeframes
property).
This is the limitation, coming from the exchange side, not from the CCXT. We'd love to add more timeframes, but, unfortunately, we have to work with what the exchange provides to us. Hope this clarified it a bit.
I have asked bitmex about that.
@YuriyTigiev ok, let us know if you have a followup on this matter!
Thanks for reaching out to us.
Unfortunately, we only offer the intervals 1m, 5m, 1h, 1d of bucketed data.
If you want to build your own 15-minute candles, for example, you can combine the date from three 5 minute candles noting the high, low open and close.
Please let us know if you have further questions.
Regards,
Hans
BitMEX
@YuriyTigiev yes, that's exactly what I told you before and this answer was pretty much expected, unfortunately. So, I guess, you're limited to 1h buckets, but you can recalculate those manually into 4h-buckets, with a very easy loop in userland. Thx for a followup!
Can you add a functionality to exist the fetchOHLCV function for emulate common timeframes based on lower timeframes? For example 2h or 4h based on 1h timeframe and etc.
@YuriyTigiev yes, we are going to do that as soon as we can: https://github.com/ccxt/ccxt/issues/6042
How can I get a notification that the functionality was implemented?
@YuriyTigiev click issue #6042 and click "subscribe" on the right there, that way you will get notified when that issue is fixed and closed (meaning that the functionality in question is implemented).
Most helpful comment
@YuriyTigiev yes, we are going to do that as soon as we can: https://github.com/ccxt/ccxt/issues/6042