Hey woolloomooloo,?

?

Yahoo Finance shows the opening price was $90.25. Perhaps they had the same issue as you (seeing the two numbers of 9.21 and 9.28) and just took an average of the two lol.

?

?

Pulling up BIDU's opening price data on 2/5/25, I show the following price action (note that I'm on MST so the market opens at 7:30 for me):

?

?

The above data is sorted Z-A and the bottom-most 4 rows have a code of T indicating those trades were made during non-regular trading hours.?Hovering over and clicking on the code's link takes me to this site here:

?

I imagine the the API's opening price of $90.28 is based on the 4th row (whose value is $90.28 and is the final row having a code of T) or perhaps it's the 5th row's data (whose value is $90.29^8, whatever that means).

?

A few rows further up, we find your $90.21 for the ISLAND exchange with a code of Q, which I believe is the number that you saw a month ago.?

?

All that to say, the two numbers are valid for different reasons. Hopefully that helps clear up the mystery that you were staring down. I for one hate to endure mysteries when my money is involved.?

?

?

How about the Relative/Pegged to Primary order-type? I have used them in the past and they're pretty neat. IB continually adjusts your order's limit price as the market moves. You can also set an offset to be a penny or more competitive than the market to help it fill quicker. The order type allows one to set a limit as well.?

?

Well, you can make your 'emulated IB Algo' as complicated as you like. To start with a timer (like I described above) seems like the simplest and most logical choice.

To make you algo 'smarter' you can also look how the market ('last') price is moving. If the current price is moving towards your limit price, you can simply sit and wait and 'let the market come to you'. If market price is moving away from your current limit price, you have to decide how bad you want the order filled. If you want very much to have the order filled, you must 'chase the market' and move your limit price faster towards the market price ...
That's why the IB Algo has this 'aggressiveness' parameter.
You could for example create a parameter in your algo, that specifies the 'change rate' of your limit price. That would be 'how much cents per minute' you want your limit to change. A high change rate would compare with a high aggressiveness in the IB Algo ....
What I describe above is basically how I fill my orders manually. I start with a limit price that is very much in my favour (right at the bid or ask price), and start changing the limit price until filled. With a liquid security that is usually around the mid price. And with options it is usually also very close to the model price that my orders are filled.

?

?

?

Agreed, that would be an option. I would like to prevent to put in a timer though. Makes the code a bit unreliable. Or do you have something else in mind. Appreciate the response!

--

Secured with Tuta Mail:

Feb 11, 2025, 09:34 by lasgo2000-1@...:

You could just use a limit order and change the limit price every x seconds by a certain price increment that you choose.

So you would basically simulate the IB Algo order type. Only, you have more control over it.
With IB Algo, you can just set the 'aggressiveness' of the order, but not actual parameters (such as price increments).

?

?

This is a good idea. I have the code for the order. Hoped that there was a preset order type for it. Appreciate the response!

--

Secured with Tuta Mail:

Feb 10, 2025, 17:46 by climbermel@...:

That should be doable.? I don't have code for that, but if you already have the code to place the order, wrap that in a loop that until filled place order plus .01, wait whatever time you want between orders, cancel order and back to top of loop.

Now you will need to watch (and wait) for callbacks to assure that the order was placed and that the cancel order was placed.?

Another option might be to place modify orders in the loop.? I've never used them so not sure if there are issues with that, but others may chi.e i? with advice on that.

Cheers,

Mel

Hi, when i download historic data on say BIDU, primary exchange is NASDAQ (ISLAND on ib) i dont get the correct info relating to open price.

?

For example, on the 5th Feb just gone, the open price for BIDU was 90.21 according to TWS tick history which correlates to the info on the TWS quote summary, but when i download, with primary exchange set to ISLAND?

i get 90.28. Infact i cant get 90.21 with any variation i can think of sofar? Does anyone have any thoughts on why this is? Is it a shortcoming of the download functionality or could i be doing something else incorrect? Regards B.

?

Thanks, it brings up shared admin for me.? I have thought about it before and now feel I really need to get at least 1 other person set up as admin for this group and the duscord group.? I hate the idea of something happening to me and both groups get locked or worse deleted...

Anyone interested let me know...?

Mel

The interesting thing there is that within minutes of it not working on 10.30, I went back to 10.19 to see if it would work, and it did. Will keep that link handy though. Thanks.?

Oh no ! Never thought this was caused by IBKR. I will search for the relevant thread about this issue. Thanks for pointing me to the right direction.

However, I am afraid the issue actually occurs every day.

I looked into yesterday's situation (i.e. 20250121) where I traded as usual the 0DTE SPX options. Here are the details :

