Posts made by Viktor

Добрый день. Вопрос к разработке: При работе сниппетов съедается оперативная память и в последствии работа всех сниппетов останавливается с ошибками. 1 Гигабайт памяти уходит за 4.5 дня.
Ошибка лога датчика:

01.11 15:46:42.285 Next start 01.11 15:46:43
01.11 15:46:43.292 Started
01.11 15:46:43.295 ERR:Snippet error { Error: spawn ENOMEM
    at _errnoException (util.js:1021:11)
    at ChildProcess.spawn (internal/child_process.js:325:11)
    at exports.spawn (child_process.js:494:9)
    at Object.exports.execFile (child_process.js:209:15)
    at Object.exports.exec (child_process.js:139:18)
    at module.exports.callback (/var/lib/intrahouse-c/projects/project_1533814451/snippets/SYS.js:6:28)
    at runSnippet (/opt/intrahouse-c/backend/lib/snippetserver/snippetserver.js:87:37)
    at Timerman.onTimerReady (/opt/intrahouse-c/backend/lib/snippetserver/snippetserver.js:178:9)
    at emitOne (events.js:115:13)
    at Timerman.emit (events.js:210:7) code: 'ENOMEM', errno: 'ENOMEM', syscall: 'spawn' }

перезагрузка IH без перезагрузки операционки возвращает свободный объем оперативной памяти и работа сниппетов восстанавливается.
В логе сниппет:

/**
* New snippet
*/

module.exports = callback => {
  require('child_process').exec('vcgencmd measure_temp', (error, stdout) => {
    let value;
    if (!error && stdout && stdout.substr(0, 4) == 'temp') {
      value =Math.round(parseFloat(stdout.split('=').pop())); 
    }
    callback( error || value === undefined, value);
  });
};

В чем причина и как исправить?

При долгой работе плагина modbus и одном отвалившемся устройстве остальные работают, но вот оперативная память заполняется. При чем за двое суток -500МБ памяти. Остановка-запуск плагина решают эту проблему, память освобождается. Как обойти проблему или организовать перезапуск плагина по расписанию? плагин v16

@intrapro спасибо за подсказку

Странная ситуация с заданием состояний устройств из сценариев. При создании третьего состояния пожарного датчика №2 либо при создании четвертого состояния переключателя №3 и попытке установки состояния через this.assign( dev, "value", 2); и this.assign( dev, "value", 3); соответственно вылезает графическая ошибка устройства "Bed device". При чем если создать переключатель, состояние №2 созданное штатно удалить и создать копированием, то в графике переключение начинает происходить с проскакивающим квадратом "Bed device"

@intrahouse был бы контроллер, вопросов бы не было. Просто рентабельность покупки оборудования хочется оценивать до покупки))

@intrahouse А как с оперативкой обстоят дела при такой конфигурации? Хватит ли ее на стабильную работу интрахаус со сценариями и, возможно, другими плагинами, например MegaD?

@intrapro Про флаг в настройках шлюза WB - да, так и есть. Спасибо, заработало.
А вот с параметром "позиция байта в слове для 1-байтовых значений" вопрос: там в настройках плагина выпадающий список из двух значений, по дефолту значение есть и убрать его мы не смогли.
Есть вопрос с параметром канала "смещение" - это что? и как это должно работать? Просто у нас ничего не меняется от этого параметра.
И еще вопрос стабильности возникает, который возможно и является причиной ложных ошибок: например сегодня однобайтовые в тех же устройствах берет без ошибки, но зато через раз лог выглядит так: (с задвоениями)

