1. Главная
  2. IntraHouse
  3. Плагины
  4. Плагин MegaD

Плагин MegaD

  • I

    @cd1room:

    Есть проблемка со скриптом управления температурой и megaD. Попробую описать. Если запускаем одновременно сервер и роутер, а роутер подвис. Температура сервере установлена 30. Т.к. датчика нет то сервер видит последнюю то есть например 28 и сервер дает команду, но устройства нет в сети. Батареи включается на интерфейсе. Перезагрузил роутер. Батарея включена на интересе дома. А по факту выход не активен. И так пока температура не подниматься выше 30 и снова упадёт. Как с этим бороться? Я так понимаю должна быть индикация аварии если устройства нет в сети.

    Вы правы, такая проблема есть.

    Дело в том, что MegaD не дает feedback, т е не подтверждает операции переключения, поэтому применяется односторонняя (или оптимистичная :)) связь при управлении: при отправке команды считается, что команда выполнена.

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

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

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

    По RGB - в Cherry виджет для визуализации RGB запланирован, но пока не сделан.

    Я правильно понимаю, Вы хотите управлять RGB с MegaD, посылая команды на диммируемые выхода?

    Пока можно управлять, диммируя каждый канал отдельно.

    Или в MegaD есть какой-то новый механизм для RGB?

    0
  • A

    @intrapro:

    Вы правы, такая проблема есть.

    Дело в том, что MegaD не дает feedback, т е не подтверждает операции переключения, поэтому применяется односторонняя (или оптимистичная :)) связь при управлении: при отправке команды считается, что команда выполнена.

    На самом деле сервер всегда может запросить состояние всех портов и распарсить их значения. Или во всяком случае MegaD ведь выдает 200 OK в TCP-сессии - это уже можно считать подтверждением выполнения команды (если эта команда однозначная, а не типа "переключения" выходов).

    @intrapro:

    Или в MegaD есть какой-то новый механизм для RGB?

    К ней с некоторых пор можно подключать I2C расширитель ШИМ-портов! Правда готовых плат с силовыми элементами для него нет.

    0
  • C

    А также с недавних пор поддерживает управление LED-лентами на базе чипов WS2818, WS2811, WS2813. При этом задействуется всего один порт для управления RGB. Хотел сделать функцию мягкого пробуждения человека с помощью RGB света. 😄

    0
  • C

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

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

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

    0
  • A

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

    0
  • T

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

    0
  • I

    @thunder_d:

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

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

    0
  • A

    @intrapro:

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

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

    0
  • E

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

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

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

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

    0
  • I

    @Erik:

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

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

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

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

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

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

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

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

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

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

    0
  • A

    Еще дополнение по доработке плагина для 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_адрес_сенсора?

    0
  • A

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

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

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

    А. Опрашивать канал "штатным" образом только по одному каналу (по факту нужно 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

    0
  • I

    @Alex_Jet:

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

    …

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

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

    0
  • A

    @intrapro:

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

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

    0
  • A

    @intrapro:

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

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

    0
  • I

    @Alex_Jet:

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

    Добрый день.

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

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

    0
  • A

    Обновления, связанные с каналами 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 нужно будет два запроса - на конвертацию температуры и запрос значений.

    0
  • I

    @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 🙂

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

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

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

    0
  • A

    @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

    0
  • A

    Еще интересный момент. Когда в момент опроса шины 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 секунд и время от времени замечаю, что плагин может в течении часа, а то и нескольких часов опрашивать шину именно в тот момент, когда она занята… соответственно данные не обновляются.

    0
плагины 22 mega-d 1
Авторизуйтесь, чтобы ответить