Сценарии - новая версия API

[IntraVM]

Исправили. Можно обновить - 4.6.2

[Alex_Jet]

Коллеги! Подскажите когда примерно ждать реализации двух моментов:

1. Возможность временного отключения задачи по расписанию

2. Передача дополнительных параметров в сценарий при настройке задачи по расписанию.

[gis]

Вопрос к разработчикам: почему не появилось в интерфейсе на закладке "Параметры" для устройства VOLL_ALL дополнительное свойство "Пониженная громкость"? Устройство VOLL_ALL работает через плагин http без обратной связи.

* @name Оповещение о входной двери 
* @desc Оповещение об открытой входной двери 
* @version 4  
*/

const SGERK_M1_P0 = Device("SGERK_M1_P0");
const VOLL = Device("VOLL_ALL", "Общая громкость", [
{"name":"VOLDOWN", "note":"Пониженная громкость",  "type":"number", "val":5},
  ]); 

startOnChange([SGERK_M1_P0]);
script({
  start() { 
     require("http").get(`http://192.168.0.43/mp3play?cmd=6&data=${VOLL.getParam("VOLDOWN")}`);
     this.startTimer("T1",1,"onTimerT1");
  },
  onTimerT1() { 
    require("http").get(`http://192.168.0.43/mp3playqueue?data=100,0,300,0,301,1002,300,0,301` );
  }
})

Просьба пояснить механизм назначения дополните свойств, сценарием. Можно ли назначать эти свойства с использованием графического редактора сценариев? Также интересует типы дополнительных свойств (можно ли вводить время, дату)? Просьба привести примеры.

[Alex_Jet]

@gis:

Вопрос к разработчикам: почему не появилось в интерфейсе на закладке "Параметры" для устройства VOLL_ALL дополнительное свойство "Пониженная громкость"? Устройство VOLL_ALL работает через плагин http без обратной связи.

> * @name Оповещение о входной двери 
> * @desc Оповещение об открытой входной двери 
> * @version 4  
> */
> 
> const SGERK_M1_P0 = Device("SGERK_M1_P0");
> const VOLL = Device("VOLL_ALL", "Общая громкость", [
> {"name":"VOLDOWN", "note":"Пониженная громкость",  "type":"number", "val":5},
>   ]); 
> 
> startOnChange([SGERK_M1_P0]);
> script({
>   start() { 
>      require("http").get(`http://192.168.0.43/mp3play?cmd=6&data=${VOLL.getParam("VOLDOWN")}`);
>      this.startTimer("T1",1,"onTimerT1");
>   },
>   onTimerT1() { 
>     require("http").get(`http://192.168.0.43/mp3playqueue?data=100,0,300,0,301,1002,300,0,301` );
>   }
> })
> 

Просьба пояснить механизм назначения дополните свойств, сценарием. Можно ли назначать эти свойства с использованием графического редактора сценариев? Также интересует типы дополнительных свойств (можно ли вводить время, дату)? Просьба привести примеры.

Где-то в этом месте рассказывали:

1. https://frm.intrahouse.ru/viewtopic.php?f=18&t=5375&hilit=свойства&start=150#p9381

2. https://frm.intrahouse.ru/viewtopic.php?f=18&t=5375&p=9478&hilit=свойства#p9478

[intrapro]

@Alex_Jet:

Коллеги! Подскажите когда примерно ждать реализации двух моментов:

1. Возможность временного отключения задачи по расписанию

2. Передача дополнительных параметров в сценарий при настройке задачи по расписанию.

Задачи небольшие, постараемся сделать в течение мая.

[intrapro]

@gis:

Вопрос к разработчикам: почему не появилось в интерфейсе на закладке "Параметры" для устройства VOLL_ALL дополнительное свойство "Пониженная громкость"? Устройство VOLL_ALL работает через плагин http без обратной связи.

> const VOLL = Device("VOLL_ALL", "Общая громкость", [
> {"name":"VOLDOWN", "note":"Пониженная громкость",  "type":"number", "val":5},
>   ]); 
> 
> 

Добрый день.

В конце массива запятая не нужна. Движок не смог распарсить JSON, поэтому дополнительное свойство не появилось.

