Ccxt: fetchOrder (bitstamp) funktioniert nicht mehr -> "invalid nonce"

Traceback (most recent call last):
  File "C:\Users\us\.thonny\BundledPython36\lib\site-packages\ccxt\base\exchange.py", line 364, in fetch
    response.raise_for_status()
  File "C:\Users\us\.thonny\BundledPython36\lib\site-packages\requests\models.py", line 935, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 403 Client Error: Authentication Failed for url: https://www.bitstamp.net/api/v2/open_orders/all/

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "\\DARTH3-V03\RedirectedFolders\us\My Documents\python\crypto\bitstamp-004.py", line 712, in <module>
    observeOpeningOrderPlaced(exchange,symbol)
  File "\\DARTH3-V03\RedirectedFolders\us\My Documents\python\crypto\bitstamp-004.py", line 528, in observeOpeningOrderPlaced
    orderInfo=exchange.fetchOrder(exchange.openOpeningOrders[symbol][side][0]) #fetchorder by orderid
  File "C:\Users\us\.thonny\BundledPython36\lib\site-packages\ccxt\bitstamp.py", line 425, in fetch_order
    orders = self.privatePostOpenOrdersAll()
  File "C:\Users\us\.thonny\BundledPython36\lib\site-packages\ccxt\base\exchange.py", line 311, in request
    return self.fetch2(path, api, method, params, headers, body)
  File "C:\Users\us\.thonny\BundledPython36\lib\site-packages\ccxt\base\exchange.py", line 308, in fetch2
    return self.fetch(request['url'], request['method'], request['headers'], request['body'])
  File "C:\Users\us\.thonny\BundledPython36\lib\site-packages\ccxt\base\exchange.py", line 376, in fetch
    self.handle_errors(response.status_code, response.reason, url, method, self.last_response_headers, self.last_http_response)
  File "C:\Users\us\.thonny\BundledPython36\lib\site-packages\ccxt\bitstamp.py", line 504, in handle_errors
    raise ExchangeError(self.id + ' ' + self.json(response))
ccxt.base.errors.ExchangeError: bitstamp {"status":"error","reason":"Invalid nonce","code":"API0004"}
>>> 

@stabilus kannst du bitte einen minimalen (kürzestmöglichen, aber vollständigen) Ausschnitt deines Codes zeigen, um das Problem zu reproduzieren?

Dies wird den Fehler erzeugen:

def instantiateExchanges():
    # instantiate exchange(s)

    #***bitstamp****
    global bitstamp_ccxt
    global g_minProfit
    bitstamp_ccxt = ccxt.bitstamp()
    bitstamp_ccxt.uid='xxxx'
    bitstamp_ccxt.password='xxxx'
    bitstamp_ccxt.apiKey='xxxx'
    bitstamp_ccxt.secret='xxxx'
    bitstamp_ccxt.loadMarkets()

instantiateExchanges()
exchange=bitstamp_ccxt
symbol='BTC/USD'

time.sleep(1)
result=exchange.createLimitBuyOrder(symbol,0.01,4100)
orderID=result['id']
print (orderID)

time.sleep(1)
print(exchange.fetchOrder(orderID))

Ok, können Sie bitte den ausführlichen Modus hinzufügen und die vollständige ausführliche Ausgabe (ohne Schlüssel) einfügen?

# ...
exchange.verbose = True # add this before the last line
print(exchange.fetchOrder(orderID))

Stehen für weitere Informationen von Ihnen bereit. Vielen Dank!

Dies ist die ausführliche Ausgabe, gefolgt von den Fehlermeldungen:

