Diskuze

RRR je negativní - typické pro tento typ strategie. Konkrétně 1: 1:56 (riskuji 1.56 abych vydělal 1). Úspěšnost cca 70%. SL vidím také jako rozhodující faktor. Nevystupuji klasicky stop příkazem, ale sekvencí limitních příkazů (ukončující celý spread ideálně za mid). A plnění na této sekvenci bude klíčové. Proto jsem strategii zas tolik nepiloval a spíše ji rychle dostal do live trading protypu. Chci nasbírat cca 100 výstupů na stop-lossu a dál se odpíchnout od toho, jak konkrétně budou plněním vycházet.

Dobrý večer, asi je zbytečné to nějak komplikovat. Už jsem minulý týden přešel na stahování MR3000 signálů z nového dashboardu a zvykl jsem si. Díky za reakci. Aleš

Zajímavé ... co si pamatuji tak u spreadů se SL byl trochu problém se skluzem, ale to určitě testujete taky. Jak Vám vychází % úspěšnost a RRR u této strategie?  

Ano, přijde mi, že právě ten stop-loss je to, co dělá z výpisů reálně použitelnou strategii. Toto je porovnání mého backtestu se stop-lossem a bez: Samozřejmě u jinak nastavené testu to bude vycházet jinak. Nicméně v zásadě mi to i u option omega vycházelo stále dost podobně. U stop-lossů je pak otázka plnění. Já vypisuji call vertikály - tedy ztráta nastává v momentě, kdy trhy rostou. Tento pohyb nebývá tak dynamický jako poklesy, takže se jeví, že by to mohlo fungovat solidně. Ostatně to je hlavní důvod, proč tu strategii jedu živě - abych získával informace o tom, jak konkrétně probíhá plnění.

Zdravím, ten 2x SL prémia vám vychází nějak lépe v backtestech? Není to trochu zbytečný když máme SL již definovaný v tom samotném spreadu. A jaká je Win úspěšnost obchodů v backtestu? Díky za reakci. T.

Aleši, přemýšlím o tom. Asi by se to dalo aplikovat, ale na druhou stranu -  u signálů je vždy datum, pro  jaký den jsou publikovány. To mi přijde jako dostatečné. Plus systém posílá email v momentě, kdy se ty signály zprocesují.

Stahování a archivace Flex reportu z IBKR Pomocí LLM lze dnes postavit aplikace vyhodnocující naše obchodování z mnoha důležitých úhlů. Podstatná je ale existence dat, která mohou analyzovat. Některá data se přitom dají z Interactive Brokers stahovat pouze za 12 měsíců, proto je dobré si je průběžně archivovat. A to i pokud je nyní nepotřebujete. V dnešním tutoriálu si ukážeme, jak jednoduše na to. Zdrojový kód: techlab- flex downloader.zip

Aktualizovaná výkonnost strategií dashboardu k 29.8.2026: Prakticky konec srpna. Ten u mě na účtu končí na nule. Nejprve to vypadalo jako velmi dobrý měsíc, následně jsem měl ochlazení prakticky ve všech strategiích. Můj IBKR účet vypadá aktuálně: Pokud vyčlením jen strategie, které sdílím v Trading Room: Samostatná equity křivka intradenního breakoutu: Ten obchoduji jako 2/3 trailing stop-loss (používám ETF) a 1/3 účtu EOD exit (používám 0DTE opce). Pro zajímavost: Konečně jsem začal automatizovaně vypisovat opce. Používám SPX vertikální call spready. Zatím velmi opatrně a prakticky spíše testuji, jestli live trading bude sedět na opční backtesting. Což sedí. Co dělám - vypisuji call vertikály na SPXW s šíří 25 a spread nechám buď vyexpirovat, nebo uzavírám na stop-lossu (cca 2x premium). Opční data stahuji z databento.com, kde jsou od 2018. Workflow vývoje strategie a automatizace jsem měl zhruba toto: testy dělám klasicky v option omega. Testoval jsem výpis vertikálů se stop-lossem. Následně vyexportoval obchody pro Claude Code. Tomu jsem zadal úkol, ať postahuje data z databento a backtest zreplikuje. Pokud má LLM referenci, vůči které je možné výsledky kontrolovat, tak to funguje velmi dobře. Získal jsem backtest. Ten vypadá zhruba takto: Sharpe cca 1.5 (po poplatcích a s velmi realistickým plněním). Sizing je velmi startovní, proto je v grafu velmi nízké CAGR. Výpis vertikálů samozřejmě nepotřebuje tak velký účet. Margin = risk, což je rozdíl strike mínus vypsané prémium (tj. kolem 2 tisíc dolarů). Pak jsem LLM nechal postavit trading bot. A pár týdnů pouštěl na paper účtu. Každý den jsem LLM zpátky ládoval logy z botu a plnění pozic, postupně jsme odladili všechny chyby. A poslední cca týden jedu vše na živo. Zatím s dost malým riskem hlavně abych viděl reálnost plnění. Za sebou mám zatím 14 živých obchodů: A tedy co je hlavní - živé obchodování je plnění naprosto shodné s tím, co jsem si průběžně nechávám testovat coby kontinuální backtest. To je tedy dost povzbudivé. Současně je skvělé, že pro celé workflow jsem nenaprogramoval ani řádek. Vše pro mě vytvořila LLM. Je to další konkrétní příklad, jak pro systematické obchodování přestává být programování nezbytné. Samozřejmě ale, že vše není bez práce. LLM je potřeba manažersky vést a trpělivě ladit všechny detaily. Plus pochopitelně 14 obchodů je zatím málo na jakékoliv závěry, obchodované objemy chci zvyšovat po přibližně 100 obchodech. Plus je ještě otázkou, jestli ve finále budu ve velkém obchodovat tuto konkrétní strategii. V principu je extrémně jednoduchá a na živo jsem ji pustil hlavně proto, abych ověřil exekuce.

