Обработка исключений wb-rules или ошибка доступности 1-wire

1

День добрый, периодически натыкаюсь на следующее поведение сценариев:

  1. В сценарии есть обращение к 1-wire датчику
Спойлер

pid_test.txt (11,5 КБ)

  1. Либо отваливается датчик на какое-то время (ошибка линии), либо (как в примере) происходит обновление контроллера (apt upgrade), и перезапускается wb-mqtt-w1
Спойлер 
 |22-10-2024 22:33:10.294|INFO: [mqtt] subscription succeeded (message id 75)|
| --- | --- |
|22-10-2024 22:33:10.265|INFO: [mqtt] subscription succeeded (message id 74)|
|22-10-2024 22:33:03.792|INFO: w1 thread Started|
|22-10-2024 22:33:03.759|INFO: [mqtt] subscription succeeded (message id 2)|
|22-10-2024 22:33:03.759|INFO: [mqtt] subscription succeeded (message id 1)|
|22-10-2024 22:33:03.747|INFO: [mqtt] connection estabilished with code "0" <success>|
|22-10-2024 22:33:03.747|INFO: [mqtt] connection estabilished with code "0" <success>|
|22-10-2024 22:33:03.729|INFO: [mqtt] UNIX socket exists, using it for connection|
|22-10-2024 22:33:03.729|INFO: [mqtt] Default host and port detected, checking if UNIX socket exists on /var/run/mosquitto/mosquitto.sock|
|22-10-2024 22:33:03.729|MQTT broker localhost:1883|
|22-10-2024 22:28:31.708|INFO: w1 thread Stopped|
|22-10-2024 22:28:31.702|INFO: [signal handling] Received signal 15|
  1. Скрипт перестает работать, не на момент отвала датчика, а совсем
Спойлер

1wire-pid result
1wire-pid result1613×773 81.4 KB

  1. Если открыть скрипт (с уже доступным датчиком) видим вот такое сообщение
Спойлер

1wire-error
1wire-error1133×734 35.1 KB

Повторюсь, датчик на момент скриншота уже давно доступен. Скрипт не работает.

  1. Нажимаем “Сохранить” на странице скрипта, все сохраняется и скрипт начинает работать

Вопрос:

  1. КМК не корректное поведение wb-rules - устройсто доступно, скрипт лежит.
  2. Есть ли возможность как то програмно обработать исключение, чтоб правило не отключалось до ручного перезапуска?
2

Кажется, разобрался что происходит - не посмотрел сразу в лог wb-rules
Cитуация происходит когда совпадают 2 события -

  1. Недоступность датчика (ошибка линии или рестарт сервиса)
  2. Перезапуск wb-rules.

В исходном примере поста, при обновлении перезапустился и wb-mqtt-w1 и wb-rules
Соответственно в логе wb-rules после рестарта видим

|22-10-2024 22:30:13.497|WARNING: couldn't load /etc/wb-rules/pid_test.js: TypeError: type error (rc -105)|
|---|---|
||anon  native strict preventsyield|
||anon /usr/share/wb-rules-system/scripts/lib.js:113 preventsyield|
||setDevValue /usr/share/wb-rules-system/scripts/lib.js:123 preventsyield|
||F /etc/wb-rules/pid_test.js:363 preventsyield|

правило просто не загрузилось из за недоступности датчика.

Вопрос о некорректном поведении снят - все логично, датчика нет → скрипт не грузится → не работает.

Вопрос “как обработать исключение?” остается. Пока, получается, после обновления нужно лезть в логи и смотреть какие скрипты отвалились и вручную перезапускать ( у меня 3-4 отваливаются периодически, ранее не мог понять почему, тут вот поймал)

4

Добрый день.
Вероятно что при чтении “несуществующего” контрола (топика) вернется null
Пример:

log.info(dev["wb-w1/28-00000e4c2180"]);

при отключенном датчике вернет:
Screenshot_20241023_131631
Следовательно - ошибка возникнет при присвоении

dev["PIDTest/enabled"] = dev["wb-w1/28-00000e4c2180"];

А почему не проверяете на null значение?

5

Андрей, день добрый. Уточнение во втором сообщении - выловил как возникает. При просто отвалившимся датчике, все окей - вернется null и ничего страшного. Проблема возникает когда перезапускается wb-rules при недоступном датчике - по причине глюков на линии (датчик недоступен, бывало ранее), либо по причине перезапуска wb-mqtt-w1 (вчера, в описанном тут случае так было). При перезапуске wb-rules данный скрипт не грузится, с появлением ошибки в логе wb-rules.

Но это тоже так себе поведение - скрип работал, обновили контроллер, нужно ловить какие скрипты упали (у меня несколько работают с 1-wire датчиками).

6

А все же вы правы - проверил, при присвоении левой части ошибка. Думаю решен вопрос, проверю на Null. Для общего развития - а разве полю virtualdevice, c type=“value” нельзя по правилам null присваивать?

1 лайк
8

Ну, null в JS присвоить переменной можно, но в случае с явно заданным типом автоматическое приведение типов похоже пасует.
И да, кстати, на проверке значения на null - можно и alarm генерироввать.