Участник @homa написал

И следом вопрос корректно ли объявлять одно и тоже свойство для одного и того же устройства в разных сценариях, или есть какие-то другие варианты обращения к ранее объявленным свойствам

идея в том, чтобы изменять из разных сценариев одно свойство... выходит не выходит)

Почему не выходит? Без проблем можно обращаться к одному свойству устройства из нескольких сценариев. При этом достаточно объявить свойство в одном сценарии, в других можно и не объявлять. При объявлении это свойство создается на уровне устройства. Проблема отсутствия свойства может быть только при первом запуске и после перезагрузки.

@alexeyalvl, если порядок меняться не будет, то можно сделать так:

Для считывания температуры (первый элемент):

let value;
if (!error && stdout) {
     value = parseFloat( stdout.split(' ').shift().split('=').pop() );
}

Для считывания влажности (второй элемент):

let value;
if (!error && stdout) {
     value = parseFloat( stdout.split(' ').pop().split('=').pop() );
}

Что тут делается:

• stdout.split(' ') - строка разбивается на элементы, разделенные пробелом:
  [ 'Temp=24.3*', 'Humidity=48.6%' ]
• shift() - берется первый элемент
  'Temp=24.3*'
• split('=') - этот элемент разбивается на элементы, разделенные знаком =
  [ 'Temp', '24.3*' ]
• pop() - берется последний элемент, то есть число
  '24.3*'
• Результат обрабатывается функцией parseFloat, результат - 24.3

Второе значение обрабатывается аналогично, только на втором шаге берется не первый элемент - shift(), а последний - pop()

Участник @Alex_Jet написал в Плагин MegaD:

@intrapro, подключил ленту WS2818 к контроллеру, в канале плагина вписал команду управления /%pwd%/?pt=%adr%&ws=%value%&chip=151. Все работает, однако братья китайцы где-то напутали и поменяли местами R и G... как итог лента не RGB, а GRB... стандартными средствами плагина можно выйти из положения?

Попробуйте в канале на вкладке Обработка прописать:
Формула расчета выходного значения для актуаторов: [ value[1],value[0],value[2] ]

Ну и входное тоже нужно так же:
Формула расчета входного значения: [ value[1],value[0],value[2] ]

Еще момент по уровню яркости. Если установить какой-нибудь цвет, то слайдер L по умолчанию переходит в значение 50. Если его двигать в сторону 0, то яркость выбранного цвета уменьшается, однако если двигать к 100, то яркость увеличивается, но и цвет плывет причем на 100 получается просто белый цвет. Это явно не верный алгоритм.

Это вопрос спорный. Сейчас нужно ориентироваться, что трушный цвет при L=50

А еще поработать бы с самим устройством. По идее индикатор 1 - это RGB параметры, а индикатор 2 - это уровень яркости. Однако сейчас индикатор 2 отображает, например, "0,255,0", хотя при настройке устройства на мнемосхеме отображается уровень в виде "100". При нажатии на устройство - ничего не меняется - (картинки одинаковые), уровень остается тот же.

Да, с индикаторами не очень Сейчас наверху выводится текущее значение массива, внизу должно быть дефолтное значение (для команды on) Cостояния on/off должны переключаться. Попробуйте нажать кнопку Выключить в боковом меню. Должны уйти нули, а устройство перейти в состояние выключено. Ну а картинку для активного состояния сами раскрасьте

Участник @Erik написал

И еще вопрос.

Как при включенном по датчику движения свете по повторному срабатыванию датчика движения обнулять таймер?

При условии if ((SAF.value === 0) && (sw.value === 0) && (lamp.value == 1)) проверить, что таймер запущен, и обнулить его (тот же самый таймер).

Для этого нужно добавить внутрь сценария "слушателя событий"

