¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
Date

Re: Trades run using python script remotely not running as expected

 

Good suggestion
Listening to errors is vital because sending an order in RO or even a simple reqIds (int numIds) trigger an error message if APi is not in RW


Re: going to have to reconsider my approach to calling reqMktData for multiple symbols how does the forum handle it please?

 

It does deliver wrong data, plenty of holes in historical market data, positions are sometimes erroneous, also try querying the new SCHEDULE historical data, pure joke, doesn't match the reqHeadTimeStamp earliest data point, doesn't match the contract expiry date i.e. will give you trading days and hours past expiry date, etc.


Re: going to have to reconsider my approach to calling reqMktData for multiple symbols how does the forum handle it please?

 

It's a lttle bit clumsy API because it show and "it smell" incremental evolution. But it is consistent.
The "unsaid" part that you hard learn by trial and error, like in any API, does varies depending upon the kind of information you look for
- Real Time
- Historical
- Fundamentals
- Technicals (like HeadStamp that should be seen as part of Historical but behave differently)
Each one does have some "variation on the theme". Understand do no assume that rules of one category does apply to other. Each one require a separate reading of the documentation.
RealTime being the most touchy one.

BTW do not re-subscribe without canceling your previous subscription. While there are a certain level of fool proofing from IB you should first respect the basic concepts.
I never saw a "unsubscribe" do do any harm, while re-subscribing for same instrument same condition may ban your new subscription (IB rule and documented) and it is frequently a silent ban (or an error message of a kind that doesn't enlighten this as the issue)

I work with many others API/ABI and frankly none are matching criteria computer science typically expect in accuracy and consistencies.
That is part of this "art".

At least IB doesn't deliver wrong data (some other API does!)
Note:
The only wrong info I caught IB delivering it? is Institutional % (even on TWS, of I must say I never understand how to interpret higher than 100%, like some stock where it reach 180%)
Seems they aggregate institutional supplied info without filtering consistencies (and institution hate disclosing their portfolio so they make very hard deciphering their legal disclosure, and anyway they doesn't have same aspect on year end and terms)
Anyway this is surely not a main issue.


Re: Trades run using python script remotely not running as expected

 

The classic gotcha in these situations is the gateway configuration on the host machine,
Configuration > API > Settings > Read-Only API

Hope this helps.


Re: RealTime tick data feed on roughly 350 symbols

 

I have a strategy running that trades all US equities listed on NASDAQ and NYSE simultaneously.
For that one I use 3 snapshots at different points of the day to take trading decisions.
You can literally take as many snapshots as you want, as long as you have the corresponding market data subscription.

For each contract:
self.reqMktData(reqId, contract, str(), True, False, [])
time.sleep(0.02)


Re: going to have to reconsider my approach to calling reqMktData for multiple symbols how does the forum handle it please?

 

Useful thread, I will add my 2 cents.

While I also monitor errors, I find it somewhat unreliable, many here swear by error code x to take action y, I disagree.
I have a separate loop monitoring the quality of the streams, if the last update was more than x ago, I resubscribe.
As a general rule, I wouldn't call anything built on top of the IB API rock solid.


Re: error with reqExecutions

 

I have the following repro:
from ibapi.client import *
from ibapi.wrapper import *
?
port = 7500
#port = 9497
?
class TestApp(EClient, EWrapper):
?
? ? def __init__(self):
? ? ? ? EClient.__init__(self, self)
?
? ? def nextValidId(self, orderId: OrderId):
?
? ? ? ? exec_filter = ExecutionFilter()
? ? ? ? exec_filter.secType = 'Fut'
? ? ? ??
? ? ? ? self.reqExecutions(
? ? ? ? ? ? 12345,
? ? ? ? ? ? exec_filter
? ? ? ? )
?
? ? def execDetails(self, reqId: int, contract: Contract, execution: Execution):
? ? ? ? print(reqId, contract, execution)
?
? ? def execDetailsEnd(self, reqId: int):
? ? ? ? print("execDetailsEnd.", reqId)
? ? ? ? self.disconnect()
?
?
app = TestApp()
app.connect("127.0.0.1", port, 1007)
app.run()

This code works fine. If I replace the line:? exec_filter.secType = 'Fut' with exec_filter.secType = 'Bag' the code now hangs. So I think the issue seems to be Bag orders.

I have notified the IB guys also. I will keep you posted. I was wondering do you guys see similar issues with Bag orders


Re: error with reqExecutions

 

Hi all,

What is your experience with commission events?

?I'm experiencing some issues lately on both exec and commission which I was catching successfully in the master client but not for the past 3 weeks, independent if 10.23 or not...

Thanks?

On Fri, 7 Jul 2023 at 19:53, <nkulki@...> wrote:
I wanted to add couple of my findings.
for 10.19.2a both the methods:?execDetails?and?execDetailsEnd fire sucessfully.
For 10.23.2a neither of the methods fire
However if I change the settings for "Instrument Specific Attributes for dual mode API Client in" to UTC or operator time zone the two methods again fire. So this gives me a clue that something is failing due to timezones. I do trade futures contracts across multiple timezones like SGX and Eurex. So perhaps this is why I see a failure and others dont see it.


Re: error with reqExecutions

 

Thank you for that update and for making the error case more precise, Narendra.

So it looks like only the "latest production" version 10.23.2a of TWS/IBGW has a regression that causes the issue and there are two workarounds:
  • Use the "time tested" version 10.19.2a of TWS/IBGW
  • Change the setting of "Instrument Specific Attributes for dual mode API Client in" to UTC or operator time zone

I know that IBKR recently sent out a "retirement" notices for 10.19.1 versions of TWS/IBGW and suggested you upgrade to the "latest" version. I always read those notices as "the latest version in the track you are using" and 10.19.2a is a perfectly good release right now (and apparently more stable than 10.23)? As a matter of practice we always run those "standalone time tested" versions of TWS/IBGW that used to be called the "stable" versions. Because they generally were and are more stable.

´³¨¹°ù²µ±ð²Ô

On Fri, Jul 7, 2023 at 01:53 PM, <nkulki@...> wrote:

I wanted to add couple of my findings.
for 10.19.2a both the methods:?execDetails?and?execDetailsEnd fire sucessfully.
For 10.23.2a neither of the methods fire
However if I change the settings for "Instrument Specific Attributes for dual mode API Client in" to UTC or operator time zone the two methods again fire. So this gives me a clue that something is failing due to timezones. I do trade futures contracts across multiple timezones like SGX and Eurex. So perhaps this is why I see a failure and others dont see it.


Re: error with reqExecutions

 

I wanted to add couple of my findings.
for 10.19.2a both the methods:?execDetails?and?execDetailsEnd fire sucessfully.
For 10.23.2a neither of the methods fire
However if I change the settings for "Instrument Specific Attributes for dual mode API Client in" to UTC or operator time zone the two methods again fire. So this gives me a clue that something is failing due to timezones. I do trade futures contracts across multiple timezones like SGX and Eurex. So perhaps this is why I see a failure and others dont see it.


Re: error with reqExecutions

 

[Moderator comment]

Originally, this was reported as a connection timeout issue with ib_insync in topic "help connecting on 10.23". All ib_insync related discussion should continue on that topic.

However, the root cause of the issue seems to be that newer versions of TWS/IBGW intermittently fail to send execDetailsEnd messages for reqExecutions calls. This would obviously impact TWS API implementations for all languages.

The discussion in this topic should focus on experiences with missing execDetailsEnd? callbacks.

´³¨¹°ù²µ±ð²Ô

On Fri, Jul 7, 2023 at 11:00 AM, <nkulki@...> wrote:

I am noticing that on my end after calling?reqExecutions, the call back?execDetails is not invoked. As a result my code simply keeps waiting until I get a timeout error. Has someone else seen this error too?


error with reqExecutions

 

I am noticing that on my end after calling?reqExecutions, the call back?execDetails is not invoked. As a result my code simply keeps waiting until I get a timeout error. Has someone else seen this error too?


Re: RealTime tick data feed on roughly 350 symbols

 

The limit of 100 instruments is not an API limitation but a limitation on your account.

Why don't you reread the Market Data Lines section in chapter of the TWS API to learn how you can get/purchase simultaneous data for more than 100 instruments.

You could also search our archive since we had many discussions about "more than 100 instruments" over the years.

´³¨¹°ù²µ±ð²Ô


RealTime tick data feed on roughly 350 symbols

 

I want to build a trading program based on the TWSAPI. And I'd like to monitor around 350 stocks's price change.

Seems there's a limit of 100 symbols for my api. Is there any way I could build the realtime price monitor?

And pls Noticed that it's not necessary using tick data, 1-minute or 5-minutes are both acceptable.


Re: Problems with the API in receiving data in real time with reqMarketData ()

 

Imho, CBOE is not NASDAQ.?
You need another subscription.?


Re: Trades run using python script remotely not running as expected

 

Sorry, I posted that to the wrong list, please ignore my last message.

Hunter

On Wednesday, July 5, 2023 at 02:47:18 PM PDT, Hunter C Payne via groups.io <hunterpayne2001@...> wrote:


Perhaps maybe track down the professor who is teaching that class and ask him not to use Maven as a classroom example.? Just to prevent this from happening again.? Or maybe that is too much?

Hunter


On Wednesday, July 5, 2023 at 02:42:12 PM PDT, omgwtfsalty@... <omgwtfsalty@...> wrote:


I am not sure if anyone will be able to help me with this as this seems to be a very niche problem.

For a while I have been running my script trade.py which creates bracket orders and exits by printing "trades complete". I login to my trade server using ssh and run the script using python3 trades.py.

However, if I try to automate this by using a python script on my main server, which in turn uses subprocesses run or asyncssh, ssh ¡­ host name ¡­ python3 trades.py, the script runs all the way, and prints trades complete, however I do not see any trades being execute.

I checked the logs in both cases and they look exactly the same, as if trades had been placed. But in the second instance no trades are actually executed.

I am not sure why the tws api behaves this way, does anyone have any ideas or suggestions on how I can troubleshoot this issue?


Re: Trades run using python script remotely not running as expected

 

Sorry I don¡¯t understand what you mean. What¡¯s maven?


Re: Trades run using python script remotely not running as expected

 

Perhaps maybe track down the professor who is teaching that class and ask him not to use Maven as a classroom example.? Just to prevent this from happening again.? Or maybe that is too much?

Hunter


On Wednesday, July 5, 2023 at 02:42:12 PM PDT, omgwtfsalty@... <omgwtfsalty@...> wrote:


I am not sure if anyone will be able to help me with this as this seems to be a very niche problem.

For a while I have been running my script trade.py which creates bracket orders and exits by printing "trades complete". I login to my trade server using ssh and run the script using python3 trades.py.

However, if I try to automate this by using a python script on my main server, which in turn uses subprocesses run or asyncssh, ssh ¡­ host name ¡­ python3 trades.py, the script runs all the way, and prints trades complete, however I do not see any trades being execute.

I checked the logs in both cases and they look exactly the same, as if trades had been placed. But in the second instance no trades are actually executed.

I am not sure why the tws api behaves this way, does anyone have any ideas or suggestions on how I can troubleshoot this issue?


Trades run using python script remotely not running as expected

 

I am not sure if anyone will be able to help me with this as this seems to be a very niche problem.

For a while I have been running my script trade.py which creates bracket orders and exits by printing "trades complete". I login to my trade server using ssh and run the script using python3 trades.py.

However, if I try to automate this by using a python script on my main server, which in turn uses subprocesses run or asyncssh, ssh ¡­ host name ¡­ python3 trades.py, the script runs all the way, and prints trades complete, however I do not see any trades being execute.

I checked the logs in both cases and they look exactly the same, as if trades had been placed. But in the second instance no trades are actually executed.

I am not sure why the tws api behaves this way, does anyone have any ideas or suggestions on how I can troubleshoot this issue?


Intermittent IBGW connection problems 10.19.2a

 

¿ªÔÆÌåÓý

Since switching from IBGW 10.12.2v (support ends July, 18th) to 10.19.2a I observe intermittent disconnects between IBGW and the IB server.
It is therefore not possible e.g. to get a continuous realtime tick-by-tick data supply (EUREX Futures).
Remarkably, a second Paper account IBGW isnt' affected at the same time and continues to deliver tick-by-tick data.

Maybe someone has the same problems or kindly enlightens me that I overlook something.

Regards
Greg

Today (July 4th) my API log of the Live account says (requesting EUREX FDXM, GBL data):

00:55:17:693 -> ---15-1-Uxxxxxxx
00:55:17:700 -> ---9-1-1-
00:55:17:700 -> ---64-2--1-2104-Market data farm connection is OK:usfarm--
00:55:17:700 -> ---84-2--1-2105-HMDS data farm connection is broken:euhmds--
00:55:17:701 -> ---44-2--1-2106-HMDS data farm connection is OK:ushmds--
00:55:17:701 -> ---94-2--1-2158-Sec-def data farm connection is OK:secdefnj--

and the Paper account:

00:52:42:430 -> ---15-1-DUxxxxxxxx
00:52:42:445 -> ---9-1-1-
00:52:42:445 -> ---64-2--1-2104-Market data farm connection is OK:usfarm--
00:52:42:449 -> ---44-2--1-2106-HMDS data farm connection is OK:euhmds--
00:52:42:449 -> ---44-2--1-2106-HMDS data farm connection is OK:ushmds--
00:52:42:449 -> ---94-2--1-2158-Sec-def data farm connection is OK:secdefil--

Yesterday (July 3rd) tickdata ceases at 06:25:37 AM and the IBGW log says, that the connection to zdc1 disconnected.
Then, it never re-connects while ndc1 re-connects within a second and stays healthy:

2023-07-03 06:26:56.740 [YN] INFO? [JTS-AsyncNonLocked-31] - disconnectAndReconnect due to routing change for euhmds state:NATIVE default:ccp dataType:NONE points:[useccphost] nativeViaCcp:null
2023-07-03 06:26:56.740 [YN] INFO? [JTS-AsyncNonLocked-31] - Disconnecting zdc1.ibllc.com:4000 [disconnectDetails=DisconnectDetails[sessionID=8,endPoint=zdc1.ibllc.com:4000,reason=DISCONNECT_ON_BROKEN_SOCKET,cause=null,systemMessage=null,keepSocketOpen=false]]...
2023-07-03 06:26:56.741 [YN] INFO? [JTS-euhmdsListenerS8-148] - Socket or stream for connection zdc1.ibllc.com:4000 was closed by another thread.
2023-07-03 06:26:56.741 [YN] INFO? [JTS-AsyncNonLocked-31] - Socket closed.
2023-07-03 06:26:56.741 [YN] INFO? [JTS-AsyncNonLocked-31] - Interrupting dispatcher [sessionID=8]...
2023-07-03 06:26:56.741 [YN] INFO? [JTS-AsyncNonLocked-31] - Interrupting listener [sessionID=8,disconnectSocket=true]...
2023-07-03 06:26:56.741 [YN] INFO? [JTS-AsyncNonLocked-31] - AuthTimeoutMonitor-euhmds: deactivate
2023-07-03 06:26:56.742 [YN] INFO? [JTS-euhmdsListenerS8-148] - Listener thread terminating [sessionID=8] [seen=20591,totalShifted=20591,moreAvailable=0]
2023-07-03 06:26:56.743 [YN] INFO? [JTS-euhmdsServicePingS8-153] - Terminating ping thread
2023-07-03 06:26:56.743 [YN] INFO [JTS-euhmdsDispatcherS8-149S8-150] - Dispatcher thread terminating [sessionID=8,interrupted=true]...
2023-07-03 06:26:56.744 [YN] INFO? [JTS-ResubscribeMarketData-79] - Resubscribing market data. desubscribe=false
2023-07-03 06:26:56.747 [YN] INFO? [JTS-DisconnectedS8-275] - Farm euhmds/NATIVE: Lost active connection with disconnect status DISCONNECT_ON_BROKEN_SOCKET
2023-07-03 06:26:56.747 [YN] INFO? [JTS-DisconnectedS8-275] - Farm euhmds/NATIVE: Resetting
2023-07-03 06:26:56.747 [YN] INFO? [JTS-DisconnectedS8-275] - CONN CALC: Last connection attempt time is cleared!
2023-07-03 06:26:56.747 [YN] INFO? [JTS-DisconnectedS8-275] - CONN CALC: Last connection set as now:06:26:56:747
2023-07-03 06:26:56.747 [YN] INFO? [JTS-DisconnectedS8-275] - HTBP Disconnected from live peer!::0
2023-07-03 06:26:56.747 [YN] INFO? [JTS-DisconnectedS8-275] - CONN CALC: Last disconnect time set as now:06:26:56:747
2023-07-03 06:26:56.748 [YN] INFO? [JTS-AsyncNonLocked-31] - Keep-alive scheduled for:euhmds
2023-07-03 06:26:56.748 [YN] INFO? [JTS-AsyncNonLocked-31] - cdebug: ROUTING | connTracker:euhmds@ab43b00 | Disconnected | 1688358414043 | true
2023-07-03 06:26:56.748 [YN] INFO? [JTS-AsyncNonLocked-31] - cdebug: ROUTING | connTracker:euhmds@5110d232 | Disconnected | 1688358414043 | true
2023-07-03 06:26:56.918 [YN] INFO [JTS-ushmdsDispatcherS20-269S20-270] - Compatible routing data:

...

2023-07-03 06:28:07.052 [YN] INFO? [JTS-usfarmListenerS3-47] - Socket for connection ndc1.ibllc.com:4000 was closed by peer.
2023-07-03 06:28:07.052 [YN] INFO? [JTS-usfarmListenerS3-47] - Disconnecting ndc1.ibllc.com:4000 [disconnectDetails=DisconnectDetails[sessionID=3,endPoint=ndc1.ibllc.com:4000,reason=DISCONNECT_ON_BROKEN_SOCKET,cause=null,systemMessage=null,keepSocketOpen=false]]...
2023-07-03 06:28:07.053 [YN] INFO? [JTS-usfarmListenerS3-47] - Socket closed.
2023-07-03 06:28:07.053 [YN] INFO? [JTS-usfarmListenerS3-47] - Interrupting dispatcher [sessionID=3]...
2023-07-03 06:28:07.053 [YN] INFO? [JTS-usfarmListenerS3-47] - Interrupting listener [sessionID=3,disconnectSocket=true]...
2023-07-03 06:28:07.053 [YN] INFO? [JTS-usfarmListenerS3-47] - AuthTimeoutMonitor-usfarm: deactivate
2023-07-03 06:28:07.053 [YN] INFO [JTS-usfarmDispatcherS3-48S3-49] - Dispatcher thread terminating [sessionID=3,interrupted=true]...
2023-07-03 06:28:07.053 [YN] INFO? [JTS-usfarmServicePingS3-77] - Terminating ping thread
2023-07-03 06:28:07.056 [YN] INFO? [JTS-DisconnectedS3-277] - Farm usfarm/CCP: Lost active connection with disconnect status DISCONNECT_ON_BROKEN_SOCKET
2023-07-03 06:28:07.055 [YN] INFO? [JTS-usfarmListenerS3-47] - Listener thread terminating [sessionID=3] [seen=422875,totalShifted=422875,moreAvailable=0]
2023-07-03 06:28:07.057 [YN] INFO? [JTS-DisconnectedS3-277] - Farm usfarm/CCP: Resetting
2023-07-03 06:28:07.057 [YN] INFO? [JTS-DisconnectedS3-277] - CONN CALC: Last connection attempt time is cleared!
2023-07-03 06:28:07.057 [YN] INFO? [JTS-DisconnectedS3-277] - CONN CALC: Last connection set as now:06:28:07:057
2023-07-03 06:28:07.058 [YN] INFO? [JTS-DisconnectedS3-277] - HTBP Disconnected from live peer!::0
2023-07-03 06:28:07.058 [YN] INFO? [JTS-DisconnectedS3-277] - CONN CALC: Last disconnect time set as now:06:28:07:058
2023-07-03 06:28:07.061 [YN] INFO? [JTS-Fuse-usfarm-ccppause-278] - Farm usfarm/DISCONNECTED: Connecting via ccp conman (usfarm)...
2023-07-03 06:28:07.061 [YN] INFO? [JTS-Fuse-usfarm-ccppause-278] - AsyncDisconnectNotifiers: 1
2023-07-03 06:28:07.061 [YN] INFO? [JTS-Fuse-usfarm-ccppause-278] - Waiting asyncDisconnectNotifiers: JTS-DisconnectedS3-277
2023-07-03 06:28:07.063 [YN] INFO? [JTS-Fuse-usfarm-ccppause-278] - Connecting ndc1.ibllc.com:4000 timeout=0...
2023-07-03 06:28:07.063 [YN] INFO? [JTS-Fuse-usfarm-ccppause-278] - CONN CALC: Last connection set as now:06:28:07:063
2023-07-03 06:28:07.064 [YN] INFO? [JTS-AsyncNonLocked-31] - Keep-alive scheduled for:usfarm
2023-07-03 06:28:07.172 [YN] INFO? [JTS-Fuse-usfarm-ccppause-278] - Connected to ndc1.ibllc.com:4000 on local port 0 socket local addrs:port /192.168.178.50:50906