960016270
POST https://www.bitstamp.net/api/v2/order_status/
Anfrage: {'Content-Type': 'application/x-www-form-urlencoded', 'User-Agent': 'python-requests/2.18.4', 'Accept-Encoding': 'gzip, deflate'}
key=XXXX&signature=XXXXXX&nonce=1518644639&id=960016270
POST https://www.bitstamp.net/api/v2/order_status/ 200
Antwort: {'Access-Control-Allow-Headers': 'x-requested-with, Content-Type, origin, accept, cache-control', 'Access-Control-Allow-Methods': 'POST, GET', ' Access-Control-Allow-Origin': '*', 'Cache-Control': 'max-age=0', 'Content-Language': 'en', 'Content-Type': 'application/json', ' Date': 'Mi, 14 Feb 2018 21:44:00 GMT', 'Expires': 'Mi, 14 Feb 2018 21:44:00 GMT', 'Last-Modified': 'Mi, 14 Feb 2018 21:44 :00 GMT', 'Server': 'Apache', 'Strict-Transport-Security': 'max-age=63072000; includeSubDomains', 'Vary': 'Accept-Language', 'X-Frame-Options': 'SAMEORIGIN', 'transfer-encoding': 'chunked', 'Connection': 'keep-alive', 'Set-Cookie' : 'visid_incap_99025=50kIyr46SE+B0q2suQdttp+thFoAAAAAAQUIPAAAAAACzzKMVkcPqA//eGaSaraPq; läuft ab=Do, 14. Februar 2019 15:06:31 GMT; Pfad=/; Domain=.bitstamp.net, incap_ses_189_99025=iEgUBEAfJAXWb/IC3XifAp+thFoAAAAanMkVCwDaOsce3XpHpKGNjQ==; Pfad=/; Domain=.bitstamp.net', 'X-Iinfo': '10-2657481-2657575 SNNN RT(1518644636526 2533) q(0 0 0 -1) r(0 0) U6', 'X-CDN': 'Incapsula ', 'Inhaltskodierung': 'gzip'}
{"status": "Offen", "id": 960016270, "transaktionen": []}
POST https://www.bitstamp.net/api/v2/open_orders/all/
Anfrage: {'Content-Type': 'application/x-www-form-urlencoded', 'User-Agent': 'python-requests/2.18.4', 'Accept-Encoding': 'gzip, deflate'}
key=6pgmGQJtGcUaZulmSYmVxP9HT9b7XYLD&signature=XXXX&nonce=1518644639
Traceback (letzter Aufruf zuletzt):
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbaseexchange.py“, Zeile 364, in fetch
response.raise_for_status()
Datei „C:Usersus.thonnyBundledPython36libsite-packagesrequestsmodels.py“, Zeile 935, in raise_for_status
HTTPError (http_error_msg, response=self) auslösen
Requests.Exceptions.HTTPError: 403 Client Error: Authentication Failed for URL: https://www.bitstamp.net/api/v2/open_orders/all/

Während der Behandlung der obigen Ausnahme ist eine weitere Ausnahme aufgetreten:

Traceback (letzter Aufruf zuletzt):
Datei "\DARTH3-V03RedirectedFoldersusMy Documentspythoncryptobitstamp-004-t1.py", Zeile 35, in
print(exchange.fetchOrder(orderID))
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbitstamp.py“, Zeile 425, in fetch_order
Bestellungen = self.privatePostOpenOrdersAll()
Datei "C:Usersus.thonnyBundledPython36libsite-packagesccxtbaseexchange.py", Zeile 311, auf Anfrage
return self.fetch2(path, api, method, params, headers, body)
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbaseexchange.py“, Zeile 308, in fetch2
return self.fetch(request['url'], request['method'], request['headers'], request['body'])
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbaseexchange.py“, Zeile 376, in fetch
self.handle_errors(response.status_code, response.reason, url, method, self.last_response_headers, self.last_http_response)
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbitstamp.py“, Zeile 504, in handle_errors
Erhöhen Sie ExchangeError (self.id + ' ' + self.json (Antwort))
ccxt.base.errors.ExchangeError: bitstamp {"status":"error","reason":"Ungültige Nonce","code":"API0004"}

