IB -> backfill dati ....
- Creatore Discussione Disilluso
- Data di inizio
Danlead
NO PAIN NO GAIN
- Registrato
- 27/3/02
- Messaggi
- 8.851
- Punti reazioni
- 421
E' il recupero dello storico dei dati, attualmente si hanno a disposizione 24 ore di storico intraday.Pig-H ha scritto:
Alcuni software (amibroker,fibonaccitrader, etc.) sono stati aggiornati con le nuove api ed eseguono automaticamente il backfill.
Si puo' ottenere anche manualmente tramite le api programmando in vb, c, java, ma non tramite il dde / excel
Ciao
Danlead
NO PAIN NO GAIN
- Registrato
- 27/3/02
- Messaggi
- 8.851
- Punti reazioni
- 421
Pig-H ha scritto:Io non ho ancora aggiornato l'ultima versione della tws, ma hai un link in cui posso trovare le istruzioni su come usarlo?
grazie!
Qua' trovi le istruzioni sul comando da utilizzare in VB per la richiesta dei dati storici intraday
http://www.interactivebrokers.com/p.../ActiveX_Other/activexmethods.htm#reqIntraday
QUESTE SONO LE INFO. CHE HO A DISPOSIZIONE:
Expanded Historical Data Queries
Since its introduction in API version 8.4 and TWS version 843.0 (client version 18 and server version 16, respectively), all socket-based API technologies, including the socket client library, ActiveX, and Java, have had the ability to extract historical data going back 24 hours for any valid contract or combo. This ability has been expanded in API Version 8.51 (client version 20) and TWS version 848 (server version 20) to allow queries of up to one week in duration, which can end at any date and time during the past six months. For this purpose, the reqIntradayData method has been renamed to reqHistoricalData(), which now sends a new version 3 of the message. The messages TWS sends in response to these queries have been renamed HISTORICAL_DATA messages, with their format unchanged. As has always been the case with API historical data queries, data is returned in bars of a nature very similar to the bars in TWS charts, with the final bar returned in response to any reqHistoricalData() request having a start time value of “finished.” This allows an API application to know when its query has completed. Finally, it remains the case that only one request for historical data can be in process at any given time.
The signature of the reqHistoricalData() method is:
reqHistoricalData(long id, String symbol, String secType, String expiry, double strike, String right, String multiplier, String exchange, String curency, String endDateTime, String durationStr, long barSizeSetting, String whatToShow, long useRTH, long formatDate)
The “endDateTime” parameter accepts a string in the form yyyymmdd HH:mm:ss, with a time zone optionally allowed after a space at the end of the string. At the time of this release, “20050701 18:26:44 GMT” is a legal value for this parameter (though it will not be six months later!)
The “durationStr” time span covered by a reqHistoricalData() request is specified via an integer followed by a space, followed by one of these units: S (for seconds), D (for days), or W (for weeks). If no unit is given, seconds is assumed.
The “barSizeSetting” specifies the size of the bars that will be returned (within limits imposed by IB’s servers and TWS). These eleven values are allowed:
1 sec 1
5 sec 2
15 sec 3
30 sec 4
1 minute 5
2 minutes 6
5 minutes 7
15 minutes 8
30 minutes 9
1 hour 10
1 day 11
The “whatToShow” parameter determines the nature of the data extracted , with allowable values being “TRADES,” “MIDPOINT,” “BID,” “ASK,” or “BID_ASK.” Bars of the first four types contain the start time, open, high, low, close, volume, and weighted average price during the time slice in question. The contents of bars returned in response to a BID_ASK query differ from those returned by the other query types, in that the open and close values are actually the time weighted average bid, and time weighted average offer, respectively. This makes these bars identical in nature to TWS’s “BID_ASK” candlestick chart bars.
Two additional parameters to reqHistoricalData() calls are “useRTH” and “formatDate.” If useRTH is set to 0, all data available during the time span requested is returned, even data bars covering time intervals where the market in question was outside of its “Regular Trading Hours” (RTH). If useRTH has a non-zero value, only data within the “Regular Trading Hours” of the product in question is returned, even if the time span requested falls partially or completely outside of them. If “formatDate” = 1, dates applying to bars are returned in a format “yyyymmdd{space}{space}hh:mm:dd” - the same format already used in EXECUTION_DATA messages. If formatDate = 2, those dates are returned as a long integer specifying the number of seconds since 1/1/1970 GMT.
When TWS connects either to IB via the internet, or an API client application, it creates Java-based sockets of a predetermined size. If an API application intends to make historical data requests that return more than 1000 bars, it is recommended that TWS be configured to increase the sizes of the API socket buffer. This can be done in the “settings.xml” file in the user’s Jts directory. It is important that TWS not be running when its settings.xml file is manually modified. In the <SystemSettings> XML element, the <apiSocketBufferSizes> elements can be used for this purpose. Adding this line to the <SystemSettings> element in settings.xml should suffice:
<apiSocketBufferSizes>500000</apiSocketBufferSizes>
Expanded Historical Data Queries
Since its introduction in API version 8.4 and TWS version 843.0 (client version 18 and server version 16, respectively), all socket-based API technologies, including the socket client library, ActiveX, and Java, have had the ability to extract historical data going back 24 hours for any valid contract or combo. This ability has been expanded in API Version 8.51 (client version 20) and TWS version 848 (server version 20) to allow queries of up to one week in duration, which can end at any date and time during the past six months. For this purpose, the reqIntradayData method has been renamed to reqHistoricalData(), which now sends a new version 3 of the message. The messages TWS sends in response to these queries have been renamed HISTORICAL_DATA messages, with their format unchanged. As has always been the case with API historical data queries, data is returned in bars of a nature very similar to the bars in TWS charts, with the final bar returned in response to any reqHistoricalData() request having a start time value of “finished.” This allows an API application to know when its query has completed. Finally, it remains the case that only one request for historical data can be in process at any given time.
The signature of the reqHistoricalData() method is:
reqHistoricalData(long id, String symbol, String secType, String expiry, double strike, String right, String multiplier, String exchange, String curency, String endDateTime, String durationStr, long barSizeSetting, String whatToShow, long useRTH, long formatDate)
The “endDateTime” parameter accepts a string in the form yyyymmdd HH:mm:ss, with a time zone optionally allowed after a space at the end of the string. At the time of this release, “20050701 18:26:44 GMT” is a legal value for this parameter (though it will not be six months later!)
The “durationStr” time span covered by a reqHistoricalData() request is specified via an integer followed by a space, followed by one of these units: S (for seconds), D (for days), or W (for weeks). If no unit is given, seconds is assumed.
The “barSizeSetting” specifies the size of the bars that will be returned (within limits imposed by IB’s servers and TWS). These eleven values are allowed:
1 sec 1
5 sec 2
15 sec 3
30 sec 4
1 minute 5
2 minutes 6
5 minutes 7
15 minutes 8
30 minutes 9
1 hour 10
1 day 11
The “whatToShow” parameter determines the nature of the data extracted , with allowable values being “TRADES,” “MIDPOINT,” “BID,” “ASK,” or “BID_ASK.” Bars of the first four types contain the start time, open, high, low, close, volume, and weighted average price during the time slice in question. The contents of bars returned in response to a BID_ASK query differ from those returned by the other query types, in that the open and close values are actually the time weighted average bid, and time weighted average offer, respectively. This makes these bars identical in nature to TWS’s “BID_ASK” candlestick chart bars.
Two additional parameters to reqHistoricalData() calls are “useRTH” and “formatDate.” If useRTH is set to 0, all data available during the time span requested is returned, even data bars covering time intervals where the market in question was outside of its “Regular Trading Hours” (RTH). If useRTH has a non-zero value, only data within the “Regular Trading Hours” of the product in question is returned, even if the time span requested falls partially or completely outside of them. If “formatDate” = 1, dates applying to bars are returned in a format “yyyymmdd{space}{space}hh:mm:dd” - the same format already used in EXECUTION_DATA messages. If formatDate = 2, those dates are returned as a long integer specifying the number of seconds since 1/1/1970 GMT.
When TWS connects either to IB via the internet, or an API client application, it creates Java-based sockets of a predetermined size. If an API application intends to make historical data requests that return more than 1000 bars, it is recommended that TWS be configured to increase the sizes of the API socket buffer. This can be done in the “settings.xml” file in the user’s Jts directory. It is important that TWS not be running when its settings.xml file is manually modified. In the <SystemSettings> XML element, the <apiSocketBufferSizes> elements can be used for this purpose. Adding this line to the <SystemSettings> element in settings.xml should suffice:
<apiSocketBufferSizes>500000</apiSocketBufferSizes>
Disilluso
... ancora oggi !!!
- Registrato
- 16/2/02
- Messaggi
- 1.201
- Punti reazioni
- 35
jakeglb ha scritto:Mi avevano detto tempo fa che avrebbero attivato questa funzione...bene
Giacomo
Attiva è attiva (anche se in realtà, pare, che fino alla TWS 849, di prossima emissione, il servizio sia si disponibile "di nascosto")
Per chi non sa una cippa di programmazione (come il sottoscritto) si deve appoggiare ad un prodotto pre-confezionato (Metaserver o Hyperserver)
Io, su di un PC. ho il Metaserver -> Aspettate a comprare la versione a pagamento !
La funzione di Backfill manda in tilt tutto il Meta ......... malgrado oggi abbiano rilasciato ben 2 patch !!!!
Sono nu' poco incaxxato con le OO che mi girano ad elicottero