Это что означает?
wb-mqtt-serial[1789]: WARNING: [register handler] failed to write: <modbus:202:holding: 21>: Serial protocol error: server device failure
На адресе 202 висит MR6C, релейки щелкают. На другом порту с тем же адресом - частотник, входы видно, и его регистр 21 я не дергаю.
Началось с час назад.
Да, появляется при записи в частотник, на другом порту.
Уточнения.
Совпадение адресов, вроде бы, ни при чем. Извините, пожалуйста, за скороспелые выводы. Авралим, нервы. Виноват.
В частотник таки идет запись, один раз, из скрипта на старте. Один.
Попробовал писнуть в него руками. Результат - да, ошибка server failure, защиту от управления по modbus забыли выключить руками.
4!!! Ранее при таких условиях (п.3) канал показывался красным на секунду-две, затем в него возвращалось прежнее значение. Сейчас же демон пытается продавить новое, много раз кряду, а старое показывается на странице только если обновить страницу со shift-cmd-R, при этом попытки записи не прекращаются!
Вот это изменение поведения и сбило меня с толку. Стоит ли вернуть прежнюю манеру? Было понятнее.
кажется, что пытаться отправлять значения несколько раз при ошибке - это более правильно. Server device failure - это, в нашей терминологии, временная ошибка, она может пропасть. Если бы устройство ответило чем-нибудь типа invalid data address, то мы бы не пытались повторять запись.
В интерфейсе, видимо, можно было бы как-то это обрабатывать более удобно, подумаем.
Сколько? 
Я насчитал несколько десятков попыток, прежде чем передернул демон.
Как видите, устройство может отвечать так, если оно залочено, на мой взгляд, надо делать 4-5 попыток (задаваемо в конфиге), затем отдать error w и вернуть старое значение.
Вот насчет установки в интерфейс ошибки - точно, надо. А прекращать попытки - зачем? Человек укзал делать - оно выполняет. Мало ли что ошибка. Может доступ будет разрешен. Ну разве что приоритет канала понизить и пробовать раз в 10 секунд.
А может, не будет.
Не лучше ли в конфиге задавать число попыток, чем раздувать лог, не давая при этом ошибку в обратку? Я считаю это алогичным и непонятным, прошу вернуть прежнее поведение.
Про Server device failure не знаю, но в случае таймаута или CRC Error на команду записи логично долбить до победного и в /meta/error выставлять особый признак, отличный от “w”. И сбрасывать его когда удалось записать. Это позволит корректно отобразить ситуацию в интерфейсе. А признак “w” писать в случае фатальных ошибок, когда не производится повторных попыток записи.
Кстати, wb-mqtt-serial записывает в mqtt топик канала новое значение из топика /on только после успешного подтверждения записи от устройства, верно?
Да, нужно расширить “ошибочные” состояние, это верно.
Для “Server device failure” - выдается просто ошибка потому как обрабатывать его по стандарту - надо, ошибка все ж. Но на практике не встречалось просто.
Тут надо обсуждать, причем всесторонне.
Тут надо, по моему скромнейшему мнению, не идти вразнос. И оставлять обработку ошибок либо на демоне, либо на юзерском скрипте, но делать это явно и документированно, а не вопреки логике и здравому смыслу.
Если error r положено обрабатывать скрипту, который читает датчик, я не вижу последовательности и логики в том, что теперь демон долбится к датчику до собственного понимания победы, при этом юзер ошибки error w не видит и вполне может пытаться записать туда еще что либо.
А вы видите логику?
Я сейчас вместо субботнего пива вынужден срочняком даунгрейдить serial на всех обновленных узлах и, если честно, я его маму труба шатал натыкаться на все новые и новые волчьи ямы. Надоело.
Предложение: введите булевую переменную “устройство на связи” для всех опрашиваемых устройств (чтобы с ней можно было работать в rules и ее было видно в web-интерфейсе), тайм-аут Т1 (время ожидания ответа от устройства в мсек- столько контроллер будет ждать ответа от устройства на свой запрос прежде чем делать следующий в случае неответа), число N- число попыток повторения запроса в случае неответа (при достижении N переменная “устройство на связи” меняет свое значение), тайм-аут Т2 в сек- пауза на которую прекращается опрос данного неотвечающего устройства, после Т2 контроллер делает очередную попытку опросить устройство с Т1 и N. Пока устройство не на связи ТУ запрещено (в веб-интерфейсе каналы ТУ при этом видно но они не активны, на команды с верхнего уровня ответ-отказ в управлении, в rules прежде чем управлять нужно проверять “устройство на связи”. Бит взводится при первом успешном опросе ТС и ТИ (примечание- все запросы изначально корректны, т.е. исправное устройство на них всегда будет отвечать), если у устройства только ТУ каналы все равно что-то нужно периодически опрашивать. Если устройство не на связи все ТС и ТИ каналы устройства должны быть как-то помечены (цвет поменять)в веб-интерфейсе, может описатель качества ввести для каждого канала (для работы в rules например)наподобии мэк-104 (там телесигнал из 00Н становится 80Н при обрыве связи с устройством.
Для этого (как и для работы скриптов через сеть) надо похерить текущую архитектуру и нарисовать другую, в которой стейт-машина возможна как часть схемы и работоспособна.
В текущей же ситуации я настаиваю на просьбе немедленно вернуть как было. И прекратить дурную тенденцию ломать то, что работало. Это одна из последних соломинок перед тем, как я попрощаюсь с вами. Честно.
так как раз ошибки чтения wb-mqtt-serial обрабатывает сам - будет повторять чтение следующий раз.
Ошибка в meta/error должна сразу появляться. Вы уверены, что не появляется? Можете логи показать или как-то ещё помочь это воспроизвести?
Если я правильно понимаю, то “как было” - это вообще никак не обрабатывать ошибки записи, даже вызванные проблемами на линии.
И я так и не понял причину вашего гнева. Что именно сломалось из-за повтора записи при ошибке? Пока в ваших сообщениях я увидел упоминание про две проблемы:
это все проблемы, или есть что-то ещё, что я упустил?
Добрый день!
Некоторые вещи отсюда уже реализованы внутри драйвера wb-mqtt-serial, например статус “устройство на связи” и разные настройки обнаружения этого статуса. Пользовательские приложения могут видеть ошибки через meta/error. Какие-то вещи сильно противоречат нашей архитектуре ПО, да и концепции Modbus: например “команды”. Вместо них мы оперируем распределённым состоянием, которое система старается синхронизовать.
Если в ваших задачах что-то такое требуется, пожалуйста опишите именно вашу задачу в новой теме, а мы подумаем, как её решить сейчас и как можно было бы улучшить наше ПО, чтобы решать её проще.
Сколько раз?! С каким интервалом? Как это задавать мне, а не искать в хардкоде? Да, это был мой вопрос.
Абсолютно (говорю за уи, а не свой скрипт). И в контроле торчит то значение, которое я туда написал, а не старое. Ждал больше минуты. При этом в лог сыпалась бесконечная простыня.
Именно что «некоторое», см. первый абзац.
Мое возмущение - не новость, меня никогда не перестанет бесить смена правил на ходу игры.
Повторю, сборка 2110.
Если запись возвращает переходящую ошибку (ошибки CRC, таймаута, server error и busy), то драйвер будет пытаться записывать значение снова и снова, но не более 10 минут. Интервал не регламентирован, т.к. запись делается один раз на цикл опроса, длительность которого зависит от количества регистров.
Параметры (максимальное время, список ошибок) сейчас настроить нельзя.
Я повторю свою просьбу: пожалуйста опишите конкретную проблему, с которой вы столкнулись. Не “ПО обновилось”, не “непредсказуемо работает”, а конкретную проблему. Мы обязательно подумаем, как её можно решить сейчас или что нам нужно улучшить в ПО, чтобы её можно было решить.
Мой вопрос был про meta/error. Про то, что значение в веб-интерфейсе осталось я понял сразу, спасибо. Про лог тоже.
Пожалуйста, ответьте на этот вопрос. Я, правда, пытаюсь понять, как нам сделать продукт лучше и надеюсь на вашу помощь.
да, всё так
Позднее, простыл, не до исследований.
Неприемлемо. Надо, чтоб настраивался. Таймаут уже есть в дереве настроек, зачем городить лишнее?
Таймауты в дереве настроек отвечают за другие вещи. response_timeout - это то, сколько ждать ответа от устройства. В вашем случае, устройство отдаёт ответ. device_timeout_ms - это про детектирование неработоспособности устройства, для того, чтобы не загружать линию опросом устройства, которое не отвечает. Тоже не про это.
Опишите пожалуйста задачу и проблемы, так мы поймём что именно и как именно должно настраиваться. Почему-то вы последовательно игнорируете мои вопросы и мне приходится угадывать, что не так.
Проблема в том, что слишком много записей в логах? Подумаем про то, чтобы их ограничить.