opt_contract = Option(‘SPX’, ’20250121’, 6015, ‘P’, ‘SMART’, currency=‘USD’, tradingClass=‘SPXW’)

Then, after ib.qualifyContracts(opt_contract), I got the contents of opt_contract as follows :

Option(conId=750913196, symbol='SPX', lastTradeDateOrContractMonth='20250122', strike=6015.0, right='P', multiplier='100', exchange='SMART', currency='USD', localSymbol='SPXW? 250121P06015000', tradingClass='SPXW')

So, I started wondering whether this is IBKR's screw-up or ib_insync's problem.

Discord looks ok. at least, no strange messages from your account so far.

Thanks leop for your reply. I did use "SPXW" (and always use it) in the tradingClass specification. The following was exactly how I define the option contract :

opt_contract = Option(symbol='SPX', lastTradeDateOrContractMonth='20250116', strike=6005.0, right='C', multiplier=100, exchange='SMART', currency='USD', tradingClass='SPXW')

?

And after ib.qualifyContracts(opt_contract), I print the contents of opt_contract and got the following :

Option(conId=750912933, symbol='SPX', lastTradeDateOrContractMonth='20250117', strike=6005.0, right='C', multiplier='100', exchange='SMART', currency='USD', localSymbol='SPXW ?250116C06005000', tradingClass='SPXW')

?

Then, I tried to find out why the lastTradeDateOrContractMonth between the above two (20250116 vs 20250117) and later I noticed that 202250116 was a trade day where both AM and PM settlement existed for SPX/SPXW. I therefore searched over the web and noticed in Reddit that some traders suggested never trade AM-settled SPX options as the settlement time is set at the morning of next day. As my algo trades 0DTE SPX and expects settlement price to be set at market close on the same day, so this is why I do not want to trade AM-settled SPX options.

I defined option contract as follows :

opt_contract = Option(‘SPX’, ’20250121’, 6015, ‘P’, ‘SMART’, currency=‘USD’, tradingClass=‘SPXW’)

?

Then, I wish to get the contract's current bid/ask prices, so I used reqTickers() as follows :

tick_details = ib.reqTickers(opt_contract)

?

For error tracing purpose, I used to print the tick_details contents. Here it is :

Ticker(contract=Option(conId=750913196, symbol='SPX', lastTradeDateOrContractMonth='20250122', strike=6015.0, right='P', multiplier='100', exchange='SMART', currency='USD', localSymbol='SPXW? 250121P06015000', tradingClass='SPXW'), time=datetime.datetime(2025, 1, 21, 14, 48, 54, 103595, tzinfo=datetime.timezone.utc), minTick=0.05, bid=6.4, bidSize=54.0, bidExchange='C', ask=6.5, askSize=2.0, askExchange='C', last=6.6, lastSize=4.0, volume=2238.0, high=14.05, low=6.45, close=27.7, halted=0.0, bidGreeks=OptionComputation(tickAttrib=0, impliedVol=0.21785950015907832, delta=-0.7116085792422059, optPrice=6.400000095367432, pvDividend=0.0, gamma=0.009767866599599677, vega=0.5477427109390766, theta=-0.0, undPrice=6035.17), askGreeks=OptionComputation(tickAttrib=0, impliedVol=0.22130962943480934, delta=-0.7085997644685299, optPrice=6.599999904632568, pvDividend=0.0, gamma=0.009662509828098607, vega=0.5504154854592325, theta=-0.0, undPrice=6035.17), lastGreeks=OptionComputation(tickAttrib=0, impliedVol=0.2021892365912554, delta=-0.7263385475706803, optPrice=6.599999904632568, pvDividend=0.0, gamma=0.010261604472690885, vega=0.5340398776862891, theta=-0.0, undPrice=6035.17), modelGreeks=OptionComputation(tickAttrib=0, impliedVol=0.21812797350188606, delta=-0.2774263862329315, optPrice=6.0125608711161505, pvDividend=0.0, gamma=0.009575647492098521, vega=0.5376558371343124, theta=-6.0125608711161505, undPrice=6035.34), bboExchange='c70003', snapshotPermissions=3)

?

As seen, the expiry date in my contract definition was 20250121, but the reqTickers() returned 20250122.

I then check IB's contract spec (by right-clicking the relevant contract on TWS and select "Details") and go the following :

?

As seen from the pic, everything is normal, i.e. conId was 750913196, strike was 6015, right was PUT, expiration and last trading date was both 20250121 and the tradingClass was correct (i.e. SPXW).

Anyone had experienced the same and how you solve this issue ? Is there a problem with ib.reqTickers() ? If so, any idea what should be used to replace ib.reqTickers()?

?

During the weekend, there is high chance of maintenance including scheduled downtime, so verify here before doing tests. That is probably what happened to you.