script({
    start() {
      if ((SAF.value === 0) && (sw.value === 0) && (lamp.value === 0)) {
         lamp.on();
         // взводим таймер, чтобы отключить 
         this.startTimer("T1", 180, "turnOff");       
        
        // Добавляем слушателей - следим за датчиком движения и светильником
        this.addListener(motion, "onMotion");
        this.addListener(lamp, "onLamp");
      }
    },
    
    onMotion() {
      // Если движение возобновилось - сбрасываем таймер
      if (motion.isOn() )  {
        this.stopTimer("T1");
      }  
       // Если движение прекратилось - взводим таймер (после повторных движений)
      if (motion.isOff() && this.timer.T1 == "off")  {
        this.startTimer("T1",  180, "turnOff");
      }  
    },
    
     onLamp() {
      // Светильник выключили другим способом - выходим
       if (lamp.isOff()) this.exit();
     },
     
    // Функция, которая сработает, когда таймер досчитает - отключаем и выходим
    turnOff() {
      lamp.off();
      this.exit(); // Здесь exit нужен, так как есть активные слушатели и сценарий сам не завершится
    }
});

Более подробно про механизм работы сценариев - https://ih-systems.com/ru/about-scenes/
Если коротко:

• Если внутри сценария просто последовательность действий, он отработает и сразу завершится (станет не активным). При следующем запуске он опять начнется со start(). Большая часть сценариев работает именно так и 99,9% времени находятся в неактивном состоянии.

• Если сценарий взводит таймеры и/или устанавливает слушателя событий устройства, то он остается активным, следит за своими таймерами и устройствами «изнутри» и выполняет действия как реакцию на отслеживаемые события. Стартовое событие не работает, так как сценарий уже активен.. В рабочих сценариях в левом столбце у сценариев, активных в данный момент, стоит зеленая галочка.
  Чтобы завершить такой сценарий, нужно выполнить команду this.exit().
  При завершении сценария все его таймеры и слушатели удаляются. При следующем запуске опять выполнится start()

Пользователь @regabriel написал в Вопросы по работе системы:

Здравствуйте. Не пойму ошибка или нет.
Создаю устройство - виртуальный датчик температуры, чтобы в нем выводить среднюю температуру с нескольких других датчиков.
Соответственно делаю мульти скриптик(так как таких средних будет несколько)
в котором прописываю:

const temp_room = Device("SensorA","Средняя температура комнаты"); 

