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

intrapro

Верните, пожалуйста, для "Объекты", "Уровни", "Зоны" ID - можно не столбец вернуть, а строку ID в настройках, как сейчас отображается у подсистем.

Вернули в новом релизе 4.5.x

@Alex_Jet:

А не планируете ввести новый класс устройств "Plugin" — плагины для стыковки с оборудованием? Чтобы можно было какие-нибудь мультисценарии написать для работы с плагинами?

В принципе, новый класс тут не нужен. Индикатор плагина - это обычный дискретный датчик (SensorD), просто создается автоматически и имеет ID специального вида: UNIT <id плагина="">Индикаторы плагинов были скрыты искусственно в списках дискретных датчиков. Сейчас (в новом релизе 4.5.x) они доступны в списках мультисценариев "Запуск для устройств"</id>

Alex_Jet

@intrapro:

Вернули в новом релизе 4.5.x

Проверил. Я бы скрыл столбец, но в настройках зоны/уровня/объекта оставил бы ID в первом не редактируемом поле. И то же для устройств (удобно было бы копировать ID устройств и вставлять в сценарии)!
@intrapro:

В принципе, новый класс тут не нужен. Индикатор плагина - это обычный дискретный датчик (SensorD), просто создается автоматически и имеет ID специального вида: UNIT <id плагина="">Индикаторы плагинов были скрыты искусственно в списках дискретных датчиков. Сейчас (в новом релизе 4.5.x) они доступны в списках мультисценариев "Запуск для устройств"</id>

Согласен. Сделал мультисценарий, выбрать устройства плагинов можно, все работает. Жаль, что пока нет кодов ошибок для плагинов.

Еще интересный момент. Сделал мультисценарий для отправки сообщений в Telegram/журнал от датчиков, по которым в системе установилась ошибка:

/** 
* @name Уведомление в Telegram об ошибке датчика
* @desc Уведомление пользователя по Telegram об ошибке датчика 
* @version 4 
*/

const sensor = Device("SensorA","Датчик"); 

startOnChange(sensor); 

script({
    start() {
      if(this.isChanged(sensor, "err")) {
        if(sensor.isError()) {
          this.info("telegram", "OWNER", "Внимание! '" +sensor.name+ "' - ошибка: " +sensor.error+ ". Значение: " +sensor.value);
          this.log("Внимание! '" +sensor.name+ "' - ошибка: " +sensor.error+ ". Значение: " +sensor.value);
        }
        else {
          this.info("telegram", "OWNER", "'" +sensor.name+ "' - ОК. Значение: " +sensor.value);
          this.log("'" +sensor.name+ "' - ОК. Значение: " +sensor.value);
        }
      }
    } 
});

Когда возникает ошибка датчика, например выход значения датчика за верхний предел (в моем случае для DS18B20 - значение 130.00), то в сообщении Телеграм/журнале значение датчика имеет предыдущее значение и как итог - пользователю не понятно что произошло. Я так понимаю, что "бракованное" значение специально откидывается и не пишется в БД, но в журнале устройства же оно появляется! Как его можно отобразить в сообщении Телеграм/журнале чтобы пользователю было понятно что именно произошло? Ну или, как вариант, сделать описание кодов ошибок.

Хотя вообще я жду расширенного функционала для плагина MegaD - функции обработки данных с изменяемым периодом опроса (например, 5 измерений подряд, отброс бракованных и усерднение оставшихся). Хотя сейчас только пришла мысль, по идее можно в функции проверять - если значение больше 100, то сделать еще один запрос?

homa

Если комментировать строку startonchange, то получаем ошибку при сохранении. Появилась давно, не с последним обновлением, но руки не доходили написать.

filippovsky

Скажите, пожалуйста, как можно привязать запуск сценария к моменту запуска сервера?

Условный пример:

Есть дискретный актуатор "Солнце".

По расписанию "На рассвете" оно включается.

По расписанию "На закате" оно выключается.

Но если сервер включен между этими событиями посреди дня - то Солнце будет выключено, пока не наступит ближайший рассвет.

Можно написать сценарий, в котором явно установить состояние Солнца в зависимости от текущего времени, времени рассвета и заката.

Но как заставить этот сценарий запуститься в момент запуска сервера, чтобы инициализировать Солнце?

intrapro

@filippovsky:

Скажите, пожалуйста, как можно привязать запуск сценария к моменту запуска сервера?

Условный пример:

Есть дискретный актуатор "Солнце".

По расписанию "На рассвете" оно включается.

