Mega 2561 и MQTT
Re: Mega 2561 и MQTT
ИМХО.
Удобство MQTT-брокера в деле домашней автоматизации состоит в том, что в любой момент времени он содержит в топиках _актуальную_ информацию о состоянии кнопок и показаниях датчиков. Что бы управляющий софт (вида того же NODE-Red) не грузить циклами по записи в топик /cmd и распарсиванием полученных значений. И если Мега2561 еще может обеспечить данный функционал в части состояния кнопок, то показания датчиков ей уже будут не под силу. А про 328-ю Мегу вообще речи нет.
Поэтому в данном случае считаю, что, как было предложено выше, HTTP-to-MQTT фронтэнд просто необходим, а разработку функционала MQTT в прошивке 2561-ой Меги на каком-то этапе (например, после реализации передачи цифровых значений как цифр, а не текста) нужно заморозить. Во фронтэнде уже будут и LWT, и QoS, и retain messages, и вся http-логика взаимодействия с обоими версиями Меги, и настраиваемые интервалы опроса для каждого порта и всё, что душа пожелает.
Удобство MQTT-брокера в деле домашней автоматизации состоит в том, что в любой момент времени он содержит в топиках _актуальную_ информацию о состоянии кнопок и показаниях датчиков. Что бы управляющий софт (вида того же NODE-Red) не грузить циклами по записи в топик /cmd и распарсиванием полученных значений. И если Мега2561 еще может обеспечить данный функционал в части состояния кнопок, то показания датчиков ей уже будут не под силу. А про 328-ю Мегу вообще речи нет.
Поэтому в данном случае считаю, что, как было предложено выше, HTTP-to-MQTT фронтэнд просто необходим, а разработку функционала MQTT в прошивке 2561-ой Меги на каком-то этапе (например, после реализации передачи цифровых значений как цифр, а не текста) нужно заморозить. Во фронтэнде уже будут и LWT, и QoS, и retain messages, и вся http-логика взаимодействия с обоими версиями Меги, и настраиваемые интервалы опроса для каждого порта и всё, что душа пожелает.
Re: Mega 2561 и MQTT
Андрей отбой тревоги. Поставил дистрибутив hass.io и там все заработало нормально. Вероятно по умолчанию в Debian 9 закрыты порты. Неохота с этим разбираться
Re: Mega 2561 и MQTT
Ну мое мнение - что если Андрей заинтересован в расширении проекта по производству и продаже Меги, то наоборот корректная и полная реализация MQTT - это необходимый этап. Аргументы:
MQTT - стандарт взаимодействия в IoT. Все программные сервера содержат логику работы и драйвера с связи с этим протоколом. А это значит не надо разбиратося , как парсить значения, как дергать скрипты по HTTP и т.д.
Сейчас нужно писать драйвера к OpenHab, Мажордомо и прочеее и прочее. И самое главное потом поддерживать (!) эти драйвера. Хорошо если энтузиазм разработчика драйвера позволяет заниматься поддержкой...
А MQTT - подключил брокер, изучил правила образования топиков - и все вперед.
MQTT - стандарт взаимодействия в IoT. Все программные сервера содержат логику работы и драйвера с связи с этим протоколом. А это значит не надо разбиратося , как парсить значения, как дергать скрипты по HTTP и т.д.
Сейчас нужно писать драйвера к OpenHab, Мажордомо и прочеее и прочее. И самое главное потом поддерживать (!) эти драйвера. Хорошо если энтузиазм разработчика драйвера позволяет заниматься поддержкой...
А MQTT - подключил брокер, изучил правила образования топиков - и все вперед.
-
- Сообщения: 528
- Зарегистрирован: 09 авг 2016, 15:09
- Откуда: Сочи
Re: Mega 2561 и MQTT
Поддержу, прежде чем купить, смотрю на простоту настройки. Кому-то просто разобрать Modbus посылку, мне не просто. А вот Mosquitto все за тебя делает (прием и передачу) и в понятном читаемом виде.
Re: Mega 2561 и MQTT
Поддерживается ли в MQTT работа с портами 1WBUS ?
На get возвращает пустое значение, на list не реагирует.
На get возвращает пустое значение, на list не реагирует.
Re: Mega 2561 и MQTT
Провел углубленное тестирование. Стало гораздо лучше, при нормальном пользовании выключателем пропусков и дизконнектов нет, но если начать быстро стучать по сенсорам, то начинаются пропуски и, очень редко, отключения Меги от брокера с последующим переподключением.
Протестировал три варианта взаимодействия с портами IN/OUT Меги и подключенного к ней ШИМ-расширителя PCA9685 из Openhab2.2
1) IN-MQTT Binding, OUT-MQTT Binding - проблемы описаны выше
2) IN-MQTT Binding, OUT-HTTP Binding - проблемы те же и, даже, хуже
3) IN-MegaD Binding, OUT-MegaD Binding(родные порты)/HTTP Binding(порты PCA9685) - почти идеально
С уважением, Игорь
Re: Mega 2561 и MQTT
Igor78, наличие "пропусков" в данной ситуации зависит от того, насколько быстро поступают пакеты от брокера/сервера.
Преимущество HTTP в том, что устройство работает напрямую с сервером, и команда на выполнение действий может присутствовать в следующем же TCP-пакете, который поступает от сервера. При наличии даже самого слабого сервера в локальной сети вы не сможете визуально отличить включение выхода через автоматику и коммутацию электрической цепи непосредственно выключателем.
С MQTT все иначе. Здесь есть посредник в виде брокера. Сначала информация о событии поступает к нему, затем он передает ее дальше серверу. Сервер отвечает командой, которая опять же идет не напрямую, а через брокер.
Я протестировал быстродействие связки устройство-брокер-сервер (клиент на PHP). Она существенно, а я бы сказал, на порядок медленнее прямого общения с сервером по HTTP. Даже на глаз заметно, что команда от сервера поступает с задержкой. Не исключаю, что причина в реализации серверного клиента на PHP. Но лучше ли реализация подобного клиента в OH?..
Я, конечно, подумаю, что тут можно сделать. Оно ведь, конечно, модно и круто, гибко и удобно...
Сочетание "IN-MQTT / OUT-HTTP" я бы точно не стал рекомендовать.
Преимущество HTTP в том, что устройство работает напрямую с сервером, и команда на выполнение действий может присутствовать в следующем же TCP-пакете, который поступает от сервера. При наличии даже самого слабого сервера в локальной сети вы не сможете визуально отличить включение выхода через автоматику и коммутацию электрической цепи непосредственно выключателем.
С MQTT все иначе. Здесь есть посредник в виде брокера. Сначала информация о событии поступает к нему, затем он передает ее дальше серверу. Сервер отвечает командой, которая опять же идет не напрямую, а через брокер.
Я протестировал быстродействие связки устройство-брокер-сервер (клиент на PHP). Она существенно, а я бы сказал, на порядок медленнее прямого общения с сервером по HTTP. Даже на глаз заметно, что команда от сервера поступает с задержкой. Не исключаю, что причина в реализации серверного клиента на PHP. Но лучше ли реализация подобного клиента в OH?..
Я, конечно, подумаю, что тут можно сделать. Оно ведь, конечно, модно и круто, гибко и удобно...
Сочетание "IN-MQTT / OUT-HTTP" я бы точно не стал рекомендовать.
Re: Mega 2561 и MQTT
Igor78, кое-что изменил, но не факт, что это как-то поможет. Попробуйте.
https://ab-log.ru/files/File/megad-2561 ... a4-hex.zip
Тестирование показало, что скорость работы с mosquitto очень высокая. Никаких задержек или сбоев. Во всяком случае я ничего такого не обнаружил.
Но может тормозить серверное ПО. В этом случае новые события могут генерироваться быстрее, чем приходят команды от сервера.
Как вы детектируете "пропуски"? Что вы вкладываете в это слово? Если под пропуском вы понимаете отсутствие на сервере информации о событии, то изменится ли что-нибудь, если сервер будет только слушать, но не давать команды в ответ?
https://ab-log.ru/files/File/megad-2561 ... a4-hex.zip
Тестирование показало, что скорость работы с mosquitto очень высокая. Никаких задержек или сбоев. Во всяком случае я ничего такого не обнаружил.
Но может тормозить серверное ПО. В этом случае новые события могут генерироваться быстрее, чем приходят команды от сервера.
Как вы детектируете "пропуски"? Что вы вкладываете в это слово? Если под пропуском вы понимаете отсутствие на сервере информации о событии, то изменится ли что-нибудь, если сервер будет только слушать, но не давать команды в ответ?
Re: Mega 2561 и MQTT
Есть одно предположение, связанное с работой "серверного ПО" и MQTT при высокой частоте обращений. Если в ПО используется база данных без поддержки транзакций - как раз и могут возникать всякие коллизии, типа подачи команд не в том порядке, в котором они пришли, и тому подобное. Для прояснения можно сделать тест, нагрузив MQTT хаотическими запросами внешним скриптом, не Мегой.
Re: Mega 2561 и MQTT
Отвечает. Проверьте пожалуйста - не забыта ли закрывающая скобка. Вижу следующий вывод:
Код: Выделить всё
megad/118/cmd get:35
megad/118/35 {"port":"35","value":"ffd041a61501:29.93;ff6e03a61503:43.75;ffe104a61503:85.00;ff5f5fa61503:46.12"
Re: Mega 2561 и MQTT
Под пропуском понимаю неисполнение отправленной сервером команды: в ответ на срабатывание сенсора (TTP223 на "родном" входе типа IN) на Мега отправляется подряд 5 команд на переключение одного "родного" выхода и изменение четырех выходов PCA9685, так вот они не всегда все исполняются.Andrey_B писал(а): ↑30 янв 2018, 18:48Igor78, кое-что изменил, но не факт, что это как-то поможет. Попробуйте.
..
Как вы детектируете "пропуски"? Что вы вкладываете в это слово? Если под пропуском вы понимаете отсутствие на сервере информации о событии, то изменится ли что-нибудь, если сервер будет только слушать, но не давать команды в ответ?
Протестировать новую прошивку постараюсь завтра.
С уважением, Игорь
Re: Mega 2561 и MQTT
Igor78, сделайте пожалуйста дамп с "пропусками" с помощью Wireshark.
Re: Mega 2561 и MQTT
r7s, добавил скобку.
https://ab-log.ru/files/File/megad-2561 ... a7-hex.zip
https://ab-log.ru/files/File/megad-2561 ... a7-hex.zip
Re: Mega 2561 и MQTT
Заработало. Спасибо.Andrey_B писал(а): ↑01 фев 2018, 12:18r7s, добавил скобку.
https://ab-log.ru/files/File/megad-2561 ... a7-hex.zip
Andrey_B. Возвращаюсь к вопросу о том, что бы выдавать более структурированный JSON. Т.е. вместо {"port":"34","value":"ff0283a61501:33.37;ff8140a61501:36.43;fffd6aa61501:42.87;ff9b84a61501:52.00"} возвращать {"port":34,"value":{"ff0283a61501":33.37,"ff8140a61501":36.43,"fffd6aa61501":42.87,"ff9b84a61501":52.00}}
На размере посылки это вроде существенно не должно сказаться, но сильно повысит удобство работы с ответом.
Есть ли такая техническая возможность? Можно ли это сделать?
-
- Сообщения: 528
- Зарегистрирован: 09 авг 2016, 15:09
- Откуда: Сочи
Re: Mega 2561 и MQTT
Пробую MQTT на Меге, для теста изменяю значение PWM.
Но в топике ничего не появляется. Только если запросить состояние вручную.
Так и должно быть?
Но в топике ничего не появляется. Только если запросить состояние вручную.
Так и должно быть?
Re: Mega 2561 и MQTT
Прошу прощения, что вклиниваюсь не в свою тему. Думаю, именно так и должно быть, потому что PWM расположен на ВЫХОДЕ. Изменение состояния выхода не вызывает обращение Меги к серверу. По крайней мере для HTTP все именно так и происходит.martiniman писал(а): ↑01 фев 2018, 20:15Пробую MQTT на Меге, для теста изменяю значение PWM.
Но в топике ничего не появляется. Только если запросить состояние вручную.
Так и должно быть?
-
- Сообщения: 528
- Зарегистрирован: 09 авг 2016, 15:09
- Откуда: Сочи
Re: Mega 2561 и MQTT
Т.е. Факт включения нагрузки не публикуется моментально?
Публикуются только входы?
Не нашел где почитать, чтобы глупых вопросов не задавать.
Публикуются только входы?
Не нашел где почитать, чтобы глупых вопросов не задавать.
Последний раз редактировалось martiniman 01 фев 2018, 20:43, всего редактировалось 1 раз.