Доброго дня! На одном из наших объектов периодически происходит следующее:
Ненадолго отключается свет, но более чем на 5 секунд.
Моторы штор остаются без питания, контроллер на UPS
Моторы штор не отвечают и драйвер wb-mqtt-serial возвращает такую ошибку
1.
18-08-2026 08:18:18.635
WARNING: </dev/ttyMOD4 9600 8 N 1>: got more than 2 consecutive failures during last 5000 ms. Try to recover, close and reopen port. Check if devices on the bus are powered
Свет возвращается, но порт остается в ошибке до его перезапуска
Шторы не работают до ручного вмешательства
Подскажите пожалуйста, как можно изменить поведение драйвера, что бы он не так активно тревожился об ошибках на этом порту, а в идеале просто игнорировал проблемы связи? Что бы он не прерывал работу при ошибках? Или как можно сбросить аварийное состояние порта не перезапуская драйвер wb-mqtt-serial?
Причины возникновения ошибок понятны и не требуют специальной реакции, однако поведение драйвера не оставляет другого варианта, кроме ручного вмешательства после кратковременных отказов электропитания. Хотелось бы или изменить это поведение, или автоматизировать борьбу с последствиями.
диагархив прилагаю на всякий який
приложен диагностический архив, доступен только сотрудникам поддержки
После возврата света вы нажимаете «Открыть» в веб-интерфейсе — и ничего не происходит? Или шторы просто остались там, где их застало отключение, и вы их не трогали до перезапуска драйвера?
После возврата света если нажать “открыть” или любую другую кнопку в веб-интерфейсе она станет красной. Мотор команду не получает. Управление рукой при этом работает, остановлен только последовательный порт контроллера, на стороне моторов ничего не приходится делать, что бы работа возобновилась, только снять галку “включить порт” в настройках драйвера, сохранить, поставить галку, сохранить
Строка got more than 2 consecutive failures ... что на шине никто не ответил в течение 5 секунд. Драйвер в ответ закрывает и тут же открывает порт заново, и повторяет это, пока шина молчит. Отсюда поток одинаковых сообщений. Сбрасывать там нечего — состояния, которое требовало бы сброса, у порта нет. А галка «Включить порт» просто перезапускает драйвер: сохранение конфигурации перезапускает службу.
Воспроизвести ваш случай на стенде не удалось. Снимал питание с устройства на выделенном порту, в том числе на три минуты. Драйвер каждый раз поднимал связь сам за несколько секунд, без вмешательства. Значит дело не в самом факте пропадания питания, а в чём-то ещё — и это надо найти.
Также заметил, что у вас 2.248.1 от мая. В 2.260.1 исправлено: команда, отданная устройству, потерявшему связь, больше не теряется, а выполняется после её восстановления.
Учтите — после обновления шторы могут поехать позже, чем вы нажали кнопку, если нажатие пришлось на момент обрыва связи.
Еще есть пару вопросов:
Питание приводов как реализовано? Идёт напрямую от автомата или через контактор либо канал реле?
По журналу за последние полтора месяца просадок было около десяти, а вмешательство потребовалось дважды. Правильно понимаем, что проблема возникает не после каждого отключения света? Если так — чем отличались те два случая?
И еще просьба, если случай повторится — прежде чем переключать галку, подождите, пожалуйста, минут пять и попробуйте нажать кнопку ещё раз. Так мы поймём, восстанавливается ли связь сама. И если получится, до переключения галки сохраните журнал и скиньте файл stuck.log:
Я обновлю ПО контроллера, мы делаем это раз в пару месяцев, что бы не сильно беспокоить пользователей, посмотрим на его поведение. Правда я считал, что это исправление касается только modbus-сеансов. Если в rpc тоже реализованно, просто замечательно.
Питание приводов четыре отдельные линии на автоматах, без реле
вмешательство потребовалось дважды
Всё абсолютно верно, такое поведение я наблюдал дважды и после второго случая создал эту тему. Мне тоже не удалось воспроизвести, однако есть у двух случаев общая черта, пропадало питание на время небольшое, но более обычного. “Обычное” в данном случае это время перевода моторного АВР на вторую линию, то есть если было пропадание одного ввода и перевод на резерв, менее пяти секунд, то аварийная ситуация не наступает. Когда было глобальное отключение и не было несколько часов оба ввода аварийная ситуация не наступала. Когда я отключал ввод руками на 10 секунд - авария не наступала. А вот позавчера, около десятисекундным отключением наступила.
Журнал сохраню, в принципе мне ничего не мешает добавить скрипт, который сохранит его, если обнаружит r в /meta/error/ у приводов, или через десять секунд после восстановления питания, так, я думаю, журнал не пропадет от моей забывчивости.
восстанавливается ли связь сама
В первый раз порт в аварии провисел довольно долго, прежде чем пользователь мне написал о проблеме, насколько я помню. Во второй раз более десяти минут, связь не восстанавливалась. Посмотрим, что будет после обновления
Вот сегодня утром появился ответ: нет, не смотря на обновление, проблема повторилась, и на этот раз немного по другому. Свет выключили в 4:50 по местному, включили после того, как сел UPS телеком оборудования, в 6:02. Последовательный интерфейс на котором шторы снова перешел в нерабочее состояние, после перезапуска сервиса wb-mqtt-serial вернулся в норму. Вот свежий диагархив, и лог, автоматически сохраненный
Из журнала видно: питание вернулось в 06:02:41, и через три секунды драйвер поднял связь примерно с 25 устройствами на портах MOD2, MOD3 и RS485-2. На MOD4 не подключилось ни одного из девяти приводов. При этом порт продолжал открываться и опрашивать их каждые 10 секунд вплоть до перезапуска сервиса в 06:40.
Опыты повторил на контроллере с точно такой же версией драйвера, как у вас. Снимал питание на минуту и на полторы — связь возвращалась сама за несколько секунд. Воспроизвести ваш случай снова не удалось.
На данный момент решения, кроме перезапуска wb-mqtt-serial, у меня нет. Передам информацию разработчикам — с логом, конфигурацией и результатами опытов. Как будет какая-нибудь информация, я вам сообщу.
Хорошо, видимо дело в реализации того, как драйвер работает именно с приводами. Поскольку о перезапуске драйвера приводы никак не могут узнать, но начинают работать после как ни в чем ни бывало.
С модбасс-устройствами на всех объектах связь восстанавливалась всегда, с такой гирляндой приводов этот объект единственный, к сожалению не на чем попытаться воспроизвести
Подскажите, пожалуйста, а есть ли возможность дать доступ в облако нашим разработчикам, если повторится такое поведение? По логам пока сложно понять в чем проблема