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

А что должно обработать топик “on” для виртуального устройства?
Используйте

mosquitto_pub -t '/devices/testdevice/controls/testcontrol' -r -m 0
mosquitto_pub -t '/devices/testdevice/controls/testcontrol' -r -m 1

должно обработать топик “on” для виртуального устройства?

Да, нужно, чтобы далее wb-rules на основании новых данных произвел расчеты.
Но при этом нужно, чтобы значение новых данных нельзя было устанавливать вручную.

Не используйте “/on” для виртуальных устройств.
Команда

dev["testdevice/testcontrol"] = true

эквивалентна

mosquitto_pub -t /devices/testdevice/controls/testcontrol -r -m 1

Не используйте “/on” для виртуальных устройств.

Ранее без этого не работало. Со второй версии начало работать?

Для виртуальных всегда так было.

Коллеги ничего не понимаю. но у меня не работает простой скрипт по инкрементированию значения виртуального устройства по появлению

Version: 2.6.0

defineVirtualDevice("WaterCount", {
    title: "WaterCount",
    cells: {
      "HW99": {//ГВС кв99
	    type: "value",
	    value: 15,
        forceDefault: true,
	    },
      "CW99": {//ХВС кв99
	    type: "value",
	    value: 55,
        forceDefault: true,        
	    },
      "HW100": {//ГВС кв100
	    type: "value",
	    value: 34580,
        forceDefault: true,        
	    },
      "CW100": {//ХВС кв100
	    type: "value",
	    value: 32000,
        forceDefault: true,        
	    }
	}
});

function WaterCount(name, control, virt, count) {
defineRule(name, { 
  whenChanged: control, //при новом импульсе
  then: function (newValue, devName, cellName) { //выполняй следующие действия
    // прибавляем к текущему значению +1
    if (newValue) {
    	var test = dev[virt][count] + 1;
    	dev[virt][count] = test;
	    log.info("rules = " + name + "   count = " + dev[virt][count]);
    }
  }
});
}

WaterCount("CW99Count", "wb-gpio/EXT2_IN6","WaterCount", "СW99");
WaterCount("HW99Count", "wb-gpio/EXT2_IN7", "WaterCount","HW99");
WaterCount("CW100Count","wb-gpio/EXT2_IN8","WaterCount","СW100");
WaterCount("HW100Count","wb-gpio/EXT2_IN9","WaterCount","HW100");

при работе скрипта вывод ниже, что бы я не делал как бы я не обращался к виртуальному устройству

dev["WaterCount/СW99"]
dev["WaterCount"]["СW99"]

Результат работы скрипта:
2021-03-26 12:33:42rules = CW99Count count = null

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

например

