Все те же проблемы с отправкой SMS, решаемые рестартом wb-rules

1

Добрый день! Хотелось бы вернуться к ранее так и не решенной проблеме с отправкой SMS через GSM-модем контроллера. После попытки отправки SMS через штатную функцию Notify в лог падает следующее:

08-06-2026 10:52:50.706 should_enable: Should enable GSM modem
08-06-2026 10:52:50.593 gsm_check_present: Modem is enabled in DT (/soc/usb@5310000/wbc-modem@1)
08-06-2026 10:52:50.523 guess_of_node: Got of_gsm_node: /soc/usb@5310000/wbc-modem@1
08-06-2026 10:52:50.475 main: Called from pid 845617 (sh)
08-06-2026 10:52:50.035 [wb-rules] INFO: [rule info] Отправлено SMS на номер XXX

При этом из консоли через ModemManager SMS продолжают нормально отправляться. Решается через рестарт сервиса wb-rules. При этом отправка может работать нормально неделями, если не трогать редактор правил (не менять правила). Есть подозрение, что какой-то конфликт возникает при нажатии кнопки “Сохранить” в редакторе правил и следующих за ним вызовах. Не знаю, существенно ли, но в файлах правил присутствуют прямые вызовы Notify.sendSMS, выполняемые сразу, при перезагрузке файлов правил.

3

Добрый день!

Пришлите, пожалуйста, диагностическую информацию. Надо собрать ее после того, как неисправность проявится (например, вы модифицировали правила, попробовали отправку, отправка не удалась), вы перезапустили wb-rules и работоспособность возобновилась.

Так же прошу указать, какой у вас контроллер и модем, включая номер ревизии. Дополнительно прошу отправить ссылку на предыдущее обращение по этой неисправности.

4

Предыдущая тема

Wiren Board 8.5.3 (s/n AXCFBMYW), release wb-2606 (as stable)

Модем: A7602E-H

приложен диагностический архив, доступен только сотрудникам поддержки
(631,0 КБ)

Диагностика собрана с попыткой отправки (неудачно), рестартом wb-rules и последующими удачными отправками

5

Выгрузите диагностику сейчас, пожалуйста. Судя по выжимке из журнала, неисправность проявлялась сегодня утром, следы в журналах должны остаться.

7

Покажите, пожалуйста, фрагмент правила, где вызывается Notify.sendSMS — особенно интересно, находится ли он внутри defineRule {…} или на верхнем уровне файла.

8

Да, как я и говорил ранее, есть вызовы вне defineRule

9

Покажите, пожалуйста, как выглядит этот вызов вне defineRule. Например, это что-то вроде:

// На старте — уведомление о перезагрузке контроллера?
Notify.sendSMS("+7999...", "Контроллер перезагружен");

defineRule("my_rule", {
  when: ...,
  then: function() {
    Notify.sendSMS("+7999...", "Событие");
  }
});
10

Дословно - например, так:

Rico.sendNotify("Завершена загрузка rules.js");

В модуле Rico объявлено так:

exports.sendSMS = function (phoneNumber, msgText) {
  Notify.sendSMS(phoneNumber, msgText);
};


exports.sendNotify = function (message) {
  sendSMS(SMS_NUMBER, message);
}
11

Вызов Notify.sendSMS на верхнем уровне файла (вне defineRule) выполняется каждый раз при загрузке/перезагрузке правил — то есть при старте wb-rules и при каждом «Сохранить» в редакторе.

Проблема в том, что в этот момент внутренний стейт Notify / wb-gsm может быть не готов, из-за чего последующие вызовы уже из defineRule тоже не работают.

Вызов при старте следует убрать с верхнего уровня и завернуть в setTimeout:

// Было:
Rico.sendNotify("Завершена загрузка rules.js");

// Стало:
setTimeout(function() {
  Rico.sendNotify("Завершена загрузка rules.js");
}, 60000); // 60 секунд — дать модему время зарегистрироваться

60 секунд - с очень большим запасом, можно подобрать индивидуально. Прошу проверить и сообщить по результатам.

12

А как связана перезагрузка wb-rules с готовностью wb-gsm? Тем более, что из консоли в момент недоступности отправки SMS из правил все нормально отправляется через mmcli. И разве нормальным является поведение

13

wb-gsm — это отдельный сервис, который живёт независимо от wb-rules. К моменту ручного рестарта wb-rules модем уже давно зарегистрирован в сети — просто потому что прошло время. Не потому что рестарт wb-rules как-то синхронизируется с wb-gsm.

То есть последовательность такая:

Старт системы
  → wb-rules стартует быстро
  → wb-gsm / ModemManager ещё инициализируются
  → Notify.sendSMS вызывается слишком рано → что-то ломается

... проходит время ...

Ручной рестарт wb-rules
  → ModemManager уже давно готов
  → Notify.sendSMS при загрузке отрабатывает нормально
  → стейт чистый → дальнейшие вызовы работают

Надёжное решение — убрать вызов Notify.sendSMS с верхнего уровня файла полностью, либо защититься проверкой готовности модема перед отправкой. setTimeout с фиксированной задержкой — лишь промежуточное решение, не гарантия, но я прошу проверить для начала его.

14

Про старт системы - понятно. Только вот, по-моему, не тот случай это, ибо:

Up time:       38 days 17:11

А проблема была менее 2 суток назад

15

Проверьте, пожалуйста, предлагаемое решение с таймаутом. Это очень важно для обсуждения проблемы с разработчиками и формирования баг-репорта.

16

Прописал таймаут 60000. Только не ясно, сколько ждать подтверждения гипотезы придется. Нет точного механизма воспроизведения проблемы

17

Спасибо! Сообщение пришло через минуту, как и должно?

18

Да. В том и дело, что оно порой и без таймера приходило.

20

Поскольку была открыта новая тема, мое предложение “переехало” в нее. Дублирую.

Предлагаю понаблюдать несколько дней за поведением системы с учетом внесенных изменений.

21

Ок, посмотрим. Вернусь с промежуточными результатами в начале следующей недели

22

Добрый день! “Крэшей” с отправкой SMS из-за сохранения правил пока не замечено. Но SMS таки перестали отправляться вчера, хоть и по другой причине. Последняя успешная отправка SMS прошла 17.06 в 13:38 с текстом о восстановлении связи с узлом. После этого - ошибки в логе. Внешняя причина связана, скорее всего с тем, что уже было отмечено в логах - авария силовой электросети и, последовавшая после этого утрата сервисов на базовой станции мобильного оператора (с резервным питанием БС все плохо). И совсем не хорошо, что у функций sendSMS, sendEmail отсутствует обратная связь о результатах своей работы.

P.S. Сегодня отправляется все (10:40).