....
script({
    start() {
         temp_room.setValue(15);

Так вот не работает x.setValue(15);
Для "ActorA" работает.
Это ошибка или так и должно быть?

Добрый день. Да, все верно, датчику значение таким образом присвоить нельзя.
Идея в том, что x.setValue задействует канал на запись, по которому значение записывается на железо. Датчик сам значение записать не может, его value только для чтения.
Для реализации виртуального датчика есть команда this.assign( имя устр-ва, имя свойства, значение)

this.assign(temp_room,"value",42);

В настройках-> дополнительно ставлю метод определения состояния "вычисляется сценарием".

Не совсем. У датчика есть value - значение и state - состояние, которое грубо говоря определяет картинку.
Этот пункт относится к state, Вы же сценарием хотите присвоить value.
Если нужно, чтобы средняя пересчитывалась динамически при изменении любого датчика, получится примерно так:

const temp1 = Device("SensorA","Датчик 1"); 
const temp2 = Device("SensorA","Датчик 2"); 
const temp3 = Device("SensorA","Датчик 3"); 
const temp4 = Device("SensorA","Датчик 4"); 
const temp_room = Device("SensorA","Средняя температура комнаты"); 

startOnChange([ temp1, temp2, temp3, temp4 ]); 

script({
    start() {
        const average = (temp1.value+temp2.value+temp3.value+temp4.value)/4;
        this.assign(temp_room,"value", average);
  }
})

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

И второй вопрос: при создании устройства выбор - актуатор бинарный(т.е. 2 состояния)
При этом в мультисценарии ActorD — дискретный актуатор.

Дискретный актуатор - имеется в виду актуатор с конечным числом состояний.
По умолчанию создается бинарный. Но можно расширить число состояний

Можно ли сделать более 2 состояний у актуатора и датчика и как? Где посмотреть примеры или описания?

Да, можно. Раздел Состояния устройств на странице https://ih-systems.com/ru/devices/

По состояниям:

• у дискретных датчиков и актуаторов обычно делают value=state,
  метод определения состояния "Стандартный"

• у аналоговых можно использовать "Метод интервалов", то есть состояние расчитывается исходя из value, по нарастанию значения (более подробно см в док-и)

метод определения состояния "вычисляется сценарием" после перехода на v4 не используется

Также обратите внимание на 2 момента:

1. Состояния должны нумероваться строго подряд, начиная с 0
2. Если устройство уже стоит на мнемосхеме, после изменения числа состояний его нужно удалить и заново поставить. На мнемосхеме можно менять визуальное представление каждого состояния, причем каждое редактируется отдельно

@alesle пожалуйста
Вот вариант еще короче

data.onew_temp.find(item => item.name=="S6").t

Современный javascript мощный и гибкий язык, особенно если использовать синтаксис ES6 (или ES2015, что одно и то же) , в данном случае стрелочные функции.
Магия этих выражений раскрывается в 2 шага

1. Массивы в JS имеют встроенные методы для поиска по заданному критерию, в частности filter, find

   • find - ищет первый элемент массива, возвращает найденный объект
   • filter - сюрприз - фильтрует входной массив и возвращает все найденные элементы (learn.javascript.ru/array-methods)

2. Методу нужно передать критерий отбора - функцию для обработки элемента массива.

   Если писать, используя синтаксис классических функций, то получится так:

    arr.filter( function (item) {
      return item.name == 'S6';  
   });
   

   Функция вызывается по очереди для каждого элемента массива (item), если возвращает true, то элемент берется в новый массив

   С введением в ES6 стрелочных функций все стало компактнее:

    function (item) {return item.name == 'S6';} 
   

   можно заменить на

    (item)  => item.name == 'S6' 
   

   Что произошло

• убрали function
• грубо говоря return заменили на =>
• если входной аргумент ровно один - то и скобки можно не ставить

Подробнее https://learn.javascript.ru/arrow-functions
Получаем:

 arr.filter( item => item.name == 'S6' );

Ну и надо иметь в виду, что возвращает метод массива.
Если результат - массив, то берем свойство его первого элемента

data.onew_temp.filter(item => item.name=="S6")[0].t

Если результат - объект, то просто берем свойство t

data.onew_temp.find(item => item.name=="S6").t

Участник @homa написал в Сниппеты на каждую функцию устройства.:

А для сниппетов работаю интервалы? Что-то не получается...

Проверили, должно работать.
Если у вас аналоговый датчик, нужно, чтобы на вкладке Дополнительно в списке Метод определения состояния было выбрано Аналоговое значение - интервалы.
Если сниппет возвращает значения подряд (0,1,...x), то можно сделать еще проще: взять дискретный датчик, у него добавить состояния 0,1,...x, метод переключать не надо, т к для дискретных датчиков состояние=значение

В любом случае, если устройство уже стояло на мнемосхеме, а потом были добавлены состояния, то нужно устройство удалить и заново разместить, иначе будет ошибка Bad device

@Alex_Jet, Добрый день! @Erik прав - нужен актуатор, который можно переключать как угодно - интерактивно, сценарием, по расписанию...

Сценарий гирлянды запускается при включении этого актуатора.

Состояния в php скрипте меняются случайным образом, поэтому логика еще проще:

1. Добавить слушателя для актуатора-триггера
2. Генерировать строку цветов случайным образом
3. Передать команду на MegaD
4. Взвести таймер 1 сек

По таймеру - повторить пункты 1-3
При выключении триггера - завершить сценарий

Пользователь @regabriel написал в Плагин MegaD:

Здравствуйте. Разбираюсь с системой и возникает множество вопросов))

1. Как настраивается в плагине в канале"Функция обработки значения"?
   в каком виде можно писать?
   Например датчик температуры, если он показывает меньше -40, либо ровно 0, либо больше 100 значит он неисправен, как это записать?

Добрый день.
Настройку интервала допустимых значений можно настроить прямо на устройстве (min-max) . Там же можно определить, что делать, если произошел выход из диапазона:

• "Не принимать значение вне диапазона" - значение не будет присвоено
• "Установить ошибку при выходе из диапазона"

Можно эти флаги устанавливать независимо. Также можно контролировать поступление данных - "Установить ошибку если нет данных в течение (сек)"

Функция обработки в канале используется, если нужна сложная предварительная обработка. Например, от контроллера получаем 5 значений, сортируем, откидываем минимальное и максимальное и вычисляем среднее. И именно вычисленное значение отдаем ядру системы.
Пример такой функции для плагина MegaD приведен в описании плагина (в конце страницы):
https://ih-systems.com/ru/product/plugin-megad/

1. Где вообще можно посмотреть хорошее описание API по intraHouse? Например по работе с БД?

Пользовательские SQL запросы к БД на уровне ядра в версии 4 не поддерживаются. Можно писать и читать из сценария с помощью функций this.dbread(), this.dbwrite().
Если нужно напрямую работать с БД, есть возможность написать отдельный плагин. Документации на эту тему нет , но есть примеры реализации.

1. Как проверять работу сложного скрипта? Как посмотреть результаты работы consol.log('') или использовать какие либо аналоги ?

Для отладки скрипта есть "Отладчик" в нижнем окне сценария. Там выводится трассировка при выполнении команд, таймеров, проверки условий.
Вместо console.log в скрипте используйте. this.log(''), сообщение будет выведено в этом же окне

@Alex_Jet Если работает, то по старому анекдоту про программиста и солнце, лучше и не трогать

А серьезно (так понимаю, ожидается вещественное число), обработку результата можно сделать так:

res.on('end', () => {
      const value = parseFloat(rawData);   
      callback(isNaN(value) ? "Не числовое значение "+rawData : "", value); 
});

Если придет не число, то в журнале устройства будет сообщение об ошибке

@konia74 Что интересно, команда проходит и в ответ на команду проходит ответ.

06.08 18:22:37.897 modbus1: writeSingleRegister: address = 1 (0x1), value = 1
06.08 18:22:37.916 modbus1: Write result: { address: 1, value: 1 } - через 20 мсек пришел ответ, что команда на запись выполнена

Но что-то мешает устройству переключиться, при этом оно виснет на некоторое время. Но потом опять начинает отвечать. Возможно, проблема в схеме подключения?

@konia74 В отладчике все нормально, снимается значение 0. Можно увеличить интервал между запросами - сейчас у Вас 200 мс, для RTU можно сделать пореже. А в чем проблема? Команда на запись не уходит?

@konia74 Добрый день!

Проверьте, какое значение стоит в параметрах плагина: Ожидание ответа на запрос (ms)

• если значение меньше 1000 -попробуйте его увеличить. По умолчанию там 5000 - это 5 секунд
• если таймаут большой, значит ответ просто не приходит. Опишите подробнее, когда возникает эта ошибка, какой транспорт (Modbus TCP/ RTU,...) используется

@regabriel, действительно, ошибочка вышла

@regabriel Наверно и сообщение о перезагрузке контроллера st=1 нужно слушать.
И на старте как-то синхронизировать. Напишите по результату, интересный опыт использования.

Пользователь @Alex_Jet написал в Плагин MegaD:

Пользователь @intrapro написал в Плагин MegaD:
Помнится мне, что парсинг ON/OFF, temp/hum и прочее происходил "по умолчанию" только у каналов, у которых ID=0...37, либо X_1/X_2? А вот если канал имеет какое-нибудь отличное от числа значение, то этот парсинг не выполняется? Или это было с чем-то другим связано?

Числовой номер канала нужен только для извлечения данных из строки all

Или уже нет смысла переписывать код плагина поскольку в версии 5 все будет совсем по другому?

Планируется, что все плагины и сценарии из v4 будут работать в v5

Вообще, код плагина MegaD просто ужасен... по мне так легче все заново написать. Было бы время и знания по API iH....

С прагматичной точки зрения, код плохой, если:

• программа работает нестабильно: зависает или вылетает, игнорирует ошибки
• требует постоянной поддержки, так как нестандартные ситуации не обрабатывает или реагирует неадекватно
• хорошо работает на компьютере разработчика, но при установке в мало-мальски другое окружение нужны ритульные пляски и сакральные знания
• при необходимости доработки нужно не забыть внести изменения в несколько мест (искать всюду 37 канал, например

Про плагин MegaD ничего такого сказать нельзя. Он работает стабильно, надежно уже несколько лет.
Вопросы от пользователей и доработки связаны с расширением функционала - (MCP, _A и _B,.. Плюс эпопеи с контроллером, но это другая история)
Есть также плюс, который не очевиден для людей, любящих покодить - порог вхождения при использовании плагина MegaD очень низкий, простой функционал настраивается очень просто.

Также можно рассмотреть вариант, предлагаемый во многих системах - нет плагина MegaD, вот вам http-клиент, дальше сами.
Эта возможность в IH тоже есть, даже 2 варианта:

• создавать сниппеты для каждого устройства и запускать их периодически;
• использовать плагин http

Для чтения CNT, кстати, это тоже решение (но не забыть при этом обрабатывать ошибки связи, если хочется сделать не поделку, которая работает при демонстрации, а реально работающий проект). И если на MegaD идет одновременно очень много независимых запросов, помнится, тоже были проблемы. Ну и по поводу CNT для счетчика - просто интересно, как решается вопрос, когда контроллер при потере питания сбрасывает значение?
Если порт заявляется как счетчик, он IMHO должен хранить значение при отключении питания. Например в оборудовании KernelChip счетчик - это счетчик, ему можно доверять.

С позиции чистого искусства - да, соглашусь, код выглядит несовременно и не очень консистентно, API v4 работы с плагинами не используется. Также выглядит не очень понятно работа с входящими сообщениями.

Хорошо бы все переписать на ES6 и с применением API. И придумать понятный механизм. И чтобы любая новинка MegaD сразу была реализована И чтобы этим занимался специалист по MegaD.
В v5 мы планируем предложить сообществу активнее разрабатывать плагины. Со стороны системы будет обеспечено:

• открытое API для создания плагинов;
• возможность декларативного описания настройки каналов и свойств, в том числе древовидные структуры
• простой механизм подключения плагина к системе и отладка;
• продвижение плагинов сторонних разработчиков через портал

И пусть каждый желающий напишет плагин своей мечты

Пользователь @regabriel написал в Плагин MegaD:

1. Вопрос в другом, как получить CNT по запросу, а не обработкой входящих?

Можно было бы привязать к каналу аналоговый датчик и в формуле расчета входного значения добавить "value = CNT", но так не работает. Увы(к счастью) у меги нет специальной команды для получения только параметра CNT.

Добрый день!
К сожалению, штатно в каналах CNT не обрабатывается (просто откидывается).

Поскольку CNT не сохраняется при перезагрузке меги, с использованием CNT счетчики пока не делали (возможно, с сохранением ситуация изменилась?)

Вы можете решить задачу через pluginCommand.
Нужно только указать имя функции - обработчика, как второй аргумент

Когда придет ответ от меги, будет вызвана эта функция - обработчик с body на входе

this.pluginCommand({unit:'megad3', command:'/sec/?pt=0&cmd=get'}, 'onGetResponse');
},

onGetResponse(body) {
//дальше уже обработаем ответ
        this.log('te = ' + body);
}

2 Вообще "формула расчета входного значения работает "? Такое ощущение, что нет.

Она работает, есть даже 2 варианта:

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

• "Формула расчета входного значения" работает уже при получении данных от плагина на уровне ядра.

Но Вы правы, в вашем случае это не работает, так как функцию делали для обработки числовых значений, и значения типа OFF/xx ON/yy просто преобразуются в 0/1.
Функция, которая вызовет обработчик (getResultValue) даже не вызывается, как верно указал @Alex_Jet в процитированном коде
Если есть желание адаптировать плагин, то место указано верно.
Можно блок isNaN(str) закрыть, выполнять для всех каналов getResultValue. Но тогда нужно обрабатывать ON/OFF и другие строки (tryReadSome) в getResultValue либо на каждый канал вешать функцию

function getResultValue(val, adrx) {
    if (isNaN(val)) return;  // Это нужно закрыть

    // Здесь парсить val
    let res = val;
    adrx = String(adrx);
    if (prefun[adrx]) {
      res = prefun[adrx].fun(val, prefun[adrx].depo);   // Это вызов пользовательского обработчика
    }
    return res;
  }

@Alex_Jet, похоже, Вы нашли баг с использованием счетчика в сценарии версии v4. А именно - value для счетчика - это aval, а не dval

Попробуйте использовать для счетчика "aval" вместо "value", т е
сделать такую замену:

 if(this.isChanged(meter, "value"))  ==>  if(this.isChanged(meter, "aval")) 

this.log("> Значение счетчика = " +meter.value); ==> this.log("> Значение счетчика = " +meter.getParam("aval")); 

Пользователь @regabriel написал в Вопросы по работе системы:

Спасибо за развернутые ответы. Но возникают еще вопросы)))

