Зависание плагина MegaD

Alex_Jet

Плагин MegaD. Созданы каналы - 14 ActorD, 8 SensorA (DHT22 - 1 шт., DS18B20 - 3 шт. на шине 1-wire, HTU21D - 1 шт., АЦП - 1 шт.). 36-й канал обрабатывается скриптом:

function (val, depo) {
   var result;
   if (!depo.res) depo.res = [];   
   depo.res.push(val);  
   if (depo.res.length < 5)    return { reqsek:5 };  // Нужны еще измерения, значение не возвращаем
   depo.res.sort();   
   result = ((Math.round((depo.res[1] + depo.res[2] + depo.res[3]) / 3) - 100 ) * 10 + 350);
   depo.res = []; // Перед следующими измерениями сбрасываем массив
   return { val:result, reqsek:300 }; // Восстанавливаем период 5 мин
}

Проблема - плагин после рестарта работает примерно 12 часов, после не отдает показания по каналам, физические актюаторы не срабатывают при их активации в вебе. Контроллер MegaD-2561 при этом работает отлично.

Лог плагина в тот момент, когда он перестает работать:

29.12.2016 16:38:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:38:35 localhost <= 192.168.12.20:80 HTTP temp:26.20/hum:23.10
29.12.2016 16:38:35 MG2?30_1=26.2&30_2=23.1&
29.12.2016 16:38:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:38:35 localhost <= 192.168.12.20:80 HTTP 26.67
29.12.2016 16:38:35 MG2?341=26.67&
29.12.2016 16:38:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:38:35 localhost <= 192.168.12.20:80 HTTP 128.85
29.12.2016 16:38:35 MG2?342=128.85&
29.12.2016 16:39:05 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:39:05 localhost <= 192.168.12.20:80 HTTP 158
29.12.2016 16:39:05 Address 36
29.12.2016 16:39:05     run script: val=158 depo={ res: [] }
29.12.2016 16:39:05  script return:{ reqsek: 5 } depo={ res: [ 158 ] }
29.12.2016 16:39:05 Address 36\. Shift request interval: 5 sek.
29.12.2016 16:39:05 MG2?
29.12.2016 16:39:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:39:10 localhost <= 192.168.12.20:80 HTTP 159
29.12.2016 16:39:10 Address 36
29.12.2016 16:39:10     run script: val=159 depo={ res: [ 158 ] }
29.12.2016 16:39:10  script return:{ reqsek: 5 } depo={ res: [ 158, 159 ] }
29.12.2016 16:39:10 MG2?
29.12.2016 16:39:15 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:39:15 localhost <= 192.168.12.20:80 HTTP 161
29.12.2016 16:39:15 Address 36
29.12.2016 16:39:15     run script: val=161 depo={ res: [ 158, 159 ] }
29.12.2016 16:39:15  script return:{ reqsek: 5 } depo={ res: [ 158, 159, 161 ] }
29.12.2016 16:39:15 MG2?
29.12.2016 16:39:20 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:39:20 localhost <= 192.168.12.20:80 HTTP 158
29.12.2016 16:39:20 Address 36
29.12.2016 16:39:20     run script: val=158 depo={ res: [ 158, 159, 161 ] }
29.12.2016 16:39:20  script return:{ reqsek: 5 } depo={ res: [ 158, 159, 161, 158 ] }
29.12.2016 16:39:20 MG2?
29.12.2016 16:39:25 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:39:25 localhost <= 192.168.12.20:80 HTTP 160
29.12.2016 16:39:25 Address 36
29.12.2016 16:39:25     run script: val=160 depo={ res: [ 158, 159, 161, 158 ] }
29.12.2016 16:39:25  script return:{ val: 940, reqsek: 300 } depo={ res: [] }
29.12.2016 16:39:25 Address 36\. Shift request interval: 300 sek.
29.12.2016 16:39:25 MG2?36=940&
29.12.2016 16:39:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:39:35 localhost <= 192.168.12.20:80 HTTP temp:26.20/hum:23.10
29.12.2016 16:39:35 MG2?30_1=26.2&30_2=23.1&
29.12.2016 16:39:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:39:35 localhost <= 192.168.12.20:80 HTTP 26.67
29.12.2016 16:39:35 MG2?341=26.67&
29.12.2016 16:39:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:39:36 localhost <= 192.168.12.20:80 HTTP 128.85
29.12.2016 16:39:36 MG2?342=128.85&
29.12.2016 16:40:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:40:10 localhost <= 192.168.12.20:80 HTTP ff862a831501:25.50;ff6e2a831501:25.56;ff676b821503:25.18
29.12.2016 16:40:10 MG2?31_ff862a831501=25.50&31_ff6e2a831501=25.56&31_ff676b821503=25.18&
29.12.2016 16:40:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:40:35 localhost <= 192.168.12.20:80 HTTP temp:26.20/hum:23.10
29.12.2016 16:40:35 MG2?30_1=26.2&30_2=23.1&
29.12.2016 16:40:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:40:35 localhost <= 192.168.12.20:80 HTTP 26.62
29.12.2016 16:40:35 MG2?341=26.62&
29.12.2016 16:40:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:40:36 localhost <= 192.168.12.20:80 HTTP 128.85
29.12.2016 16:40:36 MG2?342=128.85&
29.12.2016 16:41:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:41:35 localhost <= 192.168.12.20:80 HTTP temp:26.20/hum:23.10
29.12.2016 16:41:35 MG2?30_1=26.2&30_2=23.1&
29.12.2016 16:41:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:41:35 localhost <= 192.168.12.20:80 HTTP 26.62
29.12.2016 16:41:35 MG2?341=26.62&
29.12.2016 16:41:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:41:36 localhost <= 192.168.12.20:80 HTTP 128.85
29.12.2016 16:41:36 MG2?342=128.85&
29.12.2016 16:42:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:42:10 localhost <= 192.168.12.20:80 HTTP ff862a831501:25.50;ff6e2a831501:25.56;ff676b821503:25.18
29.12.2016 16:42:10 MG2?31_ff862a831501=25.50&31_ff6e2a831501=25.56&31_ff676b821503=25.18&
29.12.2016 16:42:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:42:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:42:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:43:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:43:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:43:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:44:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:44:25 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:44:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:44:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:44:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:45:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:45:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:45:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:46:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:46:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:46:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:46:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:47:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:47:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:47:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:48:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:48:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:48:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:48:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:49:25 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:49:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:49:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:49:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:50:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:50:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:50:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:50:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1

