В логах 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 не работают
1 Like
Как в таком случае перебирать все параметры всех устройств?..
А зачем такое делать? Я не в смысле придирок, я действительно не представляю, зачем. Допустим, я пишу правило, которое по конкретному датчику управляет конкретным реле. Я подпишусь на топики датчика, реле, и их meta/error. Пропадет связь с датчиком/реле - отправлю уведомление, или что там мне будет нужно сделаю. Отвалится Modbus-модуль - получу уведомление от каждого правила, которое связано с его контролами - ну и норм. Порвется (условно) линия связи - получу уведомления от всех правил, связанных со всеми устройствами. Учитывая, что такое крайне редко бывает, считаю вполне нормальным.