开云体育

I am concerned about the many error messages code 2105 "HMDS data farm connection is broken:ushmds" I am receiving. I am receiving these day and night, and every day of the week. What surprises me is

Hello dear members. I am in need of coding services in order to finish a python project. This project is based on the current session self updating Fibonacci levels for intraday trading and takes

Building on Gordon's comments here some thoughts: * Gordon pointed you to the TWS API Message Codes ( https://interactivebrokers.github.io/tws-api/message_codes.html ) documentation and as you can see

Forgot to mention: When I receive a 2000 class error, I keep pushing requests. Otherwise said this is an informational message and while the code should be made aware that something happens, it should

IB designed the SDK ABI without special consideration to what we call "messages" (from them to us) , they are like "errors" (from them about us, understand bad behavior of our own code) Do not

Dear community, I use coa code "SUIE" to retrieve unusual expense(inc) for Allianz SE (Ticker: ALV, Exchange:IBIS, Currency: EUR) and from unknown reasons my TWS does only provide me with values for

Sorry, the previous patch got malformed during copy & paste... assuming the groups.io preview function works, the one below should be used with

Yes, that's right. I'm guessing you didn't change what you thought you changed. Here's a step by step if you want to try again: * install the system package via ```sudo apt install

Thank you all for your help and information. I tried the mods to compilation, packages, makefiles mentioned without any change in the outcome. In fact it looks like the library is not a shared object

wrote: BTW, I also just tried w/ 981 and the bracket went through. Which makes me think that you might try updating the API version you're using (not just TWS/IBGW). I'm sure you're aware that the API

Thanks, Jürgen. The API and gateway logs don't show any data or errors (although we had some gateway logs from the day it worked). We're raising a ticket with IBKR. My best hypothesis at the moment

my bet is that it's something internal to IB.? How about just setting up a reset loop with a count. So if you hit an error like this one log it, and retry the connection n times. If you blow the n

Hello everyone, Upon launching my trading app right before the market opened, the connection was established without any issues. However, after a few hours (during active market hours), while our app

I couldn't get your new version to work until I moved the ```reader_thread.start()``` call to after the ```self.connect("127.0.0.1", self.port, self.client_id)``` call; like Jürgen's version. But

Of course. Thanks Jürgen and buddy. I had been trying to establish the reader thread after connecting (not shown in the previous code I posted) rather than prior – an approach which worked in my

There we have it, Dave. Let me see whether I can put the pieces together for you: * The typical TWS API Python client is a two-thread solution. * EReader runs in its own thread, reads TWS/IBGW

Sorry, this should be between the client and _reader_. But, the set and wait are called from the same thread of Dave's example and so all that's accomplished is deadlock.

If you mean between the client and wrapper then I'd say yes.

Hard to say since I think it depends on the overall context and mostly on what the program is meant to accomplish. For example, is it meant to be long lived or just do some processing and exit? What

Would Event objects provided bz the asyncio package work better here (IBKR suggests asyncio and ib_insync is built upon it) ? The goal, as I understand it, is to fully comply with the IBKR TWS API (as