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.

Sign up for GitHub

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

Jump to bottom

fetch_ohlcv for Bitmex returns 0 volume when fetching latest candle only #6888

Closed
daikts opened this issue May 4, 2020 · 1 comment
Closed

fetch_ohlcv for Bitmex returns 0 volume when fetching latest candle only #6888

daikts opened this issue May 4, 2020 · 1 comment
Assignees
@kroitor

Comments

@daikts
Copy link

daikts commented May 4, 2020

Hello maintainers,

I'm trying to fetch the latest 1min candle for BTC/USD on Bitmex, and am encountering unexpected results if I use the current minute as the argument to since. Code speaks a thousand words, so have a look at this repro:

import time
import ccxt
from datetime import datetime,  timezone

bitmex = ccxt.bitmex()
bitmex.verbose = False

dt = datetime.now(timezone.utc)
dt = dt.replace(second=0, microsecond=0)

for i in range(10):
    print("Fetching @",datetime.now(timezone.utc).isoformat())
    print(bitmex.fetch_ohlcv("BTC/USD", "1m", since=dt.timestamp() * 1000))
    time.sleep(10)

Output:

Fetching @ 2020-05-04T16:49:15.899577+00:00
[[1588610940000, 8816.0, 8816.0, 8816.0, 8816.0, 0.0]]
Fetching @ 2020-05-04T16:49:26.211477+00:00
[[1588610940000, 8816.0, 8816.0, 8816.0, 8816.0, 0.0]]
Fetching @ 2020-05-04T16:49:36.295965+00:00
[[1588610940000, 8816.0, 8816.0, 8816.0, 8816.0, 0.0]]
Fetching @ 2020-05-04T16:49:46.452728+00:00
[[1588610940000, 8816.0, 8816.0, 8816.0, 8816.0, 0.0]]
Fetching @ 2020-05-04T16:49:56.534189+00:00
[[1588610940000, 8816.0, 8816.0, 8816.0, 8816.0, 0.0]]
Fetching @ 2020-05-04T16:50:06.617107+00:00
[[1588610940000, 8816.0, 8816.0, 8816.0, 8816.0, 0.0], [1588611000000, None, 8816.0, 8815.5, 8816.0, 6391.0]]
Fetching @ 2020-05-04T16:50:16.772068+00:00
[[1588610940000, 8816.0, 8820.5, 8815.5, 8815.5, 542156.0], [1588611000000, 8815.5, 8816.0, 8815.5, 8816.0, 27272.0]]
Fetching @ 2020-05-04T16:50:26.852096+00:00
[[1588610940000, 8816.0, 8820.5, 8815.5, 8815.5, 542156.0], [1588611000000, 8815.5, 8816.0, 8815.5, 8815.5, 41019.0]]
Fetching @ 2020-05-04T16:50:36.925863+00:00
[[1588610940000, 8816.0, 8820.5, 8815.5, 8815.5, 542156.0], [1588611000000, 8815.5, 8816.0, 8812.5, 8813.0, 302379.0]]
Fetching @ 2020-05-04T16:50:47.011284+00:00
[[1588610940000, 8816.0, 8820.5, 8815.5, 8815.5, 542156.0], [1588611000000, 8815.5, 8816.0, 8812.5, 8814.5, 611897.0]]

In this run, I am fetching the candle for 16:49, which is not yet complete, so I would expect the candle as-is depending on the time, which Bitmex provides. Instead, the constant value [[1588610940000, 8816.0, 8816.0, 8816.0, 8816.0, 0.0]] is returned up until we're 16s past the candle. 5s past yields an extra value with a missing Open value (time sync issue?)

However, if I rewind the since param 1 min further into the past (fetching 1 extra candle that I already have) by modifying L13 in the snipped above to:

print(bitmex.fetch_ohlcv("BTC/USD", "1m", since=dt.timestamp() * 1000 - 60*1000))

then the output looks like this:

Fetching @ 2020-05-04T16:59:43.589612+00:00
[[1588611480000, 8831.0, 8835.0, 8830.5, 8835.0, 764824.0], [1588611540000, 8835.0, 8835.0, 8834.5, 8835.0, 196728.0]]
Fetching @ 2020-05-04T16:59:53.928182+00:00
[[1588611480000, 8831.0, 8835.0, 8830.5, 8835.0, 764824.0], [1588611540000, 8835.0, 8835.5, 8834.5, 8835.5, 303643.0]]
Fetching @ 2020-05-04T17:00:04.004668+00:00
[[1588611480000, 8831.0, 8835.0, 8830.5, 8835.0, 764824.0], [1588611540000, 8835.0, 8835.5, 8834.5, 8835.0, 355791.0], [1588611600000, 8835.0, 8835.5, 8835.0, 8835.5, 26204.0]]
Fetching @ 2020-05-04T17:00:14.093504+00:00
[[1588611480000, 8831.0, 8835.0, 8830.5, 8835.0, 764824.0], [1588611540000, 8835.0, 8835.5, 8834.5, 8835.0, 355791.0], [1588611600000, 8835.0, 8835.5, 8835.0, 8835.5, 37888.0]]
Fetching @ 2020-05-04T17:00:24.176160+00:00
[[1588611480000, 8831.0, 8835.0, 8830.5, 8835.0, 764824.0], [1588611540000, 8835.0, 8835.5, 8834.5, 8835.0, 355791.0], [1588611600000, 8835.0, 8840.0, 8835.0, 8840.0, 800917.0]]
Fetching @ 2020-05-04T17:00:34.259789+00:00
[[1588611480000, 8831.0, 8835.0, 8830.5, 8835.0, 764824.0], [1588611540000, 8835.0, 8835.5, 8834.5, 8835.0, 355791.0], [1588611600000, 8835.0, 8842.5, 8835.0, 8842.5, 1648673.0]]

<...>

In this case, the latest candle is updating as expected (you can see the volume grow), and there is never a 0-volume result.

Is there a better way to fetch the latest candle other than this workaround?

Log for repro with verbose=True: https://pastebin.com/Gkf6RDcn

OS: Ubuntu 20.04
Python: 3.7.5
CCXT: latest as of today (1.27.20)

Thanks for all your hard work on CCXT!
@kroitor kroitor self-assigned this May 4, 2020
@kroitor
Copy link
Member

kroitor commented Jun 3, 2020 •
edited

Hi! Pardon for the long wait. Please, let us know if this does not answer your question: #2254. Feel free to reopen it if needed, or just ask further questions if any.

@kroitor kroitor closed this as completed Jun 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kroitor kroitor

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kroitor @daikts