intrapro

Для начала нужно посмотреть общий лог системы (PM->Отладчик->Трассировка, кнопка Лог рядом с консольной кнопкой, нет ли там ошибок).

При анализе лога видно, что плагин запросы передает, но не получает ответы. При этом потери связи нет.

Возможно это происходит когда начинают отправляться два разных запроса практически одновременно:

29.12.2016 16:42:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get

29.12.2016 16:42:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d

Можно попробовать разнести запросы. Сейчас все запросы идут с периодом 1 минута. Можно попробовать сделать 60 сек, 61 сек, 62 сек…

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

Также нужно посмотреть, передаются ли на MegaD управляющие команды при нажатии на актуаторы.

Alex_Jet

Лог системы в скриншоте.

Разнести вручную конечно можно - для пробы, но вы же понимаете, что для пользователя отслеживать какой канал через сколько должен опрашиваться - просто не верное решение. Как в самописных скриптах php происходит: он вызывается по cron с заданной периодичностью, в нем же идет последовательный опрос всех каналов. Поэтому и тут надо выстраивать последовательный опрос каналов.

Как мне видится - запускается плагин, проводится анализ какой канал с какой периодичностью должен запускаться, если у нескольких каналов периодичность одинаковая, то ставим их в очередь начиная с меньшего канала. То есть формируем своеобразное cron-расписание.

Лог с командами на включение актюаторов:

29.12.2016 16:49:25 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:49:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:49:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:49:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:50:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:50:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:50:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:50:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:51:26 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=22:1
29.12.2016 16:51:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:51:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:51:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:52:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:52:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:52:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:52:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:53:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:53:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:53:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:54:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:54:25 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
29.12.2016 16:54:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:54:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:54:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:55:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:55:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:55:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:56:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:56:36 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=22:0
29.12.2016 16:56:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:56:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:56:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:57:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:57:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:57:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
29.12.2016 16:58:10 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
29.12.2016 16:58:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
29.12.2016 16:58:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
29.12.2016 16:58:37 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1

Alex_Jet

Только что снова завис. Сделаю разнос по времени, буду наблюдать.

30.12.2016 22:43:49 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
30.12.2016 22:43:49 localhost <= 192.168.12.20:80 HTTP ff862a831501:25.56;ff6e2a831501:25.62;ff676b821503:25.25
30.12.2016 22:43:49 MG2?31_ff862a831501=25.56&31_ff6e2a831501=25.62&31_ff676b821503=25.25&
30.12.2016 22:44:49 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
30.12.2016 22:44:49 localhost <= 192.168.12.20:80 HTTP temp:26.40/hum:24.00
30.12.2016 22:44:49 MG2?30_1=26.4&30_2=24&
30.12.2016 22:44:49 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
30.12.2016 22:44:49 localhost <= 192.168.12.20:80 HTTP 26.52
30.12.2016 22:44:49 MG2?341=26.52&
30.12.2016 22:44:49 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
30.12.2016 22:44:49 localhost <= 192.168.12.20:80 HTTP 128.85
30.12.2016 22:44:49 MG2?342=128.85&
30.12.2016 22:45:49 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
30.12.2016 22:45:49 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
30.12.2016 22:45:49 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
30.12.2016 22:45:50 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
30.12.2016 22:46:28 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=10:0
30.12.2016 22:46:32 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=10:1
30.12.2016 22:46:34 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=27:0
30.12.2016 22:46:36 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=27:1

