Плагин MegaD

Alex_Jet

Решил еще немного разжевать что должен обрабатывать плагин MegaD.

По подключению датчиков по I2C есть 2 варианта:

1. "Нативное" подключение - с настройкой порта MegaD на работу с конкретным датчиком:

В таком случае можно:

А. Опрашивать канал "штатным" образом только по одному каналу (по факту нужно 2-3 канала в зависимости от того сколько параметров отдает датчик) - http://192.168.0.14/sec/?pt=32&cmd=get - и это сейчас работает (парсится и привязывается к соответствующим каналам):

07.11 12:04:35.614 megad5: localhost => 192.168.11.25 HTTP GET /sec/?pt=32&cmd=get
07.11 12:04:35.640 megad5: localhost <= 192.168.11.25  response: statusCode=200 contentType = text/html
07.11 12:04:35.640 megad5:  body: temp:28.16/press:746.21
07.11 12:04:35.641 IH: get [{"id":"32_1","value":"28.16"},{"id":"32_2","value":"746.21"}]
07.11 12:04:35.641 IH: set {"STEMP1_02":{"aval":"28.16"},"SHUMIDITY1_02":{"aval":"746.21"}}

Б. Опрашивать канал по конкретным параметрам датчика - (Температура - http://192.168.0.14/sec/?pt=32&scl=34&i2c_dev=bmp180&i2c_par=1, давление - http://192.168.0.14/sec/?pt=32&scl=34&i2c_dev=bmp180) - и это сейчас не работает (значения не привязываются к соответствующим каналам):

07.11 11:55:02.303 megad5: localhost => 192.168.11.25 HTTP GET /sec/?pt=32&scl=34&i2c_dev=bmp180&i2c_par=1
07.11 11:55:02.329 megad5: localhost <= 192.168.11.25  response: statusCode=200 contentType = text/html
07.11 11:55:02.330 megad5:  body: 28.16
07.11 11:55:02.330 IH: get []
07.11 11:55:02.331 IH: set {}
07.11 11:55:02.504 megad5: 
07.11 11:55:02.504 megad5: localhost => 192.168.11.25 HTTP GET /sec/?pt=32&scl=34&i2c_dev=bmp180
07.11 11:55:02.532 megad5: localhost <= 192.168.11.25  response: statusCode=200 contentType = text/html
07.11 11:55:02.532 megad5:  body: 746.21
07.11 11:55:02.533 IH: get []
07.11 11:55:02.533 IH: set {}

2. Параллельное подключение датчиков к I2C шине. В этом случае в выпадающем списке можно выбрать ANY или SSD1306 (в таком случае контроллер при загрузке будет инициализировать OLED):
[attachment=0]MegaD_I2C_ANY&SSD1306.png[/attachment]
В таком случае данные с датчиков можно снимать только по варианту 1Б (см.выше).

По обработке данных плагином при перезагрузке MegaD и при старте самого плагина:

1. В случае если MegaD по каким-либо причинам перезагрузилась (подача питания, сработал watchdog, нажата кнопка сброса, изменены параметры, приводящие к перезагрузке), то есть отправила на сервер команду st=1 необходимо:

А. Записать в журнал это событие (для дальнейшего поиска неисправностей)

12.10 12:36:15.112 megad5: 192.168.11.25 => localhost:11025 HTTP GET /mod_megad.php?st=1
12.10 12:36:15.112 megad5: 192.168.11.25 <= localhost:11025

Б. Принять сообщения от MegaD по не нормативному состоянию каналов и перевести их в нужное состояние

12.10 12:36:15.125 megad5: 192.168.11.25 => localhost:11025 HTTP GET /mod_megad.php?pt=5&cnt=1
12.10 12:36:15.126 IH: get [{"id":"5","value":"1"}]
12.10 12:36:15.127 IH: set {"SGERKON4_02":{"dval":0}}
12.10 12:36:15.127 megad5: 192.168.11.25 <= localhost:11025 
12.10 12:36:15.140 megad5: 192.168.11.25 => localhost:11025 HTTP GET /mod_megad.php?pt=6&cnt=1
12.10 12:36:15.140 IH: get [{"id":"6","value":"1"}]
12.10 12:36:15.141 IH: set {"SMOTION4_02":{"dval":0}}
12.10 12:36:15.141 megad5: 192.168.11.25 <= localhost:11025 
12.10 12:36:15.154 megad5: 192.168.11.25 => localhost:11025 HTTP GET /mod_megad.php?pt=19&cnt=1
12.10 12:36:15.155 IH: get [{"id":"19","value":"1"}]
12.10 12:36:15.155 IH: set {"SFIRE1_04":{"dval":0}}
12.10 12:36:16.082 megad5: 192.168.11.25 => localhost:11025 HTTP GET /mod_megad.php?pt=6&m=2&cnt=1
12.10 12:36:16.083 IH: get [{"id":"6","value":"1"}]
12.10 12:36:16.083 IH: set {"SMOTION4_02":{"dval":0}}
12.10 12:36:16.084 megad5: 192.168.11.25 <= localhost:11025 
12.10 12:36:16.094 megad5: 192.168.11.25 => localhost:11025 HTTP GET /mod_megad.php?pt=5&m=2&cnt=1
12.10 12:36:16.095 IH: get [{"id":"5","value":"1"}]
12.10 12:36:16.095 IH: set {"SGERKON4_02":{"dval":0}}
12.10 12:36:16.096 megad5: 192.168.11.25 <= localhost:11025 
12.10 12:36:16.107 megad5: 192.168.11.25 => localhost:11025 HTTP GET /mod_megad.php?pt=19&m=2&cnt=1
12.10 12:36:16.108 IH: get [{"id":"19","value":"1"}]
12.10 12:36:16.109 IH: set {"SFIRE1_04":{"dval":0}}
12.10 12:36:16.109 megad5: 192.168.11.25 <= localhost:11025

В. Поскольку MegaD уже сообщила о том какие каналы находятся в не нормативном состоянии, то можно не запрашивать состояние всех остальных (cmd=all), а принять их состояние за нулевое (правда могут быть каналы с состоянием "undefined" - см.ниже).

Г. Провести опрос каналов, которые должны периодически опрашиваться (период опроса отличен от 0).

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

Е. Установить системное время в контроллере. Как вариант, сделать это опцией в настройках самого плагина

http://192.168.0.14/sec/?cf=7&stime=10:57:06:4

2. В случае если произошла перезагрузка плагина (изменение параметров каналов и прочее), то необходимо:

А. Запросить состояние всех каналов (cmd=all) и перевести их в соответствующее состояние. Учесть что некоторые каналы имеют состояние "undefined" (в ответе присутствует ";;;"). Это либо канал с шинами 1WBUS и I2C, либо считыватель типа TouchButton (1W/Wiegand) - соответственно, первые должны быть "поставлены" на периодический опрос в каналах плагина, а вторые - отдают команды серверу при внешнем воздействии.

Б. Провести опрос каналов, которые должны периодически опрашиваться (период опроса отличен от 0).

По обработке показаний датчиков. Нужно сделать как было в Berry - к каждому каналу можно было привязать свой скрипт обработки данных! Для многих систем актуально не дергаться по каждому дуновению ветра, а усреднять несколько показаний от датчиков, откидывая "бракованные"! Например, подобным скриптом:

function (val, depo)
{  var result;

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

   if (depo.res.length < 5) //Нужны еще измерения, значение не возвращаем
   return { reqsek:60 };
   else
   { depo.res.sort();
     result = ((depo.res[1] + depo.res[2] + depo.res[3]) / 3).toFixed(2);
   }

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

По состоянию устройства-плагина для контроллера MegaD уже писал тут - https://frm.intrahouse.ru/viewtopic.php?f=18&t=5312&start=40#p7901

По RGB-лентам и выводу информации на OLED уже писал тут - https://frm.intrahouse.ru/viewtopic.php?f=18&t=5312&start=50#p7936.

Если по RGB-лентам все понятно - устройство, привязанное к нужному каналу MegaD формирует цвет в шестнадцатеричном формате и это значение улетает в контроллер командой:

http://192.168.0.14/sec/?pt=35&ws=FF0000

А вот по OLED - GUI сделать сложнее, но на данном этапе можно отсылать информацию на дисплей с помощью скриптов типа:

/** 
* @name Вывод значения на OLED крупным шрифтом
* @desc При изменении значения, получаемого с датчика температуры, оно отображается
*  крупным шрифтом на OLED
*/
const dt = DeviceT("SensorA", "Датчик температуры");
const text = 'Температура';

const script = {
    start() {
    	this.pluginCommand({unit:'megad1', command:'/sec/?pt=33&text=' +text+ '&col=5&row=0'});
    	this.pluginCommand({unit:'megad1', command:'/sec/?pt=33&text=' +dt.aval+ ':'});
    }
};

Все бы было очень хорошо с OLED в таком случае, особенно если бы Вы помогли портировать скрипт центрирования Андрея с PHP на JS, а также помогли правильно вывести русские буквы на дисплее (кодовая страница CP866).

По использованию MegaD в качестве SMS-шлюза. На самом деле не являюсь сторонником использовать MegaD в качестве шлюза. Все же подсоединение GSM-модема к MegaD - это мера для более гибкой локальной работы контроллера и возможности создания GSM-сигнализации. По надежности - так как помимо самого GSM-модема, все же используем и MegaD, хотя и без преобразователей UART-USB, которые по сути есть в обычных USB GSM-модемах, то с учетом "стороннего" питания контроллера, свитчей и их питания, длинных патчкордов и их контактов мне кажется что USB-модем, воткнутый непосредственно в сервер, надежнее.

Опять же, если из скриптов можно будет давать команду на MegaD, то никаких проблем в организации из контроллера GSM-шлюз не вижу. Разбор SMS можно проводить из раздела "Расширения" плагина, обрабатывая входящий "trap" контроллера.
MegaD_I2C_ANY&SSD1306.png

intrapro

@Alex_Jet:

Решил еще немного разжевать что должен обрабатывать плагин MegaD.

…

Чуть позже распишу по действиям при перезагрузке MegaD (после загрузки выдает st=1) и при старте плагина Megad.

Большое спасибо, надеемся также на помощь при тестировании, т к имеем только MegaD 328 с довольно старой прошивкой.

Alex_Jet

@intrapro:

Большое спасибо, надеемся также на помощь при тестировании, т к имеем только MegaD 328 с довольно старой прошивкой.

Вы бы обратились к разработчику с просьбой предоставить новую MegaD для обкатки серверных решений. А лучше к товарищу d.v.ermakov - чтобы он предоставил Вам свой вариант перспективной MegaD2561-24I14O-RTC-POE. Мне реализация очень понравилась - для УД самое то, хотя с расширенным функционалом program и на промышленные объекты можно было бы ставить (я бы наши Овен с радостью на них заменил ).

Alex_Jet

@intrapro:

Большое спасибо, надеемся также на помощь при тестировании

Коллеги! Очень жду доработку плагина. Уже очень хочется перейти на Cherry.

intrapro

@Alex_Jet:

Коллеги! Очень жду доработку плагина. Уже очень хочется перейти на Cherry.

Добрый день.

Решили сначала закончить переработку движка сценариев.

Но до Нового года обновим точно

Alex_Jet

Обновления, связанные с каналами MegaD-2561 в режиме DSEN/1WBUS и OUT/DS2413. На оба таких канала можно одновременно подключить как DS18B20, так и DS2413 - по несколько штук в том числе! В общем случае, при запросе вида http://192.168.0.14/sec/?pt=32&cmd=list будет выдано следующее:

aad6a070000:25.43;79c439000000:OFF/ON

Отличия настроек каналов DSEN/1WBUS и OUT/DS2413:

1. DSEN/1WBUS - контроллер сам посылает запрос на конвертацию температуры. Поэтому при переходе по ссылке Device List (или запросе http://192.168.0.14/sec/?pt=32&cmd=list) по адресам датчиков температуры будет выдано действительное значение температур, а по адресам DS2413 - состояние их портов:

aad6a070000:25.43;85a56a070000:32.43;79c439000000:OFF/OFF;c6c439000000:ON/ON

2. OUT/DS2413 - контроллер не посылает запрос на конвертацию температуры, а в веб-интерфейсе контроллера есть кнопки ON/OFF для включения/отключения портов А и В DS2413. При этом если подключено несколько DS2413, то из веб-интерфейса контроллера будут включаться/выключаться порты всех DS2413 (соответственно - А или В). Раздельно можно включать только с помощью сервера - обращаясь к контроллеру с конкретным адресом:

http://192.168.0.14/sec/?cmd=32A:1&addr=c6c439000000

При переходе по ссылке Device List (или запросе http://192.168.0.14/sec/?pt=32&cmd=list) по адресам датчиков температуры будет выдано значение температур до их конвертации, а по адресам DS2413 - состояние их портов:

aad6a070000:85.00;85a56a070000:85.00;79c439000000:OFF/OFF;c6c439000000:ON/ON

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

http://192.168.0.14/sec/?pt=32&cmd=conv

Поскольку данные к каналам будут привязываться по адресам устройств, а запрос необходимо выполнять всего лишь раз, то логично в одном канале производить запрос на конвертацию температур, а в другом запрос по значениям. То есть для всей кучки из 100500 датчиков, подключенных к порту MegaD-2561 с режимом OUT/DS2413 нужно будет два запроса - на конвертацию температуры и запрос значений.

intrapro

@Alex_Jet:

Обновления, связанные с каналами MegaD-2561 в режиме DSEN/1WBUS и OUT/DS2413. На оба таких канала можно одновременно подключить как DS18B20, так и DS2413 - по несколько штук в том числе! В общем случае, при запросе вида http://192.168.0.14/sec/?pt=32&cmd=list будет выдано следующее:

> aad6a070000:25.43;79c439000000:OFF/ON
>

Отличия настроек каналов DSEN/1WBUS и OUT/DS2413:

1. DSEN/1WBUS - контроллер сам посылает запрос на конвертацию температуры. Поэтому при переходе по ссылке Device List (или запросе http://192.168.0.14/sec/?pt=32&cmd=list) по адресам датчиков температуры будет выдано действительное значение температур, а по адресам DS2413 - состояние их портов:

> aad6a070000:25.43;85a56a070000:32.43;79c439000000:OFF/OFF;c6c439000000:ON/ON
>

2. OUT/DS2413 - контроллер не посылает запрос на конвертацию температуры, а в веб-интерфейсе контроллера есть кнопки ON/OFF для включения/отключения портов А и В DS2413. При этом если подключено несколько DS2413, то из веб-интерфейса контроллера будут включаться/выключаться порты всех DS2413 (соответственно - А или В). Раздельно можно включать только с помощью сервера - обращаясь к контроллеру с конкретным адресом:

> http://192.168.0.14/sec/?cmd=32A:1&addr=c6c439000000
>

При переходе по ссылке Device List (или запросе http://192.168.0.14/sec/?pt=32&cmd=list) по адресам датчиков температуры будет выдано значение температур до их конвертации, а по адресам DS2413 - состояние их портов:

> aad6a070000:85.00;85a56a070000:85.00;79c439000000:OFF/OFF;c6c439000000:ON/ON
>

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

> http://192.168.0.14/sec/?pt=32&cmd=conv
>

Поскольку данные к каналам будут привязываться по адресам устройств, а запрос необходимо выполнять всего лишь раз, то логично в одном канале производить запрос на конвертацию температур, а в другом запрос по значениям. То есть для всей кучки из 100500 датчиков, подключенных к порту MegaD-2561 с режимом OUT/DS2413 нужно будет два запроса - на конвертацию температуры и запрос значений.

Често говоря, очень не хочется тащить все эти A и B в код плагина.

Вероятно, оптимальный подход - сделать для опросов двухуровневую таблицу "Запрос - связанные каналы", с настройкой парсинга для канала. Примерно как в новом http плагине, только добавив все эти прыжки в связи с st=1 и cmd=all

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

В целом объем настройки увеличится, но зато всю обработку вытащим явно.

А что думаете по поводу разбора входящих - блок Расширения?

Alex_Jet

@intrapro:

Често говоря, очень не хочется тащить все эти A и B в код плагина.

Вероятно, оптимальный подход - сделать для опросов двухуровневую таблицу "Запрос - связанные каналы", с настройкой парсинга для канала. Примерно как в новом http плагине, только добавив все эти прыжки в связи с st=1 и cmd=all

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

В целом объем настройки увеличится, но зато всю обработку вытащим явно.

А что думаете по поводу разбора входящих - блок Расширения?

А что значит "не хочется тащить все эти A и B в код плагина"? По мне так надо при запросе cmd=list ожидать что придет вышеописанная строчка (aad6a070000:25.43;79c439000000:OFF/ON) и разобрать ее по каналам - если у канала адрес вида 32_79c439000000_A, то ему присваиваем OFF, если 32_79c439000000_B, то ON. Update1: либо в явном виде - как написал ниже. По датчикам температуры - если адрес канала 32_aad6a070000, то у него значение 25.43.

Опциональный предзапрос - тоже как вариант. Хотя можно его делать в каком либо "адресуемом" канале 32. Поскольку настройку запросов будем делать в одном из них. Ну то есть, предположим будем иметь каналы:

32_aad6a070000			- тут настройка конвертации: ...pt=32&cmd=conv, периодичность 60
32_85a56a070000			- тут настройка запросов: ...&cmd=list, периодичность 60
32_79c439000000_A		- тут ничего
32_79c439000000_B		- тут ничего
32_c6c439000000_A		- тут ничего
32_c6c439000000_B		- тут ничего

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

Ну а если опционально делать, то в настройках каналов нужно что-то придумывать - дополнительный чек-бокс, например.

Разбор состояния портов у I2C блоков расширения…совсем забыл о них, поскольку еще не использовал в своей практике.

Вероятно по команде cmd=get надо парсить состояние всех портов, складывая в json {[P0:ON],[P1:OFF]…}. Каналы, наверное, надо называть как-то типа 30_Ext_P0...30_Ext_P15, соответственно, к ним привязывать результат парсинга:

1. Либо в явном виде - в настройках запроса канала пользователь делает связь с каналом расширителя, указывая запрос "...cmd=get" и номер порта. Update2: Я за этот вариант! - пользователь вводит название канала какое хочет, а к нему привязывает "железный" канал путем указания конкретных запросов и дополнительных параметров. Единственное что надо все это автоматизировать…то есть не посылать запросы по каждому каналу и парсить каждый ответ, а делать один запрос (наверное, тот который с меньшим интервалом) и по ответу обновить состояние всех каналов.

2. Либо в неявном виде - то есть раз назвали 30_Ext_P0, то он автоматом относится к порту P0 расширителя, который висит на 30 порту контроллера. Этот случай допустим, поскольку у MegaD-2561 на один порт можно повесить только один расширитель (такая концепция).

Update3:

3. Либо делаем подплагин плагина:))) - отдельно для I2C, отдельно для 1-wire…

Кстати, с 1-Wire устройствами тоже лучше осуществлять привязку к каналам в явном виде. То есть в настройках запроса канала указывать строку запроса и адрес устройства. Я делал так - в адресе канала указывал номер порта и тип порта - 1WB, раз указан тип порта, то для него актуально поле Query_String. В случае с Cherry можно сделать поле "Extentions", которое активируется чек-боксом:
Датчик_температуры_1WB_70.png

Alex_Jet

Еще интересный момент. Когда в момент опроса шины 1WBUS она занята, то контроллер выдает сообщение busy - в этом случае надо немного позже переопросить контроллер. Вероятно очередь опроса надо выстраивать заново.

03.12.2018 12:39:41 localhost => 192.168.11.21:80 HTTP GET /sec/?pt=33&cmd=list
03.12.2018 12:39:41 localhost <= 192.168.11.21:80 HTTP busy

У меня опрос шины стоит 1 раз в 60 секунд и время от времени замечаю, что плагин может в течении часа, а то и нескольких часов опрашивать шину именно в тот момент, когда она занята… соответственно данные не обновляются.

Erik

@Alex_Jet:

Еще интересный момент. Когда в момент опроса шины 1WBUS она занята, то контроллер выдает сообщение busy - в этом случае надо немного позже переопросить контроллер. Вероятно очередь опроса надо выстраивать заново.

> 03.12.2018 12:39:41 localhost => 192.168.11.21:80 HTTP GET /sec/?pt=33&cmd=list
> 03.12.2018 12:39:41 localhost <= 192.168.11.21:80 HTTP busy
>

У меня опрос шины стоит 1 раз в 60 секунд и время от времени замечаю, что плагин может в течении часа, а то и нескольких часов опрашивать шину именно в тот момент, когда она занята… соответственно данные не обновляются.

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

Но ведь текущее значение знает МегаД. Разве нельзя спросить у нее?

Alex_Jet

@Erik:

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

Но ведь текущее значение знает МегаД. Разве нельзя спросить у нее?

Андрей о таком функционале не рассказывал - спросите может узнаем что-то новое. По моему мнению в момент опроса шины, состоящей из 100500 датчиков, контроллер ждет пока ему ответят все датчики (каждый конвертирует значение температуры и отсылает мастеру) и по мере ответа перезаписывает значения в своей ОЗУ. И раз я не ввожу в url никаких определенных 1-wire адресов (посмотрите даташит - там такой команды нет!), то значит я не опрашиваю какой-то конкретный датчик, а хочу узнать состояние всех датчиков, подключенных к шине 1-wire. Так что вы не правы.

Erik

Ну, веб-интерфейс меги хранит значение датчика между 30-секундными опросами шины.

Не понятно, почему если попасть "в момент опроса шины" возвращается "занято", а не предыдущее значение.

Оно обнуляется до запроса?

Alex_Jet

@Erik:

Ну, веб-интерфейс меги хранит значение датчика между 30-секундными опросами шины.

Не понятно, почему если попасть "в момент опроса шины" возвращается "занято", а не предыдущее значение.

Оно обнуляется до запроса?

Хранит не веб-интерфейс, а ОЗУ микроконтроллера. Опять же - надо задавать вопрос Андрею, а не мне. Но сейчас суть такова. Вы бы уже сами спросили, нежели чем плодить тут сообщения не по теме.

Erik

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

А обратиться к Андрею стоило бы тем, кто пишет плагин.

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

У меня опрос шины стоит 1 раз в 60 секунд и время от времени замечаю, что плагин может в течении часа, а то и нескольких часов опрашивать шину именно в тот момент, когда она занята… соответственно данные не обновляются.

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

Alex_Jet

@Erik:

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

А обратиться к Андрею стоило бы тем, кто пишет плагин.

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

У меня опрос шины стоит 1 раз в 60 секунд и время от времени замечаю, что плагин может в течении часа, а то и нескольких часов опрашивать шину именно в тот момент, когда она занята… соответственно данные не обновляются.

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

Рекомендовать юзеру ставить датчики, висящие на шине 1-wire, на опрос со временем не кратным 30 секунд - глупо. Лучше исключить такую ситуацию добавлением в код плагина пары новых строчек.

Erik

Вам лишь бы что-нибудь ответить.

Ну, смотрите часами на свое "занято" в ожидании пары строк в коде плагина, если изменить настройку частоты опроса для вас слишком глупо.

Alex_Jet

@Erik:

Вам лишь бы что-нибудь ответить.

Ну, смотрите часами на свое "занято" в ожидании пары строк в коде плагина, если изменить настройку частоты опроса для вас слишком глупо.

Не далеко ушел от Вас. Мне легче самому добавить пару строчек в код плагина, доступ к нему я имею. Однако целесообразнее дождаться новой версии плагина от iH, а не лепить самому не зная полностью архитектуры системы.

Собственно, ответ Андрея Вы уже читали, я не смог вспомнить в чем причина всего этого, но на своем сервере УД просто спустя секунду переопрашивал контроллер. Продублирую ответ Андрея тут:
<quote>> Датчик DS18B20 отдает актуальную температуру не сразу. Ему требуется время. В 12-битном разрешении подготовка значения температуры занимает 850 мс. Почти секунда.

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

В режиме 1WBUS команда на конвертацию отправляется каждые 30 секунд.

Если сервер со своим запросом попал в этот промежуток времени (между командой на конвертацию и 850 мс), контроллер вернет "busy". Это значит, что у датчиков еще нет актуальной температуры. Они ее считают.

Контроллер не станет ждать датчики. У него могут быть другие важные задачи. Сервер же, получив такой статус, должен подождать как минимум секунду и сделать запрос заново.

Можно делать иначе.

Сервер может отправлять команды "cmd=conv" (конвертация) + 1 секунда + "cmd=list" дуплетом. Тогда а) температура всегда будет актуальная на текущий момент времени, б) никогда не будет "busy".

Erik

Ну, тогда и следующий его ответ

В случае 1WBUS контроллер каждые 30 секунд отправляет общую команду на конвертацию для всех датчиков. Не для каждого индивидуально. Это не отнимает много времени.

Что касается отключения запросов самого контроллера. В принципе есть "хак". Можно установить тип порта "OUT/DS2413". Для этой конфигурации доступна команда "cmd=list", но автоматически команды на конвертацию средствами контроллера не отправляются.

И заметьте, мое предложение не ставить таймеры, кратные 30 секундам становится все ценнее и ценнее!

Если поставите 59 минут, будете попадать на "занято" раз в 30 часов.

Alex_Jet

Поскольку js-сервер очень быстрый, то прошу в плагине опроса MegaD предусмотреть настраиваемый тайм-аут между запросами по каналам. То есть очередь запросов должна формироваться с учетом тайм-аута между запросами. Поясню - эксплуатирую несколько контроллеров с различными настройками с разработчиком обратили внимание, что плагин MegaD Berry практически в одно и то же время делает запросы на контроллер по разным каналам - это может приводить к его зависанию и сработке WD, поскольку для контроллера операции с 1WBUS и DHT22 - особо времязатратные. Как показала практика, зависания происходят если на контроллере настроена комбинация каналов с настройками 1WBUS/DHT22/I2C. Причина зависаний пока неизвестна, но факты говорят сами за себя.

Если на контроллере настроен опрос только DHT22 или 1WBUS или I2C (причем, например, вместе с DSEN-1W), то все это работает годами. Если к DHT22 добавляется 1WBUS или к I2C добавляется 1WBUS, то почему-то контроллеры начинают 1-2 раза в сутки зависать.

intrapro

@Alex_Jet:

Поскольку js-сервер очень быстрый, то прошу в плагине опроса MegaD предусмотреть настраиваемый тайм-аут между запросами по каналам.

Хорошо, сделаем