Выяснилось, что для отправки большого количества запросов с большой скоростью на мегад pluginCommand не справляется.
(не знаю из-за чего, но скорость по сравнению с file_get_contents в скриптике из php в десятки раз медленнее)
Из-за чего встает задачка проверки возможности самому отправлять запросы напрямую.

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

Для ускорения работы плагина MegaD:

• если есть опрос каналов, можно попробовать его отключить (на уровне каналов и в параметрах плагина - период опроса всех каналов поставить 0)
• самое главное - для меги есть спец настройка для замедления отправки следующей команды. "Интервал отправки запросов" установлен по умолчанию в 200 мсек, на самом деле это очень много, но были проблемы с зависанием контроллера при частой отправке запросов. Можно сильно уменьшить этот параметр.

Интересно конечно посмотреть в отладчике плагина, где происходит замедление, но если не меняли параметр Интервал опроса, то отправляется только 5 запросов в секунду. И собственно pluginCommand здесь ни при чем
Тем не менее, можно попробовать и другие варианты

В плагине от меги нашел вариант:

require("./lib/httpclient");

Правильно ли я понимаю, что подключать нужно через ./lib/ , а список всех доступных модулей можно посмотреть в /opt/intrahouse-c/backend/node_modules ? Или есть тонкости?

Нет, все что в /opt/intrahouse-c/backend/node_modules, делаете require без путей.
Приведенный пример - это http клиент внутри плагина megad, не из node_modules, а из файла /var/lib/intrahouse-c/plugins/megad/lib/httpclient.js

