The problem here is that the broker, being unaware of the order being issued during next_open, tries to see if you are submitting an order which exceeds your current cash reserves (and the current price is already the close) You can disable the submission check with checksubmit=False. See Docs - Broker And this other topic for example: https://community.backtrader.com/topic/782/help-with-simple-bband-strategy

See also this recent contribution: https://community.backtrader.com/topic/1512/kalman-pair-trade-with-ewa-ewc-from-ernie-chan-s-algorithmic-trading

Thanks a lot. Simply doing this cerebro = bt.Cerebro(stdstats=False,optreturn=True,optdatas=True) solved all of my problems. Backtrader is a powerful tool. I was able to complete 800 rounds in 2.5 hours.

@backtraderuser said in Bug (with code and screenshot): only 1 trade executes modifying example on homepage: Food for thought: If merely including the default implementation of AllInSizer in my code introduces a bug, why offer AllInSizer at all? You have written something with a logic and your expectation is that it will do "x", but it is doing "y". It is obviously a bug. You are using the wrong pieces of the puzzle. If I allocate memory with malloc and expect it to be initialized with zeroes ... my code is buggy, because I should be using calloc. And my code won't do what I am expecting it to do. @backtraderuser said in Bug (with code and screenshot): only 1 trade executes modifying example on homepage: code implementation that fails to execute the intuitive meaning represented to the user You are expecting one thing from the framework without understanding what the framework does. If you put an AllInSizer and execute it together with a Market order on the closing price of an OHLC bar, your order may never be executed. Simply because the execution price is the next incoming tick which is the next O, which may gap away from the calculated size, leaving you with not enough cash reserves for the order to be executed. Your broker would reject such an order and so does the framework. Do the same with a Limit order and the execution (if possible because the price is visited) will happen with the calculated size. The link for order management and execution (form above): Docs - Order Management and Execution And because the framework does what it is designed to do (avoid cheating) and is not meeting your (wrong) expectations you immediately call for a bug. You may of course be interested in modeling an AllIn strategy and using the close price for it (it seems to be the trend, probably due to cryptocurrency) and that's why you may use cheat-on-open and cheat-on-close. The default behavior is to be as realistic as possible, given the inherent constraints of backtesting with OHLC prices. And cheat-on-open and cheat-on-close reduce the expected realism of order execution.

Ok, no problem, I understand. Knowing your reason is already valuable to me, so thanks for that reply.

Because there is no such thing as the closing price an hour ago. Furthermore, you don't say if you are working with minutes, seconds, hours, days, quarters. Even if it seem a simple formulation for you as a human being, if you are working with seconds, there may be missing bars and when 1 hour ago happened cannot be determined with certainty. The same when crossing boundaries (you look backwards into the previous day for the previous hour) If you are really focused on time you will have to: Check the current time and write it down into a list. When you want to check that time, you look for it in the list. For working with indexing (not being focused on time but on bars), please see: Documentation - Platform Concepts and the section Indexing

@ab_trader said in Need help to get started with pre-made signal: Your prices are around 6000-10000, your cash is 10000. How can you expect to buy 100 of shares in this case? Only 1 fits. Top. I had this in mind and was completely taken off course by the chart. Because the markers and the data are located very close to each other and where the first operations would have taken place, which also raised the question: how were the buy and sell issued on the same day? (the code didn't allow that)

I fear you haven't read neither the documentation linked above about params nor the sample which shows how optimization works and which actually shows the params syntax just like any other. Docs - Quickstart What you actually mean with the same name is unclear. Thousands of functions have arguments which share the name and that doesn't make them incompatible. You use fast_period and slow_period as params and then assign them to whatever indicator you have.

No, there is only one broker.

thanks, now it makes more sense.

In any case, the alternative is that your data contains huge differences from the open to the close (which could also be the explanation for the colour of the volume bars)

The implemented feed does only download days or larger timeframes.

I think you are pretty new to trading and should take some time to understand things and grasp the concepts. Specifying exectype=bt.Order.Close has only done something which doesn't have the effect you are looking for. That order execution type is intended for intraday data, for orders which are issued before the trading day is over and which will be executed with the closing tick (in the most well known exchanges it does execute at the end of the auction which follows the end of regular trading) What you need: Provide an open price (it can be the same as the close if you don't have any other) to get something realistic or Activatecheat-on-close and work with the current close (it is calledcheat for a reason)

Store not only int values in Line object "lines" do actually storefloat values and won't store anything else. @alexrozhnov said in Store not only int values in Line object: At first I tried to dynamically create lines in Indicator,but found that it is impossible (https://community.backtrader.com/topic/294/add-lines-to-indicator) You have probably misunderstood the discussion. See here: https://community.backtrader.com/topic/837/programmatically-extending-a-datafeed/3 @alexrozhnov said in Store not only int values in Line object: Now I do not know how to solve this problem, give me any hint please You don't provide much information to work with. But in any case it doesn't seem an Indicator may help you since from the brief description it doesn't seem like the Indicator will align to the timestamps of the data feed. But this is only an assumption.

No. And this is because such a method could fetch orders which haven't been created by the client itself. When you create them you can keep a reference to the created orders.

@backtrader Thank you for that! Feeling stupid for not realising there was a _debug parameter. It appears that it was an issue with the order size being below the 20000 IdealPro minimum, resulting in a 399 error code. After amending the order size to meet the minimum criteria, the code which was previously added can be removed: if order.status == order.Completed: return

No. Different lengths are perfectly supported. You can simultaneously trade the SPX and the DAX, which have different trading calendars and different lengths. Your concrete problem is the warm-up or minimum period which is needed to ensure all buffers can produce something at [0]. If you have things starting at different dates, the buffers cannot be guaranteed to deliver until the latest date has been reached.

The answer is still being pondered upon.