20.12 05:31:23.090 modbus1: READ: unitId = 2, FC = 3, address = 0x9C40 (0x9c40), length = 2
20.12 05:31:23.090 modbus1: READ: unitId = 2, FC = 3, address = 0x9C40 (0x9c40), length = 2
20.12 05:31:23.120 IH: get [ { id: 'ch17', value: 33620271 } ]
set { parse_kdl: { aval: 1, err: 0 } }
20.12 05:31:23.120 IH: get [ { id: 'ch17', value: 33620271 } ]
set { parse_kdl: { aval: 1, err: 0 } }
20.12 05:31:23.320 modbus1: READ: unitId = 2, FC = 3, address = 0x9C87 (0x9c87), length = 1
20.12 05:31:23.320 modbus1: READ: unitId = 2, FC = 3, address = 0x9C87 (0x9c87), length = 1
20.12 05:31:23.348 IH: get [ { id: 'ch18', value: 187 } ]
set { ch71: { aval: 187, err: 0 } }
20.12 05:31:23.348 IH: get [ { id: 'ch18', value: 187 } ]
set { ch71: { aval: 187, err: 0 } }
20.12 05:31:23.549 modbus1: READ: unitId = 1, FC = 4, address = 0x5000 (0x5000), length = 2
20.12 05:31:23.549 modbus1: READ: unitId = 1, FC = 4, address = 0x5000 (0x5000), length = 2
20.12 05:31:23.610 IH: get [ { id: 'ch10', value: -223084544 } ]
set {}

В чем причина?

@intrahouse
Итак по тестам:

1. Плагин V15 далеко не всегда стартует сам без бубна. Во всяком случае лог выводит только одну строчку. Интересный момент: каждый старт - стоп лога плагина при возникновении такой ошибки добавляет такую же строчку в лог и все.
2. Плагин V15 начал обрабатывать отключение одного из устройств в линии но! есть большое но! Он обрабатывает только первый заход, начиная со второго захода он не видит устройство с другим адресом

//отключение питания счетчика ABB
19.12 21:40:07.247 modbus1: READ: unitId = 1, FC = 4, address = 0x502D (0x502d), length = 1
19.12 21:40:10.252 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:10.464 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:10.464 modbus1: READ: unitId = 1, FC = 4, address = 0x5294 (0x5294), length = 1
19.12 21:40:13.460 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:13.666 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:13.667 modbus1: READ: unitId = 2, FC = 3, address = 0x9C40 (0x9c40), length = 2
19.12 21:40:13.699 IH: get [ { id: 'ch17', value: 33620271 } ]
set {}   //значение устройства №2 пришло
19.12 21:40:13.900 modbus1: READ: unitId = 1, FC = 4, address = 0x5000 (0x5000), length = 2
19.12 21:40:16.901 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:17.102 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:17.111 modbus1: READ: unitId = 1, FC = 4, address = 0x5001 (0x5001), length = 2
19.12 21:40:20.146 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:20.313 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:20.324 modbus1: READ: unitId = 1, FC = 4, address = 0x5002 (0x5002), length = 2
19.12 21:40:23.402 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:23.527 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:23.529 modbus1: READ: unitId = 1, FC = 4, address = 0x5003 (0x5003), length = 2
19.12 21:40:26.530 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:26.730 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:26.732 modbus1: READ: unitId = 1, FC = 4, address = 0x500A (0x500a), length = 1
19.12 21:40:29.734 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:29.937 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:29.939 modbus1: READ: unitId = 1, FC = 4, address = 0x500B (0x500b), length = 1
19.12 21:40:32.940 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:33.223 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:33.223 modbus1: READ: unitId = 1, FC = 4, address = 0x500C (0x500c), length = 1
19.12 21:40:36.145 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:36.433 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:36.433 modbus1: READ: unitId = 1, FC = 4, address = 0x500D (0x500d), length = 1
19.12 21:40:39.355 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:39.555 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:39.560 modbus1: READ: unitId = 1, FC = 4, address = 0x500F (0x500f), length = 1
19.12 21:40:42.561 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:42.764 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:42.766 modbus1: READ: unitId = 1, FC = 4, address = 0x5010 (0x5010), length = 1
19.12 21:40:45.768 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:45.970 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:45.973 modbus1: READ: unitId = 1, FC = 4, address = 0x5011 (0x5011), length = 1
19.12 21:40:48.973 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:49.173 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:49.179 modbus1: READ: unitId = 1, FC = 4, address = 0x501F (0x501f), length = 2
19.12 21:40:52.180 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:52.381 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:52.397 modbus1: READ: unitId = 1, FC = 4, address = 0x502D (0x502d), length = 1
19.12 21:40:55.398 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:55.598 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:55.601 modbus1: READ: unitId = 1, FC = 4, address = 0x5294 (0x5294), length = 1
19.12 21:40:58.602 modbus1: Network ERROR: ETIMEDOUT
19.12 21:40:58.803 modbus1: Port is not open! TRY RECONNECT
19.12 21:40:58.805 modbus1: READ: unitId = 2, FC = 3, address = 0x9C40 (0x9c40), length = 2
19.12 21:41:01.808 modbus1: Network ERROR: ETIMEDOUT
19.12 21:41:02.010 modbus1: Port is not open! TRY RECONNECT
//устройство №2 отвалилось
19.12 21:41:02.018 modbus1: READ: unitId = 1, FC = 4, address = 0x5000 (0x5000), length = 2
19.12 21:41:05.018 modbus1: Network ERROR: ETIMEDOUT
19.12 21:41:05.219 modbus1: Port is not open! TRY RECONNECT
19.12 21:41:05.229 modbus1: READ: unitId = 1, FC = 4, address = 0x5001 (0x5001), length = 2
19.12 21:41:22.880 modbus1: undefined  //проскакивающая ошибка
19.12 21:41:24.271 modbus1: Network ERROR: ETIMEDOUT
19.12 21:41:24.472 modbus1: Port is not open! TRY RECONNECT
19.12 21:41:24.475 modbus1: READ: unitId = 1, FC = 4, address = 0x500D (0x500d), length = 1
19.12 21:41:27.476 modbus1: Network ERROR: ETIMEDOUT
19.12 21:41:27.676 modbus1: Port is not open! TRY RECONNECT

