Плагин MegaD

cd1room

Пример: включить все диоды красным цветом

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

Но хотелось бы из интерфейса управлять цветом. И настраивать цвет пробуждения в параметрах.

Alex_Jet

С учётом того, что "обычные" ШИМ-каналы в MegaD скорее всего будут использоваться и для диммирования, то для RGB логичнее использовать либо расширитель ШИМ по I2C или подключать к контроллеру WS28xx. А для этого нужен какой-то функционал для записи значений в канал для устройства типа "актюатор аналоговый". Кстати вывод информации на OLED можно таким же образом сделать, а потом в скрипте написать функцию записи в OLED значений в нужную строку и столбец.

thunder_d

Вопрос к разработчикам? Может сделать отдельно плагин для MegaD-328 и MegaD-2561.

intrapro

@thunder_d:

Вопрос к разработчикам? Может сделать отдельно плагин для MegaD-328 и MegaD-2561.

Почему? Разве они не совместимы снизу вверх?

Alex_Jet

@intrapro:

Можно еще проще - привязать бинарный актуатор, а интерактивные операции для него отключить

В принципе эта идея сработала. При поднесении нужного ключа к считывателю актуатор меняет свое состояние. Отталкиваясь от его состояния можно написать сценарий установки/снятия с охраны. Единственный неопределенный момент в том, что когда MegaD опрашиваем командой cmd=all, то канал, соответствующий считывателю находится в неопределенном состоянии (ранее писал, что не верно под неопределенным состоянием считать 0). Возникает вопрос - после перезагрузки MegaD в каком состоянии окажется привязанный к этому каналу актуатор (ну или сенсор, если добавите ему обработку toggle). Или все же это правильно - считать за 0/OFF неопределенное состояние порта?

Erik

Здравствуйте.

Подскажите, можно ли и как сделать "расширение" без сообщения от меги?

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

А как сделать расширение без входящего сообщения от контроллера, чтобы передать меге команду с паузой, и привязать это расширение к кнопке на экране?

intrapro

@Erik:

Здравствуйте.

Подскажите, можно ли и как сделать "расширение" без сообщения от меги?

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

А как сделать расширение без входящего сообщения от контроллера, чтобы передать меге команду с паузой, и привязать это расширение к кнопке на экране?

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

Но плагин должен поддерживать эту возможность.

Для плагина MegaD запланирована переработка, эта опция будет добавлена.

Тогда для решения вашей задачи достаточно будет к кнопке привязать сценарий с командой

	this.pluginCommand({unit:'megad1', command:'/sec/?cmd=7:0;p10;7:1'});

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

Alex_Jet

Еще дополнение по доработке плагина для MegaD - в случае если MegaD перезагрузилась (пришла команда st=1):

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

2. Восстановить состояние каналов-выходов на те, которые были до перезагрузки MegaD

3. Опросить все каналы MegaD, распарсить их значения и присвоить к соответствующим сенсорам

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

Up1: еще можно по умолчанию сделать список из 38 каналов (с 0 по 37) - каждый канал можно в любой момент отредактировать как необходимо пользователю и они всегда будут отображаться по порядку. А вот создавать все 38 каналов вручную - муторное занятие. Пользователю придется создавать только "виртуальные" каналы - для опроса I2C датчиков, датчиков на 1Wbus. Я их делаю с номерами типа 30_1, 30_2 и т.д.

Кстати, надо попробовать подключить датчики на 1WBus - как их система будет идентифицировать и присваивать значения? - так же как в Berry? - то есть номер канала должен быть типа 30_адрес_сенсора?

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-секундными опросами шины.

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

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