Плагин MegaD
-
Ну, веб-интерфейс меги хранит значение датчика между 30-секундными опросами шины.
Не понятно, почему если попасть "в момент опроса шины" возвращается "занято", а не предыдущее значение.
Оно обнуляется до запроса?
-
Ну, веб-интерфейс меги хранит значение датчика между 30-секундными опросами шины.
Не понятно, почему если попасть "в момент опроса шины" возвращается "занято", а не предыдущее значение.
Оно обнуляется до запроса?
Хранит не веб-интерфейс, а ОЗУ микроконтроллера. Опять же - надо задавать вопрос Андрею, а не мне. Но сейчас суть такова. Вы бы уже сами спросили, нежели чем плодить тут сообщения не по теме.
-
Я думаю, что модератор форума решит про уместность, и почистит тему, если посчитает нужным, вам незачем об этом беспокоиться.
А обратиться к Андрею стоило бы тем, кто пишет плагин.
Ведь он часто вносит исправления в прошивку по запросам пользователей. Может и это поправит. Это лучше, чем реализация повторных опросов в плагине. Тем более, что
У меня опрос шины стоит 1 раз в 60 секунд и время от времени замечаю, что плагин может в течении часа, а то и нескольких часов опрашивать шину именно в тот момент, когда она занята… соответственно данные не обновляются.
если не достаточно просто не ставить на сервере время опроса кратным установленному на меге. Поставьте 55. Второй раз гарантировано не будет "занято".
-
Я думаю, что модератор форума решит про уместность, и почистит тему, если посчитает нужным, вам незачем об этом беспокоиться.
А обратиться к Андрею стоило бы тем, кто пишет плагин.
Ведь он часто вносит исправления в прошивку по запросам пользователей. Может и это поправит. Это лучше, чем реализация повторных опросов в плагине. Тем более, что
У меня опрос шины стоит 1 раз в 60 секунд и время от времени замечаю, что плагин может в течении часа, а то и нескольких часов опрашивать шину именно в тот момент, когда она занята… соответственно данные не обновляются.
если не достаточно просто не ставить на сервере время опроса кратным установленному на меге. Поставьте 55. Второй раз гарантировано не будет "занято".
Рекомендовать юзеру ставить датчики, висящие на шине 1-wire, на опрос со временем не кратным 30 секунд - глупо. Лучше исключить такую ситуацию добавлением в код плагина пары новых строчек.
-
Вам лишь бы что-нибудь ответить.
Ну, смотрите часами на свое "занято" в ожидании пары строк в коде плагина, если изменить настройку частоты опроса для вас слишком глупо.
-
Вам лишь бы что-нибудь ответить.
Ну, смотрите часами на свое "занято" в ожидании пары строк в коде плагина, если изменить настройку частоты опроса для вас слишком глупо.
Не далеко ушел от Вас. Мне легче самому добавить пару строчек в код плагина, доступ к нему я имею. Однако целесообразнее дождаться новой версии плагина от iH, а не лепить самому не зная полностью архитектуры системы.
Собственно, ответ Андрея Вы уже читали, я не смог вспомнить в чем причина всего этого, но на своем сервере УД просто спустя секунду переопрашивал контроллер. Продублирую ответ Андрея тут:
<quote>> Датчик DS18B20 отдает актуальную температуру не сразу. Ему требуется время. В 12-битном разрешении подготовка значения температуры занимает 850 мс. Почти секунда.Прошивка контроллера устроена таким образом, чтобы избегать подобных задержек.
В режиме 1WBUS команда на конвертацию отправляется каждые 30 секунд.
Если сервер со своим запросом попал в этот промежуток времени (между командой на конвертацию и 850 мс), контроллер вернет "busy". Это значит, что у датчиков еще нет актуальной температуры. Они ее считают.
Контроллер не станет ждать датчики. У него могут быть другие важные задачи. Сервер же, получив такой статус, должен подождать как минимум секунду и сделать запрос заново.
Можно делать иначе.
Сервер может отправлять команды "cmd=conv" (конвертация) + 1 секунда + "cmd=list" дуплетом. Тогда а) температура всегда будет актуальная на текущий момент времени, б) никогда не будет "busy".
-
Ну, тогда и следующий его ответ
В случае 1WBUS контроллер каждые 30 секунд отправляет общую команду на конвертацию для всех датчиков. Не для каждого индивидуально. Это не отнимает много времени.
Что касается отключения запросов самого контроллера. В принципе есть "хак". Можно установить тип порта "OUT/DS2413". Для этой конфигурации доступна команда "cmd=list", но автоматически команды на конвертацию средствами контроллера не отправляются.
И заметьте, мое предложение не ставить таймеры, кратные 30 секундам становится все ценнее и ценнее!
Если поставите 59 минут, будете попадать на "занято" раз в 30 часов.
-
Поскольку js-сервер очень быстрый, то прошу в плагине опроса MegaD предусмотреть настраиваемый тайм-аут между запросами по каналам. То есть очередь запросов должна формироваться с учетом тайм-аута между запросами. Поясню - эксплуатирую несколько контроллеров с различными настройками с разработчиком обратили внимание, что плагин MegaD Berry практически в одно и то же время делает запросы на контроллер по разным каналам - это может приводить к его зависанию и сработке WD, поскольку для контроллера операции с 1WBUS и DHT22 - особо времязатратные. Как показала практика, зависания происходят если на контроллере настроена комбинация каналов с настройками 1WBUS/DHT22/I2C. Причина зависаний пока неизвестна, но факты говорят сами за себя.
Если на контроллере настроен опрос только DHT22 или 1WBUS или I2C (причем, например, вместе с DSEN-1W), то все это работает годами. Если к DHT22 добавляется 1WBUS или к I2C добавляется 1WBUS, то почему-то контроллеры начинают 1-2 раза в сутки зависать.
-
Поскольку js-сервер очень быстрый, то прошу в плагине опроса MegaD предусмотреть настраиваемый тайм-аут между запросами по каналам.
Хорошо, сделаем
-
Всем добрый день
Подскажите чайнику как настроить мегу для работы с ih
Плагин я скачал, установил, даже что то там настроил
Ну ip адрес меги и ее пароль, а в самой меге что нужно настроить?
-
Всем добрый день
Подскажите чайнику как настроить мегу для работы с ih
Плагин я скачал, установил, даже что то там настроил
Ну ip адрес меги и ее пароль, а в самой меге что нужно настроить?
Все очень доступно написано здесь.
-
Та я эти ссылки наизусть уже знаю, но все равно не понятно
Какой порт после ip указать и нужен он вообще
Какой скрипт? md.php? Или другой?
-
У меня так
-
Порт 80.Какой скрипт?
-
@art:
У меня так
У меня так:
Mega-D ID с галочкой srv-loop если надо слать на сервер значения раз в минуту. Можно и не ставить. У меня 3 меги. Эти настройки для первой. Соответственно для второй - порт 8082 и скрипт megad_2.php. В настройках плагина также.
-
Порт 8088 - это порт Ih в настройках. В настройках для каждой меги слушающий порт присваивается свой
-
Ну вот теперь понятно, вечерам попробую
Спасибо
-
1. Подскажите как в Cherry привязать 1-wire девайс к устройству? Имею такой лог - куда вписать адрес устройства?
Сейчас адрес устройства "вписан" в номер канала - "33_ff48a6701605", но привязки не происходит.
04.01 13:40:46.979 megad1: localhost => 192.168.11.21 HTTP GET /sec/?pt=33&cmd=list 04.01 13:40:47.037 megad1: localhost <= 192.168.11.21 response: statusCode=200 contentType = text/html 04.01 13:40:47.037 megad1: body: ff48a6701605:2.43;ff779e701604:1.122. Можно как-то прояснить на какое время запланирована доработка/переработка плагина? С текущим функционалом не могу полностью перейти на Cherry.
3. Для плагинов функционал копирования можно сделать? Чтобы не заводить все каналы с нуля и типовые настройки?
-
1. Подскажите как в Cherry привязать 1-wire девайс к устройству? Имею такой лог - куда вписать адрес устройства?
Сейчас адрес устройства "вписан" в номер канала - "33_ff48a6701605", но привязки не происходит.
Да, у вас все верно. Адресация каналов такая же как в Berry. При последней доработке (v1.1.6) была внесена ошибка
Вы можете скачать последний релиз (v1.1.7) c гитахаба, там ошибка исправлена:
https://github.com/intrahouseio/intraHouse.plugin-MegaD/releases
Для стандартного обновления выложим чуть позже
2. Можно как-то прояснить на какое время запланирована доработка/переработка плагина? С текущим функционалом не могу полностью перейти на Cherry.
В ближайшее время (учитывая, что сейчас праздники), планируем доработать плагин (вариант, который посылали вам для тестирования)
Там добавлено:
1. Отправка команды плагину из сценария - любые запросы, которые принимает MegaD
2. Функция обработки данных на плагине
3. Восстановление выходов при перезагрузке контроллера
4. Изменен механизм отправки команд - команды включаются в общую очередь
5. Изменен механизм обработка результата - канал переключается при получении результата запроса
6. Обработка ответа busy - такой запрос ставится в очередь на 2 сек
Механизм адресации каналов не меняется, это будет просто обновление плагина.
Так понимаю, вам не хватает I2C каналов. Нужно придумать, как их адресовать в той же парадигме
Также добавили и сейчас тестируем отправку времени на контроллер и некоторые другие мелкие моменты.
Сообщите, какой функционал вам необходим, постараемся добавить.
Что не покрывается в текущем плагине
1. Несколько запросов для получения данных одного канала
2. Один запрос для получения данных нескольких каналов (сейчас можно конечно, например для 1Wire, задать период опроса в одном из каналов, и за счет привязки к порту данные поступают в каналы, для которых нет опроса)
3. Формирование нестандартных команд управления
Для решения этих задач планируется разработать новый плагин для MegaD (megadext), в котором не будет такой привязки к портам, как сейчас.
Каналы будут настраиваться аналогично плагину http (иерархически), а разбор будет задаваться явно.
Новый плагин можно будет использовать наряду со старым. По этому плагину сроки пока не определены.
3. Для плагинов функционал копирования можно сделать? Чтобы не заводить все каналы с нуля и типовые настройки?
Не совсем понятно, каналы ведь копировать можно.
Или вы имеете в виду копирование всех каналов плагина в целом? При подключении еще одной меги?
Сделаем, если это востребовано.
-
Большое спасибо за развернутый ответ! Теперь я пройдусь по пунктам:
Да, у вас все верно. Адресация каналов такая же как в Berry. При последней доработке (v1.1.6) была внесена ошибка
Вы можете скачать последний релиз (v1.1.7) c гитахаба, там ошибка исправлена:
https://github.com/intrahouseio/intraHouse.plugin-MegaD/releases
Для стандартного обновления выложим чуть позже
Все понял, обновлю сейчас и посмотрю (Update - да, действительно в 1.1.7 разбор 1-wire девайсов работает). Поскольку решил постепенно переходить на Cherry, то решил из нее делать хотя бы опрос датчиков без прослушки http-трапов от MegaD.
@intrapro:В ближайшее время (учитывая, что сейчас праздники), планируем доработать плагин (вариант, который посылали вам для тестирования)
Там добавлено:
1. Отправка команды плагину из сценария - любые запросы, которые принимает MegaD
2. Функция обработки данных на плагине
3. Восстановление выходов при перезагрузке контроллера
4. Изменен механизм отправки команд - команды включаются в общую очередь
5. Изменен механизм обработка результата - канал переключается при получении результата запроса
6. Обработка ответа busy - такой запрос ставится в очередь на 2 сек
Все что добавлено я уже протестировал. Из замечаний только по п.2 - не очень удобно редактировать скрипт обработки данных в боковом меню (как вариант, сделать так же как редактируется код html-виджета) и нет возможности изменять интервал опроса как в Berry (опрос датчика с периодичностью раз в 5 минут - 5 опросов через 5 секунд с отбросом крайних и усреднением оставшихся). И интересует более подробно п.4 - что это и зачем?
@intrapro:Механизм адресации каналов не меняется, это будет просто обновление плагина.
Так понимаю, вам не хватает I2C каналов. Нужно придумать, как их адресовать в той же парадигме
Также добавили и сейчас тестируем отправку времени на контроллер и некоторые другие мелкие моменты.
Сообщите, какой функционал вам необходим, постараемся добавить.
I2C каналы сейчас можно сделать (иерархически нельзя как в http-плагине, но все же), но не происходит "обработки" данных в теле:
04.01 19:31:58.684 megad5: 04.01 19:31:58.685 megad5: localhost => 192.168.11.25 HTTP GET /sec/?pt=31&scl=34&i2c_dev=htu21d&i2c_par=1 04.01 19:31:58.745 megad5: localhost <= 192.168.11.25 response: statusCode=200 contentType = text/html 04.01 19:31:58.746 megad5: body: 27.16 04.01 19:31:58.747 IH: get [] 04.01 19:31:58.748 IH: set {} 04.01 19:31:58.885 megad5: 04.01 19:31:58.885 megad5: localhost => 192.168.11.25 HTTP GET /sec/?pt=31&scl=34&i2c_dev=htu21d 04.01 19:31:58.914 megad5: localhost <= 192.168.11.25 response: statusCode=200 contentType = text/html 04.01 19:31:58.915 megad5: body: 14.58 04.01 19:31:58.916 IH: get [] 04.01 19:31:58.917 IH: set {}Вот этого, действительно не хватает! Для всех I2C-девайсов есть "отдельный" запрос по каждому параметру, например, http://192.168.0.14/sec/?pt=31&scl=30&i2c_dev=bmx280&i2c_par=1 таким образом считываемый параметр легко привязать к устройству. Не стоит делать реализацию (cmd=get), при которой надо парсить сразу все значения параметров (так выводится в веб-интерфейсе, когда датчик подключен к MegaD "нативно"), придумывая как их привязывать к каналам. Сейчас только, если надо, например, для канала 31 сделать 7 подканалов не единовременно, то они будут разбросаны по разным местам.
По отправке времени на контроллер - это хорошо!
Еще надо:
1. Опционально (check box при настройке плагина) в журнал делать записи о перезагрузке MegaD (st=1).
2. Адекватное поведение виджета плагина. Если остановлен, то STOPPED. Если в работе и MegaD нормально отвечает, то RUN. Если MegaD не отвечает, то NOT ACTIVATED до тех пор пока контроллер не ответит (сейчас если контроллера нет в сети, но плагин запущен происходит дергание STOPPED/RUN).
@intrapro:Что не покрывается в текущем плагине
1. Несколько запросов для получения данных одного канала
2. Один запрос для получения данных нескольких каналов (сейчас можно конечно, например для 1Wire, задать период опроса в одном из каналов, и за счет привязки к порту данные поступают в каналы, для которых нет опроса)
3. Формирование нестандартных команд управления
Вот эти моменты/формулировки честно говоря не до конца понял.
1. Несколько запросов - это надо только для 1-wire когда на одном канале висят разные 1-wire устройства (запрос на конвертацию температуры и запрос на отображение состояния). По сути можно обойтись.
2. Это касаемо "гирлянды" 1-wire устройств на одном канале? Конечно было бы лаконичнее делать один запрос по каналу и получать данные по подканалам, но тоже можно обойтись тем что есть сейчас.
3. Это, как мне кажется, лучше делать с помощью сценариев, благо plugincCommand сейчас есть. Хотя если хочется просто привязать RGB-светильник к каналу, на котором висит RGB-лента, то вероятно так сейчас не получится (чтобы код RGB передавался в get-запрос канала).
Для решения этих задач планируется разработать новый плагин для MegaD (megadext), в котором не будет такой привязки к портам, как сейчас.
Каналы будут настраиваться аналогично плагину http (иерархически), а разбор будет задаваться явно.
Новый плагин можно будет использовать наряду со старым. По этому плагину сроки пока не определены.
Это правильно, но пугает переход на новый плагин… у меня сейчас порядка 200 каналов расписаны!
Не совсем понятно, каналы ведь копировать можно.
Или вы имеете в виду копирование всех каналов плагина в целом? При подключении еще одной меги?
Сделаем, если это востребовано.
Тут имел ввиду именно копирование плагина со всеми имеющимися каналами, например, при добавлении нового MegaD. Сейчас приходится добавлять плагин, вводить IP-настройки и вручную создавать 38 каналов, поскольку они все в итоге оказываются востребованными.