плюс проскакивает ошибка undefined на ровном месте.
3. когда у нас не запускался V15 пытались пробовать V14 для своих тестов, там отваливается все при разных настройках double/int/uint

@intrahouse
Плагин V14 при наличии хотя бы одного заданного канала INT8 или UINT8 1 байт падает, выдает ошибку типа
при смене INT8 или UINT8 1 байт на любое 2х и более байтное - стартует.
Плагин V15 при выборе в канале INT8 или UINT8 1 байт стартует, но впечатление, что однобайтовые принимает как двухбайтовые. Во всяком случае приходящее значение не то.
Пока смотрим дальше...

@intrahouse
Спасибо, проверим, напишем

@intrahouse
WB-MGE

@intrapro
При

read({ unitid, fcr, address, length, ref }) {
    let that = this;

    this.client.setID(unitid);
    this.plugin.log(
      'READ unitid=' + unitid + ' FC=' + fcr + ' address=' + this.showAddress(address), 1
    );

     this.modbusReadCommand(fcr, address, length)
     .then(res => {
       this.plugin.sendDataToServer(protocol.getDataFromResponse(res.buffer, ref));
       that.plugin.log(res.buffer, 2); 
       return sleep(this.plugin.params.polldelay || 1); 
     })
     .catch(e => {
       that.checkError(e);
       that.client.close();  // Закрыть 
       return sleep(that.plugin.params.polldelay || 1); // сделать задержку. Ее можно увеличить
     })
     .then(() => {
       if (!that.client.isOpen())  return that.connect();
     })
     .then(() => {
        that.sendNext();
     })
    .catch(e => {
          that.plugin.log(' REconnection error:' + JSON.stringify(e), 0);  
          that.stop();
          process.exit(1);
    }); 
  },

и

  checkError(e) {
    if (e.errno && networkErrors.includes(e.errno)) {
      this.plugin.log('Network ERROR: ' + e.errno, 0);
    } else {
      this.plugin.log('ERROR: ' + util.inspect(e), 0);
    }
    // TODO - проверить ошибку и не всегда выходить
    //this.stop();
    //process.exit(1);
  },