Hallo Kroitor
Haben Sie alle Informationen, die Sie von mir benötigen, um dies zu untersuchen? Was ich seltsam finde, ist, dass die Methode früher gut funktionierte und dann plötzlich anfing, diesen Nonce-Fehler auszulösen.

Wollte das gleiche posten.

Zwei Probleme:

fetchOrder auf Bitstamp besteht aus 2 Aufrufen: Zuerst prüfen wir den Auftragsstatus (offen oder geschlossen) und fragen dann je nach Auftragsstatus den entsprechenden Endpunkt ab. (oder so sollte es sein, jetzt überprüfen wir den Status und fragen dann trotzdem den "offenen" Endpunkt ab, aber das ist eine einfache Lösung.)

Wie auch immer, der erste Aufruf geht perfekt, der zweite Aufruf gibt einen Nonce-Fehler.
Wenn man sie einzeln anruft, geht alles gut.

In der ausführlichen Ausgabe können wir sehen, dass die Nonce wiederverwendet wird. Ich glaube, dies verursacht das Problem.

fetch:
 bitstamp POST https://www.bitstamp.net/api/v2/order_status/
Request:
 { 'Content-Type': 'application/x-www-form-urlencoded' }
 key=xxx&signature=xxx&nonce=1518686391&id=962455719

handleRestResponse:
 bitstamp POST https://www.bitstamp.net/api/v2/order_status/ 200 OK
