Поэтому и написал тут.
Саму проблему решил самостоятельно (и описал как)
Я так понимаю, проблема носит массовый характер, но да, скорее всего проявляется только при “слабом” Интернет. Может кратковременная потеря пакетов (что TCP не может сам исправить, или вообще UDP используется некорректно …)
Как разработчик, могу сказать, что основная причина - “неправильный” алгоритм, то есть проблема проектирования: нет учета “слабых” мест. При этом решение хоть и не совсем индустриальное, такого все равно не должно быть, имхо.
Повторюсь, о тех проблемах (и как должно быть), с моей точки зрения.
(Но у меня не многолетний опыт работы именно с WB, но и RS и Debian …, поэтому не факт, что прав абсолютно)
- Работа что через консоль, что через WEB должна быть абсолютно одинаковой! Через интерфейс только упрощается выбор устройства и “кнопка” … Через интерфейс возможностей обычно меньше, чем через консоль
- Работа должна быть абсолютно надежной
- Должен быть ключ утилиты “только скачать все прошивки и/или загрузчики” последней или заданной версии (с вариантом очистки предыдущих версий (замены) или положить рядом)
- Должен быть ключ интерфейса “обновлять устройства только из локальной копии (то что скачали пунктом 3 или положили в определенную папку вручную”
- Должен быть ключ вывода подробной информации (по сути он должен быть для WEB интерфейса, сам анализ вывода утилиты - вывод в интерфейс, а кнопка должна вызывать ту же саму консольную команду: “обновить -конкретное_устройство -включая/исключая_загрузчик -тихо -с_выводом_подробной_информации”
- Должна быть возможность проверки версии загрузчика
- Должна быть возможность сохранить и восстановить значения “настроечных” регистров.
- Должна быть возможность “тихой” установки - то есть не задавая никаких вопросов
- Должгны быть возможность обновления загрузчика
- Возможность очистки скачанных обновлений после успешной установки прошивки/загрузчика (для экономии места) или оставлять (для “истории” или использования на другом контроллере … или для других алгоритмов (замена неисправного устройства на новое и возврат на него версии и значений сохраненных регистров)
- Сам алгоритм обновления должен быть (а он примерно такой и есть сейчас, но “примерно”) четко по “ШАГАМ”: скачивание (при чем минимум три попытки, если соединение прервалось, или этот шаг пропускается ключом), сохранение всех настроечных параметров устройства (шаг можно пропустить), строго автономное (отдельным процессом, чтобы даже отвалившаяся консоль … не могла появлиять) обновление загрузчика (этот шаг можно пропустить ключом), аналогично обновление прошивки (также можно пропустить или обязателен при обновлении загрузчика), восстановление всех настроечных параметров устройства (можно пропустить или указать версию/дату сохранения параметров …), проверка версии (а может еще какая диагностика устройства).
В результате можно как по времени разделять (скачивать обновления (при чем не факт что самим контроллером), обновлять … ), так и гибкость и любая автоматизация процесса (а то получается “умный дом”, что только и исключительно “без участия человека”, но даже чтобы обновить, нужно очень плотное “участие”)
Но … все эти доработки не “быстрые”, и наверняка задач много …
Но с другой стороны, нужна надежность в любом случае, а значит в любом случае допиливать и исправлять …
P.S. И в WEB интерфейсе должна быть не “новая утилита” обновления со “своим” алгоритмом, а также самая утилита, единственная, только обернутая в WEB интерфейс. Имея два алгоритма в разных местах контроллера (а в WEB интерфейсе он второй исключительно потому, что консольная утилита “так не может”) получаете две разработки и ошибки в двух местах (а при обновлении/изменении логики работы еще и кучу дополнительных проблем)