По расписанию "На закате" оно выключается.

Но если сервер включен между этими событиями посреди дня - то Солнце будет выключено, пока не наступит ближайший рассвет.

Можно написать сценарий, в котором явно установить состояние Солнца в зависимости от текущего времени, времени рассвета и заката.

Но как заставить этот сценарий запуститься в момент запуска сервера, чтобы инициализировать Солнце?

Нужно в сценарий включить функцию boot, которая должна вернуть результат true, чтобы сценарий запустился при старте сервера. Выполнение, как обычно, начнется с функции start()

boot() {
    return true; // Всегда запускать при старте сервера
},

start() {
   //  
}

Эта возможность не документирована. Возможно, синтаксис изменится при доработке API сценариев.

filippovsky

@intrapro:

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

Эта возможность не документирована. Возможно, синтаксис изменится при доработке API сценариев.

Спасибо большое

filippovsky

Можно попросить добавить в окно отладчика сценариев кнопку "Пробный запуск сценария"?

Сейчас "Пробный запуск" можно сделать из меню по кнопке в верхней части экрана, но при открытом отладчике эта кнопка становится disabled.

В итоге невозможно сделать РУЧНОЙ пробный запуск сценария с просмотром в отладчике.

Alex_Jet

@filippovsky:

Можно попросить добавить в окно отладчика сценариев кнопку "Пробный запуск сценария"?

Сейчас "Пробный запуск" можно сделать из меню по кнопке в верхней части экрана, но при открытом отладчике эта кнопка становится disabled.

В итоге невозможно сделать РУЧНОЙ пробный запуск сценария с просмотром в отладчике.

Тоже соглашусь с этим. Очень неудобно держать открытыми 4-5 (2 для сценариев, 2 для плагинов и 1 для изменения разных настроек) окон PM для отладки!

Кстати, по поводу:

1. Реализации "cron" для сценариев (запуск сценариев для проверки состояния устройств)

2. Доступности из сценариев "журнал устройств" (для принудительного запуска насосов/котлов/кранов/клапанов если их период простоя велик)

3. Доступности из сценариев данных по устройству из БД (для составления и отправки месячной сводки в управляющие компании)

4. Доступности из сценариев пользовательских журналов (создавать журналы можно, но писать в них логи пока никак)

Какие-нибудь комментарии будут? Даже не комментарии, а возможная реализация и ее примерный срок.

По столбцам ID у объектов/зон/систем/устройств уже сообщал свое пожелание выше… хотя тут обнаружил, что система теперь запоминает расположение столбцов. То есть если столбцы перенести как нужно администратору системы, то они в таком виде и останутся при следующим заходе в pm?

artem521

Доброго времени суток. Помогите пожалуйста сообразить сценарий. Смысл такой: Имеются 2 датчика E18-D80NK которые будут вести подсчет людей зашедших/вышедших из комнаты. Допустим зашло 2 человека, один человек вышел- свет горит, вышел второй человек- свет погас. Также дополнить все это дело датчиком освещенности, что это все работает с условием что если допустим выше 200 lux свет не горит, 100 lux горит.

intrapro

@filippovsky:

Можно попросить добавить в окно отладчика сценариев кнопку "Пробный запуск сценария"?

Сейчас "Пробный запуск" можно сделать из меню по кнопке в верхней части экрана, но при открытом отладчике эта кнопка становится disabled.

В итоге невозможно сделать РУЧНОЙ пробный запуск сценария с просмотром в отладчике.

Да, Вы правы, постараемся добавить в одной из ближайших версий

intrapro

@Alex_Jet:

Кстати, по поводу:

1. Реализации "cron" для сценариев (запуск сценариев для проверки состояния устройств)

Будет в конце месяца для простых и мультисценариев (пока без блок-схем)

@Alex_Jet:

2. Доступности из сценариев "журнал устройств" (для принудительного запуска насосов/котлов/кранов/клапанов если их период простоя велик)

Эта возможность уже добавлена в последней версии 4.5.3 как функция устройства device.getLog(<count>)

Опциональный параметр count - количество записей.

Возвращаются последние записи по возрастанию времени в виде массива с полями: значение, флаг ошибки, метка времени

{val:"23.5", err:0, ts:1554076800000}

Получить последние 10 записей:

const logArr = dn.getLog(10);
logArr.forEach(item => {
         this.log(JSON.stringify(item));
});

@Alex_Jet:

4. Доступности из сценариев пользовательских журналов (создавать журналы можно, но писать в них логи пока никак)