Response:
 { 'access-control-allow-headers': 'x-requested-with, Content-Type, origin, accept, cache-control',
  'access-control-allow-methods': 'POST, GET',
  'access-control-allow-origin': '*',
  'cache-control': 'max-age=0',
  'content-language': 'en',
  'content-type': 'application/json',
  date: 'Thu, 15 Feb 2018 09:19:51 GMT',
  expires: 'Thu, 15 Feb 2018 09:19:51 GMT',
  'last-modified': 'Thu, 15 Feb 2018 09:19:51 GMT',
  server: 'Apache',
  'strict-transport-security': 'max-age=63072000; includeSubDomains',
  vary: 'Accept-Language',
  'x-frame-options': 'SAMEORIGIN',
  'transfer-encoding': 'chunked',
  connection: 'Close',
  'set-cookie': 'incap_ses_767_99025=0QFGaFjglGiWXciQp+6kCrZQhVoAAAAAxIrWQDe9KAbjpI79FozUVQ==; path=
/; Domain=.bitstamp.net',
  'x-iinfo': '12-9910999-9911000 NNNN CT(17 17 0) RT(1518686390399 13) q(0 0 0 -1) r(0 0) U6',
  'x-cdn': 'Incapsula',
  'content-encoding': 'gzip' }
 {"status": "Finished", "id": 962455719, "transactions": [{"fee": "1.18", "price": "187.99000000", "
datetime": "2018-02-15 06:50:34.427688", "ltc": "2.50625000", "tid": 54805885, "type": 2, "eur": "47
1.1499375000000000"}]}

fetch:
 bitstamp POST https://www.bitstamp.net/api/v2/open_orders/all/
Request:
 { 'Content-Type': 'application/x-www-form-urlencoded' }
 key=xxx&signature=xxx&nonce=1518686391

handleRestResponse:
 bitstamp POST https://www.bitstamp.net/api/v2/open_orders/all/ 403 Authentication Failed
Response:
 { 'access-control-allow-headers': 'x-requested-with, Content-Type, origin, accept, cache-control',
  'access-control-allow-methods': 'POST, GET',
  'access-control-allow-origin': '*',
  'content-language': 'en',
  'content-type': 'application/json',
  date: 'Thu, 15 Feb 2018 09:19:51 GMT',
  server: 'Apache',
  'strict-transport-security': 'max-age=63072000; includeSubDomains',
  vary: 'Accept-Language',
  'x-frame-options': 'SAMEORIGIN',
  'transfer-encoding': 'chunked',
  connection: 'Close',
  'set-cookie': 'incap_ses_767_99025=PfW/HILr8gmiXciQp+6kCrZQhVoAAAAAFEUdOmQ1qzRZv0WUKrhIBg==; path=
/; Domain=.bitstamp.net',
  'x-iinfo': '14-16391799-16391801 NNNN CT(17 18 0) RT(1518686390551 19) q(0 0 1 -1) r(1 1) U6',
  'x-cdn': 'Incapsula',
  'content-encoding': 'gzip' }
 {"status": "error", "reason": "Invalid nonce", "code": "API0004"}

(node:6004) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error:
bitstamp {"status":"error","reason":"Invalid nonce","code":"API0004"}
(node:6004) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future
, promise rejections that are not handled will terminate the Node.js process with a non-zero exit co
de.

fetchOrder auf Bitstamp sind 2 Aufrufe

Dies ist das Hauptproblem, wir sollten den zweiten Anruf von dort entfernen.

In Ihrem speziellen Fall besteht eine Problemumgehung jedoch darin, die Ratenbegrenzung zu aktivieren (setzen Sie „enableRateLimit“ auf „true“ in Ihrer Instanz).

Wir werden das fetchOrder für Bitstamp aus dem emulierten Teil entfernen, da die aktuelle Implementierung fehlerhaft ist (erfordert zwei Aufrufe statt nur einem). Bitstamp hat überhaupt keine Methode zum Abrufen einer einzelnen Bestellung, sie haben nur offene Bestellungen. Und wir werden andere Methoden mit Cache emulieren.

vergiss das:

Zuerst prüfen wir den Auftragsstatus (offen oder geschlossen) und fragen dann je nach Auftragsstatus den entsprechenden Endpunkt ab. (oder so sollte es sein, jetzt überprüfen wir den Status und fragen dann trotzdem den "offenen" Endpunkt ab, aber das ist eine einfache Lösung.)

Alle Informationen für geschlossene Bestellungen befinden sich im "Status"-Aufruf.
Ich werde eine vorübergehende Bestellung aufgeben, die offen bleibt, und sehen, ob ich die auch im Statusaufruf erhalten kann.
Das sollte es ermöglichen, zu einem Anruf zu gehen.

Es gibt keine fetchOrder für Bitstamp mehr, es gibt jetzt nur noch die fetchOpenOrders. Wir werden in Kürze eine Emulation für die fetchOrder hinzufügen.

Ich werde eine vorübergehende Bestellung aufgeben, die offen bleibt, und sehen, ob ich die auch im Statusaufruf erhalten kann.
Das sollte es ermöglichen, zu einem Anruf zu gehen.

• https://github.com/ccxt/ccxt/wiki/Manual#querying -orders
• https://github.com/ccxt/ccxt/wiki/Manual#orders-cache
• https://github.com/ccxt/ccxt/blob/master/js/liqui.js#L511 (überprüfen Sie dort updateCachedOrders, fetchOrders, fetchOpenOrders, fetchClosedOrders, um zu sehen, wie wir damit umgehen).

Bisher war das Abrufen von offenen und geschlossenen Bestellungen in ccxt nicht implementiert. Wenn Sie das implementieren, wäre das bereits eine großartige Funktion, mit der Sie arbeiten können
Entschuldigung, ich kann Ihnen beim Codieren nicht aktiv helfen - ich bin ein Python-Neuling ...

Gemäß der Bitstamps-API werden offene Bestellungen 10 Sekunden lang zwischengespeichert, während es keinen Cache für den Bestellstatus gibt. Um schnell auf Änderungen des Bestellstatus reagieren zu können, ist es möglicherweise ratsam, bei der Implementierung der Methode fetchOrder auf der ccxt-Seite weiterhin Bestellstatusaufrufe zu verwenden.

@stabilus

Es kann ratsam sein, weiterhin Auftragsstatusaufrufe zu verwenden, wenn die Methode fetchOrder auf der ccxt-Seite implementiert wird

Wenn zwei Aufrufe erforderlich sind, wird dringend davon abgeraten. Stattdessen schlagen wir vor, den bestehenden fetchOrderStatus mit fetchOpenOrders zu verwenden und die Reihenfolge der sequentiellen Aufrufe dem Benutzer zu überlassen (wird nicht über die Reihenfolge der sequentiellen Aufrufe in der Bibliothek entscheiden).

orderStatus-Ausgabe für eine geschlossene Bestellung:

{ status: 'Finished',
  id: 962455719,
  transactions:
   [ { fee: '1.18',
       price: '187.99000000',
       datetime: '2018-02-15 06:50:34.427688',
       ltc: '2.50625000',
       tid: 54805885,
       type: 2,
       eur: '471.1499375000000000' } ] }

für offene Bestellung:
{ status: 'Open', id: 963180354, transactions: [] }

Könnten wir fetchOrder nur diesen einen Aufruf machen?
Es ist nicht perfekt, da es nicht viele Informationen zu offenen Bestellungen zurückgibt, aber es ist besser, als fetchOrder insgesamt zu löschen.

Perfekt! Das ist alles, was wir brauchen! Ich möchte zu Ihrem großen Einsatz beitragen. Bitte geben Sie für eine kleine Spende Ihre BTC-Adresse an!

Nicht verbunden, nur ein glücklicher "Kunde" wie Sie.
Für Spenden an das CCXT-Team: https://opencollective.com/ccxt/donate

404... ?

Könnten wir fetchOrder nur diesen einen Aufruf machen?

Ja, wir werden es mithilfe des Auftrags-Cache neu implementieren. Im Moment bieten wir fetchOrderStatus + fetchOpenOrders an (was effektiv der früheren fetchOrder-Implementierung entspricht).

Es ist nicht perfekt, da es nicht viele Informationen zu offenen Bestellungen zurückgibt, aber es ist besser, als fetchOrder insgesamt zu löschen.

Wir löschen es nicht für immer, sondern machen Aufrufe nur explizit, und wir werden Bitstamp in Kürze auch eine Caching-Schicht hinzufügen.

https://opencollective.com/ccxt)

Bitte geben Sie für eine kleine Spende Ihre BTC-Adresse an!

https://github.com/ccxt/ccxt#crypto ) Danke )

ETH 0xa7c2b18b7c8b86984560cad3b1bc3224b388ded0
BTC 33RmVRfhK2WZVQR1R83h2e9yXoqRNDvJva
BCH 1GN9p233TvNcNQFthCgfiHUnj5JRKEc2Ze
LTC LbT8mkAqQBphc4yxLXEDgYDfEax74et3bP

hat es von BTC an das OpenCollective geschickt. Danke!

Im Moment bieten wir fetchOrderStatus + fetchOpenOrders an (was effektiv der früheren fetchOrder-Implementierung entspricht).

Bei allem Respekt, das ist es nicht.
fetchOrderStatus gibt nur "geschlossen" oder "offen" zurück.
fetchOpenOrders gibt nur offene Bestellungen zurück.
Mit dem neuesten Update haben wir KEINE Möglichkeit, geschlossene Bestellungen zu überprüfen.

Ich benötige Details zu geschlossenen Bestellungen, und die Informationen sind in demselben Aufruf verfügbar, der für fetchOrderStatus verwendet wird. Rohausgabe:

{ status: 'Finished',
  id: 962455719,
  transactions:
   [ { fee: '1.18',
       price: '187.99000000',
       datetime: '2018-02-15 06:50:34.427688',
       ltc: '2.50625000',
       tid: 54805885,
       type: 2,
       eur: '471.1499375000000000' } ] }

Ich kann aus diesem Aufruf eine fetchOrder() machen (einmaliger Aufruf jetzt, nicht doppelt so wie es war), der einzige Nachteil ist, dass die Informationen für offene Bestellungen sehr begrenzt sein werden.

Wenn wir eine Caching-Implementierung haben, können wir diese natürlich stattdessen verwenden.

@stabilus

hat es von BTC an das OpenCollective geschickt. Danke!

Vielen Dank! Opencollective akzeptiert jedoch keine BTC )) Sie akzeptieren Fiat-Zahlungen ... wenn Sie mit Krypto beitragen möchten, sind Ihre Beiträge willkommen, und die Krypto-Adressen sind:

ETH 0xa7c2b18b7c8b86984560cad3b1bc3224b388ded0
BTC 33RmVRfhK2WZVQR1R83h2e9yXoqRNDvJva
BCH 1GN9p233TvNcNQFthCgfiHUnj5JRKEc2Ze
LTC LbT8mkAqQBphc4yxLXEDgYDfEax74et3bP

Thx nochmal)

