Добрый день!
Разберу по порядку:
Что случилось с сервисом. Процесс wb-mqtt-serial обратился к недопустимой памяти, и за это его завершило ядро. Именно это означает строка status=11/SEGV в вашем логе. Дальше systemd автоматически поднял сервис заново, это его штатное поведение при падении.
Почему код в этот момент пошёл не туда — точно сказать нельзя. Самая вероятная версия — обработка битых ответов с шины: у вас на шинах постоянно идут таймауты и повреждённые кадры, значит эти ветки кода работают непрерывно. Но это предположение, не факт.
Почему сработали сценарии. При остановке драйвер помечает свои контролы как недоступные — в топике счётчика оказывается пустое значение. При старте он опрашивает устройства и публикует значения заново. wb-rules видит цепочку «значение → пусто → значение» и отрабатывает whenChanged, передавая в правило то же самое число, что было до падения. Счётчик при этом не изменился ни на единицу, и модули питание не теряли — они и не обнулялись.
Ваш эксперимент с обесточиванием — это второй, отдельный случай: там счётчик в модуле действительно сбрасывается в 0, и правило видит изменение.
Что делать, по порядку:
1. Исправить правила. Проверки newValue > 0 недостаточно — она ловит только случай с обесточенным модулем. Нужно ещё сравнивать с предыдущим значением, тогда отсекается и повтор того же числа после рестарта драйвера:
function buttonSinglePress(input, action) {
var topic = input + " Single Press Counter";
var counter = dev[topic]; // при старте может быть null
defineRule({
whenChanged: topic,
then: function (newValue) {
if (newValue > 0 && counter !== null && newValue != counter) {
action(newValue); // настоящее нажатие
}
counter = newValue;
}
});
}
Этот вариант из темы, где коллеги разбирали такую же ситуацию: Отработка правил завязанных на счетчики при перезагрузке. Там же объяснено, почему более простые проверки не закрывают оба случая.
2. Обновить ПО контроллера до актуального стабильного релиза. У вас wb-mqtt-serial 2.180.2 — версия годичной давности, с тех пор вышло много исправлений.
3. Разобраться с шиной. Частотные преобразователи снимать срочно не нужно — они на отдельном порту MOD3, прямой связи с падением в логах не вижу. Но по архиву видно две проблемы:
-
GRD9L-S с адресом 3 не отвечает практически постоянно — почти 5000 таймаутов за два часа;
-
один из преобразователей (адрес 1) регулярно отваливается и подключается заново, второй при этом работает нормально.
Проверьте у них питание, проводку и адресацию. Плюс на шине с модулями MR6C раз в 5–10 минут проскакивают битые ответы от разных модулей — это то самое «покраснение» топиков. Стоит пройтись по монтажу: RS-485: Физическое подключение.