defineVirtualDevice("Termostat", {
    title: "Termostat",
    cells: {
      // =============== Прихожая теплый пол
      "R01-TS16-1-mode": {//режим 0-ручной 1-по расписанию
	    type: "switch",
	    value: false,
	    },
      "R01-TS16-1-setpoint": {//уставка
	    type: "range",
	    value: 25,
        max: 30,
        readonly: false
	    },
      "R01-TS16-1-lock": {//блокировка в визуализации 0-снята 1-заблокирована
	    type: "switch",
	    value: false,
	    },.......

var hysteresis = 0.5;
function Termostat(name, temp, setpoint, TS, TS_onoff) {
defineRule(name, { 
  whenChanged: temp, //при изменении состояния датчика
  then: function (newValue, devName, cellName) { //выполняй следующие действия
    if (dev[TS_onoff]) {
    	if ( newValue < dev[setpoint] - hysteresis) { //если температура датчика меньше уставки - гистерезис
      	dev[TS] = true;
    	}
    	if ( newValue > dev[setpoint] + hysteresis) { //если температура датчика больше виртуальной уставки + гистерезис
      	dev[TS] = false;
    	}
    }
    else dev[TS] = false;
  }
});
}

Termostat("R01-TS16-1", "A60-M1W3/External Sensor 1", "Termostat/R01-TS16-1-setpoint", "wb-gpio/EXT4_R3A1", "Termostat/R01-TS16-1-onoff"); // Прихожая теплый пол


коды символов

&#1057;&#87;&#57;&#57;

перепишите вручную или скопируйте из места, где обращаетесь к функции
Имею в виду что первый символ, “C” у вас странной кодировки

Во истину странно!
Переписал, заработало. Спасибо!

Русскую “С” от английской “C” на вид довольно сложно отличить, сам так попадался.

Предпринял новую попытку обновить wb-rules c 1.7.1 на 2.6.3 на «боевом» контроллере. Опять - неудача:

Первое
На этом контроллере кроме штатных сервисов Wiren работают дополнительные сервисы:

  • Работают сервисы, которые опрашивают и управляют устройствами, работающие по протоколу SNMP. Родной драйвер WB мне использовать не удалось, ввиду его куцести и непредсказуемости.
  • Работают сервисы, которые опрашивают и управляют устройствами по REST HTTP.
  • Работает сервис, который проверяет, актуальны ли данные с устройств в MQTT БД, или уже “протухли” (на основе меняющих значений Uptime в регистрах датчиков и исполнительных устройств). Если данные протухли – сигнализирует или перезапускает wb-mqtt-serial

Всё это взаимодействует через wb-mqtt-db (через подписку и публикацию топиков по MQTT).

В старой версии wb-rules все виртуальные устройства были по умолчанию как бы “writable” и wb-rules реагировал на событие “whenChanged” , когда производилась публикация в mqtt топик вида /devices/DEV/controls/CONT/on
Параметр readonly: false в описании вирт устройств влиял только на возможность редактировать значение данного устройства в интерфейсе (WebUI)

В новой версии, для того чтобы wb-rules реагировал на событие “whenChanged” при записи в топик вида /devices/DEV/controls/CONT/on необходимо явно задавать параметр readonly: false и соответственно данные устройства становятся автоматически редактируемыми в WebUI ! Что для меня лично – совсем не желательно.
Мне нужно, что бы вирт. устройство отображалась в интерфейсе без возможности редактирования и реагировало на событие “whenChanged” при записи в топик вида /devices/DEV/controls/CONT/on

Мне непонятно - в чем логика того, что если устройство readonly, то оно не дожно реагировать на событие при записи в топик вида /devices/DEV/controls/CONT/on?

Второе
В версии wb-rules 1.7.1. при описании виртуальных устройств типа value и ряда других к нему приравненных (Temperature, Power, Voltage и прочих) допускалось указывать значение в кавычках. Движок автоматически преобразовывал текстовое значение в число. В новой же версии присвоение значения не происходит. Приходится убирать лишние кавычки (’ ')

В документации в разделе «Совместимость скриптов при обновлении wb-rules» об этом типе данных явно ничего не указано.
Было бы не плохо добавить эту информацию для тугих, как я.

PS
Прошу еще обратить внимание на виртуальные устройства типа «wo-switch». Они не реагируют на присвоение значений value: , да и вообще ,по-моему, ни на что не реагируют.
А для чего этот тип устройств нужен?

Добрый день!

Это мы поддерживать не будем. Собственно разделение на readonly и не readonly каналы и было введено, чтобы убрать бардак.

В вашем случае правильное решение проблемы - это создавать устройства и наполнять их данными в одном сервисе. Это может быть либо wb-rules, в который переедет лоигка из сервиса опроса SNMP, либо, наоборот, внешний сервис опроса SNMP, в котором нужно будет создать структуру устройств.

Я буду очень признателен, если вы найдёте 10 минут и напишите подробно про куцесть и непредсказуемость родного драйвера SNMP. Нам это важно, чтобы понять, что чинить и улучшать. Вы свою проблему уже решили, но другим пользователям это будет полезно. Спасибо!

Да, спасибо, напишем.

И создали новый бардак - свалив все в одну кучу. Т.е. одним параметром и канал в не readonly включаем и одновременно в WebUI поле редактируемым делаем. Нельзя, хотябы это отдельными параметрами задавать?

В вашем случае правильное решение проблемы - это создавать устройства и наполнять их данными в одном сервисе. Это может быть либо wb-rules,

Даже если все делать в wb-rules (версии 2.x.x), то для того что бы произошло событие “whenChanged” в результате каких то вычислений и присвоение значений вирт. устройству - это вирт устройство должно быть readonly: false. И оно опять же становится редактируемым в интерфейсе.

либо, наоборот, внешний сервис опроса SNMP, в котором нужно будет создать структуру устройств.

Видимо, к этому все и прийдет - прийдется забыть про wb-rules и WebUI и использовать стороние сервисы.

И да - вы так и не ответили - в чём же логика. Почему readonly канал (по вашей терминологии) не может вызвать событие “whenChanged” путем записи в топик через MQTT типа /devices/DEV/controls/CONT/on

Все возникшие проблемы были описаны в теме ниже

Если кратко

  • Не поддерживались длиные OIDы
  • Не поддерживались некоторые типы данных
  • Падение сервиса, если при старте не мог “достучаться” до SNMP хоста
  • Если SNMP хост во время опроса становился не доступен - это ни как не фиксировалось в виде ошибки (как это сделано у wb-mqtt-serial по modbus)

Делали так изначально. Путались все, включая разработчиков и авторов.

Так мне кажется это вполне логичным. Вот пишете вы на wb-rules, например, драйвер внешнего термостата. Температура с его датчика - это параметр с readonly: true, потому что поменять его никак нельзя. Зачем там whenChanged?
Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.

Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.

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

С точки зрения wb-rules, MQTT и конвенций, веб-интерфейс - это ровно такой же сервис, как и все другие. Поэтому он подчиняется всем тем же правилам. Если кому-то можно менять канал, то и веб-интерфейсу можно.

Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.

На “переходной” период для чтения “readonly” можно вообще использовать trackMqtt.

Делали так изначально. Путались все, включая разработчиков и авторов.

Думаю, тут вопрос больше понятий и терминологии. Назвали параметр, например, editable - сразу путаться бы перестали :slight_smile:

Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.

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

Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.

Стараюсь функцию whenChanged вообще не использовать (только как событие, того, что какой то контрол или уставки в интерфейсе изменили). Изменение значений с датчиков отслеживаю переодическим опросом. Так сказать - топор в бою надежней.

Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.

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

На “переходной” период для чтения “readonly” можно вообще использовать trackMqtt.

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

И все же - почему в новом движке wb-rules “whenChanged” не реагирует на топики c /on на конце, если,

  • они опубликованные из сторонних программ
  • в вирт устройстве не выставлен флаг readonly: false

Но при этом, устройства созданные, например, wb-mqtt-serial визуально не имеют флага readonly: false - но они обрабатываются событием “whenChanged”

В чем логика?
Зачем создана такая путаница и “дискриминация” сторонних программ?

1 Like

Так из bash через mosquitto_pub реагирует же!

Только контролы типа “switch” и “range” по умолчанию активны для изменения в виртуальном устройстве. Для остальных нужно указывать опцию readonly: false. По историческим причинам.

Только если в вирт. устройстве задано - readonly: false

В то время, как устройства созданные через wb-mqtt-serial реагируют на события WhenChnged даже без этой опции (в мета опциях readonly 0 отсутствует или даже напротив - устанвлена 1 “…/meta/readonly 1” )

Только контролы типа “switch” и “range” по умолчанию активны для изменения в виртуальном устройстве. Для остальных нужно указывать опцию readonly: false. По историческим причинам.

Вообще-то, wb-rules ver 1.7.1 реагирует на публикацию значений и величин в топиках …/on без всяких опций readonly: false. О каких исторических причинах идет речь?