Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Twsapi
- Messages
Search
|
Re: anyone know where I can find the IB maintenance timetable
keep hitting the return key sorry. Anyway the script tries 10 times and same message. I tried to run in 5 times after 18:00 with the same results. The last time I tried was 22:30 cst. My bet is that this is a maintenance issue but I can't find the IB schedule for system tasks. Is it posted somewhere please? The script is fine and so is my connection to my TWS connection . thank you. |
|
anyone know where I can find the IB maintenance timetable
All this week I have had a cronjob running a script to get 3 years of daily trades from ib using reqHistoricalData . Nothing special, just running download speed tests for something else. The cronjob ran successfully at 18:00 cst monday through thursday but this friday 11/15/24 it failed consistantly and all I got was |
|
Re: execDetails(...)+commissionReport(...) Callback different behaviour when not opening trade history
I can confirm that TWS 10.30.1p indeed sends unsolicited commission and execution reports upon client connection, if the "Trade History" window is open. But I cannot believe that this is intended behavior and I am not sure which other TWS versions show this behavior. The correct way to get commission and execution reports for recent orders is a call to If your client needs historical execution and commission reports, it should call reqExcutions. The only documented relationship between "Trade History" in TWS and calls is the time period for which trade details are available. The "" chapter says: Important: By default, only those executions occurring since midnight for that particular account will be delivered. If you want to request executions up to last 7 days, TWS's Trade Log setting "Show trades for ..." must be adjusted to your requirement. Please note, that IB Gateway would be unable to change the Trade Log's settings, thus limited to only executions since midnight to be delivered. 闯ü谤驳别苍 PS. When my client called during startup while TWS had an open Trade History windows, all commission and execution reports as well as were received twice.
?
On Fri, Nov 15, 2024 at 04:37 PM, <simon.meier1987@...> wrote:
|
|
execDetails(...)+commissionReport(...) Callback different behaviour when not opening trade history
Hi all,
i noticed a difference in the behaviour of the execDetails(...)+commissionReport(...) Callback functions. When i start the tws and do not open the "trade history" dialog then all orders that are opened or closed from this point are only "returned" ONCE in the execDetails(...) + commissionReport(...). Furthermore i do not receive the previous trading history ( more precise all executions and commission reports that occured before the new start of tws). If i open the dialog shortly after the start of the tws i receive all the executions and it keeps sending them in a regular time intervall.
?
The reason why i am asking ( or created a topic), is that my trading system gets invalidated if i dont receive all the execution (i cant determined when a position is closed and the is no other way with this design). The problem is that the tws is restarting every day, so i get this set of conditions (after restart -> the dialog hasn't been opened, without intervening) and thus the callbacks are sending only once.?
?
Is it possible that a message is lost ( due to connection problems) ? If so, is there some mechanism to get the dialog open? automatically ? Or how can i enforce it that the callbacks are sending periodically ? How is this solved in the IB Gateway ?
?
regards,
Simon
?
? |
|
Re: keeping subscriptions
I check each 60 seconds if there was any data that was delivered if not I resubscribe
?
sometimes this happens to scanners as well and you have to trigger a restart of IBKR
?
i use a docker container for IBKR to deal with this
?
its quite a mess but thats how it is unfortunately?
?
IBKR is the cheapest source to realtime data that has an individual friendly api |
|
Re: Error 201 - Error 201, reqId 1067: Order rejected - reason:<h3>Action Required</h3><br>We have identified certain information on your account that needs to be confirmed or corrected in order to avoid a possible trading disruption.
I don't see pending items. The API successfully executed two trades prior to this error message on the same day. The provided in the error message just doesn't make sense:?
sso://action=ACCT_MGMT On Fri, Nov 15, 2024 at 4:25?AM Jelmer P. via <vriesdephilip=[email protected]> wrote:
|
|
Re: Error 201 - Error 201, reqId 1067: Order rejected - reason:<h3>Action Required</h3><br>We have identified certain information on your account that needs to be confirmed or corrected in order to avoid a possible trading disruption.
Have you logged in on the website and clicked the bell icon (right top) to check for pending items? Or maybe trading permissions? |
|
Error 201 - Error 201, reqId 1067: Order rejected - reason:<h3>Action Required</h3><br>We have identified certain information on your account that needs to be confirmed or corrected in order to avoid a possible trading disruption.
Hi, I encountered the following error today: ERROR Error 201, reqId 1067: Order rejected - reason:<h3>Action Required</h3><br>We have identified certain information on your account that needs to be confirmed or corrected in order to<br>avoid a possible trading disruption. Please click <a href="sso://action=ACCT_MGMT">here</a> to review this information. What could this mean? And how to resolve this issue? ?kos |
|
keeping subscriptions
Hi Group,
For quite some time I observe that some data subscriptions do not hold overnight. Most of them are streaming Level I tick data.
My routine includes daily restart at 5PM EST, this is when all market data subscriptions are started.
Stock symbols pause trading at 8PM EST, and remain idle until IB restart at around 1-2AM EST.
Everything runs smooth for most symbols during all the reconnections, but for some symbols.
Usually what happens, a few symbols just fail to acquire data starting at 4AM EST unless I restart again.
The weird part is that they are different symbols each time, and there're no errors logged whatsoever.
Again no changes to data subscriptions are made from the start at 5PM until 4AM when ETH starts trading.
Just some subscriptions do not remain it seems.
This is quite difficult to catch, as many symbols do not open legitimately at 4AM as there're no quotes or trades.
But this shouldn't happen to actively traded symbols.
No data lines limits are breached.
Where should I look to see why this happens?
?
? |
|
Re: Updating a profit target order
When you make the order update call, does the original parent (entry) order still exist, or has that been filled by that time? Take a look at the topic "10326 - OCA group revision is not allowed". Apparently, the bracket order update behavior changed and TWS 10.30 and TWS 10.32 will reject the update if the parent order is not open any longer, but the order your are trying to update still has the parentId field pointing there. If you cannot use a TWS/IBGW prior to 10.30, one suggestion was to set the parentId to 0 when you update it. Just a guess. 闯ü谤驳别苍 ?
?
?
On Wed, Nov 13, 2024 at 06:16 PM, IBmark wrote:
|
|
Updating a profit target order
Hello!
?
I have been trying to fix something for the last few days but I failed. When the code attempts to update a target order belonging to a bracket order, It throws error 135. After logging I confirmed it tries to update the entry order instead of the profit taking order. Everything in the code seems fine.? ?
?
On trade class:
?
? ? def update_profit_target_price(self, broker_instance, new_profit_target):
? ? ? ? self.profit_order.lmtPrice = new_profit_target
? ? ? ? self.profit_order.transmit = True
? ? ? ? broker_instance.placeOrder(self.profit_order.orderId, self.contract, self.profit_order)
?
?
And on the logic class after being called to update:
?
def update_profit_targets_to_new_fibo_level(self):
? ? ? ? # when levels change, the profit target for any OPEN positions that were entered in the current session
? ? ? ? # is updated; ?the stop loss for the position remains unchanged
? ? ? ? for t in self.trade_list:
? ? ? ? ? ? assert isinstance(t, Trade)
? ? ? ? ? ? status = t.status_at_broker(self.ib)
? ? ? ? ? ? if status == 'OPEN':
? ? ? ? ? ? ? ? # open position: adjust profit target for open position to new level; leave stop loss as is
? ? ? ? ? ? ? ? ? ? new_profit_target_price = (self.data[self.profit_taking_for_long_positions])
? ? ? ? ? ? else:
? ? ? ? ? ? ? ? ? ? new_profit_target_price = (self.data[self.profit_taking_for_short_positions])
? ? ? ? ? ? LOG.info(f'{self.contract_ticker} ~ update ~ Trade {t.trade_id}: status = {status}, '
? ? ? ? ? ? ? ? ? ? ? ? ?f'Profit target for open position will be updated to new level '
? ? ? ? ? ? ? ? ? ? ? ? ?f'(${new_profit_target_price})')
? ? ? ? ? ? t.update_profit_target_price(self.ib, new_profit_target_price)
?
?
Order structure:
?
# Main order (limit order)
? ? ? ? main_order = Order()
? ? ? ? main_order.eTradeOnly = False
? ? ? ? main_order.firmQuoteOnly = False
? ? ? ? main_order.orderId = entry_order_id
? ? ? ? main_order.orderRef = f'{self.stamp}_ENTRY'
? ? ? ? main_order.action = action
? ? ? ? main_order.orderType = "LMT"
? ? ? ? main_order.totalQuantity = quantity
? ? ? ? main_order.lmtPrice = limit_price ?# This is now the limit price
? ? ? ? main_order.transmit = False ?# To ensure the main order isn't transmitted before its children
? ? ? ? main_order.tif = 'DAY' ?# Make the order Good-till-Cancelled
? ? ? ? main_order.outsideRth = False ?# Enable Outside Regular Trading Hours
? ? ? ? # Take profit order
? ? ? ? take_profit = Order()
? ? ? ? take_profit.eTradeOnly = False
? ? ? ? take_profit.firmQuoteOnly = False
? ? ? ? take_profit.orderId = entry_order_id + 1
? ? ? ? take_profit.orderRef = f'{self.stamp}_PROFIT_TARGET'
? ? ? ? take_profit.action = "SELL" if action == "BUY" else "BUY"
? ? ? ? take_profit.orderType = "LMT"
? ? ? ? take_profit.totalQuantity = quantity
? ? ? ? take_profit.lmtPrice = take_profit_price
? ? ? ? take_profit.parentId = entry_order_id ?# Important: this ties the order to the parent order
? ? ? ? take_profit.tif = 'GTC'
? ? ? ? take_profit.transmit = False
? ? ? ? take_profit.outsideRth = True ?# Here is where you set the order to allow execution outside RTH
? ? ? ? # Stop loss order
? ? ? ? stop_loss = Order()
? ? ? ? stop_loss.eTradeOnly = False
? ? ? ? stop_loss.firmQuoteOnly = False
? ? ? ? stop_loss.orderId = entry_order_id + 2
? ? ? ? stop_loss.orderRef = f'{self.stamp}_STOP_LOSS'
? ? ? ? stop_loss.action = "SELL" if action == "BUY" else "BUY"
? ? ? ? stop_loss.orderType = "STP"
? ? ? ? stop_loss.totalQuantity = quantity
? ? ? ? stop_loss.auxPrice = stop_loss_price ?# Stop price
? ? ? ? stop_loss.parentId = entry_order_id ?# Important: this ties the order to the parent order
? ? ? ? stop_loss.tif = 'GTC'
? ? ? ? stop_loss.transmit = True
? ? ? ? stop_loss.outsideRth = True ?# Here is where you set the order to allow execution outside RTH
? ? ? ? self.entry_order = main_order
? ? ? ? self.profit_order = take_profit
? ? ? ? self.stop_loss_order = stop_loss
?
?
I have been trying to fix it for a while now but running out of options before digging deeper into status at broker. Does anyone see anything I am missing? Learning here, so please go easy on me.
?
thanks in advance for any input,
?
m?
? |
|
Re: Trail price movement callbacks?
It is correct, that the callback focuses on the status and (partial) fills of an order, but there is also the callback. That callback provides you information about all aspects of open orders and the changes that take place. You receive:
That includes any changes that were applied manually in TWS (such as changing the limit of an order) or automatically by IBKR or the exchange (such as the current trail price). And a "master client" or "client 0" can request callbacks for orders placed from within TWS or other client applications. More detail in the "Order Management" section of the TWS API documentation or . I don't think that there is anything missing. 闯ü谤驳别苍 ?
On Wed, Nov 13, 2024 at 03:51 PM, Orionn wrote:
Since no one replied to your question, I will provide my (possibly outdated) contribution. |
|
Re: Trail price movement callbacks?
Since no one replied to your question, I will provide my (possibly outdated) contribution.
Several years ago, I was also interested in monitoring the updated price of trailing (stop) orders. I confirmed that the "orderStatus" callback was called periodically for these order types but unfortunately no price updates were being issued. I contacted IB which provided the usual response: "it is like this by design". So I gave up. I cannot confirm if this unfortunate limitation is still in place. Hope this helps. -- |
|
Re: 10326 - OCA group revision is not allowed
开云体育After upgrading, the api and tws I ran into similar problems, but they all are fixable. Here's my original post:/g/twsapi/topic/java_tws_api_972_03_too_old/109159281 In the old situation, I always updated an oca child order with the same parameters, including the parentId . That no longers works. And the error message is actually helpful ;-) Leave parentId out when updating a child oca order when the parent has already been triggered. Worked for me. Good luck, regards, Raoul On 13-11-2024 17:19, Andrew Flis via
groups.io wrote:
|
|
Re: 10326 - OCA group revision is not allowed
I would like to confirm that IBKR has some serious problems with software releases. 10.30.1o released Oct 24 is garbage. I tried to create a simple bracket order (through API) and once the parent order was filled I tried to modify the stop order and later the target order. Both attempts failed with error 135: parent order not found. I created a ticket. Two days later IBKR released 10.30,1p with the same results. I downloaded 10.23, which works and sent logs from both 10.30.1p and 10.23 repeating the same bracket order test . I was advised not to use 10.30.1p. On Nov 12 10.30.1q was released. I managed to to modify stop order in the bracket order once. Any other attempt after that failed with the same error.. It shows how little care and virtually no testing takes place at IBKR (bracket order is so basic one) . How long they are going to be in business !?
One lesson to be learned: keep the working version in a separate directory, test new software release in paper account before using it in your live account.Here is the link to 10.23 which is not going to be overwritten by automatic software update.
?
?
?
[Moderator Addition]
Please not that TWS 10,23 is available for download only not IBKR.
|
|
Re: How are built the Continuous future data retrieved with secType = CONTFUT ?
A watchout with ratio adjustments (RA):
- useful when calculating % returns, roll yields or other multiplicative measures
- resulting in different signals when running the same ATS on it again (backtesting results will differ)
?
For completeness, one can calculate rollover also like this:
- by date no adjustment
- by volume (front < back) no adjustment
- by date backadjusted BA (front settlement - back settlement)
- by volume backadjusted BA (front settlement - back settlement)
?
The BA data (not available on TWS) is suitable for additive measures (net profit, draw down) and remains stable for backtesting (up to a constant offset). The ratio data is suitable only for multiplicative measures (returns, standard deviation of returns, TWRR/CAGR, etc.) - you cannot add profit from trade A in $ with profit from trade B a few months ago. Also, obviously one cannot have a buy on one side of an RA and the corresponding sale on the other side (this is true for BA also). |
|
Re: downlod historical SH data, Proshares Short S&P 500, before the split
Yes, a time is required. What worked best for me is this:
闯ü谤驳别苍
?
On Tue, Nov 12, 2024 at 03:37 PM, <supis31@...> wrote:
|
|
Re: downlod historical SH data, Proshares Short S&P 500, before the split
SH before and after the reverse split are two different instruments. ProShares, for example, indicates the SH CUSIPs as 74347B425 (before) and 74349Y753 (after) and, consequently, IBKR changed the conid for the SH contracts as well:
I am not sure what exactly your "Stock()" function does, but if it returns a contract with conid 236687911, that contract will now be rejected even for data requests for time frames when it was the correct contract. At this point (20241107 and after) only contracts for SH with conid 738523410 will work. But those new contracts describe an instrument with 1/4th of the shares than before the reverse split. I guess that is why that contract reports prices from before 201107 at 4x the actual price for that day. And the volume is probably be reported at 1/4 of the actual volume. 闯ü谤驳别苍 ?
reqHistoricalData:SH:20241113 00:00:00 US/Eastern:3:YEAR:_1_day:TRADES:true:false
?
On Tue, Nov 12, 2024 at 12:23 PM, <supis31@...> wrote:
|
|
Re: downlod historical SH data, Proshares Short S&P 500, before the split
I think I have to provide a time, otherwise I get an error:
Error 10314, reqId 13: End Date/Time: The date, time, or time-zone entered is invalid. The correct format is yyyymmdd hh:mm:ss xx/xxxx where yyyymmdd and xx/xxxx are optional. E.g.: 20031126 15:59:00 US/Eastern ?Note that there is a space between the date and time, and between the time and time-zone. ?If? no date is specified, current date is assumed. If no time-zone is specified, local time-zone is assumed(deprecated). ?You can also provide yyyymmddd-hh:mm:ss time is in UTC. Note that there is a dash between the date and time in UTC notation., contract: Stock(symbol='SPY', exchange='SMART', primaryExchange='ARCA', currency='USD')
|
to navigate to use esc to dismiss