UPD. Разнес примерно так:

30.12.2016 22:51:22 MegaD plugin has started.
30.12.2016 22:51:22 Listening localhost:8020
30.12.2016 22:51:22 Address 36 (IA36). Loading script
30.12.2016 22:51:22 Polling   192.168.12.20:80/sec/?cmd=all, interval 0 sek
30.12.2016 22:51:22 Polling   192.168.12.20:80/sec/?pt=30&cmd=get, interval 60 sek
30.12.2016 22:51:22 Polling   192.168.12.20:80/sec/?pt=36&cmd=get, interval 320 sek
30.12.2016 22:51:22 Polling   192.168.12.20:80/sec/?pt=31&cmd=list, interval 70 sek
30.12.2016 22:51:22 Polling   192.168.12.20:80/sec/?pt=34&scl=35&i2c_dev=htu21d, interval 61 sek
30.12.2016 22:51:22 Polling   192.168.12.20:80/sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1, interval 62 sek

intrapro

@Alex_Jet:

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

Вы абсолютно правы, это не решение, а только проверка гипотезы, что зависание связано со слишком часто идущими запросами.

@Alex_Jet:

Как в самописных скриптах php происходит: он вызывается по cron с заданной периодичностью, в нем же идет последовательный опрос всех каналов. Поэтому и тут надо выстраивать последовательный опрос каналов.

Как мне видится - запускается плагин, проводится анализ какой канал с какой периодичностью должен запускаться, если у нескольких каналов периодичность одинаковая, то ставим их в очередь начиная с меньшего канала.

В принципе, так и происходит, существует очередь опроса, за один раз передается только один запрос. Если время одинаково, то следующий запрос передается с интервалом 100 мсек.

Alex_Jet

Снова плагин завис:

31.12.2016 02:23:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
31.12.2016 02:23:45 localhost <= 192.168.12.20:80 HTTP temp:26.20/hum:19.30
31.12.2016 02:23:45 MG2?30_1=26.2&30_2=19.3&
31.12.2016 02:24:04 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
31.12.2016 02:24:04 localhost <= 192.168.12.20:80 HTTP ff862a831501:25.43;ff6e2a831501:25.43;ff676b821503:25.06
31.12.2016 02:24:04 MG2?31_ff862a831501=25.43&31_ff6e2a831501=25.43&31_ff676b821503=25.06&
31.12.2016 02:24:14 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
31.12.2016 02:24:14 localhost <= 192.168.12.20:80 HTTP 23.48
31.12.2016 02:24:14 MG2?341=23.48&
31.12.2016 02:24:36 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
31.12.2016 02:24:36 localhost <= 192.168.12.20:80 HTTP 128.85
31.12.2016 02:24:36 MG2?342=128.85&
31.12.2016 02:24:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
31.12.2016 02:24:56 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
31.12.2016 02:25:14 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
31.12.2016 02:25:15 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
31.12.2016 02:25:39 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
31.12.2016 02:25:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
31.12.2016 02:26:16 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d

intrapro

Да, печалька .

Значит, дело не в интервалах запросов.

Добавили в лог более подробный вывод получения ответа (response code), можно обновиться.

А другие Меги работают?

Может, с i2C датчиками все не так просто… Надо разбираться.

С неудержимо наступающим на нас Новым Годом. Интересных задач, успехов и удачи в Новом Году!

Alex_Jet

@intrapro:

Да, печалька .

Значит, дело не в интервалах запросов.

Добавили в лог более подробный вывод получения ответа (response code), можно обновиться.

А другие Меги работают?

Может, с i2C датчиками все не так просто… Надо разбираться.

С неудержимо наступающим на нас Новым Годом. Интересных задач, успехов и удачи в Новом Году!

С новым годом господа!!! Новых расширений, новых идей, новых спонсоров и новых продуктов Вам желаю!

Да, дело не в интервалах, а в "нативном" опросе I2C датчика HTU21D - как только исключил опрос данных каналов (в request убрал период запроса), так плагин продолжал бесконечно трудиться. Другой MegaD-2561 (только они имеют "нативную" поддержку HTU21D) пока нет. Обновил систему, включил опрос канала датчика влажности HTU21D. На утро плагин завис:

02.01.2017 08:59:52 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
02.01.2017 08:59:52 localhost <= 192.168.12.20:80 status code=200
02.01.2017 08:59:52 localhost <= 192.168.12.20:80 data.chunk=176
02.01.2017 08:59:52 localhost <= 192.168.12.20:80 data.end
02.01.2017 08:59:52 localhost <= 192.168.12.20:80 HTTP 176
02.01.2017 08:59:52 Address 36
02.01.2017 08:59:52     run script: val=176 depo={ res: [] }
02.01.2017 08:59:52  script return:{ reqsek: 5 } depo={ res: [ 176 ] }
02.01.2017 08:59:52 Address 36\. Shift request interval: 5 sek.
02.01.2017 08:59:52 MG2?
02.01.2017 08:59:58 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
02.01.2017 08:59:58 localhost <= 192.168.12.20:80 status code=200
02.01.2017 08:59:58 localhost <= 192.168.12.20:80 data.chunk=176
02.01.2017 08:59:58 localhost <= 192.168.12.20:80 data.end
02.01.2017 08:59:58 localhost <= 192.168.12.20:80 HTTP 176
02.01.2017 08:59:58 Address 36
02.01.2017 08:59:58     run script: val=176 depo={ res: [ 176 ] }
02.01.2017 08:59:58  script return:{ reqsek: 5 } depo={ res: [ 176, 176 ] }
02.01.2017 08:59:58 MG2?
02.01.2017 09:00:03 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
02.01.2017 09:00:03 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:00:03 localhost <= 192.168.12.20:80 data.chunk=174
02.01.2017 09:00:03 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:00:03 localhost <= 192.168.12.20:80 HTTP 174
02.01.2017 09:00:03 Address 36
02.01.2017 09:00:03     run script: val=174 depo={ res: [ 176, 176 ] }
02.01.2017 09:00:03  script return:{ reqsek: 5 } depo={ res: [ 176, 176, 174 ] }
02.01.2017 09:00:03 MG2?
02.01.2017 09:00:08 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
02.01.2017 09:00:08 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:00:08 localhost <= 192.168.12.20:80 data.chunk=176
02.01.2017 09:00:08 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:00:08 localhost <= 192.168.12.20:80 HTTP 176
02.01.2017 09:00:08 Address 36
02.01.2017 09:00:08     run script: val=176 depo={ res: [ 176, 176, 174 ] }
02.01.2017 09:00:08  script return:{ reqsek: 5 } depo={ res: [ 176, 176, 174, 176 ] }
02.01.2017 09:00:08 MG2?
02.01.2017 09:00:13 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get
02.01.2017 09:00:13 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:00:13 localhost <= 192.168.12.20:80 data.chunk=176
02.01.2017 09:00:13 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:00:13 localhost <= 192.168.12.20:80 HTTP 176
02.01.2017 09:00:13 Address 36
02.01.2017 09:00:13     run script: val=176 depo={ res: [ 176, 176, 174, 176 ] }
02.01.2017 09:00:13  script return:{ val: 1110, reqsek: 300 } depo={ res: [] }
02.01.2017 09:00:13 Address 36\. Shift request interval: 300 sek.
02.01.2017 09:00:13 MG2?36=1110&
02.01.2017 09:00:35 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
02.01.2017 09:00:35 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:00:35 localhost <= 192.168.12.20:80 data.chunk=ff862a831501:25.12;ff6e2a831501:25.18;ff676b821503:24.81
02.01.2017 09:00:35 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:00:35 localhost <= 192.168.12.20:80 HTTP ff862a831501:25.12;ff6e2a831501:25.18;ff676b821503:24.81
02.01.2017 09:00:35 MG2?31_ff862a831501=25.12&31_ff6e2a831501=25.18&31_ff676b821503=24.81&
02.01.2017 09:00:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 data.chunk=temp:25.90/hum:19.80
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 HTTP temp:25.90/hum:19.80
02.01.2017 09:00:45 MG2?30_1=25.9&30_2=19.8&
02.01.2017 09:00:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 data.chunk=21.90
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:00:45 localhost <= 192.168.12.20:80 HTTP 21.90
02.01.2017 09:00:45 MG2?342=21.9&
02.01.2017 09:01:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 data.chunk=ff862a831501:25.12;ff6e2a831501:25.18;ff676b821503:24.81
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 HTTP ff862a831501:25.12;ff6e2a831501:25.18;ff676b821503:24.81
02.01.2017 09:01:45 MG2?31_ff862a831501=25.12&31_ff6e2a831501=25.18&31_ff676b821503=24.81&
02.01.2017 09:01:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 data.chunk=temp:25.80/hum:19.90
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:01:45 localhost <= 192.168.12.20:80 HTTP temp:25.80/hum:19.90
02.01.2017 09:01:45 MG2?30_1=25.8&30_2=19.9&
02.01.2017 09:01:46 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
02.01.2017 09:01:46 localhost <= 192.168.12.20:80 status code=200
02.01.2017 09:01:46 localhost <= 192.168.12.20:80 data.chunk=21.92
02.01.2017 09:01:46 localhost <= 192.168.12.20:80 data.end
02.01.2017 09:01:46 localhost <= 192.168.12.20:80 HTTP 21.92
02.01.2017 09:01:46 MG2?342=21.92&
02.01.2017 09:02:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
02.01.2017 09:02:46 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
02.01.2017 09:02:55 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
02.01.2017 09:03:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
02.01.2017 09:03:46 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
02.01.2017 09:04:05 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
02.01.2017 09:04:45 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
02.01.2017 09:04:46 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
02.01.2017 09:05:13 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=36&cmd=get

