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

Alex_Jet

Легче вернуть столбцы ID в таблицы. Которые скрыли, чтобы не пугать пользователей

Сейчас можно создать команду в блок-схеме и посмотреть id в скрипте

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

Alex_Jet

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

intrapro

@Alex_Jet:

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

Мы как раз сейчас приступаем к реализации открытого API плагинов и механизмов взаимодействия.

Было бы хорошо, если бы Вы описали, какие задачи хотите решить

Alex_Jet

@intrapro:

Мы как раз сейчас приступаем к реализации открытого API плагинов и механизмов взаимодействия.

Было бы хорошо, если бы Вы описали, какие задачи хотите решить

Меня интересуют перезапуски плагинов и причины их перезапуска. Обратил внимание, что почти все плагины MegaD у меня перезапускаются, а по идее должны работать с момента последнего запуска. Кроме этого, если по какой-то причине оборудование отвалилось от сети (нет доступности, сгорело, пропало питающее напряжение и т.д.), то хотелось бы чтобы по Telegram/SMS/E-mail приходило уведомление администратору системы. Конечно можно использовать плагин ping, создавать для него новые устройства и их добавлять в мультисценарий, но это не комильфо, когда у нас уже есть самостоятельные сущности плагинов в системе.

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

intrapro

@Alex_Jet:

Верните, пожалуйста, для "Объекты", "Уровни", "Зоны" 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 и уважуха" к вашей компании! И просто спасибо:)

sergeyygr

@Alex_Jet:

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

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

sergeyygr

@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 плагинов.

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

Вот бы пример сценария где эти «пазлы» упорядоченно сложены! У меня в голове не укладывается). Есть 4 Счетчика воды, счётчик электроэнергии ( день/ ночь), Показания нужно передавать 17 числа каждого месяца. Как сформировать отчёт и выслать в УК?

IntraVM

@sergeyygr:

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

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

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