[{"name":"VOLDOWN", "note":"Пониженная громкость", "type":"number", "val":5} [color=#FF0000]<size size="150">,</size>]);

Можно назначать дополнительные свойства через сценарии любым устройствам, привязка к каналам значения не имеет.

@gis:

Просьба пояснить механизм назначения дополните свойств, сценарием. Можно ли назначать эти свойства с использованием графического редактора сценариев?

Если в каком-то сценарии объявить доп. свойство устройству, это свойство можно использовать в любых сценариях, в том числе в блок-схемах, используя Операции-> "блок DP" (свойства устройства) для сравнения или команду "Присваивание значения".

Объявить новое свойство через блок-схему нельзя.

@gis:

Также интересует типы дополнительных свойств (можно ли вводить время, дату)? Просьба привести примеры.

Пока реализовано только три типа для ввода: number, cb (checkbox) и time. Любой другой тип, включая string, выводится в Параметрах как readOnly string.

checkbox - это галочка, значения true/false, можно 0/1

 {"name":"myFalg", "note":"Использовать  ...", "type":"cb", "val":0}

time используется для ввода временных интервалов. Значение будет в секундах, просто для ввода используется специальный компонент, позволяющий ввести Час-Мин-Сек.

 {"name":"waitTime", "note":"Время таймера ожидания", "type":"time", "val":10}

Дату, время как временную точку пока интерактивно вводить нельзя.

Но в сценарии для хранения timestamp Вы можете использовать тип number.

В этом случае параметр редактировать вручную вряд ли кто-то будет, поэтому его лучше скрыть ( "hide":1)

 {"name":"lastTime", "note":"Время последней фиксации ..", "type":"number", "val":0, "hide":1 }

В коде сценария:

  if (!myActor.getParam("lastTime")) {
  	myActor.getParam("lastTime") = Date.now();
  } else  if (Date.now() - myActor.getParam("lastTime") > 10000)  {
     .....
  }

[Alex_Jet]

Коллеги! Сегодня перенастроил задачи по расписанию - с закат+х и рассвет-х поставил статическое время. Уже сутки все сценарии выполняются по два раза подряд! Систему перезагружал вчера при обновлении.

[intrapro]

@Alex_Jet:

Коллеги! Сегодня перенастроил задачи по расписанию - с закат+х и рассвет-х поставил статическое время. Уже сутки все сценарии выполняются по два раза подряд! Систему перезагружал вчера при обновлении.

Добрый день.

То есть это происходит после изменения пунктов расписания? Пока у себя не смогли воспроизвести. Но будем искать

Попробуйте сервер перезагрузить.

[Alex_Jet]

@intrapro:

@Alex_Jet:

Коллеги! Сегодня перенастроил задачи по расписанию - с закат+х и рассвет-х поставил статическое время. Уже сутки все сценарии выполняются по два раза подряд! Систему перезагружал вчера при обновлении.

Добрый день.

То есть это происходит после изменения пунктов расписания? Пока у себя не смогли воспроизвести. Но будем искать

Попробуйте сервер перезагрузить.

Как будто - да! Сегодня обновил систему с перезагрузкой. Понаблюдаю. Двое суток утром и вечером сценарии запускались по два раза подряд.

Update: понаблюдал - в общем после перезагрузки iH задачи по расписанию, которые ранее изменялись, отрабатывают нормально!!!

[intrapro]

@Alex_Jet:

Как будто - да! Сегодня обновил систему с перезагрузкой. Понаблюдаю. Двое суток утром и вечером сценарии запускались по два раза подряд.

Update: понаблюдал - в общем после перезагрузки iH задачи по расписанию, которые ранее изменялись, отрабатывают нормально!!!

Спасибо, теперь знаем где рыть

[intrapro]

@sergeyygr:

Добрый день. Сейчас в графическом редакторе сценариев не наблюдаю выбор режима "mode" (trigger или state) для датчиков и актуаторов. По умолчанию все триггерами назначаются. Как режим сейчас задать?

Добрый день!

Да, действительно, сейчас для этого используется блок DP "Свойство устройства" на вкладке "Операции".

Нужно задать устройство и свойство из выпадающего списка. Таким образом есть возможность выбора любых свойств,в том числе дополнительных.

В результате появляется желтый блок со свойством. Например, на этой блок-схеме Датчик температуры не является триггером:

[Alex_Jet]

Подскажите, у меня в старой версии сценария рассчитывались уставки и проверялось условие перехода в start() таким образом:

    ust_min: 0,
    ust_max: 0,
    text: "",

    check() {
      //Определение уставок
      this.ust_min = dt.defval - heater.hist;
      this.ust_max = dt.defval + heater.hist/2;
      //Проверка основных условий
      return heater.auto && ( !heater.dval&&(dt.aval <= this.ust_min)&&(dt_ext.aval < dt_ext.defval) || heater.dval&&(dt.aval >= this.ust_max) );
    },

Хочу переписать под новую версию сценариев и есть два вопроса:

1. Как рассчитывать уставки и определять их, используя StartOnChange?

2. Хочу добавить проверку работоспособности основного датчика и если по нему фиксируется авария, то переключаться на другой. Сейчас в одном из сценариев у меня сделано так:

      let sensor_ext = '';

      //Проверка работоспособности датчика уличной температуры
      //При его неисправности - работаем по резервному датчику
      if(!dt_ext.isError()) {
        sensor_ext = dt_ext;
      }
      else {
        sensor_ext = dt_ext_rez;
        this.log("Датчик '" +dt_ext.name+ "' неисправен!");
      }

По идее sensor_ext должен участвовать в StartOnChange вместо dt_ext (см.код выше). Как это все вместе записать, опять же используя StartOnChange? Ну или ваш вариант.

[intrapro]

@sergeyygr:

В свойствах property есть значение, состояние, ошибка. Уставка (как в примере) не отображается.

А какое у Вас устройство?

Уставка есть только у аналоговых устройств, причем в настройке устройства должна стоять галочка "Есть уставка (дефолтное значение)"

[intrapro]

@sergeyygr:

Понятно теперь. У меня счетчик, хочу написать сценарий отключения клапана воды по достижению на счетчике установленного значения, потом у счетчика должны обнулиться показания и так каждый цикл работы сценария. Лучше конечно, что бы был обратный отсчет 100,99,98…0 литров. Может подскажете как реализовать?

Порог можно добавить сценарием как дополнительное свойство, оно в списке появится. А насчет обратного отсчета - не совсем понятно

[intrapro]

@sergeyygr:

@intrapro:

@sergeyygr:

Понятно теперь. У меня счетчик, хочу написать сценарий отключения клапана воды по достижению на счетчике установленного значения, потом у счетчика должны обнулиться показания и так каждый цикл работы сценария. Лучше конечно, что бы был обратный отсчет 100,99,98…0 литров. Может подскажете как реализовать?

Порог можно добавить сценарием как дополнительное свойство, оно в списке появится. А насчет обратного отсчета - не совсем понятно

По поводу обратного отсчета. Допустим задан порог 100 литров. В иконке 100 литров, когда началось потребление значение пошло на уменьшение, дошло до 0, клапан закрылся. Но это наверное лишнее

То есть счетчик считает в обе стороны ? Или их два?

[homa]

@sergeyygr:

@intrapro:

@sergeyygr:

По поводу обратного отсчета. Допустим задан порог 100 литров. В иконке 100 литров, когда началось потребление значение пошло на уменьшение, дошло до 0, клапан закрылся. Но это наверное лишнее

То есть счетчик считает в обе стороны ? Или их два?

Счётчик один, режим реверсивного отсчёта.

Создайте второй виртуальный счетчик, и сценарий meter2=100-meter1 когда достигает нуля, обнуляем первый и присваиваем 100 второму

[Alex_Jet]

Коллеги! Всех с праздником Великой победы!

Intrapro, intrahouse, помогите разобраться как правильно использовать startOnChange в качестве функции с расчетом уставок и проверкой разных значений. Мой предыдущий пост тут - https://frm.intrahouse.ru/viewtopic.php?f=18&t=5446&start=270#p10166

[dev]

@Alex_Jet:

Коллеги! Всех с праздником Великой победы!

Intrapro, intrahouse, помогите разобраться как правильно использовать startOnChange в качестве функции с расчетом уставок и проверкой разных значений. Мой предыдущий пост тут - https://frm.intrahouse.ru/viewtopic.php?f=18&t=5446&start=270#p10166

Добрый день, попробуйте использовать блочные сценарии там все просто и понятно

startOnChange([], условное выражение)

Первый параметр — устройство или массив устройств из тех, что были объявлены как Device

Второй параметр — опциональное условное выражение, которое проверяется до того как сценарий запустится

Если триггеры не объявлены (startOnChange отсутствует) — сценарий по событиям запускаться не будет.

script ({
  sensor_ext: "",
  start() {
    if(!dt_ext.isError()) {
        this.sensor_ext = dt_ext;
      }
      else {
        this.sensor_ext = dt_ext_rez;
        this.log("Датчик '" +dt_ext.name+ "' неисправен!");
      }
  },
)

[intrapro]

@Alex_Jet:

Подскажите, у меня в старой версии сценария рассчитывались уставки и проверялось условие перехода в start() таким образом:

>     
>     ust_min: 0,
>     ust_max: 0,
>     text: "",
> 
>     check() {
>       //Определение уставок
>       this.ust_min = dt.defval - heater.hist;
>       this.ust_max = dt.defval + heater.hist/2;
>       //Проверка основных условий
>       return heater.auto && ( !heater.dval&&(dt.aval <= this.ust_min)&&(dt_ext.aval < dt_ext.defval) || heater.dval&&(dt.aval >= this.ust_max) );
>     },
> 

Хочу переписать под новую версию сценариев и есть два вопроса:

1. Как рассчитывать уставки и определять их, используя StartOnChange?

2. Хочу добавить проверку работоспособности основного датчика и если по нему фиксируется авария, то переключаться на другой. Сейчас в одном из сценариев у меня сделано так:

>       let sensor_ext = '';
>       
>       //Проверка работоспособности датчика уличной температуры
>       //При его неисправности - работаем по резервному датчику
>       if(!dt_ext.isError()) {
>         sensor_ext = dt_ext;
>       }
>       else {
>         sensor_ext = dt_ext_rez;
>         this.log("Датчик '" +dt_ext.name+ "' неисправен!");
>       }
> 

По идее sensor_ext должен участвовать в StartOnChange вместо dt_ext (см.код выше). Как это все вместе записать, опять же используя StartOnChange? Ну или ваш вариант.

Добрый день!

По поводу startOnChange и check(). На самом деле check продолжает работать в новой версии

То есть проверять условие на входе можно двумя способами:

1. Можно добавить как второй аргумент в startOnChange.

2. Можно определить функцию check, и если она вернет false, сценарий также не запустится.

Нельзя использовать оба варианта одновременно, первый является основным.

Эти сценарии работают одинаково:

Используем условное выражение в startOnChange

const lamp = Device("LAMP1"); 
startOnChange(lamp, lamp.auto); 
script({
    start() {
        this.log('Сценарий запущен!');
        // ....
    } 
});

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

const lamp = Device("LAMP1"); 
startOnChange(lamp); 
script({
    check() {
        return lamp.auto;
    }, 

    start() {
        this.log('Сценарий запущен!');
        // ....
    } 
});

Главное отличие: в предыдущей версии устройства-триггеры неявно извлекались из функции check.

Теперь их нужно прописать явно в startOnChange. Как написал dev в предыдущем сообщении, если нет startOnChange -сценарий по событиям запускаться не будет.

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

const lamp = Device("LAMP1"); 

script({
    check() {
        return lamp.auto;
    }, 

    start() {
        this.log('Сценарий запущен!');
        // ....
    } 
});

То есть Вам достаточно объявить триггеры в startOnChange([dev1, dev2,…]) А check оставить как есть

К сожалению, в документации это толком не прописано. Исправим это упущение

[Anatol]

Прошу помощи: есть zigbee кнопка, работает по mqtt, как датчик аналоговый, при одиночном нажатии приходит значение "single". Как сделать сценарий чтобы при нажатии выполнялась команда toggle().

const SENSORA2_1 = Device("SENSORA2_1");

const SOCKET1_2 = Device("SOCKET1_2");

startOnChange([SENSORA2_1])

script({

start() {

if (SENSORA2_1.value == "single") {

SOCKET1_2.toggle();

}

}

});

При таком варианте срабатывает только один раз ,так как каждый раз при нажатии проходит одно и тоже значение и тригер не срабатывает :

12.05 23:47:56.860 IH: set {"SENSORA2_1":{"aval":"single","err":0}}

12.05 23:47:58.525 IH: set {"SENSORA2_1":{"aval":"single","err":0}}

12.05 23:48:00.521 IH: set {"SENSORA2_1":{"aval":"single","err":0}}