В логах wb-mqtt-srial вижу периодические warning на CRC error (1 ошибка в минуту). Вообще говоря, “плохие” пакеты в последовательной шине дело в целом “нормальное” до определенной поры.
Многие вендоры предлагают некоторые метрики для контроля качества связи.
Могли бы подсказать, можно ли как-то придумать механизм, чтобы копить ошибки обмена данными? 0.01% ошибок в запросах это условно норма. 1% - стало хуже. 20% - очень много.
Хотелось бы знать, что связь “портится”.
Хочется больше информации о состоянии линии связи и её качестве
Такая логика реализована в драйвере wb-mqtt-serial.Если время от времени топик /devices/…/controls/…/meta/error принимает значения ошибок (это можно отследить средствами wb-rules) - надо что-то предпринимать. Иначе можно считать линию связи качественной.
1 лайк
Драйвер wb-mqtt-serial УЖЕ это делает или вы имеете ввиду что средствами JS это можно делать?
Обычно такую вещь “вшивают” в драйвер, а наружу торчит только KPI качества связи (% любых потерянных\плохих пакетов).
Мне кажется делать в rules проверку на meta\error даст дополнительную ненужную нагрузку на процессор…
Добрый день!
Есть несколько вариантов поведения при накоплении ошибок. Когда их становится слишком много, драйвер временно отключает шину и пишет в лог:
WARNING: closed due to repetetive errors
Чтобы не дожидаться автоматического отключения, можно заранее отслеживать специальный топик с ошибками — /meta/errors. Подробнее об этом написано в данной статье.
Что касается нагрузки: правило, отслеживающее эти ошибки, на практике не создаёт значительной нагрузки на систему. Кроме того, MQTT-топики можно анализировать и обрабатывать сторонними средствами — например, через Node-RED или внешние скрипты.
Отключает шину или исключает устройство из опроса? Полностью отключать шину отключать как-то жёстко.
Отключение шины == перезагрузке wb-mqtt-serial?
Чтобы не дожидаться автоматического отключения, можно заранее отслеживать специальный топик с ошибками —
/meta/errors.
Если я сделаю каунтер на все */meta/errors, то как не допускать автоматического отключения, что вы имели ввиду?
документация
в части описание meta/error немного отличается от
этой на гитхабе
на гитхабе упомянут ключ p, но толком тоже не описан.
Если в драйвере уже реализован счётчик для покраснения, нельзя ли его “достать” наружу либо положить в meta/error, чтобы не считать ещё раз в пользовательском скрипте?
У вас же уже практически всё сделано, зачем два раза процессор мучать.
Очень подробно описано в документации.
Добрый день, удалось ли решить вопрос?
Я так и не понял, по какому значению устройство становится “красным”, чтобы это отслеживать и включать предупреждение заранее. Или не ориентироваться на него (красное устройство)?
Добрый день!
Устройства отображаются красными, когда в мета error присутствуют ошибки.
Одна единственная ошибка чтения\записи “зажигает” устройство? или по какому-то счетчику ошибок?
Вот же ответ на ваш вопрос: Каким образом контролировать качество каналов связи? - #7 от пользователя BrainRoot
Когда драйвер не может достучаться до устройства, он пишет в meta/error ошибку, и веб-интерфейс зажигает соотв. контрол красным.
Добрый день, удалось ли решить вопрос?