Каким образом контролировать качество каналов связи?

В логах wb-mqtt-srial вижу периодические warning на CRC error (1 ошибка в минуту). Вообще говоря, “плохие” пакеты в последовательной шине дело в целом “нормальное” до определенной поры.
Многие вендоры предлагают некоторые метрики для контроля качества связи.
Могли бы подсказать, можно ли как-то придумать механизм, чтобы копить ошибки обмена данными? 0.01% ошибок в запросах это условно норма. 1% - стало хуже. 20% - очень много.
Хотелось бы знать, что связь “портится”.
Хочется больше информации о состоянии линии связи и её качестве

Такая логика реализована в драйвере wb-mqtt-serial.Если время от времени топик /devices/…/controls/…/meta/error принимает значения ошибок (это можно отследить средствами wb-rules) - надо что-то предпринимать. Иначе можно считать линию связи качественной.

1 Like

Драйвер 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 ошибку, и веб-интерфейс зажигает соотв. контрол красным.

Добрый день, удалось ли решить вопрос?

Из документации:
Если первое обращение к устройству в ограниченном режиме закончилось ошибкой, драйвер считает что устройство все еще отключено и больше не опрашивает его в этом цикле. Это позволяет тратить меньше времени на отключенные устройства. Первый успешный запрос к устройству будет расценен как переподключение устройства.
И как контролировать, что драйвер считает, что устройство всё еще отключено?

Короче говоря, накинул скрипт:

// Создаем виртуальное устройство для счетчиков ошибок
defineVirtualDevice("errorCounterDevices", {
  title: "Error Counters per Device",
  cells: {
    device1ErrorCount: {
      type: "value",
      value: 0
    },
    device2ErrorCount: {
      type: "value",
      value: 0
    },
    // Добавьте столько устройств, сколько необходимо
  }
});

// Функция для обработки ошибок
function handleModbusError(deviceName, errorCounter) {
  dev["errorCounterDevices"][errorCounter]++;
  log("Ошибка связи с " + deviceName + ". Текущее количество ошибок: " + dev["errorCounterDevices"][errorCounter]);
}

// Подписка на топики ошибок
defineRule("modbusErrorMonitoring", {
  whenChanged: [
    "/devices/2A2/controls/meta/error",  // замените на реальные топики
    "/devices/device2/controls/meta/error",
    "/devices/+/meta/error",
    // Добавьте топики для каждого устройства
  ],
  then: function(newValue, devName, cellName) {
    if(newValue) { // Если ошибка присутствует
        log("Ошибка связи поймана " + devName + " " + newValue);
      switch(devName) {
        case "2A2":
          handleModbusError("2A2", "device1ErrorCount");
          break;
        case "device2":
          handleModbusError("Устройство 2", "device2ErrorCount");
          break;
        // Добавьте обработку для каждого устройства
      }
    }
  }
});

Потом поменял у работающего реле настройку скорости. Устройство в списке красное, но в логах не вижу “таймаутов” и счетчик не крутит…

Похоже, “отсоединенное по таймауту” устройство как-то хитро опрашивается и /error не взводится?.. Тоже странновато… Как мне программно то отловить, что с устройством нет связи?.. Хочу сделать HMI и отобразить диагностику (есть связь\нет связи, качество связи (количество ошибок) и т.п. счетчик аптайма не предлагать. Не у всех модбас устройств оно есть, так что решение не универсальное)

Добавил тестовый параметр с несуществующим адресом, чтобы поймать ошибку связи\статуса:
в логах вижу:
WARNING: [register handler] failed to write: <</dev/ttyRS485-1 57600 8 N 2> modbus:171:holding: 17000>: Serial protocol error: illegal data address

Почему не срабатывает
“/devices/+/meta/error”,
??

Как вообще отличать статус “полной потери связи” с устройством от каких-то ошибок на определенном параметре?..

whenChanged: [“2A2/<идентификатор контрола>#error”, ․․․],

такие конструкции с whenChanged не работают

Документация: GitHub - wirenboard/wb-rules: Rule engine for Wiren Board

1 Like

Как в таком случае перебирать все параметры всех устройств?..

А зачем такое делать? Я не в смысле придирок, я действительно не представляю, зачем. Допустим, я пишу правило, которое по конкретному датчику управляет конкретным реле. Я подпишусь на топики датчика, реле, и их meta/error. Пропадет связь с датчиком/реле - отправлю уведомление, или что там мне будет нужно сделаю. Отвалится Modbus-модуль - получу уведомление от каждого правила, которое связано с его контролами - ну и норм. Порвется (условно) линия связи - получу уведомления от всех правил, связанных со всеми устройствами. Учитывая, что такое крайне редко бывает, считаю вполне нормальным.