А что должно обработать топик “on” для виртуального устройства?
Используйте
mosquitto_pub -t '/devices/testdevice/controls/testcontrol' -r -m 0
mosquitto_pub -t '/devices/testdevice/controls/testcontrol' -r -m 1
А что должно обработать топик “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"); // Прихожая теплый пол
коды символов
СW99
перепишите вручную или скопируйте из места, где обращаетесь к функции
Имею в виду что первый символ, “C” у вас странной кодировки
Во истину странно!
Переписал, заработало. Спасибо!
Русскую “С” от английской “C” на вид довольно сложно отличить, сам так попадался.
Предпринял новую попытку обновить wb-rules c 1.7.1 на 2.6.3 на «боевом» контроллере. Опять - неудача:
Первое
На этом контроллере кроме штатных сервисов Wiren работают дополнительные сервисы:
Всё это взаимодействует через 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
Все возникшие проблемы были описаны в теме ниже
Если кратко
Делали так изначально. Путались все, включая разработчиков и авторов.
Так мне кажется это вполне логичным. Вот пишете вы на wb-rules, например, драйвер внешнего термостата. Температура с его датчика - это параметр с readonly: true, потому что поменять его никак нельзя. Зачем там whenChanged?
Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.
Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.
readonly - это свойство канала, которое показывает, можно ли его менять. Это не управление отображением в веб-интерфейсе.
С точки зрения wb-rules, MQTT и конвенций, веб-интерфейс - это ровно такой же сервис, как и все другие. Поэтому он подчиняется всем тем же правилам. Если кому-то можно менять канал, то и веб-интерфейсу можно.
Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.
На “переходной” период для чтения “readonly” можно вообще использовать trackMqtt.
Делали так изначально. Путались все, включая разработчиков и авторов.
Думаю, тут вопрос больше понятий и терминологии. Назвали параметр, например, editable - сразу путаться бы перестали
Логика в том, что если вы можете поменять значение этого канала снаружи wb-rules (или другого сервиса - держателя соответствующего устройства), то этот канал не readonly.
Склонен подозревать, что вы, вероятно, решили ограничить нагрузку на wb-rules, уменьшив количество отслеживаемых событий.
Ну то есть выглядит так, как будто вы пытаетесь связывать какие-то внутренние компоненты через логику правил, которая для этого не предназначена. Значит, их нужно связать как-то по-другому. Функцию там вызвать, флажок поставить.
Стараюсь функцию whenChanged вообще не использовать (только как событие, того, что какой то контрол или уставки в интерфейсе изменили). Изменение значений с датчиков отслеживаю переодическим опросом. Так сказать - топор в бою надежней.
Я думаю, что решение вашей задачи лежит где-то вокруг настройки виджетов в веб-интерфейсе, чтобы readonly:false каналу можно было отключить возможность задавать в этом виджете данные.
Думаю, это было бы идеальным решением - задавать параметры вывода в настройках виджетов.
На “переходной” период для чтения “readonly” можно вообще использовать trackMqtt.
Вопрос касался перехода работающих скриптов со старой версии движка на новую с меньшими затратами на переделку. Потому, буду пока терпеть такой вид отображения значений. У меня это в основном отображаемые счетчики обратных таймеров для визуализации остатка времени работы исполнительных устройств.
И все же - почему в новом движке wb-rules “whenChanged” не реагирует на топики c /on на конце, если,
Но при этом, устройства созданные, например, wb-mqtt-serial визуально не имеют флага readonly: false - но они обрабатываются событием “whenChanged”
В чем логика?
Зачем создана такая путаница и “дискриминация” сторонних программ?
Так из 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. О каких исторических причинах идет речь?