@wannesdemaeght Ich habe (vorerst) Folgendes für fetchOrder wiederhergestellt:

    async fetchOrder (id, symbol = undefined, params = {}) {
        await this.loadMarkets ();
        let market = undefined;
        if (typeof symbol !== 'undefined')
            market = this.market (symbol);
        let response = await this.privatePostOrderStatus ({ 'id': id });
        return this.parseOrder (response, market);
    }

Das sieht aus wie das, was Sie brauchen, oder? )

Entschuldigung, ich hinke hinterher...
.orderStatus gibt jetzt nur "offen" oder "geschlossen" zurück, aber keine Handelsinformationen. Wie würden Sie nun die verbleibende bzw. die gefüllte Portion erhalten - ohne openOrders aufrufen zu müssen (das für 10 Sekunden zwischenspeichert)?
.parseOrder(orderid) gibt einen Fehler zurück:

Traceback (letzter Aufruf zuletzt):
Datei "“, Zeile 1, ein
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbitstamp.py“, Zeile 378, in parse_order
datetimeString = self.safe_string(order, 'datetime')
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbaseexchange.py“, Zeile 447, in safe_string
return str(dictionary[key]), wenn key nicht None ist und (key in dictionary) und dictionary[key] nicht None ist, sonst default_value
TypeError: Argument vom Typ „int“ ist nicht iterierbar

