Сценарии - новая версия API
-
А подскажите как из сценария выключить весь свет на этаже (привязка устройств к уровню/зоне), либо вообще весь свет в доме?
Команды для групп устройств
-
Отлично! Всем спасибо!
Выключить все устройства подсистемы освещения
> 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 системы) ведь не соответствуют №п/п, которые созданы для упорядочивания в таблицах?
-
А вот еще что интересно. Я конечно могу залезть в json на сервере и посмотреть какие номера имеют у меня те или иные уровни/зоны/подсистемы, но может быть можно вернуть номер уровня/зоны/подсистемы по его названию? То есть написать функции типа NumberPlace("Территория") или NumberSubs("Освещение")? Эти номера (ID системы) ведь не соответствуют №п/п, которые созданы для упорядочивания в таблицах?
Легче вернуть столбцы ID в таблицы. Которые скрыли, чтобы не пугать пользователей
Сейчас можно создать команду в блок-схеме и посмотреть id в скрипте
-
Легче вернуть столбцы ID в таблицы. Которые скрыли, чтобы не пугать пользователей
Сейчас можно создать команду в блок-схеме и посмотреть id в скрипте
Да уж. Порой вектор развития приводит не туда куда хотелось бы :lol:
В качестве метода сценария, вероятно можно такие вещи сделать? В конце-концов с точки зрения нормального программиста это будет читаемый код, а не хард-код, состоящий из цифр - условных обозначений…
-
На простой блок-схеме появилась новая ошибка) Куда копать?
-
На простой блок-схеме появилась новая ошибка) Куда копать?
внутри нее почему-то сгенерировался неверный скрипт:ъ/**
* @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(); } })
-
Легче вернуть столбцы ID в таблицы. Которые скрыли, чтобы не пугать пользователей
Сейчас можно создать команду в блок-схеме и посмотреть id в скрипте
Верните, пожалуйста, для "Объекты", "Уровни", "Зоны" ID - можно не столбец вернуть, а строку ID в настройках, как сейчас отображается у подсистем. Кстати, для устройств тоже было бы удобно - когда в настройках отображается ID устройства - скопировал его и вставил в сценарий, например.
-
А не планируете ввести новый класс устройств "Plugin" — плагины для стыковки с оборудованием? Чтобы можно было какие-нибудь мультисценарии написать для работы с плагинами?
-
А не планируете ввести новый класс устройств "Plugin" — плагины для стыковки с оборудованием? Чтобы можно было какие-нибудь мультисценарии написать для работы с плагинами?
Мы как раз сейчас приступаем к реализации открытого API плагинов и механизмов взаимодействия.
Было бы хорошо, если бы Вы описали, какие задачи хотите решить
-
Мы как раз сейчас приступаем к реализации открытого API плагинов и механизмов взаимодействия.
Было бы хорошо, если бы Вы описали, какие задачи хотите решить
Меня интересуют перезапуски плагинов и причины их перезапуска. Обратил внимание, что почти все плагины MegaD у меня перезапускаются, а по идее должны работать с момента последнего запуска. Кроме этого, если по какой-то причине оборудование отвалилось от сети (нет доступности, сгорело, пропало питающее напряжение и т.д.), то хотелось бы чтобы по Telegram/SMS/E-mail приходило уведомление администратору системы. Конечно можно использовать плагин ping, создавать для него новые устройства и их добавлять в мультисценарий, но это не комильфо, когда у нас уже есть самостоятельные сущности плагинов в системе.
Кроме этого, мне бы хотелось работать с основной вкладкой или вкладкой "Параметры" бокового меню устройства, соответствующего плагину. Например, парсить страницу config тех же контроллеров MegaD http-плагином и привязывать параметры на вышеуказанные вкладки (идею описывал тут). То же самое я уже проделал с mdmTerminal2, но с ним легче - он шлет get серверу, соответственно по ним сервер вызывает сценарий, в котором я определяю новые параметры плагина и привязываю к ним полученные данные.
-
Верните, пожалуйста, для "Объекты", "Уровни", "Зоны" ID - можно не столбец вернуть, а строку ID в настройках, как сейчас отображается у подсистем.
Вернули в новом релизе 4.5.x
А не планируете ввести новый класс устройств "Plugin" — плагины для стыковки с оборудованием? Чтобы можно было какие-нибудь мультисценарии написать для работы с плагинами?
В принципе, новый класс тут не нужен. Индикатор плагина - это обычный дискретный датчик (SensorD), просто создается автоматически и имеет ID специального вида: UNIT <id плагина="">Индикаторы плагинов были скрыты искусственно в списках дискретных датчиков. Сейчас (в новом релизе 4.5.x) они доступны в списках мультисценариев "Запуск для устройств"</id>
-
Вернули в новом релизе 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, то сделать еще один запрос?
-
Если комментировать строку startonchange, то получаем ошибку при сохранении. Появилась давно, не с последним обновлением, но руки не доходили написать.
-
Скажите, пожалуйста, как можно привязать запуск сценария к моменту запуска сервера?
Условный пример:
Есть дискретный актуатор "Солнце".
По расписанию "На рассвете" оно включается.
По расписанию "На закате" оно выключается.
Но если сервер включен между этими событиями посреди дня - то Солнце будет выключено, пока не наступит ближайший рассвет.
Можно написать сценарий, в котором явно установить состояние Солнца в зависимости от текущего времени, времени рассвета и заката.
Но как заставить этот сценарий запуститься в момент запуска сервера, чтобы инициализировать Солнце?
-
Скажите, пожалуйста, как можно привязать запуск сценария к моменту запуска сервера?
Условный пример:
Есть дискретный актуатор "Солнце".
По расписанию "На рассвете" оно включается.
По расписанию "На закате" оно выключается.
Но если сервер включен между этими событиями посреди дня - то Солнце будет выключено, пока не наступит ближайший рассвет.
Можно написать сценарий, в котором явно установить состояние Солнца в зависимости от текущего времени, времени рассвета и заката.
Но как заставить этот сценарий запуститься в момент запуска сервера, чтобы инициализировать Солнце?
Нужно в сценарий включить функцию boot, которая должна вернуть результат true, чтобы сценарий запустился при старте сервера. Выполнение, как обычно, начнется с функции start()
boot() { return true; // Всегда запускать при старте сервера }, start() { // }
Эта возможность не документирована. Возможно, синтаксис изменится при доработке API сценариев.
-
Нужно в сценарий включить функцию boot, которая должна вернуть результат true, чтобы сценарий запустился при старте сервера.
Эта возможность не документирована. Возможно, синтаксис изменится при доработке API сценариев.
Спасибо большое
-
Можно попросить добавить в окно отладчика сценариев кнопку "Пробный запуск сценария"?
Сейчас "Пробный запуск" можно сделать из меню по кнопке в верхней части экрана, но при открытом отладчике эта кнопка становится disabled.
В итоге невозможно сделать РУЧНОЙ пробный запуск сценария с просмотром в отладчике.
-
Можно попросить добавить в окно отладчика сценариев кнопку "Пробный запуск сценария"?
Сейчас "Пробный запуск" можно сделать из меню по кнопке в верхней части экрана, но при открытом отладчике эта кнопка становится disabled.
В итоге невозможно сделать РУЧНОЙ пробный запуск сценария с просмотром в отладчике.
Тоже соглашусь с этим. Очень неудобно держать открытыми 4-5 (2 для сценариев, 2 для плагинов и 1 для изменения разных настроек) окон PM для отладки!
Кстати, по поводу:
1. Реализации "cron" для сценариев (запуск сценариев для проверки состояния устройств)
2. Доступности из сценариев "журнал устройств" (для принудительного запуска насосов/котлов/кранов/клапанов если их период простоя велик)
3. Доступности из сценариев данных по устройству из БД (для составления и отправки месячной сводки в управляющие компании)
4. Доступности из сценариев пользовательских журналов (создавать журналы можно, но писать в них логи пока никак)
Какие-нибудь комментарии будут? Даже не комментарии, а возможная реализация и ее примерный срок.
По столбцам ID у объектов/зон/систем/устройств уже сообщал свое пожелание выше… хотя тут обнаружил, что система теперь запоминает расположение столбцов. То есть если столбцы перенести как нужно администратору системы, то они в таком виде и останутся при следующим заходе в pm?
-
Доброго времени суток. Помогите пожалуйста сообразить сценарий. Смысл такой: Имеются 2 датчика E18-D80NK которые будут вести подсчет людей зашедших/вышедших из комнаты. Допустим зашло 2 человека, один человек вышел- свет горит, вышел второй человек- свет погас. Также дополнить все это дело датчиком освещенности, что это все работает с условием что если допустим выше 200 lux свет не горит, 100 lux горит.
-
Можно попросить добавить в окно отладчика сценариев кнопку "Пробный запуск сценария"?
Сейчас "Пробный запуск" можно сделать из меню по кнопке в верхней части экрана, но при открытом отладчике эта кнопка становится disabled.
В итоге невозможно сделать РУЧНОЙ пробный запуск сценария с просмотром в отладчике.
Да, Вы правы, постараемся добавить в одной из ближайших версий