Your best bet is to create a discussion on pysystemtrade, and hopefully there will be someone there who can help. Like I said, it works fine for me, so I can't really reproduce your problem. Rob
hey lore. There was a discussion that was ongoing for some days about running pysys in different time zones. What came out of it was the GMT_offset parameter. (I remember this feautre addition having a bug fix at one time, so make sure you are running the most recent of pysys.). I myself am only 1 hour infront of GMT - but I am running in docker containers with system clocks equal to london/Europe to avoid time zone issues. FYI there is a file specifying when the market should be trading. sysbrokers/IB/ib_trading_hours.py
A word of warning, this isn't really 'mini Lumber' as it's a different product, so unlike for the other 'minis' there is no arbitrage and the price is different. Perhaps 'LUMBER-new' is a better name. Rob
I had a look at LBR a week or so ago from the eyes of someone looking to include this as a diversifier in a smallish account. I still found the contract to be too large for my liking, my calcs show it to be about the same size as the small silver contract. So, waiting patiently for (i) more historical data, (ii) more daily volume and (iii) more capital before I start to trade this. KH
@globalarbtrader have you noticed any changes with IB API in the last 8 years that are backward incompatible and resulting in part of your code not working anymore? I mean, does IB always do backward compatible changes with their API or not?
From memory I had two ocassions of an obvious backward incompatibiity change when I was directly dealing with the API myself. Usually something like a function call requiring an additional compulsory - and also redundant - argument, which is really irritating. Why not just add a default to the signature guys? Since I've started using ib_insync, though things have become more opaque. Something will stop working, and I'll upgrade both ib_insync and the gateway, and things work again. But whether that's a backward incompatible thing, or just a forced upgrade cycle by IB ('upgrade to this version or we'll stop talking to you'), or something else, I don't know. Since Ewald is a nice guy, I don't think I have seen any instances of ib_insync making backward incompatible changes that have affected my code. Rob
According to my diagnostic reports the new lumber is doing less than 10 contracts a day, so that would have to change before I considered it. (Obviously minimum capital probably isn't an issue with DO, except at the limits) Rob
Just got this email from IB: --- Please note that Interactive Brokers is completing an effort to update and consolidate exchange names where appropriate. When this effort is complete, the following updates will be in effect: GLOBEX and CMECRYPTO will be consolidated to a single exchange, ‘CME’ ECBOT will be updated to ‘CBOT’ COMEX listed metals (previously reflected as NYMEX) will be updated to exchange ‘COMEX’ NYMEX, no change Given the wide breadth of products involved, we are migrating in four waves based on underlying products: Key Effective Trade Date Products Wave 1 October 30, 2022 GLOBEX:ZAR, LB, DA, IXE Wave 2 November 6, 2022 GLOBEX:EMD, BRE, CHF, SOFR3, E7, NKD CMECRYPTO:BTCEURRR, ETHEURRR, MET Wave 3 November 13, 2022 GLOBEX:All remaining products CMECRYPTO:All remaining products ECBOT:ZO, ZR, 2YY, 30Y NYMEX:ALI, QI, QC Wave 4 TBD ECBOT:All remaining products NYMEX:All remaining "Metal" products Note: After each migration, GTC orders will be retained. These orders will show the updated exchange name but remain active.
so from one perspective it's "NYMEX, no change" from the other all NYMEX "Metal" products should be updated to ‘COMEX’. I hope they will clarify which exact products they mean, currently I do have things like have Gold, Palladium, Platinum under 'NYMEX', I understand they will be moved to COMEX..
https://www.cmegroup.com/markets/products.html#exch=COMEX&sortDirection=desc&sortField=oi GC, MGC goes from NYMEX to COMEX.