суть не меняется, + 1 строчка лога

@intrapro Да, мы тоже так думали. Однако в таком виде он начинает выдавать бесконечную ошибку (на картинке). При чем нет даже пауз

Вопрос к разработке: при подключении к серверу устройств через переходник Wirenboard (протокол rtu over tcp) плагин modbus версии 13 опрашивает регистры циклически. При отключении одного из устройств от линии modbus, либо отсутствии ответа по одному из регистров плагин встает и пишет разрыв соединения. Как обойти остановку плагина и сделать циклический опрос последующих устройств и их регистров с простым выводом в лог ошибки без остановки плагина? Какая команда в agent.js отвечает за переход в следующему каналу по списку?

Будет ли работать плагин Modbus в режиме RTU over TCP с преобразователем интерфейсов RS-485/RS-232 В ETHERNET С2000-ETHERNET фирмы Болид? Очень актуальное оборудование для связи систем охраны.

Производитель заявляет поддержку UDP, ICMP (ping), ARP (хотя про настройку прибора в ICMP (ping) ни слова). Из руководства следует, что пакеты RS-485/RS-232 передаются в UDP протоколе, в том числе и modbus.

С аналоговым по своей сути клапаном проблема в том, что даже рассчитав по ПИД закону необходимое минимальное время поворота, это самое время рано или поздно станет настолько малым, что подача напряжения не будет вызывать поворот клапана. т.е. по сути его всегда будет дергать. Была статья в сети на тему такого клапана. Там человек задавал поворот по логике больше-меньше. Т.е. температура меньше уставки - поворот на минимальное время - таймер - проверка повышение/понижение температуры - если понижение то еще поворот.

Спасибо. Теперь заработало

Программно просто. Зависит от работы самого клапана. В одном из вариантов 2 устройства ih равные двум физическим выходам. Оба устройства только включаются, например на время смены положения заслонки и только попеременно. Какой включается определяется температурой. Это в случае простейшего клапана. Ещё сразу хорошо бы понимать есть ли в клапане электрическая защита от включения одновременно двух направлений. Ещё вариант- это переключающее реле, равное одному устройству ih. Другое устройство ih- подача питания на вращения. Т.е. При любом изменении положения клапана включается устройство подачи питания+ переключается реле в нужную сторону

@Erik:

положение вентиля трехходового клапана должно учитывать:

1. Температуру на улице.

2. Температуру в комнате.

3. Разницу между температурой в комнате и температурой уставки.

4. Динамику изменения температуры в комнате.

5. Температуру подачи в системе отопления (в том числе выход за нижний предел).

6. Температуру подачи в контуре отопления.

7. Состояние циркуляционного насоса в контуре отопления.

8. Выставленный режим отопления.

9. Расписание (время до следующего переключения режима).

10. Ограничения минимальной и максимальной температуры подачи в контуре отопления.

11. Состояние клапанов на петлях (если они есть).

12. Режим тренировки (чтобы клапан не закисал).

13. Возможность сброса избыточного тепла в контур из системы отопления.

Если вы не программист - купите готовый контроллер. Это дешевле, чем заказывать ПО с нуля.

В общем то расписанные пункты- это контроль параметров в целом в системе отопления, а не поддержание температуры теплоносителя. Если необходимая температура теплоносителя известна, то просто по её достижении переключать на круг. Упала на сколько то, переключать на контур. Более развито, это ПИД регулирование, там колебания системы затухнут. Кстати не так сложно реализуется, учитывая то, что ih воспринимает формулы math.

Почему то плагин из архива не присваивает значение датчику. Лог плагина выдает следующее:

17.09 22:31:26.634 vcgencmd: stdout: temp=52.1'C

17.09 22:31:26.636 IH: get { id: 'CPU_TEMP', value: 52.1, err: 0 }
set {}

хотя датчик температуры прописан в канале

Что не так?