@stabilus

1. ccxt auf Version 1.10.1113 aktualisieren
2. rufen Sie fetchOrder (id) wie zuvor auf (verwenden Sie Ihren ursprünglichen Code, ohne etwas daran zu ändern)

Ich bin am 1.10.1113.
exchange.fetchOrder(963439610)
Traceback (letzter Aufruf zuletzt):
Datei "“, Zeile 1, ein
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbitstamp.py“, Zeile 362, in fetch_order
return self.parse_order(Antwort, Markt)
Datei „C:Usersus.thonnyBundledPython36libsite-packagesccxtbitstamp.py“, Zeile 402, in parse_order
gefüllt += Handel['Betrag']
TypeError: nicht unterstützte(r) Operandentyp(en) für +=: 'int' und 'NoneType'

@stabilus ok, ein weiterer Fix steht bevor ... warte

@wannesdemaeght Ich habe (vorerst) Folgendes für fetchOrder wiederhergestellt:

async fetchOrder (id, symbol = undefined, params = {}) {
    await this.loadMarkets ();
    let market = undefined;
    if (typeof symbol !== 'undefined')
        market = this.market (symbol);
    let response = await this.privatePostOrderStatus ({ 'id': id });
    return this.parseOrder (response, market);
}

Das sieht aus wie das, was Sie brauchen, oder? )

Vielen Dank.
Nun gibt es einige grundlegende Probleme beim Analysieren dieser Antwort:

RangeError: Ungültiger Zeitwert

Dies hat mit dem Codieren und Decodieren des datetimestring zu tun.
Wenn ich diese zum Testen auskommentiere, bekomme ich folgende Antwort:

