Добрый день! WB Rules как то не совсем понятно почему не присваивает команды.
Например есть скрипт, который сначала wb-mdm3_159/Channel 1 присваивает значение 32, а после изменяет на значения 2.
При этом происходит просто присваивание значения 2.
defineRule(‘show_input’, {
whenChanged: ‘WBVirtualPressButt/btnStartStop’,
then: function (){
dev[‘wb-mdm3_159/Channel 1’]=32;
dev[‘wb-mdm3_159/Channel 1’]=2;
}
}
)
Добрый день!
Чтобы лучше разобраться сделайте логирование результата каждого присваивания в отладочную консоль.
У вас без задержек (сразу друг за другом с интервалом с миллисекунды) в устройство пишутся два значения. Т.е. в устройство отправляете 32 и тут же следом отправляете 2.
Соответственно, вы видите последнее присвоенное значение - 2, что логично.
defineRule(‘show_input’, {
whenChanged: ‘WBVirtualPressButt/btnStartStop’,
then: function (){
// dev[‘wb-mdm3_159/K1’] = false;
debug(dev['wb-mdm3_159/Channel 1'])
dev['wb-mdm3_159/Channel 1']=32;
debug(dev['wb-mdm3_159/Channel 1'])
dev['wb-mdm3_159/Channel 1']=2;
debug(dev['wb-mdm3_159/Channel 1'])
}
}
)
Строка выводит . Начальное значение было выставлено как 100
выше по тексту
Не понимаю смысл вашего скрипта.
Сделайте задержку между командами присваиваниями и будете видеть изменение переменной.
Скрипт сделан от балды , на самом деле 
Просто я хотел сделать свет плавно загорающимся и плавно затухающимся. Однако это сделать не удалось . А удалось только повесить систему с помощью цикла while. Поэтому я начал смотреть почему у меня значения не изменяются адекватно и это меня и провело к Вам.
Последовательность действий в системе будет такая:
dev['wb-mdm3_159/Channel 1']=32;ПОСЛЕ этого чтение топика /device/wb-mdm3_159/value/Channel 1 вернет вам последнее известное (но не факт, что текущее) значение. До этого, топик /device/wb-mdm3_159/value/Channel 1 будет содержать “последнее известное” (в вашем случае, скорее всего “100” ) значение.
между всеми этим событиями есть разнообразные временные интервалы (очереди, опросы устрйств на шинах и пр)).
Т.е. изменения (прохождение команд) происходят не мгновенно.
Обратите внимание, что
dev['wb-mdm3_159/Channel 1']=32 - пишет 32 в один топик ( /device/wb-mdm3_159/value/Channel 1 /on ) - запрос на изменение регистра, а
var x = dev['wb-mdm3_159/Channel 1]` - читает из другого топика ( /device/wb-mdm3_159/value/Channel 1) - последняя известная публикация результата
Для этого же предусмотрена встроенная функция “Плавность диммирования” в самом WB-MDM3.
Если выполнять такой алгоритм с помощью правил, то это займет много ресурсов и может вообще работать нестабильно.
Немного неверно. Можно хоть с промежутком в 10мкс публиковать новые значения в топик /on. Драйвер wb-mqtt-serial их запишет в свою очередь и будет отправлять в шину. фактически непрерывно. Цикл опроса значений из устройства к записи новых имеет весьма опосредованное отношение.
То есть между чтением регистра в него можно успеть записать и десяток разных новых значений.
Да, по сути я приблизительно это и пытался донести (возможно не совсем корректно). Существует временной лаг между “записью в правилах” и получением результирующего ответа на эту запись в соответствующий топик.
В контексте текущей темы, строчки в wb rules следующие друг за другом без задержки
dev['wb-mdm3_159/Channel 1']=32;
debug(dev['wb-mdm3_159/Channel 1'])
вернут в лог “нестабильный” (недостоверный, ибо в ответе могут быть предыдущие и пред-предыдущие и пред-пред-предыдущие… опубликованные состояния устройства) из-за временного лага фактического исполнения команды .
Совершенно верно. То есть в топике - то что было прочитано при последнем чтении.
То есть “записать новое в регистр” и “прочитать текущее из регистра” - оно не зависят друг от друга и выполняются почти асинхронно, но в одной очереди.