Включение/отключение актюатора:

02.01.2017 10:41:56 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
02.01.2017 10:42:14 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=10:0
02.01.2017 10:42:15 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
02.01.2017 10:42:16 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=10:1
02.01.2017 10:42:56 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
02.01.2017 10:42:56 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d

intrapro

Да, непонятно, почему связь есть, а ответа от MegaD нет. Нужен анализ сетевого трафика.

Можно установить tcpdump:

sudo apt-get install tcpdump

и посмотреть трафик с MegaD :

 sudo tcpdump host 192.168.0.14  // MegaD IP

Стандартный обмен пакетами такой :

`10:56:21.270792 IP 192.168.0.238.34130 > 192.168.0.14.http: Flags [s], ..length 0 //SYN- Запрос связи
10:56:21.271635 IP 192.168.0.14.http > 192.168.0.238.34130: Flags [S.],..length 0 // подтв от Mega 
10:56:21.271686 IP 192.168.0.238.34130 > 192.168.0.14.http: Flags [.],... length 0 // связь установлена
10:56:21.271937 IP 192.168.0.238.34130 > 192.168.0.14.http: Flags [P.],..length 76 // PUSH- плагин передает запрос
10:56:21.273701 IP 192.168.0.14.http > 192.168.0.238.34130: Flags [.],... length 0  // подтв от Mega
10:56:21.274157 IP 192.168.0.14.http > 192.168.0.238.34130: Flags [FP.],.length 41 // FIN&PUSH- ответ Mega, конец связи
10:56:21.276393 IP 192.168.0.238.34130 > 192.168.0.14.http: Flags [F.],.. length 0  // FIN - конец св. 
10:56:21.277288 IP 192.168.0.14.http > 192.168.0.238.34130: Flags [.],.... length 0 // Соединение закрыто` 

Хорошо бы посмотреть, какие идут пакеты в случае зависания.[/s]

Alex_Jet

@intrapro:

Да, непонятно, почему связь есть, а ответа от MegaD нет. Нужен анализ сетевого трафика.

Повторилась ситуация с кучей запросов к MegaD и отсутствием ответа от нее. До этого экспериментировал с прошивкой MegaD…

Я Вас удивлю - при зависании плагина (в логе - постоянные запросы к MegaD) обмена пакетами между сервером и MegaD вообще нет! Сервер общается с другими MegaD, с компьютером, роутером, а с искомым MegaD - нет!

При этом! При замыкании входа на MegaD плагин обрабатывает запрос и отвечает на него. Вот что есть:

05.01.2017 23:27:42 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
05.01.2017 23:27:42 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
05.01.2017 23:27:42 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d
05.01.2017 23:28:27 192.168.12.20 => localhost:8020 HTTP GET /mod_megad.php?pt=1&cnt=1&mdid=
05.01.2017 23:28:27 MG2?8=TG&
05.01.2017 23:28:27 192.168.12.20 <= localhost:8020 8:2
05.01.2017 23:28:41 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
05.01.2017 23:28:42 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
05.01.2017 23:28:42 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1
05.01.2017 23:28:42 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=34&scl=35&i2c_dev=htu21d

TCP dump показал обмен пакетами только при вышеописанной ситуации (замыкание входа MegaD). Тут 192.168.12.10 - сервер, 192.168.12.20 - MegaD, Neb.lan - компьютер:

`23:28:38.996222 IP 192.168.12.20.2883 > 192.168.12.10.8020: Flags [s], seq 14080, win 768, options [mss 790], length 0
23:28:38.996494 IP 192.168.12.10.8020 > 192.168.12.20.2883: Flags [S.], seq 3115332790, ack 14081, win 29200, options [mss 1460], length 0
23:28:38.997167 IP 192.168.12.20.2883 > 192.168.12.10.8020: Flags [.], ack 1, win 1024, length 0
23:28:38.998114 IP 192.168.12.20.2883 > 192.168.12.10.8020: Flags [P.], seq 1:108, ack 1, win 1024, length 107
23:28:38.998340 IP 192.168.12.10.8020 > 192.168.12.20.2883: Flags [.], ack 108, win 29200, length 0
23:28:39.036567 IP 192.168.12.10.http > NeB.lan.63743: Flags [P.], seq 4072708747:4072708826, ack 2592931699, win 1332, length 79
23:28:39.044673 IP 192.168.12.10.8020 > 192.168.12.20.2883: Flags [P.], seq 1:162, ack 108, win 29200, length 161
23:28:39.046796 IP 192.168.12.20.2883 > 192.168.12.10.8020: Flags [F.], seq 108, ack 162, win 1024, length 0
23:28:39.059605 IP 192.168.12.10.8020 > 192.168.12.20.2883: Flags [F.], seq 162, ack 109, win 29200, length 0
23:28:39.060672 IP 192.168.12.20.2883 > 192.168.12.10.8020: Flags [.], ack 163, win 1024, length 0
23:28:39.239707 IP NeB.lan.63743 > 192.168.12.10.http: Flags [.], ack 79, win 16482, length 0
23:28:41.586502 IP NeB.lan.53027 > 192.168.12.10.http: Flags [P.], seq 604146295:604146304, ack 76401422, win 16226, length 9
23:28:41.590171 IP 192.168.12.10.http > NeB.lan.53027: Flags [P.], seq 1:12, ack 9, win 509, length 11
23:28:41.788640 IP NeB.lan.53027 > 192.168.12.10.http: Flags [.], ack 12, win 16224, length 0
23:28:44.232830 ARP, Request who-has 192.168.12.10 tell 192.168.12.1, length 48
23:28:44.233006 ARP, Reply 192.168.12.10 is-at b8:27:eb:93:1e:de (oui Unknown), length 46
23:28:49.570500 IP NeB.lan.63743 > 192.168.12.10.http: Flags [P.], seq 1:10, ack 79, win 16482, length 9
23:28:49.574795 IP 192.168.12.10.http > NeB.lan.63743: Flags [P.], seq 79:90, ack 10, win 1332, length 11
23:28:49.798720 IP NeB.lan.63743 > 192.168.12.10.http: Flags [.], ack 90, win 16479, length 0`[/s]

intrapro

Alex_Jet, правда, удивительно… Спасибо за подробное описание.

Будем рыть глубже

Пожалуйста, обновите систему, добавлено логирование событий сокета.

Упс...Логирование пока убрали, там ошибка. Последний релиз v17.01.06.01 с обычным логированием.

Alex_Jet

Да, обновил и ничего нового не увидел:). Буду ждать когда добавите.

Alex_Jet

С Рождеством весь Ваш коллектив!!!

Сегодня выловил еще вот такой момент:

07.01.2017 16:22:53 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
07.01.2017 16:22:53 localhost <= 192.168.12.20:80 HTTP busy
07.01.2017 16:22:53 MG2?
07.01.2017 16:23:53 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
07.01.2017 16:23:53 localhost <= 192.168.12.20:80 HTTP temp:26.20/hum:15.30
07.01.2017 16:23:53 MG2?30_1=26.2&30_2=15.3&
07.01.2017 16:23:53 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
07.01.2017 16:23:53 localhost <= 192.168.12.20:80 HTTP busy
07.01.2017 16:23:53 MG2?
07.01.2017 16:24:53 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
07.01.2017 16:24:53 localhost <= 192.168.12.20:80 HTTP temp:26.20/hum:15.30
07.01.2017 16:24:53 MG2?30_1=26.2&30_2=15.3&
07.01.2017 16:24:53 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
07.01.2017 16:24:53 localhost <= 192.168.12.20:80 HTTP busy
07.01.2017 16:24:53 MG2?
07.01.2017 16:25:53 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
07.01.2017 16:25:53 localhost <= 192.168.12.20:80 HTTP temp:26.30/hum:15.50
07.01.2017 16:25:53 MG2?30_1=26.3&30_2=15.5&
07.01.2017 16:25:53 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
07.01.2017 16:25:53 localhost <= 192.168.12.20:80 HTTP busy
07.01.2017 16:25:53 MG2?

Порт 31 сконфигурирован как 1-wire bus, на нем сейчас висит 3 датчика DS18B20. Период конвертации данных в MegaD - 30 секунд. Когда запрос попадает на момент конвертации, то MegaD выдает "busy". Однако это "busy" в логах плагина длилось порядка 1 часа, пока я не перезагрузил плагин. Как Вы понимаете, 60 раз попадать на момент конвертации данных просто невозможно! Такое ощущение, что это где-то закэшировалось…

intrapro