{ id: '962455719',
  timestamp: undefined,
  status: 'closed',
  symbol: undefined,
  type: undefined,
  side: undefined,
  price: undefined,
  cost: undefined,
  amount: undefined,
  filled: NaN,
  remaining: undefined,
  trades:
   [ { id: '54805885',
       info: [Object],
       timestamp: 1518677434427,
       datetime: '2018-02-15T06:50:34.427Z',
       symbol: undefined,
       order: undefined,
       type: undefined,
       side: 'sell',
       price: 187.99,
       amount: undefined,
       fee: [Object] } ],
  fee: undefined,
  info: { status: 'Finished', id: 962455719, transactions: [ [Object] ] } }

eine Idee bezüglich des Zeitstempels? Rohformat ist dies:

datetime: '2018-02-15 06:50:34.427688'

In Bezug auf das Parsen weiß ich nicht, was besser wäre:
parseOrder ändern, um mit fetchOrder zu arbeiten,
oder erstellen Sie eine neue, temporäre parseFetchOrder (da die gesamte Implementierung von fetchOrder ebenfalls temporär ist).

Bitte lassen Sie mich wissen, wie ich vorgehen soll.

eine Idee bezüglich des Zeitstempels?

Es ist leicht erklärt: keine Zeitstempeldaten für die Bestellung ... Der Zeitstempel, den Sie posten, ist der Handelszeitstempel (wird korrekt analysiert). Mit Codierung hat das überhaupt nichts zu tun. In dieser Antwort fehlen lediglich die Daten für die Bestellung. Werde das auch beheben.

Bitte lassen Sie mich wissen, wie ich vorgehen soll.

Keine Sorge im Moment, ich repariere den Parser so, dass er zumindest die Handelsbeträge + den Auftragserfüllungswert ausgibt.

Es ist leicht erklärt: keine Zeitstempeldaten für die Order ... Der Zeitstempel, den Sie posten, ist der Handelszeitstempel.

Richtig, macht Sinn. Zeitstempel ist für mich sowieso nicht wichtig :-)

Keine Sorge im Moment, ich repariere den Parser so, dass er zumindest die Handelsbeträge + den Auftragserfüllungswert ausgibt.

Idealerweise sollten wir die folgenden Informationen zurückgeben:
Preis,
Kosten,
Menge,
Gebühr

Diese Informationen sollten im Bestellstatus leicht verfügbar sein.

Diese Informationen sollten im Bestellstatus leicht verfügbar sein.

Nicht wirklich, es ist nicht ... der Gesamtbetrag der Bestellung ist noch unbekannt.

Idealerweise sollten wir die folgenden Informationen zurückgeben:
Preis,
Kosten,
Menge,
Gebühr

Wir können diese Informationen nur für Trades innerhalb der Order zurückgeben, aber nicht für die Order selbst. Für die Bestellung selbst können wir nur den gefüllten Betrag zurückgeben, nicht aber den Gesamtbetrag.

{ status: 'Finished',
  id: 962455719,
  transactions:
   [ { fee: '1.18',
       price: '187.99000000',
       datetime: '2018-02-15 06:50:34.427688',
       ltc: '2.50625000',
       tid: 54805885,
       type: 2,
       eur: '471.1499375000000000' } ] }

wenn Ergebnis == fertig, Gesamtmenge = gefüllte Menge (in diesem Fall 2.50625000 LTC)

@wannesdemaeght richtig, aber nur wenn es fertig ist (es kann teilweise gefüllt sein)

richtig, aber wenn es nicht fertig ist, kommt es so zurück:

{ Status: 'Offen', ID: 963180354, Transaktionen: [] }

also eigentlich egal

wenn status == fertig --> betrag = summe aller transaktionen. betrag (blöd, dass sie den betrag als ltc / eth / ... angeben)

richtig, aber wenn es nicht fertig ist, kommt es so zurück:
{ Status: 'Offen', ID: 963180354, Transaktionen: [] }