Как подключать библиотеки express или request ?

Для запросов к MegaD ни request, ни тем более express не нужен, нужен простой http клиент (get запросы без затей). Встроенный в nodejs модуль http покроет
с избытком:

require('http').get('http://192.168.11.22/sec/?.....')

Примеры использования есть на примере сниппетов:

https://forum.ih-systems.com/topic/139/сниппеты/3?_=1594984596289

В зависимости от вашей задачи есть варианты:

• использовать require('http') из сценария или сниппета (здесь есть накладные расходы на запуск - останов сценария; если запросов ооочень много, то может пострадать общая производительность системы, так как сценарии работают в основном процессе)
• использовать http плагин (который кстати использует request, так как поддерживает post запросы и др фишки). Плагины запускаются как дочерние процессы.
• если там действительно много запросов и скорость не устраивает, написать свой плагин с оптимизацией под конкретную задачу.

Пользователь @regabriel написал в Вопросы по работе системы:

Здравствуйте. Для работы одного сложного устройства пришлось создать "библиотеку" в 600-1000 строк из объекта с методами.

Если данное устройство будет использоваться в нескольких сценариях, как лучше организовать работу?

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

Добрый день!
Можно вынести код объекта в отдельный файл в виде модуля

// File mybigobject.js

module.exports = {
  get() {
     ...
  },...

};

В сценарии делаете require - загрузка модуля:

... const myobj = require("путь к файлу/mybigobject");
    const x = myobj.get();

Пропишите абсолютный путь - тогда не будет проблем с дефолтными путями.
Если этот модуль разместить в node_modules, то путь прописывать не надо.

Но есть 2 момента:

• редактировать этот файл нужно будет не через систему - для 1000 строк это точно не минус
• если будете менять код, то сервер нужно перезагружать, так как require кэширует модуль. Это тоже плюс для Вас - можете вызывать в разных сценариях, модуль загрузится только однажды