Плагин MegaD
-
Странно работает опрос всех портов (создается ощущение, что не работает).
Привязал к порту 7 устройство "светильник".
Настроил в параметрах плагина опрос всех портов контроллера Меги каждые 60 секунд.
Включаю светильник из intraHouse.
Изменение порта отображается.
Выключаю на контроллере порт 7 командой из браузера (руками).
Порт 7 на контроллере выключается, но intraHouse этого не видит, ни через 60 секунд, ни больше…
Желательно посмотреть в отладчике плагина:
Выберите плагин, в нижнем окне - Отладчик. У вас вместо modbus будет megad
Кнопка play - начинает вывод, стоп - останавливает
Там нужно смотреть:
1. Отправляются или нет запросы cmd=all
2. Если да, что отвечает megad по 7 каналу
3. Как эти данные интерпретирует сервер (get - получил от плагина, set - записал в устройство)
-
странно.
Сейчас отработало нормально.
Спасибо, понаблюдаю еще..
02.02 17:06:45.813 megad1: localhost => 192.168.0.15 HTTP GET /sec/?cmd=7:1
02.02 17:06:45.898 megad1: localhost <= 192.168.0.15 response: statusCode=200 contentType = text/html
02.02 17:06:45.899 megad1: body: Done
02.02 17:06:45.900 IH: get [{"id":"7","value":1}]
02.02 17:06:45.901 IH: set {"LAMP_HALL1":{"dval":1,"err":0}}
02.02 17:07:12.262 megad1:
02.02 17:07:12.264 megad1: localhost => 192.168.0.15 HTTP GET /sec/?cmd=all
02.02 17:07:12.355 megad1: localhost <= 192.168.0.15 response: statusCode=200 contentType = text/html
02.02 17:07:12.357 megad1: body: OFF/0;OFF/0;OFF/0;OFF;OFF;OFF;OFF;ON;OFF;OFF;ON;ON;ON;ON;ON;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;temp:-1.93;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF
02.02 17:07:12.359 IH: get [{"id":"7","value":"1"},{"id":"27","value":"-1.93"}]
02.02 17:07:12.360 IH: set {"LAMP_HALL1":{"dval":"1","err":0},"STEMP1":{"aval":"-1.93","err":0}}
02.02 17:08:12.364 megad1:
02.02 17:08:12.365 megad1: localhost => 192.168.0.15 HTTP GET /sec/?cmd=all
02.02 17:08:12.474 megad1: localhost <= 192.168.0.15 response: statusCode=200 contentType = text/html
02.02 17:08:12.475 megad1: body: OFF/0;OFF/0;OFF/0;OFF;OFF;OFF;OFF;OFF;OFF;OFF;ON;ON;ON;ON;ON;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;OFF;temp:-1.93;OFF;ON;OFF;OFF;OFF;OFF;OFF;OFF;OFF;ON
02.02 17:08:12.477 IH: get [{"id":"7","value":"0"},{"id":"27","value":"-1.93"}]
02.02 17:08:12.477 IH: set {"LAMP_HALL1":{"dval":"0","err":0},"STEMP1":{"aval":"-1.93","err":0}}
-
Коллеги, подскажите! А плагин не будете дорабатывать в части более сложной обработки данных от аналоговых устройств?
Для обработки данных от MH-Z14A требуется: общая периодичность опроса датчика - 5 минут, при опросе необходимо сделать 5 запросов через 5-10 секунд, далее отсортировать их, откинуть крайние, сложить оставшиеся и усреднить. В Berry это получилось сделать когда стало возможно возвращать не только значение устройства, но и период его опроса (reqsec).
Ну и все же очень хотелось бы такого же поведения плагина Cherry как в Berry в том случае когда контроллер шлет сообщения с m=1 и m=2.
-
Коллеги, подскажите! А плагин не будете дорабатывать в части более сложной обработки данных от аналоговых устройств?
Для обработки данных от MH-Z14A требуется: общая периодичность опроса датчика - 5 минут, при опросе необходимо сделать 5 запросов через 5-10 секунд, далее отсортировать их, откинуть крайние, сложить оставшиеся и усреднить. В Berry это получилось сделать когда стало возможно возвращать не только значение устройства, но и период его опроса (reqsec).
Ну и все же очень хотелось бы такого же поведения плагина Cherry как в Berry в том случае когда контроллер шлет сообщения с m=1 и m=2.
Добрый день!
Период опроса из функции - сделаем
Также добавим и это: по умолчанию в качестве параметра передавать JSON, в котором будет содержаться IP-адрес MegaD
А вот по входящим без m - это загадка
Вероятно, придется добавить что-то вроде pt=xx&m=! - не брать запрос, если присутствует m
По срокам точно не скажу, до конца месяца будет
-
Период опроса из функции - сделаем
Также добавим и это: по умолчанию в качестве параметра передавать JSON, в котором будет содержаться IP-адрес MegaD
Отлично, буду ждать.
@intrapro:А вот по входящим без m - это загадка
Вероятно, придется добавить что-то вроде pt=xx&m=! - не брать запрос, если присутствует m
Я конечно все понимаю, но в вашем случае даже реверс-инжиниринг не надо делать. Тем более у Вас появился железный контроллер MegaD-2561. Надо вывести отладку в Berry и Cherry и сымитировать ситуацию "долгого удержания кнопки" в режиме P. Я же привел скриншоты что в Berry работало все отлично, а в Cherry - все иначе. Причем помню мне Владимир писал, что достаточно указать pt=1 и если будет вхождение только pt=1, то request сработает. Ну то есть работало фактически по маске. Если пишешь pt=1&m=1, то сработает только на такое вхождение, если pt=1&m=2 то только на такое…
И еще забыл, правда сам не тестировал пока - в серверной части внесли изменения по отображению 3-х состояний индикатора плагина: NOT ACTIVATED, STOPPED, RUN? И еще что-то было по серверной части...пойду почитаю ветку.
-
Я конечно все понимаю, но в вашем случае даже реверс-инжиниринг не надо делать. Тем более у Вас появился железный контроллер MegaD-2561. Надо вывести отладку в Berry и Cherry и сымитировать ситуацию "долгого удержания кнопки" в режиме P. Я же привел скриншоты что в Berry работало все отлично, а в Cherry - все иначе. Причем помню мне Владимир писал, что достаточно указать pt=1 и если будет вхождение только pt=1, то request сработает. Ну то есть работало фактически по маске. Если пишешь pt=1&m=1, то сработает только на такое вхождение, если pt=1&m=2 то только на такое…
Тут MegaD не нужен совсем. Обработка запросов построена на идее, что мы не отслеживаем, какие параметры передает контроллер (кроме pt), просто ищется максимально подходящий вариант.
Алгоритм такой:
Запросы группируются по pt. Отдельная группа - запросы без pt
Далее определяется, какие ключи есть в запросе и подбирается подходящий запрос по наличию максимального количества совпадений ключей.
Например, есть запросы в таблице:
1. /pt=7&m=1
2. /pt=7
Контроллер присылает /pt=7&cnt=1 - возьмется второй, /pt=7&m=2 - не возьмется никакой, так как ключи совпали с первым, а значение-нет.
Но если в таблице единственный запрос /pt=7 - он и считается подходящим для любого варианта, хоть с m, хоть без m. Потому что про m алгоритм не знает
Выхода два:
Вариант 1. Сделать ловушку:
/pt=7&m=* -сюда попадаем, если m есть с любым значением. Можно оставить без обработки
/pt=7 - сюда попадаем, если m нет
Это работает уже сейчас
Вариант 2.
Как то сообщить алгоритму, что если в запросе есть m, то его не надо брать, например
/pt=7&m=! (или какой-то другой символ отрицания)
-
Алгоритм такой:
Запросы группируются по pt. Отдельная группа - запросы без pt
Далее определяется, какие ключи есть в запросе и подбирается подходящий запрос по наличию максимального количества совпадений ключей.
А где это все описано? Точнее в каком файле, какую часть кода посмотреть?
@intrapro:…
Вопрос на засыпку - у Вас нет плагина, который слушает порт и смотря что пришло по нему - выполняет команды? А-ля урезанная версия MegaD, но только без каналов…
Update: в общем все везде поменял на имя нового плагина. Выпилил из function next() case 2. Плагин запустился и начал слушать порт. Сообщения приходят. Надо гит осваивать:)
Предлагаю открыть новую тему по созданию плагинов пользователями. Однако нужен вводный пост от Вас - из чего состоит плагин, что собой представляют разные файлы (скелет плагина), как происходит взаимодействие сервера с плагинами и прочее. Ну и вводный экскурс как это все размещать на гитхабе чтобы можно было пользоваться штатной процедурой обновления плагинов.
-
Алгоритм такой:
Запросы группируются по pt. Отдельная группа - запросы без pt
Далее определяется, какие ключи есть в запросе и подбирается подходящий запрос по наличию максимального количества совпадений ключей.
А где это все описано? Точнее в каком файле, какую часть кода посмотреть?
Все в файле lib/httpserver.js
При запуске формируется таблица для поиска - функция formTableMReq
При поступлении запроса функция findMReq ищет в этой таблице
В общем все везде поменял на имя нового плагина. Выпилил из function next() case 2. Плагин запустился и начал слушать порт. Сообщения приходят.
Отлично!!! Мы заинтересованы, чтобы продвинутые пользователи создавали плагины
Предлагаю открыть новую тему по созданию плагинов пользователями. Однако нужен вводный пост от Вас - из чего состоит плагин, что собой представляют разные файлы (скелет плагина), как происходит взаимодействие сервера с плагинами и прочее. Ну и вводный экскурс как это все размещать на гитхабе чтобы можно было пользоваться штатной процедурой обновления плагинов.
Да, тема по созданию плагинов нужна, откроем. С описанием - на это нужно некоторое время.
Хотя документация по плагинам уже есть на гитхабе: https://github.com/intrahouseio/intraHouse-Cherry/wiki
Раздел "Concept of Plugins" и дальше (там только названия английские, внутри на русском)
Возможно, некоторые детали устарели, но в целом по структуре плагина там все описано.
-
Господа, разработчики! А раз у Вас есть MegaD-2561, то вы не могли бы потестировать ее с плагином Cherry? Навешать на 30-35 порты I2C датчики, ds18b20 и несколько DS18B20 на шине I2C. Могу прислать свой конфиг, в котором вам нужно будет только IP адрес свой прописать. У меня раз в 2-3 дня все так же зависает контроллер. С разработчиком ни к чему не пришли…у него со скриптами на php все отлично работает продолжительное время! Грешит на iH...
-
Господа, разработчики! А раз у Вас есть MegaD-2561, то вы не могли бы потестировать ее с плагином Cherry? Навешать на 30-35 порты I2C датчики, ds18b20 и несколько DS18B20 на шине I2C. Могу прислать свой конфиг, в котором вам нужно будет только IP адрес свой прописать. У меня раз в 2-3 дня все так же зависает контроллер. С разработчиком ни к чему не пришли…у него со скриптами на php все отлично работает продолжительное время! Грешит на iH...
Добрый день!
Дежа вю
07 апр 2017, 04:27
Подытожу данную тему. Проблема зависания MegaD-2561 при подключенном к нему по I2C датчике HTU21D была в прошивке. Автор не раскрывает секретов что он изменил или сам не понимает какое изменение повлияло на удаление данного бага. К слову сказать с тех пор было много изменений прошивки - добавлена поддержка многих других датчиков, работающих по шине I2C (BH1750, TSL2591, BMP180, BMP/BME280, SI7021, MCP23008), поддержка считывателей и кодовых панелей с Wiegand-26, нативная поддержка OLED-дисплеев на контроллере SSD1306 (также I2C-шина), добавлен новый режим для входов "Click mode", появилась возможность работы с контроллером по MQTT и прочее.
Напомню, баг проявлялся только при опросе контроллера MegaD-2561 командой /%pwd%/?pt=34&scl=35&i2c_dev=htu21d&i2c_par=1 (запрос температуры с датчика HTU21D) с любой периодичностью (пробовал 60 секунд - 5 минут) - контроллер через какое-то время зависал (промежуток времени от 3 до 24 часов), помогал только ручной сброс (в версии платы контроллера 1.0 - отключение по питанию, в версии 2.0 - сброс кнопкой), пока автором прошивки не был включен встроенный в МК "сторожевой пес".
В связи с вышеизложенным, выражаю большую признательность авторам IH, что откликнулись и провели большую работу по выявлению описанного бага. Отрицательный результат - также результат!
Так понимаю, watch dog сейчас срабатывает, контроллер не зависает, а перезагружается.
Ну давайте еще раз проанализируем задачу:
1. У Вас перезагружается один контроллер, на котором есть I2C, 1Wire и 1Wire по I2C
Остальные контроллеры работают без проблем
2. За все время (3 года) у других пользователей не было проблем с зависанием ни плагина, ни контроллера. По крайней мере, не было сообщений. Приглашаю пользователей MegaD сообщить, если сталкивались с зависаниями.
3. В плагине для Cherry гарантируется, что запросы идут не чаще заданного вами в настройке интервала. То есть ни о какой ddos-атаке речь идти не может
Что можно предпринять:
1. Упростить конфигурацию датчиков и выяснить, какой датчик приводит к проблемам
2. Уменьшить "Интервал отправки запросов (мсек)" до минимально декларируемого для MegaD, но не воспринимаемого как ddos атака.
Скорее всего, в этом случае зависание поймается быстрее. Если да - запишите трафик с помощью tcpdump и пришлите его нам.
sudo tcpdump -s0 -A -vvv host 192.168.0.14 -w megadump.pcap
В следующем релизе системы будет возможность писать логи плагина в файлы (как в Berry)
Но там информации конечно меньше чем в дампе.
-
Добрый день!
Дежа вю
Какая у Вас длинная память!!! Я уже даже не помню такого. Однако проблема зависания у меня появилась после того, как к этому контроллеру (кроме одного DS18B20 и BMP280E) подключил 1-wire шину, состоящую из 3-х датчиков DS18B20, питание которых подключено к +3,3В. Да, витая пара частично проходит рядом с силовыми кабелями, питающими газовый/электрический котел и насосы. Однако я бы понял что при включении/выключении котла/насосов контроллер бы зависал. А тут нет - все оборудование пыхтит и трудится, а контроллер бац и перезагружается! Поэтому в версию "плохой электромагнитной совместимости" я не верю.
Другой контроллер стал перезагружаться раз в сутки когда я к нему (кроме одного DHT22) добавил 2 шт. DS18B20 в режиме термостата и шину 1-wire, состоящую из 2-х DS18B20, питание которых подключено к +3,3В. Однако вопрос был закрыт, когда я отсоединил DHT22 от порта контроллера - его аптайм просто громадный с момента последнего обновления прошивки. Как только к любому порту подключаю этот жу DHT22, то в течении суток контроллер перезагружается. Других DHT22 просто нет в наличии и нет желания покупать.
Ни в одном, ни в другом случае автор контроллера проблем не выявил, поскольку "невозможно воспроизвести всех ваших условий на макете, надо разбираться в каждом конкретном случае".
Что можно предпринять:
1. Упростить конфигурацию датчиков и выяснить, какой датчик приводит к проблемам
2. Уменьшить "Интервал отправки запросов (мсек)" до минимально декларируемого для MegaD, но не воспринимаемого как ddos атака.
Скорее всего, в этом случае зависание поймается быстрее. Если да - запишите трафик с помощью tcpdump и пришлите его нам.
sudo tcpdump -s0 -A -vvv host 192.168.0.14 -w megadump.pcap
В следующем релизе системы будет возможность писать логи плагина в файлы (как в Berry)
Но там информации конечно меньше чем в дампе.
1. По сути выяснено (вероятно тут сочетания датчиков I2C и 1-wire или DHT22 и 1-wire).
2. Я очень надеялся на этот параметр, когда просил Вас его реализовать. По умолчанию 200, я изменил на 300сек, но радость моя была не долгой - через ~5 суток снова перезагрузка. Изменил на 500сек, но благодаря сообщениям в Телеграм вижу, что через 2-5 дней все равно происходит перезагрузка.
Я бы предпочел писать лог не изменяя интервалы, поскольку контроллеры в работе и нельзя вредить их более менее стабильной работе…по крайней мере пока у нас зима.
-
Однако вопрос был закрыт, когда я отсоединил DHT22 от порта контроллера - его аптайм просто громадный с момента последнего обновления прошивки. Как только к любому порту подключаю этот же DHT22, то в течении суток контроллер перезагружается. Других DHT22 просто нет в наличии и нет желания покупать.
Alex_Jet, Какая у Вас прошивка MegaD? У меня модули DHT22 во всех комнатах стабильно работали с ESP8266 (провода до 10 метров), но после перехода на MegaD стали бессистемно подвисать. Предполагаю, что в MegaD плохо организована работа с DHT22.
-
@gis:
Alex_Jet, Какая у Вас прошивка MegaD? У меня модули DHT22 во всех комнатах стабильно работали с ESP8266 (провода до 10 метров), но после перехода на MegaD стали бессистемно подвисать. Предполагаю, что в MegaD плохо организована работа с DHT22.
У меня сейчас на всех MegaD-2561 fw: 4.31b7. По DHT22 разработчик действительно подтверждает проблему работы с ним - "лучше было бы выпилить его поддержку из прошивки". Но опять же - мою проблему Андрей воспроизвести не смог. Хотя логи я ему присылал и видно было что зависает контроллер именно на опросе DHT22, однако он стал это делать только после подключения 1-wire (2 DS18B20 на шине) и двух DS18B20 в режиме термостата.
-
У меня сейчас на всех MegaD-2561 fw: 4.31b7. По DHT22 разработчик действительно подтверждает проблему работы с ним - "лучше было бы выпилить его поддержку из прошивки". Но опять же - мою проблему Андрей воспроизвести не смог. Хотя логи я ему присылал и видно было что зависает контроллер именно на опросе DHT22, однако он стал это делать только после подключения 1-wire (2 DS18B20 на шине) и двух DS18B20 в режиме термостата.
Вы свою схему тут рисовали
https://www.ab-log.ru/forum/viewtopic.php?f=1&t=1195&p=34390#p34378
Вы на каждый датчик длинной линией свою землю подаете. Это путь к проблеме "земляная петля". И проявления, которые вы описываете так же похожи не нее же. Она не решается программным способом.
Если в каждой раздаточной коробке все "земли" объединить в одну точку, то получится похоже на "земляную шину". Что снимет проблему. А если по счастливой случайности через все раздаточные коробки проходит неиспользуемая жила потолще - и ее нужно добавить в "шину".
-
Вы свою схему тут рисовали
https://www.ab-log.ru/forum/viewtopic.php?f=1&t=1195&p=34390#p34378
Эта проблема исчезла ровно в тот момент, когда я отключил DHT22 от контроллера. С тех пор работает как часы с большим аптайм. Как может быть с ним связана земляная петля, которая может наводится в витой паре? Вообще топология звезда - самая "безопасная", имея опыт с аудиотрактами я ее и использовал тут. В моей схеме минус нигде не возвращается обратно на MegaD. Update: хотя благодаря "свежему" взгляду сейчас обратил внимание, что все же возврат есть и его легко можно убрать, по крайней мере на стороне MegaD.
А вот на другом контроллере появилась проблема уже после предыдущего случая - когда я повесил на него 1-wire шину с 3-мя DS18B20.
-
с DHT22 связана не проблема, а проявление?
Соберите на столе схему, с тем же контроллером и тем же датчиком, без вашей системы проводов.
Если проблему повторить не сможете - она в проводах.
-
Соберите на столе схему, с тем же контроллером и тем же датчиком, без вашей системы проводов.
Если проблему повторить не сможете - она в проводах.
Появится свободное время - сделаю. Тем более свободные контроллеры есть.
-
1. По сути выяснено (вероятно тут сочетания датчиков I2C и 1-wire или DHT22 и 1-wire).
2. Я очень надеялся на этот параметр, когда просил Вас его реализовать. По умолчанию 200, я изменил на 300сек, но радость моя была не долгой - через ~5 суток снова перезагрузка. Изменил на 500сек, но благодаря сообщениям в Телеграм вижу, что через 2-5 дней все равно происходит перезагрузка.
Я бы предпочел писать лог не изменяя интервалы, поскольку контроллеры в работе и нельзя вредить их более менее стабильной работе…по крайней мере пока у нас зима.
Обратите внимание, интервал между запросами устанавливается в мсек. Если вы установили 500 сек (500000 мсек) - это 8 минут!! время огромное даже в мире MegaD - боюсь, дело не в софте ни с одной стороны. Какой такой запрос надо раз в 8 минут дать контроллеру, чтобы его повесить
.И в логе мы скорее всего ничего не увидим. Если только собирать статистику и будет наблюдаться какая-то регулярность, возможно дело в том, что подключено оборудование по разным протоколам, и (в порядке гипотезы, не специалист по MegaD) есть проблема на контроллере с высвобождением памяти. Если так, то уменьшение интервала должно вести к более частым перезагрузкам.
С другой стороны, существуют системы автоматизации, которые настоятельно рекомендуют перезагружать сервер со всеми потрохами ежедневно по ночам, чтобы обеспечить работу 24х7
А у вас - всего-то раз в 5 дней контроллер перезагрузился. Он же не вешается, watch dog работает, выхода восстанавливаются. Постфактум узнаете - ну да, перезагрузился. В чем проблема?
-
Обратите внимание, интервал между запросами устанавливается в мсек. Если вы установили 500 сек (500000 мсек) - это 8 минут!! время огромное даже в мире MegaD - боюсь, дело не в софте ни с одной стороны. Какой такой запрос надо раз в 8 минут дать контроллеру, чтобы его повесить
.И в логе мы скорее всего ничего не увидим. Если только собирать статистику и будет наблюдаться какая-то регулярность, возможно дело в том, что подключено оборудование по разным протоколам, и (в порядке гипотезы, не специалист по MegaD) есть проблема на контроллере с высвобождением памяти. Если так, то уменьшение интервала должно вести к более частым перезагрузкам.
С другой стороны, существуют системы автоматизации, которые настоятельно рекомендуют перезагружать сервер со всеми потрохами ежедневно по ночам, чтобы обеспечить работу 24х7
А у вас - всего-то раз в 5 дней контроллер перезагрузился. Он же не вешается, watch dog работает, выхода восстанавливаются. Постфактум узнаете - ну да, перезагрузился. В чем проблема?
Нет, конечно я установил 500мсек. Это была моя отчепятка:
В логе можно увидеть на чем спотыкается контроллер. Вообще основная проблема была в том, что все выходы контроллера сбрасывались при его перезагрузке, но вы сделали опцию, благодаря которой теперь все более менее нормально. Правда загрузчик MegaD висит 5 секунд после рестарта (нужно для восстановления контроллера при неудачной прошивке) и только потом загружает прошивку.Представьте себе как было раньше - газовый котел работает почти на 100%, а тут на тебе и больше подачи тепла не нужно, пока проходит порядка 1-5 минут (переопрос датчиков iH и усреднение по последней пятиминутке) он успевает остановится, если температура ниже уставки, то iH бац и снова включает только что вставший котел - не есть айс для него. А если температура выше нижней границы, но ниже верхней, то котел вообще не включается и дом снова остывает и, как итог, к заданному времени не прогревается как надо. Сейчас с опцией восстановления выходов котел даже не успевает остановится пока MegaD в течении 5 секунд перезагружается.
По моему опыту разработки контроллеров на базе AVR никаких зависаний вообще не должно быть! WD - это просто "костыль" на всякий случай! Если программа не обнуляет его счетчик, то он делает reset микроконтроллеру.
-
Нет, конечно я установил 500мсек. Это была моя отчепятка:
Понятно. Это уже другие времена.
В логе можно увидеть на чем спотыкается контроллер….. Сейчас с опцией восстановления выходов котел даже не успевает остановится пока MegaD в течении 5 секунд перезагружается.
То есть не фатально, об этом и речь. Версия системы с сохранением лога плагина в файлы будет вероятно к концу месяца.