Dies ist nicht immer der Fall. Im Falle einer teilweisen Ausführung wird der Status = "Offen" mit nicht leeren Transaktionen zurückgegeben (da bin ich mir nicht sicher, sie speichern ihn möglicherweise bis zu dem Moment, an dem die Bestellung "Fertig" wird). Und in dieser Situation können wir den Gesamtbetrag der Bestellung leider nicht aus Trades ableiten. Ihre API ist zu schlecht.

die Summe der Beträge in Transaktionen entspricht dem erfüllten Teil einer offenen teilweise ausgeführten Order. so könnte vielleicht das Attribut "ausgefüllt" im Falle einer teilweise ausgeführten Bestellung bereitgestellt werden

@stabilus ja, das ist, was ich sage, wir können filled bereitstellen, aber in diesem Fall nicht insgesamt amount für die Bestellung.

Wird eine Korrektur hochladen und Sie hier bald aktualisieren.

macht Sinn.
Offen --> gefüllt = Summe der Beträge, Gesamtbetrag = undefiniert
Geschlossen --> gefüllt = Gesamtbetrag = Summe der Beträge

@kroitor
"Thx! Opencollective akzeptiert jedoch keine BTC %)) Sie akzeptieren Fiat-Zahlungen ... wenn Sie mit Krypto beitragen möchten, sind Ihre Beiträge willkommen, und die Krypto-Adressen sind:"

opencollective scheint BTC akzeptiert zu haben (sie haben ein Zahlungsgateway für BTC). Beim nächsten Mal kenne ich Ihre direkte BTC-Adresse. :)

@stabilus wow, wusste ich nicht %) Thx nochmal )

https://twitter.com/opencollect/status/943620141430067208

Ok, dies wurde in ccxt 1.10.1114 behoben und fetchOrder sollte jetzt normal funktionieren, wie oben in Bezug auf amount und filled beschrieben.

@stabilus , @wannesdemaeght lass es mich wissen, wenn du immer noch Schwierigkeiten damit hast. Vielen Dank für Ihr Engagement!

{ id: '962455719',
  datetime: undefined,
  timestamp: undefined,
  status: 'closed',
  symbol: 'LTC/EUR',
  type: undefined,
  side: undefined,
  price: undefined,
  cost: undefined,
  amount: 2.50625,
  filled: 2.50625,
  remaining: 0,
  trades:
   [ { id: '54805885',
       info: [Object],
       timestamp: 1518677434427,
       datetime: '2018-02-15T06:50:34.427Z',
       symbol: 'LTC/EUR',
       order: '962455719',
       type: undefined,
       side: undefined,
       price: 187.99,
       amount: 2.50625,
       fee: [Object] } ],
  fee: undefined,
  info: { status: 'Finished', id: 962455719, transactions: [ [Object] ] } }

Preis: wenn Status == geschlossen --> (Preis pro Trade * Betrag pro Trade) / Gesamtbetrag
Kosten: wenn Status == geschlossen --> Preis * Menge
Gebühr: wenn Status == geschlossen --> Summe der Gebühren pro Trade

@wannesdemaeght ja, du hast recht, werde das auch hinzufügen.

Ich liebe es wirklich, Leuten zu sagen, was sie tun sollen :rofl:

funktioniert wie ein Charmekumpel! Für mein Verständnis: fetchOrder macht 1 Aufruf an die Börse - nicht 2, richtig? Und es ruft die bitstamp orderStatus-Methode auf (die 10 Sekunden lang nicht zwischengespeichert wird). Richtig?

@stabilus

fetchOrder macht 1 Aufruf an die Börse - nicht 2, richtig?

Exakt.

großartig, und was ist mit "es ruft die bitstamp orderStatus-Methode auf (die nicht 10 Sekunden lang zwischengespeichert wird). Richtig?"

Es ruft die bitstamp orderStatus-Methode auf (die nicht 10 Sekunden lang zwischengespeichert wird). Richtig?"

Jawohl.

Preis, Kosten und Gebühr für die Rücksendung der Bestellung in CCXT 1.10.1115 hinzugefügt

Danke, Mann! Funktioniert perfekt.