@yeahaa828

It's probably not easy to block the bt internal loop and wait for an input. You will have to fetch the parameter from outside the strategy.

sockets are too low level. If you generate the parameters in another python script and want to serve it, zeromq is a better alternative.

If you update the parameters manually, just read from a file, or, maybe fancier, redis.

@ab_trader

Lucky for you, IB has a continuous futures, available in API as real time bars. https://interactivebrokers.github.io/tws-api/basic_contracts.html

It's back-adjusted, so keep that in mind when generating signals. https://www.interactivebrokers.com/en/software/tws/usersguidebook/technicalanalytics/continuous.htm

It should be quite simple to adjust ibdata to subscribe to it.

Experiment:

• as stated by @backtrader, next() is only called after the last contract starts.
• Each later data series has an abrupt start from 0 and an abrupt end from 0. like this:
• strategy.datas[0].datetime.datetime() stops updating after the first data feed stops.

I can imagine some additional problems in live trading:

• at backfilling start, some latest contracts may not have any data at all, for that particular time.
• May not be possible to add contracts in the far future, such that their symbols are not available at all.

@ab_trader Are you working on trading futures? I saw you in the other post.

@ab_trader @Paska-Houso

No, rolloverdata cannot be rewritten to access multiple contracts at the same time. The way it's implemented, the "new" contract simply skips expired data. The only option with backtrader is to add each contract as a separate data feed.

this post:

rolloverdata assume (naively) that the data feeds passed to them are already in order and nowhere else in the system. The latter being what would prevent buying from different targets.
An approach you may consider:

• add each contract as a separate data feed,
• manually manage index of the active contract,
• override _getminperstatus() to hack the minimum period requirement.

Apparently those who want to trade continuous futures will also have to add contracts separately.

It's shouldn't be too hard, I presume. Need to override _getminperstatus() to just respect the minimum period of the first data only.

@ab_trader @Paska-Houso

Thanks, first!

The futures term structure consists of the prices of multiple futures contracts at the same time, instead of designating any one of them like a continuous futures does.

However, now that you reminded me, I can probably rewrite the ReplayData class to carry out the calculation there. Thank you for the pointers!

I'll see how I can share the results when I'm done with it.

Maybe a fourth option:

• Add each and every individual futures data as a data feed.

In which case there will be a great lot of them, and I don't know how the backfilling will play out with their different timings?

@Paska-Houso Thank you for your suggestion. Normally, it would work like you said.

The difficulty is that the futures are not a single, perpetual data stream, but rather individual ones with different settlement dates (and different days starting with which the data is available). It's similar to this post. I can't add them to backtrader as-is.

But since I trade only futures ETNs, which are perpetual contracts, I can get away with it, as long as I somehow manage to feed the data in.

My strategy trades futures ETNs, instead of futures. However it makes use of the futures term structure to generate trading signals. The usage of the signal is rather simplistic, like greater or less than a threshold or so.

For backtesting I simply added the signal as an extra field to the data feed. For live trading, I use IB, and I have subscriptions for the futures data from it. But I'm not sure how to add it to the strategy.

Some options I can think of:

• Fetch the future data outside of backtrader and generate the trading signals there, and then maybe save them in a Redis store, and let backtrader access it;
• Override the IBData class to fetch futures data, do the calculation, and incorporate an extra field of data;
• Use another completely different trading platform.

Which way is the least overwhelming? What do you guys think? Any idea is appreciated.

There is a certain strategy that makes decisions with pre-opening prices at time prior to market opening, and place orders at open.

The backtesting can be done by using cheat-on-open. Now, suppose I have an external live source for such pre-opening prices. To live trade the strategy, the live broker should call next_open() some time before the opening of next bar, but without the opening price data updated (since they are unknown), unlike with bbroker. The difference should be quite clear.

The difficulty mostly lies in specifying a particular clock time, so that the live broker can call the method prior to market opening by that much of time. I've looked and can't see how this can be implemented easily.

Quick fix, though in no way tested:

• in stores/ibstore.py, lines 725, 751 and 836, add 'CMDTY', etc. if contract.m_secType in ['CASH', 'CFD', 'CMDTY']: ..
• when defining the data feed, use full kwargs, etc.

data = ibstore.getdata(
    dataname = 'XAUUSD',
    sectype = 'CMDTY',
    exchange = "SMART",
    currency = "USD",
)