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



  • Проблему уже заметили. Через час будет обновление.



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



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

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

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



  • Вопрос к разработчикам: почему не появилось в интерфейсе на закладке "Параметры" для устройства 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` );
      }
    })
    
    

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



  • @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



  • @Alex_Jet:

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

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

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

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



  • @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:

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

    Добрый день.

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

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

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

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



  • @Alex_Jet:

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

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

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



  • @sergeyygr:

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

    Добрый день!

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

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

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



  • Подскажите, у меня в старой версии сценария рассчитывались уставки и проверялось условие перехода в 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? Ну или ваш вариант.



  • @sergeyygr:

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

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

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

    devSetpoint.png



  • @sergeyygr:

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

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



  • @sergeyygr:

    @intrapro:

    @sergeyygr:

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

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

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

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



  • @sergeyygr:

    @intrapro:

    @sergeyygr:

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

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

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

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



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

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



  • @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+ "' неисправен!");
          }
      },
    )
    
    
    


  • @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 оставить как есть

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


Авторизуйтесь, чтобы ответить