Python считает, а торговать пусть MQL? Или можно исполнять прямо из Python

Полтора года всё делаю в Python: беру бары из терминала через пакет MetaTrader5, считаю сигнал в pandas на M5, заявки отправляю тем же пакетом. Счёт реальный, небольшой, три пары. Работает, но всё чаще думаю, что исполнение надо переносить в MQL5, и хочу послушать тех, кто это так или иначе решал.
Что беспокоит. Если скрипт падает, позиции остаются без присмотра. А он падал дважды за год: один раз после обновления библиотеки, второй раз терминал перезапустился, и соединение отвалилось. Стопы на сервере стоят, но выход по сигналу и перенос стопа делает скрипт. Потом время: от закрытия бара до ответа сервера у меня 150-400 мс, большая часть это мой расчёт и запрос истории. Для M5 вроде некритично, но не уверен. И обработка ошибок написана на скорую руку, повторы там примитивные.
Варианты, которые вижу: оставить как есть и обвесить сторожами; Python только считает и пишет сигнал в файл, а советник на MQL5 читает и исполняет; или сокет между ними. С MQL5 я на «вы», писал только индикаторы.

У меня как раз второй вариант, уже два года. Python считает и раз в бар пишет JSON в общую папку терминалов (Common\Files): символ, направление, объём, стоп, время расчёта и порядковый номер сигнала. Советник на MQL5 в OnTimer раз в 500 мс смотрит файл, сверяет номер с последним исполненным и, если сигнал новый, отправляет заявку, разбирает коды возврата, ведёт позицию и переносит стоп.
Что это даёт. Падение Python больше не оставляет позиции без присмотра: советник ведёт то, что открыто, просто новых сигналов не будет. Вся работа с торговым сервером в одном месте, которое живёт внутри терминала и переживает переподключение. И отлаживать по частям проще: советника можно гонять в тестере, подсовывая ему файлы с сигналами.
Минусы тоже есть. Два кода вместо одного, и формат надо держать в голове с обеих сторон. И свежесть сигнала: это надо решить заранее, а не после первого случая.

vadim_spb Написал(а):Для M5 вроде некритично

Некритично, у меня через пакет медиана 68 мс. Падение скрипта страшнее любых миллисекунд.

С файлами осторожнее. У меня советник однажды прочитал недописанный файл: Python ещё писал, а OnTimer уже открыл. JSON не разобрался, хорошо хоть советник при ошибке разбора ничего не делал. Теперь пишу во временный файл и потом переименовываю, на одном диске это почти атомарно. Сокет в этом смысле надёжнее, но там своя возня с переподключением, а файл проще отлаживать: открыл и видишь, что лежит.

egorov_m, а как советник понимает, что сигнал протух? Скрипт умер, а файл лежит со вчерашним сигналом.

В файле время расчёта по серверу и номер бара, к которому относится сигнал. Если сигнал старше двух баров M5, советник его не исполняет, пишет в журнал и шлёт мне в телеграм. Плюс Python каждый бар пишет пустую запись «жив», даже без сигнала, и если файл не обновлялся 15 минут, это тоже уведомление. А номер сигнала нужен, чтобы после перезапуска советник не исполнил тот же сигнал второй раз.

Расскажу вариант без MQL: у меня всё в Python, и переписывать я не готова, ошибок в MQL я наделаю больше, чем сэкономлю. Скрипт работает как служба с автоперезапуском и при старте первым делом читает открытые позиции с сервера, а не из своих файлов. Стоп на сервере ставится сразу с заявкой, без «поставлю потом». Отдельный сторож проверяет, что скрипт пишет в лог хотя бы раз в минуту. За год два падения, оба раза поднялся сам. Просто другой компромисс, не против схемы egorov_m.

Спасибо, картина стала понятнее. Сделал так: на демо параллельно запускаю схему с файлом и советником-исполнителем, как у egorov_m, с временным файлом и переименованием, и месяц смотрю, совпадают ли сделки с основным счётом и что вылезет. На реале пока оставил Python, но добавил сторожа, и при старте скрипт теперь читает позиции с сервера. Что выберу в итоге, пока не знаю.