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

Доброго дня.
Используется датчик протечки aqara T1 zigbee
канал water_leak в статусе - false

состояние конвертора zigbee - онлайн

Выставленное значение в заданное значение - 0 (соответствие false) выдает постоянно оповещение о протечке в чат бот телеграмм.
Для примера здесь же создано оповещение по температуре от другого датчика zigbee корректно отрабатывает при значении меньше установленной.
В чем может быть ошибка?

Добрый день.
А какое значение (его тип и само значение) вы сравниваете с числом “0” в условии?

Как понял в значение введено 0, что соответствует false (0), по моей логике, если параметр water leak станет 1 true, то должно сработать оповещение?!
В скриншоте отслеживаемый параметр указан же.

А какое значение именно в топике? Подпишитесь на него и проверьте.
Сравнивать значения разных типов, строку с числом, например - недопустимо.

Если правильно понял ваш вопрос

То значение в топике у этого параметра конечно не числовое, текстовое - false

Если так не работает, то можете пояснить как это применить или доработать в последующих релизах!?

Оптимально, пожалуй - это преобразовать значение в числовой вид, скриптом. Ну или сравнивать тоже со строкой.

Со скриптами “не дружу”, пока еще, учусь.

Попробую еще через сценарии создать виртуальное устройство, запуск звукового сигнала от этого датчика на mwac2 , а от него уже оповещение создать от бота.

Если конечно в доработку возможно взять, было здорово.

Это какой-то весьма сложный путь, зачем?

Что за доработка?

Чтобы работало условие изменения false на true

В графическом интерфейсе WB имеющимися возможностями это не реализовать сейчас получается.

“Скрипт” мне это не понятно сейчас, куда и какой без конкретного примера и отсутствия навыка.

Такое же у меня с заменой показания датчиков с мбар на мм. рт ст., предлагают “да просто же правило написать”, сколько не пытался с ИИ это победить, все мимо пока.

После решений и возможностей SprutHub сложно
Задача от поддерживаемого zigbee датчика протечки получить оповещение в телеграмм и сигнал на имеющийся MWAC v2 (работа со значениями false и true)

Вот это “false” и “true” - строки их, вообще, некорректно сравнивать с нулем и единицей.
Строки надо явно сравнивать со строками, то есть тип сравниваемого значения должен - не может различаться.

Опять повторю, это не значения, это просто строка в которой символами записано. То есть не булево, просто набор байт, складывающихся в строку.
Для примера:

//12_20_test_02.js
function makeNewVirtualControl(vdName, nameControl, typeControl){
  if (getDevice(vdName) === undefined) {
    defineVirtualDevice(vdName, {
      title: vdName,
      cells: {},
    })
  } 
  else{
    log.debug("Устройство "+vdName+" уже есть.")
  }
     //Тут проверим есть ли уже контрол и если нет - создадим.
    if (!getDevice(vdName).isControlExists(nameControl)) {
      log.debug("Контрола "+nameControl+" нет, создаем.")
      getDevice(vdName).addControl(nameControl, typeControl);
    }
    else{
      log.debug("Контрол "+nameControl+" уже есть.")
    }
      
}


//просто источник как строка, для теста
makeNewVirtualControl("test_03_04_02", "forUseAstext", {type: "text", value: "",readonly: false})


makeNewVirtualControl("test_03_04_02", "forUseAsNumber", {type: "value", value: 2, readonly: false})
//Ну и правило
defineRule("test_03_04_02", {
  whenChanged: "test_03_04_02/forUseAstext",
    then: function(value) {
      if (value == "true"){
        dev["test_03_04_02/forUseAsNumber"] = 3;
      }
      else{
        dev["test_03_04_02/forUseAsNumber"] = 0;
      }
    }
})

Если “test_03_04_02/forUseAstext” равно “true” то в “test_03_04_02/forUseAsNumber” публикуется 3.
И именно это значение можно использовать для сравнения.
Ну и использовать штатный сервис уведомлений не слишком (мне) удобно. Можно ведь просто в бот отправить, из того же правила.

Спасибо, за пример, но без понимания чтения правил, не осилить. Если бы был мой рабочий пример, можно было бы от обратного его разобрать и осмыслить как логику, например, конфиги рабочие когда пересматриваю, большая часть текста и стиля json понятна.

Речь хотел все же свести к расширению возможности графического интерфейса разделов WB.
Если вы уже создали частичную возможность использовать, задавать сценарии,оповещения, почему не продолжить и нужные скрипты, алгоритмы расширять и представлять в юзабельном виде для “непрограммистов“, хотя бы самые ходовые, используемые?
Так получается проприетарные решения нужны пока обязательно (SH…)

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

Да, есть примеры, в статье Примеры правил — Wiren Board - первый же.