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
- Ib-Async
- Messages
Search
|
Error 162, Historical Market Data Service error message:API scanner subscription cancelled:
Hello,
?
i am using a basic scanner, that is repeated in a loop:
? ? ? ? ? ? ? ? if ENABLE_BUYING and ((is_premarket() and PREMARKET_ONLY) or not PREMARKET_ONLY):
? ? ? ? ? ? ? ? ? ? scan_sub = ScannerSubscription( ? ? ? ? ? ? ? ? ? ? ? ? instrument='STK', ? ? ? ? ? ? ? ? ? ? ? ? locationCode='STK.US.MAJOR', ? ? ? ? ? ? ? ? ? ? ? ? scanCode='TOP_PERC_GAIN' ? ? ? ? ? ? ? ? ? ? ) ? ? ? ? ? ? ? ? ? ? scan_results = ib.reqScannerData(scan_sub)
? ? ? ? ? ? ? ? ? ? scan_results = scan_results[:10] ?# Limit to top 10 results Everything works fine, but my terminal gets flooded with this error:
Error 162, reqId 33346: Historical Market Data Service error message:API scanner subscription cancelled: 33346 ?
They only mention of this error in the docs is that you can ignore it. I found other posts in the TWSAPI group, but they also dont know how to fix it.?
?
Any suggestions? |
|
Re: asyncio example
¿ªÔÆÌåÓýOff topic... I'm sitting here listening to Neil Young and your email pops up... slightly different spelling but still manage to startle me for a sec... -------- Original message -------- From: "Neal Young via groups.io" <youngneal@...> Date: 2024-08-31 3:51 p.m. (GMT-08:00) Subject: Re: [ib-async] asyncio example I would summarize it by saying the execution model is substantially different, and the python async mechanism is a work in progress, so best practices are still being developed, and not very cleanly documented. ?One easy example is that the semantics of exception handling is completely changed, and not easy to work with. ?Here are some details.
?
Asynchronous subroutines execute, roughly speaking, in two stages (similarly to subroutines with yield). ?The first stage (if you just call the subroutine, but don't yet await the returned object, creates (semantically) a closure that holds the state of the called routine ready to execute, but not yet executing. ? By various mechanisms (e.g. by "awaiting" this closure, or by inserting it directly via a call to asyncio.create_task or ensure_future, this closure is later executed by the asyncio event loop. ?(This _can_ happen well after the first call that created the closure has returned, and even after that calling routine has completed.) Now, what happens if the closure, when executed, generates an exception?
?
Note that the closure is executing (within the stack) below the asyncio event loop. ?The asyncio loop will catch the exception, but what should it do with it? ?One natural possibility is to re-raise the exception within some subroutine that is "awaiting" the asynchronous closure. ?And that happens sometimes. ?But there might not be such a subroutine... or there could be more than one. ?So in general it is not so clear what should happen. ?Indeed, in some circumstances exceptions can be silently discarded.
?
I had to think this through carefully during development, for debugging, when of course unforeseen bugs would cause unforeseen exceptions, with varying degrees of visibility. ?It took me a while to come up with some mechanisms that more or less worked for me, so that I could debug more or less normally.
?
Note that the eventkit Events used by ib_insync / ib_async play relatively nicely with asyncio, and _seem to_ provide a relatively clean (and different) semantics for working around some of these issues. ?More realistically, they make it easier to sweep some of the issues under the rug. ?Underneath the hood (to mix metaphors) the async semantics are still in play, and the semantics of e.g. exceptions are not somehow made "clean" just by using Events. ?So, while Events are accessible and relatively clean on the surface, and may let you "get started" relatively easily, they are not a full workaround. ?
?
I went through several stages of learning, trying to leverage existing mechanisms (e.g. taskgroups), before eventually understanding what clean mechanism I wanted and how to implement it. ?In my case, I wanted any raised exception (other than those cleanly anticipated in the code) to immediately cause all async tasks to cleanly shutdown, and then to give a clean stack trace showing the source of the exception. ?This was not too hard to do once I understood asyncio and what I was trying to accomplish. ?But it took me a while to get there. ??
?
And none of what I have discussed here begins to touch on how specifically how I ended up organizing my asyncio tasks to coordinate with each other when executing as intended.
?
To get some idea of these issues, I suggest you try an exercise: implement a class or subroutine that, given a coroutine as an argument will spawn an async task that, every second, calls the given coroutine. ?(Running forever.) ?This subroutine or task should return immediately after spawning the async task.
?
Once you've done that to your satisfaction, figure out how to augment so that if any exception is raised within such a spawned task, every spawned task will ?be stopped, but not until after some cleanup mechanism for the task is executed.
?
-Neal
?
|
|
Re: asyncio example
I would summarize it by saying the execution model is substantially different, and the python async mechanism is a work in progress, so best practices are still being developed, and not very cleanly documented. ?One easy example is that the semantics of exception handling is completely changed, and not easy to work with. ?Here are some details.
?
Asynchronous subroutines execute, roughly speaking, in two stages (similarly to subroutines with yield). ?The first stage (if you just call the subroutine, but don't yet await the returned object, creates (semantically) a closure that holds the state of the called routine ready to execute, but not yet executing. ? By various mechanisms (e.g. by "awaiting" this closure, or by inserting it directly via a call to asyncio.create_task or ensure_future, this closure is later executed by the asyncio event loop. ?(This _can_ happen well after the first call that created the closure has returned, and even after that calling routine has completed.) Now, what happens if the closure, when executed, generates an exception?
?
Note that the closure is executing (within the stack) below the asyncio event loop. ?The asyncio loop will catch the exception, but what should it do with it? ?One natural possibility is to re-raise the exception within some subroutine that is "awaiting" the asynchronous closure. ?And that happens sometimes. ?But there might not be such a subroutine... or there could be more than one. ?So in general it is not so clear what should happen. ?Indeed, in some circumstances exceptions can be silently discarded.
?
I had to think this through carefully during development, for debugging, when of course unforeseen bugs would cause unforeseen exceptions, with varying degrees of visibility. ?It took me a while to come up with some mechanisms that more or less worked for me, so that I could debug more or less normally.
?
Note that the eventkit Events used by ib_insync / ib_async play relatively nicely with asyncio, and _seem to_ provide a relatively clean (and different) semantics for working around some of these issues. ?More realistically, they make it easier to sweep some of the issues under the rug. ?Underneath the hood (to mix metaphors) the async semantics are still in play, and the semantics of e.g. exceptions are not somehow made "clean" just by using Events. ?So, while Events are accessible and relatively clean on the surface, and may let you "get started" relatively easily, they are not a full workaround. ?
?
I went through several stages of learning, trying to leverage existing mechanisms (e.g. taskgroups), before eventually understanding what clean mechanism I wanted and how to implement it. ?In my case, I wanted any raised exception (other than those cleanly anticipated in the code) to immediately cause all async tasks to cleanly shutdown, and then to give a clean stack trace showing the source of the exception. ?This was not too hard to do once I understood asyncio and what I was trying to accomplish. ?But it took me a while to get there. ??
?
And none of what I have discussed here begins to touch on how specifically how I ended up organizing my asyncio tasks to coordinate with each other when executing as intended.
?
To get some idea of these issues, I suggest you try an exercise: implement a class or subroutine that, given a coroutine as an argument will spawn an async task that, every second, calls the given coroutine. ?(Running forever.) ?This subroutine or task should return immediately after spawning the async task.
?
Once you've done that to your satisfaction, figure out how to augment so that if any exception is raised within such a spawned task, every spawned task will ?be stopped, but not until after some cleanup mechanism for the task is executed.
?
-Neal
?
|
|
Re: asyncio example
?
To help set your expectations: I learned to use asyncio (with ib_async / ib_insync) over the last year. ? I'm a fairly experienced Python programmer. ? It took me about four months, and many iterations of the code, to understand asyncio and work through the various potential complications and pitfalls. ?The execution model is significantly different, and there are lots of implementation details to figure out. ?It's doable, and worthwhile, but is a significant effort. |
|
asyncio example
Hi,
?
Ewald at some point had an example of using asyncio in one of his notebook examples. But I cant find it in the new ib_async or the previous ib_insync. Was it removed at some point.....if so, question (1),? does anyone know where i could find this example?
?
I have been using ib_insync for several years in a way that runs through a series of executions then ends. I now want to take this to another level where the program runs and monitors for a given opportunity continuously through the day session.......so I am assuming i may need to learn how to implement with asyncio, given comments on this S.O question
?
?
question (2) can anyone point me to any specific examples that help me understand how to implement an algo as a continuously running/monitoring process? This part is hard for me as I am a self-taught programmer, and according to the S.O link there seem to be some pitfalls in doing this.
?
Finally, thank you so much to the extremely generous people who have taken up Ewalds legacy in continuing this library.
?
Regards
B.
? |
|
Re: Starting and stopping market data using ticker object
Dan, I use this. I don't know 100% if it works as I didn't bother to test since it was not mission critical for my use case: def req_market_data_initial_contracts(previous_options_contracts=None): And then when I need to cancel any of these: ? ? ? for contract_item in previous_options_contrs: On Wed, Aug 21, 2024 at 12:30?PM Daniel Stewart via <danieljstewart=[email protected]> wrote:
|
|
Starting and stopping market data using ticker object
Hi all,
First thanks for resurrecting the forum following Ewald's sad passing. He was very kind and helpful to me when i was getting my head around Insync.
?
My problem now though is that I need to both start streaming a ticker, and also to stop it later.
?
I can start it no problem:
?
? ? stock_symbols = ['SPY', 'AAPL'],
? ? stocks = [Stock(symbol, 'SMART', 'USD') for symbol in stock_symbols]
? ? for stock in stocks:
? ? ? ? ib.qualifyContracts(*stocks)
? ? ? ? ticker = ib.reqMktData(stock, '', False, False)
?
..but have been unable to selectively cancel a ticker, ie cancel AAPL and keep SPY streaming. This seems to be because there is no reqID fround to identify the tickers.
?
Any help would be much appreciated.
Thanks
Dan |
|
Re: Email digests
I am in too! The old group had many important discussions. Not the expert in python but yeah pretty decent.? On Sat, 10 Aug, 2024, 17:35 MB via , <mbaker=[email protected]> wrote:
|
|
Re: Email digests
Yes, FP was helping me with them, but first I was away for a while and now that I'm working on them again, I am having issues with some code he gave me. It seemed like a simple process when I started, but to strip out email addresses, but to keep in a names so you can follow a thread was tough. Also to keep attachments such as images and files was another fun task. I am working on it again now, but any help would be fine since my python is obviously not as exceptional as I would like to think! Mel |
|
Mid price for options spread
Hi Guys, does anybody have experience with midpoint()). I am showing the code below. I suspect this may not be 100% reliable. I am thinking of calculating the mid price as bid + ask/ 2, what is your opinion?
Thank you,
?
# Step 1: Define the long/short calls
symbol = 'TSLA' long_strike = 220 short_strike = 225 expiry = '20241220' assert long_strike < short_strike, "Not a bull call debit spread" long_call = Option(symbol=symbol, lastTradeDateOrContractMonth=expiry, strike=long_strike, ? ? ? ? ? ? ? ? ? ?right='C', exchange='SMART', currency='USD') short_call = Option(symbol=symbol, lastTradeDateOrContractMonth=expiry, strike=short_strike, ? ? ? ? ? ? ? ? ? ? right='C', exchange='SMART', currency='USD') # Qualify the contracts
ib.qualifyContracts(long_call, short_call) ?
?
# Print long and short calls to check if they are correctly defined
print(long_call) print(short_call) ?
combo_legs = [
? ? ComboLeg(conId=long_call.conId, ratio=1, action='BUY', exchange='SMART'), ? ? ComboLeg(conId=short_call.conId, ratio=1, action='SELL', exchange='SMART') ] ?
bull_call_debit_spread = Bag(symbol=symbol, comboLegs=combo_legs, exchange='SMART')?
?
# Print the bull call debit spread to verify
print(bull_call_debit_spread) ?
ticker = ib.reqMktData(bull_call_debit_spread, "", False, False)?
ib.sleep(2) ?
# Print ticker information to diagnose any issues
print(ticker) print('Bid:', ticker.bid) print('Ask:', ticker.ask) print('Midpoint:', ticker.midpoint()) ?
ticker.midpoint()
?
? |
wordd
buddy
to navigate to use esc to dismiss