Собственно следующая заморочка
Есть стратегия, которую разработал в TSlabe. Но т.к. в ней сделки совершаются не часто, то смогу и руками бить по рынку.
Вопрос: Можно ли каким-нибудь способом в реальном времени торговать по сигналам стратегии не покупая абонентскую плату TSlab ?
*или для этого можно использовать другие программы? (опять же в реальном времени — только не выводя сделки на биржу)
у брокера айти
1 тслаб 1500р в месяц
2 есть свои бесплатные роботы на изиленгвич
3 если таймфрейм большой имхо бот не работает… т.к. ньюансов много… нормально отрабатывается таймфреймы 1-5-15мин… все что выше имхо для ботов малопригодно
Если в тслаб собирал робота не кубиками, а кодом, то в айти смартком бесплатен, при условии, что наторгуешь комиссии на 600р в месяц. Если комиссия меньше — то возьмут разницу между 600р и комиссией. Очень простое апи.
ignat, мне кажется это из разряда вредных советов. Простое API только по документации. Если бы все работало четко, как в документации, то да, не сильно сложно. Говорю, как человек, который уже год ловит баги в Смарткоме. Каждую неделю что-нибудь интересное вылезает.
Eduard, так напишите в саппорт айти — поправят. На мой личный взгляд — они стараются очень быстро исправлять баги. Либо сюда напишите, мне любопытно, у меня смартком работает очень стабильно.
ignat, вы пробовали? У вас есть позитивный опыт?
Ни мои обращения в саппорт, ни обращения на форуме не приводит к исправлению недостатков данного API. Последнее обращение уже более 20 дней без ответа. Формально никто мне из них ничем не обязан.
По сути за год ни одной описанной мною проблемы, не были решены разработчиками. Исправления ошибок делали либо хуже и откатывались (история с OrderMoveFailed на форуме), либо не имело никакого эффекта. Решение всех проблем были только с моей стороны путем написания очередной обертки/проверяльщика.
Звучит это общение примерно так
Проблема: иногда UpdateOrder не приходит при перемещении ордера (вопреки документации). Аттачем все логи.
Ответ: используйте OrderMoveSucceeded.
Все, мы вам совет дали, а вы думайте дальше как хотите. Аргументы, что OrderMoveSucceeded не содержит ни цену заявки, ни нового OrderNo, потенциально ведет к проблеме с идентификацией обычной отмены не имеют значения. Конечно сделать так, чтобы заявленные события всегда приходили тоже не вариант, это же надо что-то делать с библиотекой.
С учетом того, что OrderMoveSucceeded тоже не всегда приходит, то это вообще становится вероятностной оценкой, узнаете ли вы что что-то изменилось или нет.
Вообще этот API пестрит тем, что в документации написано, что должно прийти из событий, а оно может прийти, может не прийти. По настроению.
Порядок прихода событий тоже, как повезет. Т.е. сначала может прийти событие перемещения ордера по акциям, за ним тут же его отмена. Как интерпретировать? Если заявка старая снимается из ТС, то по-логике должна сначала отмена прийти, а потом постановка в новое место. в 98% случаев так, в 2% случаев не так. Отличить отмену по перемещению от легальной отмены из-за этих 2% у вас возможности нет.
Если что-то пошло не так со стороны API (например Symbol Not Found), то сколько потом не запрашивай инструменты, поможет только перезапуск клиента.
Ошибку с пропуском запрашиваемой истории с нового года чинят. Даже новую версию выпустили и отрапортавали об этом. Но ошибка и в новой версии такая же. Запрашиваете историю инструмента дневными барами до сегодняшнего дня, а вам может прийти история только до конца 2014 года, без 2015. Изредка, в 1 случае из 30. В зависимости от фазы их ТС дырки в барах есть на всех таймфреймах. И начинаем писать проверки, если история пришла древняя, то перезапросим историю. Упс, перезапрос истории инструмента возвращает ее опять в том же объеме, сколько не запрашивайте. Только перезапуск клиента.
Ок, сервер упал/выключается/глючит (дисконект вам не придет от АПИ, пишите проверяльщик состояния сервера. У меня настроено на отсутствие любых изменений котировок или стакана в течение минуты по всем инструментам — зашибись способ, да?), переключились на резервный. Запросили историю инструмента. Упс… в истории дырки — сервера не синхронизированы. Упс… последнии лимитники застряли в ТС на основном сервере, а на резервном не отображаются, через АПИ не пришли. Потом через 3 часа после переключения на резерв выставились старые лимитники с основного сервера, где они стояли в Pending 3 часа и АПИ, подключенное к резерву, данных о них не получило, с какого перепугу?.. По вечерам разбираю лог и диву даюсь, чего там только могло произойти остается догадываться.
Да блин, там такой ворох проблем, что у меня на 200 строк алгоритма 6000 строк обработчиков разных ситуаций.
Где-то тут на СЛ был замечательный пост про сравнения АПИ, там красиво было про SmartCOM, как оно выглядит в теории и как реально сделать на практике.
Eduard, у меня UpdateOrder приходит всегда. Когда-то давно он терялся, но тогда же и починили. Да, иногда статусы ордера приходят вразнобой — сначала оупен, потом отмена — для мува, но каким-то образом я это решил в коде. Как — сейчас сам не помню и сразу не могу понять в коде, но данная проблема меня не беспокоит и решается несложно. Внутренние события смарткома не использую, обрабатываю только UpdateOrder.
Символы инструментов я проверяю при старте и иногда действительно они не приходят (редко), тогда робот останавливается и мне приходится его запустить еще раз.
Событие дисконнект приходит всегда, если сервер выключается.
Ордера иногда застревают в пендингах (очень редко) — вижу их в терминале и снимаю руками или звоню в саппорт, чтобы точно знать, что они сняты.
А с историей не работал, поэтому говорить не буду.
ignat, да вы фартовый :) А мне поддержка пишет, что UpdateOrder является необязательным к получению от API SmartCOM, что я вижу с завидной регулярностью. Вижу, что лог клиента пишет, мол перемещение завершено, но в логе событий чисто. Сообщения на эту тему висят в двух последних страницах форума поддержки.
Аналогично события UpdateOrder для отмены ордеров (в случае CancelOrder) не является обязательным (офф.ответ поддержки). Ума не приложу, как вы не обрабатываете эти события.
У меня был робот, который совершал по 300-400 сделок на инструменте, вот там вообще веселуха была, когда 2% событий не ловились смарткомом.
Про Pending это хорошо сказано, если есть возможность смотреть в терминал весь день. Тут наверное мне робот был бы уже не нужен. А вот если нужно робота без присмотра оставлять, тогда сложно становится.
Кстати останавливать робота не обязательно по символам. Ловим исключения по событиям:
ListenTicks(Symbol);
ListenQuotes(Symbol);
ListenBidAsks(Symbol);
и достаточно создать новый класс StServerClass(). Старый не нужен. Это перезапускает локальный сервер и можно заново подписываться на события и регистрировать обработчики. Как раз к этому моменту еще иструменты могут быть неинициализированы, поэтому и проблем в этой части мало. GetSymbols (офф.решение от поддержки) только замедлит запуск/перезапуск.
Eduard, я не знаю, фарт ли это )
В сессию бывает до 3000 заявок, большинство — мувы. Если бы терялись, я бы с этим точно столкнулся, но у меня нет потерь ни от потерянных апдейтордер, ни от неправильного порядка прихода статусов.
И заморачиваться с классами не хочется, у меня один класс в роботе, один поток и проще ткнуть кнопку старт еще раз, когда символ робот не получил.
Кстати, вот как раз создать новый объект StServerClass() смартком не даст — что-то там с доменами приложения. То есть невозможно обнулить объект и пересоздать, надо закрывать приложение и открывать опять. Во всяком случае, раньше было так, с тех пор не менял этот кусок кода.
Обновление кредитных рейтингов в ВДО и розничных облигациях (ООО "АЗЮ" подтвержден ВВ.ru, ПР-Лизинг подтвержден ru.BBB+, АО "ГЛАВСНАБ" понижен C.ru, АО "Нэппи Клаб" присвоен статус "под наблюдением)
🟢ООО «Агро Зерно Юг» НКР подтвердило кредитный рейтинг на уровне BB.ru ООО «Агро Зерно Юг» — один из крупных российских экспортёров растениеводческой продукции. Компания поставляет пшеничные...
Торговая активность наших клиентов на срочном рынке активно росла в 1-м квартале — на 66% с января по март.
Более того, март — рекордный месяц по объёму сделок с фьючерсами и опционами...
Баланс факторов позволит ЦБ и дальше двигаться по пути снижения «ключа»
Базовый сценарий аналитиков «Финама» предполагает, что Банк России на ближайшем заседании продолжит снижение ключевой ставки, понизив ее еще на 50 б.п., то есть. до 14,5%. Но с учетом...
ЮМГ МСФО 2025 г. - чистая денежная позиция превратилась в чистый долг
Компания Юнайтед медикал групп опубликовала финансовые результаты за 2025 год. Выручка компании за год выросла на 14,1% до 289,5 млн евро. В рублях рост составил +9,8% до 27,3 млрд руб. Во 2-м...
Crusader99, да, в приложении увидел и указана допка в размере 2,6, и того один только выпуск 5,2 тяжёлый, в случае шухера сползают быстро, а на рост медленно
Группа Эмитента на рынке Москвы и Московской области в сфере розничной торговли бензинами и дизельным топливом по доле АЗС составляет 3%, а по продажам – 4,7%
Вадим, там проблема у Сибавто что договор на 5,6 млрд до 2027 года полетел. Но думаю найдутся и другие заказчики в будущем все равно, тем более на снижении ключа. Написали же что только в марте кон...
В среду — пятницу, малыми лотами, продал остатки, купленные на проливе. Ну что, балабол — дрысня, что-то случилось с эмитентом, на отрезке 6 месяцев с начала размещения дебютного?
С понедельника, м...
1 тслаб 1500р в месяц
2 есть свои бесплатные роботы на изиленгвич
3 если таймфрейм большой имхо бот не работает… т.к. ньюансов много… нормально отрабатывается таймфреймы 1-5-15мин… все что выше имхо для ботов малопригодно
Ни мои обращения в саппорт, ни обращения на форуме не приводит к исправлению недостатков данного API. Последнее обращение уже более 20 дней без ответа. Формально никто мне из них ничем не обязан.
По сути за год ни одной описанной мною проблемы, не были решены разработчиками. Исправления ошибок делали либо хуже и откатывались (история с OrderMoveFailed на форуме), либо не имело никакого эффекта. Решение всех проблем были только с моей стороны путем написания очередной обертки/проверяльщика.
Звучит это общение примерно так
Проблема: иногда UpdateOrder не приходит при перемещении ордера (вопреки документации). Аттачем все логи.
Ответ: используйте OrderMoveSucceeded.
Все, мы вам совет дали, а вы думайте дальше как хотите. Аргументы, что OrderMoveSucceeded не содержит ни цену заявки, ни нового OrderNo, потенциально ведет к проблеме с идентификацией обычной отмены не имеют значения. Конечно сделать так, чтобы заявленные события всегда приходили тоже не вариант, это же надо что-то делать с библиотекой.
С учетом того, что OrderMoveSucceeded тоже не всегда приходит, то это вообще становится вероятностной оценкой, узнаете ли вы что что-то изменилось или нет.
Вообще этот API пестрит тем, что в документации написано, что должно прийти из событий, а оно может прийти, может не прийти. По настроению.
Порядок прихода событий тоже, как повезет. Т.е. сначала может прийти событие перемещения ордера по акциям, за ним тут же его отмена. Как интерпретировать? Если заявка старая снимается из ТС, то по-логике должна сначала отмена прийти, а потом постановка в новое место. в 98% случаев так, в 2% случаев не так. Отличить отмену по перемещению от легальной отмены из-за этих 2% у вас возможности нет.
Если что-то пошло не так со стороны API (например Symbol Not Found), то сколько потом не запрашивай инструменты, поможет только перезапуск клиента.
Ошибку с пропуском запрашиваемой истории с нового года чинят. Даже новую версию выпустили и отрапортавали об этом. Но ошибка и в новой версии такая же. Запрашиваете историю инструмента дневными барами до сегодняшнего дня, а вам может прийти история только до конца 2014 года, без 2015. Изредка, в 1 случае из 30. В зависимости от фазы их ТС дырки в барах есть на всех таймфреймах. И начинаем писать проверки, если история пришла древняя, то перезапросим историю. Упс, перезапрос истории инструмента возвращает ее опять в том же объеме, сколько не запрашивайте. Только перезапуск клиента.
Ок, сервер упал/выключается/глючит (дисконект вам не придет от АПИ, пишите проверяльщик состояния сервера. У меня настроено на отсутствие любых изменений котировок или стакана в течение минуты по всем инструментам — зашибись способ, да?), переключились на резервный. Запросили историю инструмента. Упс… в истории дырки — сервера не синхронизированы. Упс… последнии лимитники застряли в ТС на основном сервере, а на резервном не отображаются, через АПИ не пришли. Потом через 3 часа после переключения на резерв выставились старые лимитники с основного сервера, где они стояли в Pending 3 часа и АПИ, подключенное к резерву, данных о них не получило, с какого перепугу?.. По вечерам разбираю лог и диву даюсь, чего там только могло произойти остается догадываться.
Да блин, там такой ворох проблем, что у меня на 200 строк алгоритма 6000 строк обработчиков разных ситуаций.
Где-то тут на СЛ был замечательный пост про сравнения АПИ, там красиво было про SmartCOM, как оно выглядит в теории и как реально сделать на практике.
Символы инструментов я проверяю при старте и иногда действительно они не приходят (редко), тогда робот останавливается и мне приходится его запустить еще раз.
Событие дисконнект приходит всегда, если сервер выключается.
Ордера иногда застревают в пендингах (очень редко) — вижу их в терминале и снимаю руками или звоню в саппорт, чтобы точно знать, что они сняты.
А с историей не работал, поэтому говорить не буду.
Аналогично события UpdateOrder для отмены ордеров (в случае CancelOrder) не является обязательным (офф.ответ поддержки). Ума не приложу, как вы не обрабатываете эти события.
У меня был робот, который совершал по 300-400 сделок на инструменте, вот там вообще веселуха была, когда 2% событий не ловились смарткомом.
Про Pending это хорошо сказано, если есть возможность смотреть в терминал весь день. Тут наверное мне робот был бы уже не нужен. А вот если нужно робота без присмотра оставлять, тогда сложно становится.
Кстати останавливать робота не обязательно по символам. Ловим исключения по событиям:
ListenTicks(Symbol);
ListenQuotes(Symbol);
ListenBidAsks(Symbol);
и достаточно создать новый класс StServerClass(). Старый не нужен. Это перезапускает локальный сервер и можно заново подписываться на события и регистрировать обработчики. Как раз к этому моменту еще иструменты могут быть неинициализированы, поэтому и проблем в этой части мало. GetSymbols (офф.решение от поддержки) только замедлит запуск/перезапуск.
В сессию бывает до 3000 заявок, большинство — мувы. Если бы терялись, я бы с этим точно столкнулся, но у меня нет потерь ни от потерянных апдейтордер, ни от неправильного порядка прихода статусов.
И заморачиваться с классами не хочется, у меня один класс в роботе, один поток и проще ткнуть кнопку старт еще раз, когда символ робот не получил.
Кстати, вот как раз создать новый объект StServerClass() смартком не даст — что-то там с доменами приложения. То есть невозможно обнулить объект и пересоздать, надо закрывать приложение и открывать опять. Во всяком случае, раньше было так, с тех пор не менял этот кусок кода.
вот то сообщение. Со временем я понял, насколько оно правдиво :)
Постоянно приходится писать обертки.