Концепция журналов будет пересматриваться, пока по срокам не ясно

@Alex_Jet:

По столбцам ID у объектов/зон/систем/устройств уже сообщал свое пожелание выше… хотя тут обнаружил, что система теперь запоминает расположение столбцов. То есть если столбцы перенести как нужно администратору системы, то они в таком виде и останутся при следующим заходе в pm?

Да, это работает довольно давно.

Запоминаются ширина и порядок столбцов. Настройки хранятся на сервере, для нового сеанса всегда используется последняя настройка.</count>

intrapro

@Alex_Jet:

3. Доступности из сценариев данных по устройству из БД (для составления и отправки месячной сводки в управляющие компании)

Эта возможность добавлена в последней версии 4.5.3 в тестовом режиме.

this.dbread({table:'consumption',dn:'METER1,METER2', start:'2019-04-01', end:'2019-04-01 23:59'}, 'onReady');

Здесь результат сразу не возвращается, так как чтение происходит асинхронно. При получении данных будет вызвана функция сценария (здесь она называется onReady), в которой данные нужно обработать.

onReady(result) {
  this.log('Получено записей: '+result.length);
   result.forEach(item => {
         this.log(JSON.stringify(item));
   });
}

Первый аргумент this.dbread - объект, содержащий критерии отбора данных:
<list>* table - имя таблицы. Показания счетчиков хранятся в таблице consumption

dn: ID устройства или список через запятую

start: метка времени или строка, определяющая начало диапазона

end: метка времени или строка, определяющая конец диапазона</list>

То есть можно задавать временные точки по разному

  start:1554076800000 // timestamp
  start:Date.now()-3600000 // timestamp
  start:'2019-04-01'   // string дата 0 часов
  start:'2019-04-01 22:00' // string дата время

Данные возвращаются в массиве, каждая запись содержит метку времени, ID устройства, значение:

03.04 18:16:00.910 log: {"id":723,"ts":1554289199000,"dn":"METER1","val":"970.8578"}

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

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

И почему бы не получить данные за год и посчитать что-нибудь этакое средневзвешенное…

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

Планируется в мае выпустить версию и опубликовать новое API плагинов.

Цель - дать возможность пользователям разрабатывать свои плагины для решения прикладных задач, когда функционала сценариев недостаточно. Есть также идея делать это интерактивно, по аналогии со сценариями, чтобы порог вхождения был пониже.

Alex_Jet

Ну прям все круто! "Respect и уважуха" к вашей компании! И просто спасибо:)

IntraVM

@sergeyygr:

Показания нужно передавать 17 числа каждого месяца. Как сформировать отчёт и выслать в УК?

Не понятно. Про какой отчет идет речь?

Нужно ведь отправлять показания счетчиков?

IntraVM

@Alex_Jet:

Ну прям все круто! "Respect и уважуха" к вашей компании! И просто спасибо:)

@sergeyygr:

Присоединяюсь! Тоже с восхищением отношусь к вашей работе и мгновенной обратной связи!

Коллеги, большое спасибо!

Ваша поддержка придает уверенность и силы в дальнейшей работе

IntraVM

На сайте в блоге опубликовали статью по отправке показаний счетчиков https://ih-systems.com/ru/send_meter/

Надеюсь, будет полезна.

Alex_Jet

@sergeyygr:

Спасибо! Все отлично работает! Только в показаниях счетчиков электроэнергии, после запятой, число длинной с… километр :lol: А в настройках стоит 2 знака.

Надо использовать функции js:

const meter = Device("METER1_01");

script({
    start() {
      //Сводка по газу
      let account = xxxxxx;
      let name = meter.name;
      let value = meter.value.toFixed(0);

      this.info("email", "GAS_SERVICE", account+ "*" +value);
      this.info("telegram", "OWNER", "Текущее показание '"+name+ "' - " +value+ " куб.м");

    }
});

Alex_Jet

Интересный вопрос - если нужно временно отключить выполнение скрипта по расписанию, то как это можно сделать? Если убрать все дни недели, то он запуститься в уже назначенное время? Предусмотрите, пожалуйста, возможность блокировки задания в расписании. Конечно кто-то скажет что можно удалить и т.д., но если это надо временно, то почему бы не иметь возможность просто блокировать выполнение?

То же, например, с блокировкой мультисценариев и блокировкой канала плагина Ping.

IntraVM

Вопрос правильный. Надо сделать.

Alex_Jet

@intrahouse:

Вопрос правильный. Надо сделать.

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