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



  • Отлично! Всем спасибо!

    @intrapro:

    Выключить все устройства подсистемы освещения

    > this.doAll({subs:'1'}, ‘off’)
    > 
    > 
    

    На 1 этаже (place 1)

    > this.doAll({place:'1', subs:'1'}, ‘off’)
    > 
    > 
    

    В доме, но не на территории (place 4)

    > this.doAll({place:'1,2,3,5', subs:'1'}, ‘off’)
    > 
    > 
    

    А вот еще что интересно. Я конечно могу залезть в json на сервере и посмотреть какие номера имеют у меня те или иные уровни/зоны/подсистемы, но может быть можно вернуть номер уровня/зоны/подсистемы по его названию? То есть написать функции типа NumberPlace("Территория") или NumberSubs("Освещение")? Эти номера (ID системы) ведь не соответствуют №п/п, которые созданы для упорядочивания в таблицах?



  • @Alex_Jet:

    А вот еще что интересно. Я конечно могу залезть в json на сервере и посмотреть какие номера имеют у меня те или иные уровни/зоны/подсистемы, но может быть можно вернуть номер уровня/зоны/подсистемы по его названию? То есть написать функции типа NumberPlace("Территория") или NumberSubs("Освещение")? Эти номера (ID системы) ведь не соответствуют №п/п, которые созданы для упорядочивания в таблицах?

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

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



  • @intrapro:

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

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

    Да уж. Порой вектор развития приводит не туда куда хотелось бы :lol:

    В качестве метода сценария, вероятно можно такие вещи сделать? В конце-концов с точки зрения нормального программиста это будет читаемый код, а не хард-код, состоящий из цифр - условных обозначений…



  • На простой блок-схеме появилась новая ошибка) Куда копать?
    kl.JPG



  • @homa:

    На простой блок-схеме появилась новая ошибка) Куда копать?

    внутри нее почему-то сгенерировался неверный скрипт:ъ/**

    * @name KitchenLightOn  
    * @desc  
    * @version 4 
    */
    
    const LAMP4 = Device("LAMP4");
    const LAMP2 = Device("LAMP2");
    const LAMP14 = Device("LAMP14");
    
    startOnChange([LAMP4,LAMP2]);
    
    script({
      start() { 
         LAMP14.on();
         LAMP14.off();
      }
    })
    
    


  • @intrapro:

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

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

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



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



  • @Alex_Jet:

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

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

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



  • @intrapro:

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

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

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

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



  • @Alex_Jet:

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

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

    @Alex_Jet:

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

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



  • @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), то в сообщении Телеграм/журнале значение датчика имеет предыдущее значение и как итог - пользователю не понятно что произошло. Я так понимаю, что "бракованное" значение специально откидывается и не пишется в БД, но в журнале устройства же оно появляется! Как его можно отобразить в сообщении Телеграм/журнале чтобы пользователю было понятно что именно произошло? Ну или, как вариант, сделать описание кодов ошибок.

    iH_Journal_DS18B20.png

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



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



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

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

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

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

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

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

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

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



  • @filippovsky:

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

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

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

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

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

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

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

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

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

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

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



  • @intrapro:

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

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

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



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

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

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



  • @filippovsky:

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

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

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

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

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

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

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

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

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

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

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



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



  • @filippovsky:

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

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

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

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



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


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