Alex_Jet, спасибо, и Вас с Рождеством!!! Готово рождественское обновление

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

2. Добавлен флаг Debug - сохранение флагов трассировки, suspend и log для плагинов при перезагрузке.

Alex_Jet

Спасибо, обновлюсь.

Тут уже методом перебора пытаюсь выявить из-за чего плагин зависает, поэтому отключаю по одному из датчиков. Отключил датчик СО2, показания по которому обрабатываются скриптом, убрав период опроса в Request, однако при старте плагина скрипт загружается, идет первый опрос и на этом заканчивается. По моему это не правильно. По идее если убрали период опроса, то и скрипт не должен загружаться? Ну или как-то так - Вы сами определите как должно быть правильно.

08.01.2017 20:25:59 MegaD plugin has started.
08.01.2017 20:25:59 Listening localhost:8020
08.01.2017 20:25:59 Address 36 (IA36). Loading script
08.01.2017 20:25:59 Polling   192.168.12.20:80/sec/?cmd=all, interval 0 sek
08.01.2017 20:25:59 Polling   192.168.12.20:80/sec/?pt=30&cmd=get, interval 60 sek
08.01.2017 20:25:59 Polling   192.168.12.20:80/sec/?pt=31&cmd=list, interval 60 sek
08.01.2017 20:25:59 localhost => 192.168.12.20:80 HTTP GET /sec/?cmd=all
08.01.2017 20:25:59 localhost <= 192.168.12.20:80 HTTP OFF/0;OFF/0;OFF/0;OFF/0;OFF/0;OFF/0;OFF/0;OFF;ON;OFF;ON;OFF;OFF;OFF;ON;OFF/0;OFF/0;OFF/0;OFF/0;OFF/0;OFF/0;OFF/0;OFF;OFF;OFF;OFF;ON;OFF;OFF;ON;temp:25.30/hum:14.10;;OFF;OFF;;OFF;160;ON
08.01.2017 20:25:59 Address 36
08.01.2017 20:25:59     run script: val=160 depo={}
08.01.2017 20:25:59  script return:{ reqsek: 5 } depo={ res: [ 160 ] }
08.01.2017 20:25:59 MG2?0=0&1=0&2=0&3=0&4=0&5=0&6=0&7=0&8=1&9=0&10=1&11=0&12=0&13=0&14=1&15=0&16=0&17=0&18=0&19=0&20=0&21=0&22=0&23=0&24=0&25=0&26=1&27=0&28=0&29=1&30_1=25.3&30_2=14.1&31=0&32=0&33=0&34=0&35=0&37=1&
08.01.2017 20:26:59 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=30&cmd=get
08.01.2017 20:27:00 localhost <= 192.168.12.20:80 HTTP temp:24.80/hum:8.40
08.01.2017 20:27:00 MG2?30_1=24.8&30_2=8.4&

Сам скрипт, который Владимир на ab-log выкладывал:

function (val, depo)
{   var result;

   if (!depo.res) depo.res = [];   
   depo.res.push(val);  

   if (depo.res.length < 5)    return { reqsek:5 }; // Нужны еще измерения, значение не возвращаем
   depo.res.sort();   

   result = ((Math.round((depo.res[1] + depo.res[2] + depo.res[3]) / 3) - 100 ) * 10 + 350);

   depo.res = []; // Перед следующими измерениями сбрасываем массив
   return { val:result, reqsek:300 }; // Восстанавливаем период 5 мин
}

Alex_Jet

@intrapro:

Alex_Jet, спасибо, и Вас с Рождеством!!! Готово рождественское обновление

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

2. Добавлен флаг Debug - сохранение флагов трассировки, suspend и log для плагинов при перезагрузке.

1. В логе плагина ничего не увидел нового… где смотреть? UPD: все увидел! Просто логи плагинов после обновления выключились....

2. Где это найти?

Нельзя ли в каналы плагинов вывести столбец "Период опроса"? Правда вероятно для маленьких разрешений экрана надо будет горизонтальный скролбар добавить... иначе, например, у меня при 1280х720 содержание столбца "Устройства в системе" уже обрезано.

Вот такой вредный busy на канале с 1-wire bus! Так понимаю, что на протяжении примерно 30 минут запрос попадает на конвертацию температуры:

08.01.2017 22:53:26 
08.01.2017 22:53:26 localhost => 192.168.12.20:80 HTTP GET /sec/?pt=31&cmd=list
08.01.2017 22:53:26 localhost <=>192.168.12.20:80 socket handle=17\. Header: GET /sec/?pt=31&cmd=list HTTP/1.1
Host: 192.168.12.20
Connection: close

