SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
Блог им. qadexys
Пользуется ли кто то API Финам?
- 29 октября 2024, 13:48
- |
Всем привет.
Потихоньку готовлю инфраструктуру для ухода от терминала Metatrader5 — есть некоторые неудобства при алготрейдинге с десятком торгуемых символов FORTS MOEX. В связи с этим хочу воспользовать API Финама для получения и сохранения котировок фьючерсов срочного рынка (для начала).
Ориентируясь на библиотеку и разбираясь с интернет запросами столкнулся, что следующий запрос:
{
"interval": {
"count": 500,
"from": {
"seconds": "1729382400"
}
},
//"security_board": "SPBFUT",
//"security_code": "RIZ4",
"security_board": "TQBR",
"security_code": "SBER",
"time_frame": "INTRADAYCANDLE_TIMEFRAME_M1"
}Является рабочим, данные поступают, OHLC каждой свечи с временной меткой — приходят.
Но при попытке получить то же для фьючерса RIZ4 — ошибка. И там и там данные хочу получить с 20.10.2024, но для акции SBER успешно, для фьючерса RIZ4 — не успешно.
Может кто то работал с этим, подскажите, что я делаю не так?
теги блога Quntag
- AFKS
- aflt
- ALRS
- API
- ED
- EU
- EURRUB
- EURUSD
- FIVE
- Gold
- imoex
- MAGN
- Meta Trader 5
- MGNT
- MOEX
- ng
- NGAs
- NLMK
- python
- ROSN
- RTS
- S&P500
- SBRF
- Si
- Silver
- SP
- spy
- VWAP
- yndx
- алготрейдинг
- Алроса
- АФК Система
- аэрофлот
- брент
- брокеры
- депо трейдера
- Доллар рубль
- евро
- евродоллар
- еврорубль
- ед
- золото
- интрадей
- интрадей торговля
- итоги
- итоги года
- Итоги недели
- конец месяца
- Магнит
- Магнитогорский МК
- мани менеджмент
- ММК
- МосБиржа
- натуральный газ
- НЛМК
- объём входа
- плечи
- Программирование
- риск менеджмент
- роботы
- Роснефть
- РТС
- сбербанк
- СБРФ
- серебро
- си
- слив
- сложный процент
- среднесрочная торговля
- статистика
- Тиньков Банк
- торговые роботы
- торговые сигналы
- торговый дневник
- трейдинг
- финам
- форекс
- фортc
- ФОРТС
- фьючерс
- фьючерс ртс
- ФЬЮЧЕРСЫ
- фьючерсы ММВБ
- яндекс
Дмитрий Овчинников,
Добрый день.
Смена символов каждый месяц-квартал. 4 терминала, ~10 символов в каждом, 40 раз «перетянуть» актуальный контракт на «окошко» с символом. Шов между терминалом, ведением статистики торговли, отправкой результатов в телеграм. Хочется чтобы всё было в одной среде и MQL, увы, это не позволяет.
Дмитрий, а у Вас удалось наладить тестирование стратегий на МТ5 от Финама? Интересуют ТФ минутные или тиковые. Раньше пользовался открытием но теперь, к сожалению, тестирую иначе.
P.S. Вспомнил что ещё. Не нравится держать открытым терминал, в котором открыты все символы. Хочется чтобы было что то полегче, визуальная часть мне перестаёт быть нужна. И тогда сразу требования к платформам (Windows) уходит, требования к ОЗУ снижаются. На арендованном сервере это имеет значение.
Тогда вам действительно Квик никак не подходит. Кроме Transaq коннектора или его эквивалента ничего и не придумаешь. Зато, хошь Питон, хошь JS, хош под Винду, хошь под Линукс. Новый Питон3.13 оч шустрый стал, но под него еще не все либы подогнали.
да, экспирация конечно это черные дни рабского однообразного труда, я всегда чертыхаюсь. Зато дает ощущение «работы».
Насчет шва не понял, в MQL есть все возможности по экспорту данных.
Тестирование наладил с небольшими нюансами. Точнее с большими нюансами, но, наверное, я к ним уже привык.
Про версию терминала для алго я давно ною, но кого это интересует в MQ? Им бы побольше рюшечек туда налепить, это стандартный путь любого ПО. Сервер у меня с большим запасом, так что это скорее просто нытье.
Единственная возможность MQL по экспорту — формирование csv со сделками. Этим только и пользуюсь. Но как только хочется что то большее то он мне не помогает.
У меня по одному символу торгуются и лонги и шорты. Покажи мне сделки за месяц на одном графике по двум направлениям? Не может.
Покажи мне эквити с фактором восстановления, за год торговли? Нет.
Отправь мне таблицу, где написано, сколько я заработал по дням, неделям, месяцам? Тоже нет.
Они сделали очень красивый отчётик, который можно сформировать в терминале, но не дают вообще никаких возможностей напрямую работать котировками и отображать чего я хочу, и в целом не дают отображать графики, не относящиеся к OHLC.
Не очень хочется называть это нытьём, в конце концов у вас оно своё, у меня своё. Но под свои задачи языка MQL мне маловато, а с необходимостью поиска костылей для теста захотелось работать с котировками самому. К тому же эффективность и скорость тестирования в МТ тоже вызывала вопросы — по крайней мере в моей стратегии за один прогон я могу сделать больше, чем МТ.
А в целом да, если вы программист, тогда надо делать свой велосипед. Можно применить бэкграунд ;)
Ну вот тем более, отчёт красивый, но бесполезен.
У меня тоже всё началось с написания скрипта:)
Вообще-то, даже собирался использовать, но все недостатки в совокупности меня остановили.
Пожалуй, основной, это наличие только у одного брокера — прикован к нему как цепями. Я это проходил с АПИ Альфы — кончилось АПИ, и все многолетние наработки коту под хвост. Многое так и не было восстановлено.
Я, конечно, не оч в курсе, но по Енжине сразу ограничивается функциональность подключения. Универсальность всегда дает ограничения.
А дает то, что вы написали. Не мучаться с переходом на другое АПИ, что возможно даже в рамках одного брокера.
Посмотрел ваш сайт и гитхаб, Питон для крипты, смотрю, поддерживается и обновляется. Смотрю и асинхронность, вроде, есть. Поддерживаемые версии Питон только не указаны. И не понял, там и REST API и вебсокеты? Че-то подробностей не нашел.
Я, вообще, софт от Unicorn использую.
osaengine.ru/ это мой сайт. Там каталог готовых платформ. Я никаких программ или платформ не предлагаю. Я занимаюсь описанием и отзывами к программам от других авторов.
Конечно хочется сделать, чтобы надолго и как можно более универсальнее.
Есть сторонние программы для торговли через Квик, все они работают через Луа. OS Engine, например (не единственная) — там все под С#, если не ошибаюсь. Мне она не нравится, но многие говорят, что самое оно.
Кто-то прямо на Луа ТС пишет, но язык больше для сценариев, для работы как самостоятельная программа как-то не оч.
А чего там еще есть под Квик? S#? — этот смотрел лет 10 назад, ниче не знаю.) Что еще? Разве только самому ДЛЛ писать.
Ну вы же прочитали пост, и увидели, что я пользуюсь библиотекой «FinamPy», ссылка на которую есть у вас на сайте. И да, эта библиотека для конкретного брокера. Совсем универсального пока не нашёл.
ДЛЛ есть и готовая, можно найти в инете, но она, в общем, для чего-то более менее простенького. Мне не подошла. Там еще начнутся проблемы с потоками, на чем Квик виснет целиком.
С потоками да, в LUA это проблемно, но это уже не простой скрипт будет, и ничего не мешает запускать для каждого алгоритма и для каждого инструмента свой отдельный скрипт. У меня постоянно висят 15 штук, не на самой мощной виртуалке и ничего не виснет.
Не понял, откуда в main() берутся данные подписок на котировки, установки и срабатывания заявок и пр. Они же не сами там появляются.)
Я-то их через ДЛЛ получал и там по потокам разводил.
Просто интересно, сейчас я на другой бирже, без Квик, через вебсокеты.
local tabCurCandles = getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1) — выборка свечей
Стакан читается
local ask_price,bid_price = 0,0
ql2 = getQuoteLevel2(class_code, sec_code) — стакан
if ql2.offer~=nil and ql2.bid~=nil then
ask_price=tonumber(ql2.offer[1].price)
bid_price=tonumber(ql2.bid[tonumber(ql2.bid_count)].price)
Позицию открывает
local result = sendTransaction(transaction) — запрос на сервер для открытия позиции
Все это встроенные в Lua функции.
Проверка срабатывания заявок идет через стандартное событие OnTransReply
function OnTransReply(trans_reply)
if trans_reply ~= nil and type(trans_reply) == «table» then
есть еще OnTrade(), но я им не пользуюсь.
Сомневаюсь что с графика т.к. квик делали адекватные коллеги которые понимают что ГУЙ нужен для отображения данных а не для того чтобы их оттуда брать(ГУЙ всегда работает в отдельном потоке поэтому данные будут разными постоянно в общем точно не с графика поверьте). Данные берутся всегда из бэкэнда и только у изобретателей велосипедов с ГУЯ. Изобретение таких «корявых» решений может приводить к тому что данные которые дожны тестироваться за 5-6 секунд тестируются 2 минуты 23 секунды как в этой теме — Торговая стратегия «все сделки в плюс» бесплатно --> «smart-lab.ru/blog/1075769.php». Если нужны детали почему 2 с лишним минуты для тестирования слишком «рукалицо» с удовольствием распишу подробней.(это я взял самый затратный вариант — тики, а если там 6 лет тестировалось на свечах то «рукалицо²»). На свечах даже если минутных 6-10-15 лет должны тестироваться 0 секунд.
Вспомнил отрывок из варкрафта:
— не понимаю как Вы люди выживаете, никаких мышц, хрупкие кости.
— ты не сильно от нас отличаешься.
— как же ты выжила?
— ломаные кости потом крепче.
— мои очень крепкие.
ГУЙ работает в отдельном потоке(это база для любого адекватного писателя кода, если будет работать не в отдельном то будет виснуть). Сколько там ещё потоков знают только разработчики, но никак не Вы. Поэтому:
Это разговор «с дивана или кухни». Порядочные коллеги используют отдельный поток для ГУЯ, ассинхронные всякие моменты в какой-то период чтобы не грузить бэкэнд и т.д. Если у Вас есть код где можно посмотреть сколько потоков запускается квиком то — «в студию».
Не знают или не отвечают на подобные вопросы? Как по мне то тёмная, светлая или любая другая тема это то что вообще никак не влияет. Потому что устанавливается один раз при старте квика(т.е. не на «горячем пути») и потом никак процессорное время не занимает. Вот покрасили Вы кнопку в чёрный один раз когда стартовал квик и пока не выключите его она так и будет чёрной. Что за проблема?
А потом появляются коментарии типа почему квик висит. Потому что:
)))
Очень сомнительно.
Опишите в общих чертах как Вы это тестировали чтобы так говорить.)))
Даже сама фраза звучит как мем.)
Совет: проведите такой тест — включите квик и Ваших ботов, дождитесь клиринга и убедитесь что после его начала Вам не приходят данные(которые только добрались до Вас т.к. бот был сильно занят расчётами и тасканием данных с графиков).
Это не проблема. Это то как должно быть. В клиринг данные не должны приходить т.к. клиринг идёт. Если бы они продолжали приходить то это бы означало что где-то происходит «неуспев» и нужно искать где и почему. Но если у Вас такого нет то значит всё ок.(у меня по молодости было 14:03 а данные всё идут это как бы намекало что когда торговал то не совсем в тех данных ставил ордера и неудивительно почему бот работает не так как хотелось бы, у меня была связка эксель + квик, поэтому ГУЙ и данные лучше разделять(т.е. брать из бэкэнда а на ГУЙ можно смотреть можно не смотреть это уже дело вкуса)).
Ну это уже больше девопсовские штуки и они сильно не критичны. Их можно делать 100500 разными способами например докерами и т.п. Это всё не относится к «горячему пути» а вот брать данные с ГУЯ, лучше так не делать. Но Вы скорее всего так и не делаете т.к. getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1) с ГУЯ данные(скорее всего) не берёт он их берёт из бэкэнда луа именно из этого же места они отдаются ГУЮ какой-то где-то метод(в коде квика(не луа)) их забирает и отдаёт на отрисовку.
Я так понимаю вы вообще великий теоретик, но с практикой беда. Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется. И перестанете писать о ваших домыслах, которые мало коррелируют с реальностью. Особенно было смешно читать ваши рассуждения про черную тему в Quik. Поверьте людям она намертво кладет Quik это проверенный факт.
Проблема с внимательностью у Вас(я не писал ПОСЛЕ клиринга я писал ПОСЛЕ ЕГО НАЧАЛА), внимательно читайте что я писал и вдумывайтесь в то что написано:
Если в бота приходят данные и он не успевает их обрабатывать то будет копиться очередь, у меня приходили данные 3 минуты после начала клиринга, поэтому никто их не считывает они не успевают вовремя обработаться поэтому копятся. Именно это я написал Вам проверить но с внимательностью у Вас проблемы, поэтому так подробно расписал.
Так может это из-за того что надо их брать не с графика а из бэкэнда? Не думали об этом?
Насчёт луа, да никогда не использовал. Спросил у чатгпт, он сказал что можно:
так же Вам писал коллега:
Именно так и должны использоваться данные а не те костыли которые(с большой долей вероятности) используете Вы. Возможно те проблемы о которых Вы пишете что типа разработчики не делают как надо и самому приходится… Возникают именно из-за того что Вы используете квик/луа через жо#у и Вам видимо все эти костыли по кайфу. Поэтому чтобы понимать как нужно работать с данными в квике не надо знать луа и т.п. надо просто понимать как с данными не принято работать и этого достаточно чтобы не городить говнокод и потом за#бывать разработчиков тупыми вопросами на форуме. Соревнуясь между собой у кого какая тема ляжет светлая или тёмная или любая какую не дай.
Ещё есть момент с путаницей в показаниях:
Почитал форум там пишут что и светлая кладёт квик. Поэтому там скорее всего писатели кода так его пишут что в «какой цвет не покрась они её всё равно положат».))) Поэтому ситуация не очевида. Откуда разработчики квика знают что именно кладёт квик? Может там такие «ядрёные велосипедные связки, многопоточность и т.п.» что хорошо что квик тормозит а не взрывается.
чатгпт говорит что так можно получать без ГУЯ(проверить не могу т.к. у меня линукс, квик 5000 лет не пользовал, луа никогда вообще и т.д.):
Возможно Ваша проблема возникает из-за Вашего говнокода:
Попробуйте вместо:
getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1)
использовать:
getCandlesByIndex(SEC, 0, 100)
Не удивлюсь если проблема возникает из-за того что Вы вместо обращения к бэкэнду обращаетесь к ГУЮ(указывая ID_Graph). ГУЙ обновляется асинхронно но асинхронность != консистентность(lanes/атомарные структуры данных/shared memory/volatile). В бэкэнде свечи должны быть на месте(с чем в ГУЕ могут возникать проблемы из-за потоков, частоты обновления ГУЯ, ядро легло спать не воткнув данные в ГУЙ а воткнёт когда встанет и т.п.). Поэтому когда Вы пишете на форуме и думаете что общаетесь с разработчиками, на самом деле Вы общаетесь с техподдержкой(в которой могут за небольшие деньги работать такие же кубигаторы как Вы) и уже от техподдержки летит весь шквал г@вна который говнокодеры сами и создают а потом пишут в квик что он тормозит и не все свечи выводит. Делайте с учётом таких моментов как «лучшие практики» и очень большой пласт потенциальных проблем просто не возникнет т.к. Вы с ним даже не будете соприкосаться. Пример одного из пунктов «лучших практик» не брать данные с ГУЯ, вместо ГУЯ брать с бэкэнда. Даже не понимая почему так а не иначе можно избежать множества потенциальных проблем. Для примера что за проблемы могут быть: бид аск очень часто у бота и в ГУЕ разный(чем активнее инструмент тем чаще это будет проявляться) это может проявляться даже если Вы данные берёте из бэкэнда но у Вас разные потоки(для этого придумано lanes/атомарные структуры данных/shared memory/volatile). Часто любители потоков удивляются почему у них стаканы кривые, одна из причин может быть то что я описал.
Долбаёб у меня нет квика поэтому я могу только предполагать из за чего у тебя фуфела не работает. Я предположил а ты пишешь сумашедший/дебил. Попробуй так candles = getCandles(«SEC», 0, 100) для свечей. Для стакана если тебе не нравятся ответы чатгпт то вот здесь есть ответ как без ГУЯ получить стакан. --> «quik2dde.ru/viewtopic.php?id=419»
цитата:
Поэтому вытащи говно из своей башки, прочитай почему не надо брать данные с ГУЯ(можешь в интернете полазить), но судя по всему у таких олигофренов как ты элементарные вещи даже в голове не помещаются из за того что там вместо мозга говно. Мне вот интересно почему всякие выблядки вроде тебя начинают писать дебил и т.п. я же тебе такого не писал первый, зачем грубить Вась?
вот ещё чатгпт накидал несколько причин для тебя дятла:
Как я и писал до этого возможно что твоя проблема
связана что используешь квик/луа через жопу. Но понять это такому упоротому как ты это наверное не дано.
П.С.
чтобы рассуждать на тему дебилизма тебе следовало бы для начала почистить ту дичь которую ты постишь и уже потом смотреть в это направление.
Долбаёб.)
Кто расскажет? Такие же кубигаторы как Вы?))) Мне их и здесь достаточно. И объяснять им очень сложная и затратная задача, которая держится только на «тщеславных моментах».
Еще по поводу адекватности разработчиков при реализации автоматического перезапуска скриптов после перезагрузки терминала можно рассказать. Чтобы этого добиться, нужно сделать несколько идиотских действий. Нужно открыть терминал, запустить все нужные скрипты и… нужно закрыть терминал, а потом опять открыть. Только в этом случае Quik запомнит какие скрипты у него должны быть активными. Иначе после аварийного перезапуска системы в Quik ни один нужный скрипт не запустится. И таких ситуаций еще вагон с тележкой. Адекватность это не про разработчиков Quik и не надо тут заливать. Латают дыры и подпирают костылями только при самые вопиющих проблемах.
Я их понимаю т.к. пишу всё сам. Но мне намного легче т.к. у меня «кастомный кейс» а у них все рынки, все инструменты, биржа сделала новую фишку все сразу пишут квик где нам новая фишка и т.д. Я как-то хотел по криптовалюте посмотреть но там есть некоторое кол-во отличий которое меня «не вдохновило». Например одна из причин — числа с плавающей точкой, я их никогда не использовал т.к. всегда только фьючерсы и всегда(почти) только си а там даже объёмы с плавающей точкой. У меня заточено всё под микро(использовать мало памяти, ссылки/указатели чтобы влазить в L1 и т.п.) т.е. пришлось бы кое-что переписывать и я не стал заморачиваться. А у них так нельзя всё расписано по дням и всё такое.
Так docker/docker-compose же есть. Пропишите и всё, там можете определить что после чего запускать, сколько ждать, сколько раз перезапускать, что проверять запущено или нет и всё такое.
lualanes.github.io/lanes/
И чем это отличается от просто написания ДЛЛ и далее на чем хош? Непонятно, на фига надстройки.
Я тоже сперва огреб немало гемора с многопоточкой, в том числе терминал наглухо зависал, но перенос всей обработки событий полностью в поток скрипта с помощью механизма обмена сообщениями из Lanes их полностью устранил.
В общем, если что, Lanes с квиком дружит, включая создание своих потоков.
Тем что сделано руками которые растут из нужного места. В отличии от «кастомных решений». И меньше вероятность получить «кривые стаканы».
Конкретно про ДЛЛ и тот код который выше:
представим что 1 ядро записало в кэш ...ask_price=tonumber(ql2.offer[1].price) и уснуло, другое проснулось и у него совсем другое в кэше(так как оно спало икс переключений в зависимости от кол-ва ядер и нагрузки на них). Потом появляются разговоры о «кривых стаканах», биржа сломалась, квик не так работает. Нужно читать док-цию как с чем работать и где что можно вызывать а где не очень.
А так, мой сайт со сборником всех популярных опен сорсов osaengine.ru/ Если уж и программировать, то через какую-то платформу.