Сценарии - новая версия 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
-
Коллеги! Подскажите когда примерно ждать реализации двух моментов:
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) { ..... }
-
Коллеги! Сегодня перенастроил задачи по расписанию - с закат+х и рассвет-х поставил статическое время. Уже сутки все сценарии выполняются по два раза подряд! Систему перезагружал вчера при обновлении.
-
Коллеги! Сегодня перенастроил задачи по расписанию - с закат+х и рассвет-х поставил статическое время. Уже сутки все сценарии выполняются по два раза подряд! Систему перезагружал вчера при обновлении.
Добрый день.
То есть это происходит после изменения пунктов расписания? Пока у себя не смогли воспроизвести. Но будем искать
Попробуйте сервер перезагрузить.
-
Коллеги! Сегодня перенастроил задачи по расписанию - с закат+х и рассвет-х поставил статическое время. Уже сутки все сценарии выполняются по два раза подряд! Систему перезагружал вчера при обновлении.
Добрый день.
То есть это происходит после изменения пунктов расписания? Пока у себя не смогли воспроизвести. Но будем искать
Попробуйте сервер перезагрузить.
Как будто - да! Сегодня обновил систему с перезагрузкой. Понаблюдаю. Двое суток утром и вечером сценарии запускались по два раза подряд.
Update: понаблюдал - в общем после перезагрузки iH задачи по расписанию, которые ранее изменялись, отрабатывают нормально!!!
-
Как будто - да! Сегодня обновил систему с перезагрузкой. Понаблюдаю. Двое суток утром и вечером сценарии запускались по два раза подряд.
Update: понаблюдал - в общем после перезагрузки iH задачи по расписанию, которые ранее изменялись, отрабатывают нормально!!!
Спасибо, теперь знаем где рыть
-
Добрый день. Сейчас в графическом редакторе сценариев не наблюдаю выбор режима "mode" (trigger или state) для датчиков и актуаторов. По умолчанию все триггерами назначаются. Как режим сейчас задать?
Добрый день!
Да, действительно, сейчас для этого используется блок DP "Свойство устройства" на вкладке "Операции".
Нужно задать устройство и свойство из выпадающего списка. Таким образом есть возможность выбора любых свойств,в том числе дополнительных.
В результате появляется желтый блок со свойством. Например, на этой блок-схеме Датчик температуры не является триггером:
-
Подскажите, у меня в старой версии сценария рассчитывались уставки и проверялось условие перехода в 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? Ну или ваш вариант.
-
В свойствах property есть значение, состояние, ошибка. Уставка (как в примере) не отображается.
А какое у Вас устройство?
Уставка есть только у аналоговых устройств, причем в настройке устройства должна стоять галочка "Есть уставка (дефолтное значение)"
-
Понятно теперь. У меня счетчик, хочу написать сценарий отключения клапана воды по достижению на счетчике установленного значения, потом у счетчика должны обнулиться показания и так каждый цикл работы сценария. Лучше конечно, что бы был обратный отсчет 100,99,98…0 литров. Может подскажете как реализовать?
Порог можно добавить сценарием как дополнительное свойство, оно в списке появится. А насчет обратного отсчета - не совсем понятно
-
Понятно теперь. У меня счетчик, хочу написать сценарий отключения клапана воды по достижению на счетчике установленного значения, потом у счетчика должны обнулиться показания и так каждый цикл работы сценария. Лучше конечно, что бы был обратный отсчет 100,99,98…0 литров. Может подскажете как реализовать?
Порог можно добавить сценарием как дополнительное свойство, оно в списке появится. А насчет обратного отсчета - не совсем понятно
По поводу обратного отсчета. Допустим задан порог 100 литров. В иконке 100 литров, когда началось потребление значение пошло на уменьшение, дошло до 0, клапан закрылся. Но это наверное лишнее
То есть счетчик считает в обе стороны ? Или их два?
-
По поводу обратного отсчета. Допустим задан порог 100 литров. В иконке 100 литров, когда началось потребление значение пошло на уменьшение, дошло до 0, клапан закрылся. Но это наверное лишнее
То есть счетчик считает в обе стороны ? Или их два?
Счётчик один, режим реверсивного отсчёта.
Создайте второй виртуальный счетчик, и сценарий meter2=100-meter1 когда достигает нуля, обнуляем первый и присваиваем 100 второму
-
Коллеги! Всех с праздником Великой победы!
Intrapro, intrahouse, помогите разобраться как правильно использовать startOnChange в качестве функции с расчетом уставок и проверкой разных значений. Мой предыдущий пост тут - https://frm.intrahouse.ru/viewtopic.php?f=18&t=5446&start=270#p10166
-
Коллеги! Всех с праздником Великой победы!
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+ "' неисправен!"); } }, )
-
Подскажите, у меня в старой версии сценария рассчитывались уставки и проверялось условие перехода в 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 оставить как есть
К сожалению, в документации это толком не прописано. Исправим это упущение