08.01.2017 22:53:26 localhost <= 192.168.12.20:80 response: statusCode=200 contentType = text/html
08.01.2017 22:53:26 localhost <= 192.168.12.20:80 HTTP busy
08.01.2017 22:53:26 MG2?
08.01.2017 22:53:26 localhost <=>192.168.12.20:80 socket closed

intrapro

@Alex_Jet:

Отключил датчик СО2, показания по которому обрабатываются скриптом, убрав период опроса в Request, однако при старте плагина скрипт загружается, идет первый опрос и на этом заканчивается. По моему это не правильно. По идее если убрали период опроса, то и скрипт не должен загружаться?

Сейчас скрипт грузится, если для канала стоит галка: "Запускать скрипт обработки данных" (колонка Скрипт).

Если галку убрать, скрипт не пропадет, будет доступен для редактирования, просто не будет загружаться.

Связи с периодом опроса канала нет, т.к. значение может читаться при общем опросе. Или как для двойных датчиков или 1-Wire - период м.б. ноль, но данные можно обработать скриптом.

@Alex_Jet:

Нельзя ли в каналы плагинов вывести столбец "Период опроса"? Правда вероятно для маленьких разрешений экрана надо будет горизонтальный скролбар добавить… иначе, например, у меня при 1280х720 содержание столбца "Устройства в системе" уже обрезано.

Горизонтальный скролбар убирали из эстетических соображений :). В планах у нас включена задача: настраивать интерактивно ширину и состав столбцов таблиц в PM.

@Alex_Jet:

Просто логи плагинов после обновления выключились….

Да, в новом релизе добавлен флаг Debug: "Запустить в режиме отладки".

Устанавливается PM: Система - Системные настройки - Параметры запуска сервера.

При установленном Debug после перезагрузки:

сохраняются флаги suspend и log для плагинов,
сохраняются системные флаги логирования (Трассировка).

Если флаг сброшен, при перезагрузке все это сбрасывается (рабочий режим).

intrapro

@Alex_Jet:

Порт 31 сконфигурирован как 1-wire bus, на нем сейчас висит 3 датчика DS18B20. Период конвертации данных в MegaD - 30 секунд. Когда запрос попадает на момент конвертации, то MegaD выдает "busy". Однако это "busy" в логах плагина длилось порядка 1 часа, пока я не перезагрузил плагин.

….

Вот такой вредный busy на канале с 1-wire bus! Так понимаю, что на протяжении примерно 30 минут запрос попадает на конвертацию температуры

А сколько времени MegaD находится в состоянии busy? Если речь идет о 1-2 сек, то попав в зону busy, можно там и остаться, если период опроса кратен 30 сек ( в данном случае 60 сек). Вариант решения - сделать период не кратным 30 сек - 67 сек, например.

Alex_Jet

Как ответил разработчик MegaD - период конвертации для любого количества датчиков равен 750 мС. Конечно можно разносить период опроса вручную, но вероятно лучше программно обрабатывать тот же "busy" - если ответ такой, то повторяем запрос через 1 секунду, иначе следующий интервал опроса тот что в request.

Кстати, в настройках железа устройств есть "Специальное значение, означающее ошибку датчика" как это работает? То есть впишу я туда "busy" и что сделает система когда датчик ответит ей "busy"? Надо бы это осветить!

Пока больше зависаний плагина не могу зафиксировать. Спустя примерно 5 часов виснет сама MegaD! Сегодня поменяю железку на новую - тут виновата либо железо, либо система…

intrapro

@Alex_Jet:

Как ответил разработчик MegaD - период конвертации для любого количества датчиков равен 750 мС. Конечно можно разносить период опроса вручную, но вероятно лучше программно обрабатывать тот же "busy" - если ответ такой, то повторяем запрос через 1 секунду, иначе следующий интервал опроса тот что в request..

Да, программно обрабатывать можно, просто не хотелось привязываться к деталям реализации…

И жестко программировать повтор запросов, устройство довольно нежное

Поскольку у нас нет возможности проверить (у нас есть только MegaD 238), проверьте пожалуйста, если цикл сдвинуть - ответ после busy все же придет?

@Alex_Jet:

Кстати, в настройках железа устройств есть "Специальное значение, означающее ошибку датчика" как это работает? То есть впишу я туда "busy" и что сделает система когда датчик ответит ей "busy"? Надо бы это осветить!

Эту настройку плагин Mega пока не использует. Стандартное использование - если с канала читается что-то не то, то просто выставляется флаг ошибки датчика, будет алерт и соотв. индикация.

@Alex_Jet:

Пока больше зависаний плагина не могу зафиксировать. Спустя примерно 5 часов виснет сама MegaD! Сегодня поменяю железку на новую - тут виновата либо железо, либо система…

Как в этом случае отрабатывает плагин? Ошибка индицируется? Что в логах?

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