Dobrý den, requirements.txt nebyl součástí materiálů ke stažení. Ukazovali jsme si, k čemu slouží, a každý si následně mohl vytvořit vlastní podle svého prostředí a potřeb. Pokud jste ho omylem smazal, můžete soubor buď vytvořit ručně a uvést v něm názvy potřebných knihoven, nebo ho automaticky vygenerovat z aktuálního Python prostředí pomocí příkazu pip freeze > requirements.txt. Případně ho můžete obnovit z Gitu, pokud máte projekt verzovaný. Nicméně pro ukázku připojím jednu z variant souboru, kterou používám v prostředí pro přípravu tutoriálů.  requirements.txt B.

obchoduji i GBTC (BTC), vím že když se to tenkrát řešilo tak se týkalo i GLD ale ten neobchoduji. prostě si script načte nejbližší opci a tu obchoduje. Obchoduji to stejne jako 0DTE aniž bych musel používat další metodu. má sice nižší likviditu, což zhoršuje výsledky. ale výsledky za lonský rok nebyli špatné.  Ruda.

Aha, no je pravda, že ten bot stavím tak, jak jej sám používám a obchoduji pouze 0DTE. Ale výběr vzdálenější expirace by to moc zkomplikovat nemusel. Co a jak konkrétně používáte ve sterém skriptu?

Hezký den,. už jsem na to přišel narozdíl od předchozí verze umí pouze 0DTE OPCE, není schopen najit nejbližžš expiraci. bude tato funkcionalita doplněna, nebo je to příliš komplikované? Děkuji Ruda

Dobrý večer. Podařilo se mi vymazat soubor requirement.txt, mohu ho někde na stránkách najít? Děkuji

Historie se stahuje pouze k obchodovanému kontraktu. Stahuje se počet dnů odpovídající 2xpoužívanému ATR. Pokud máte ATR(5) stahuje se 10 dnů - je to kvůli rezervě pro různé svátky atd. MES má během obchodní seance 1365 minut = tj. celkem za 10 dnů 13350 úseček MBT se obchoduje i v neděli, má proto úseček více. Toto je stejné, jako to bylo v bracket helperu. Petr

Zkouším ještě teda na paper účtu skript s debug:true .... max contracts skutečně ovlivňuje kolik kontraktů je max. zadáno, takže to musím určitě zvednout.  V debug:true se zadali obchody, je tam tedy mraky hlášek na data. Mně přijde, že jich skript začal stahovat hrozně mnoho. Není možné, že to ovlivňuje ta nová funkce s volume? Přijde mi jakoby skript stahoval data pro všechny kontraktní měsíce aby je porovnával, které má vyšší volume, což je asi účel, ale možná to nám způsobuje ty problémy.

Zdravím, dnes zkouším novou verzi. Vypadá, že funguje lépe. Ještě mě napadlo, že jsem zvedal hodnotu u max_contracts třeba u MBT na 200. Říkám si jestli to nemělo vliv na množství stahovaných dat ...  Jinak koukám u MES se stahuje 13 352 baru a u MBT 19 272, proč je to proboha tolik ? T.

Pošlete mi prosím log na petr@financnik.cz.

Zdravím, včera jsem měl signály na 2x QQQ a 1x SPY, něco před pátou našeho času se zobchodovali. Ve 21:58 se uzavřeli, na Telegramu vše ok. Teď koukám, že se o pár vteřin později, 21:58:14, otevřely dvě QQQ do shortu a po čtvrté ráno se přiřadily. Naštěstí to ještě testuji na paper.   M.

Dobrý den,  ano, tento kód je aktivní. B.

Díky za tip. Pro někoho, kdo sleduje opce a nechce hned platit za data, to může být docela užitečné. Jen bych před použitím ověřil, co přesně znamená „zdarma“ a jestli se to týká i realtime dat, nebo jen zpožděných kotací.