Новая версия движка правил

https://wirenboard.com/wiki/index.php?title=Совместимость_скриптов_при_обновлении_wb-rules

думаю дело в

dev["wb-mr3_15"]["K1"] = 1;

но в логах это должно быть, посмотрите пожалуйста ещё раз

спасибо, подправил, всё заработало. В логах пусто все равно.

Причину нашел.

Если внутри функции, вызываемой по setInterval сделать clearInterval с ее айдишником - то wb-rules упадет.

Спасибо за репорт бага. Фикс подготовлен, в ближайшее время будет релиз с исправлением этой проблемы.

Испрвалено в 2.3.2, в стабильном репозитории.

11 сообщений были перенесены в новую тему: Странные значения в топиках вирутального устройства

Обновились до версии 2.3.3. Устройства на шине не срабатывали, т.е., например, правило указывает включить реле, правило работает, реле не включается.
Глубоко не разбирались.
Откат до версии 1.7.1 исправил положение.

Итак, продолжаем BugHunting:

Движок 2.3.3:

Если обратится к массиву глобальных значений, к ключу который еще не был проинициализирован, то wb-rules упадет, пример кода:

var globalLights = new PersistentStorage("lights_storage", {global: true}); // Глобальное хранилище значений диммеров в ПЗУ

   if (globalLights["123"] === undefined) { 
       log("Этот комментарий не появится, а wb-rules упадет, пока ключ 123 Не будет проинициализирован");
   }
1 Like

@borg спасибо! Будем исправлять.

Добрый день.

Не получается воспроизвести проблему на 2.3.3 (в ветке 1.7 эта проблема действительно присутствует) - сообщение в логе появляется wb-rules не падает.

Могли бы вы предоставить дополнительную инфомацию:

  1. вывод apt policy wb-rules
  2. выполнить
    service wb-rules stop ; /usr/bin/wb-rules -editdir /etc/wb-rules /usr/share/wb-rules-system/rules/ /etc/wb-rules /usr/share/wb-rules/
    добиться креша и прикрепить сюда вывод из терминала (желательно отдельным файлом)
  3. если для воспроизведения в этих условиях потребуется изменить код скрипта - приложите его сюда в новом виде

У меня тоже не воспроизвелось:

root@wirenboard-AQZBLNTY:/mnt/data/root# dpkg -s wb-rules | grep Version
Version: 2.2.2

Вот вы все будете удивлены, но у меня тоже все заработало. может помогла неоднократная перезагрузка устройства. Сорри за беспокойство.
Но есть еще один вопрос - по изменению состояний девайсов (диммеры) записываю их значения в:
var globalLights = new PersistentStorage(“lights_storage”, {global: true}); // Глобальное хранилище значений диммеров в ПЗУ
таким образом: globalLights[key] = value;

После перезагрузки скрипта, читаю эти значения и соответственно восстанавливаю состояния диммеров: if (debugLog) log("[Lights] " + relay_name + relay_control + " = " + globalLights[relay_name + relay_control]);

Так вот, при перезагрузке скрипта, все работает идеально - все что было сохранено, также и восстанавливается. Но стоит перезагрузить контроллер (через reboot now либо кнопкой) то значения восстанавливаются совершенно иные, нежели были записаны в последний раз.
Отчего такое может происходить?

P.S. причем в соседнем скрипте я также вытаскиваю данные при загрузке и там все ок, там правдо ключи более простые K1, K2 и т.д., в отличии от этого хранилища где ключи текстовые до 20 символов. Также в первом (работающем) хранилище есть только boolean значения, то в неработающем есть как boolean так и integer.

UPD: Попробовал заменить хранилище, создал с новым идентификатором - все ровно тоже самое.

Не работают правила если определение устройства и правило его использующее находятся в разных файлах.

  1. Файл test_rule.js:
    defineRule(‘test_test’, {
    whenChanged: ‘testControl/switch_control’,
    then: function (newValue, devName, cellName) {
    if (newValue) {
    dev[‘testControl’][‘pers_text’] = “Test text”;
    log(“text: {}”, dev[‘testControl’][‘pers_text’]);
    } else {
    dev[‘testControl’][‘pers_text’] = ‘’;
    log(“text: {}”, dev[‘testControl’][‘pers_text’]);
    }
    }
    });

  2. Файл test_device.js:
    defineVirtualDevice(‘testControl’, {
    title: ‘Test’,
    cells: {
    pers_text: {
    type: ‘text’,
    value: ‘’
    },
    switch_control: {
    type: ‘switch’,
    value: false
    }
    }
    });

mosquitto_sub -v -t “/devices/testControl/controls/”# | ts
May 31 18:48:28 /devices/testControl/controls/switch_control/on 1
May 31 18:48:28 /devices/testControl/controls/switch_control 1
May 31 18:48:28 /devices/testControl/controls/pers_text Test text
May 31 18:48:36 /devices/testControl/controls/switch_control/on 0
May 31 18:48:36 /devices/testControl/controls/switch_control 0
May 31 18:48:36 /devices/testControl/controls/pers_text (null)
May 31 18:48:41 /devices/testControl/controls/switch_control/on 1
May 31 18:48:41 /devices/testControl/controls/switch_control 1
May 31 18:48:41 /devices/testControl/controls/pers_text Test text

Лог при включении/выключении свича:
May 31 18:48:28 wirenboard-AHZ2TA3P daemon.info wb-rules[24319]: INFO: [rule info] text: null
May 31 18:48:36 wirenboard-AHZ2TA3P daemon.info wb-rules[24319]: INFO: [rule info] text: null
May 31 18:48:41 wirenboard-AHZ2TA3P daemon.info wb-rules[24319]: INFO: [rule info] text: null
То же самое при использовании dev[‘testControl’][‘pers_text’] в других правилах.

Так это же явно описано: Движок правил wb-rules — Wiren Board

Ну там написано про глобальные переменные и функции.
И если так, то добавьте к моему примеру еще один свитч и вывод его в лог - удивитесь.

Расскажите, пожалуйста, поподробнее.

Ну во-первых я не согласен что мой случай описан по ссылке. Если бы это было так, правило не должно срабатывать вообще. (у меня куча правил ссылается или изменяет статус девайсов объявленных в других файлах. это же касается и реальных устройств, разве нет?)

Расскажите, пожалуйста, поподробнее.

А свитч будет отрабатывать (включая лог) как положено.

Стоит ли ждать исправления и если да то когда?
Работало правильно в 1.7.

Всем привет.

Надеюсь задаю вопрос в правильной ветке, но полагаю здесь это более уместно.

При загрузке системы (после включения), все правила которые привязаны на отработку изменений нажатия (например) кнопок - запускаются со значением False.

Приведу пример:

Вот такое правило:
defineRule(name, {
whenChanged: “wb-gpio/” + switch_control,
then: function(newValue, devName, cellName) {
}
});

Отработает при загрузке системы со значение newValue = false.

Для себя это вижу как проблему, т.к. в процессе загрузки стартуют правила, которые должны обрабатывать нажатия кнопок и соответственно если был факт перезагрузки контроллера (питание отключали надолго и не справились UPSы) то при загрузке может включится свет, вентиляторы и еще много чего.

Баг или фича?

P.S. Версия wb-rules 2.3.3
P.P.S. Пришлось сделать заплатку, а именно флаг boolean initialized = false и после 10 секунд от начала работы скрипта записывать в него true и все события уже отрабатывать как только initialized = true.

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

1 Like