• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Как достучаться до esp через глобальную сеть ?

pvvx

Активный участник сообщества
Не соглашусь, коллега :)
Давать кому угодно управлять модулем - неправильно. Нужно использовать стандарты индустрии, в данном случае для шифрования - TLS, а для аутентификации - либо TLS client certs, либо руками пароли делать, либо другие варианты
Да, они не дают мобильности доступа к устройству. Требуют и внешнее специализированное оборудование. Т.е. путь в никуда.
И это всё для простой кнопки с функцией обмена кода аналогичному как у сигнализации для авто - открыть/закрыть дверь? Любое соединение, хоть UDP и своя шифрация кода решат все ваши проблемы, но требуется аналогично обученное устройство для коммуникации. Смартфон к примеру решает эту задачу из любого места...
А нагородить можно что угодно, но если оно стандартное - прорубят сразу. :)
Или вы тут разрабатываете новый серийный защищенный протокол, который будет хакатся и публиковаться глобальными командами и годами? :confused:
 

nikolz

Well-known member
Да, они не дают мобильности доступа к устройству. Требуют и внешнее специализированное оборудование. Т.е. путь в никуда.
И это всё для простой кнопки с функцией обмена кода аналогичному как у сигнализации для авто - открыть/закрыть дверь? Любое соединение, хоть UDP и своя шифрация кода решат все ваши проблемы, но требуется аналогично обученное устройство для коммуникации. Смартфон к примеру решает эту задачу из любого места...
А нагородить можно что угодно, но если оно стандартное - прорубят сразу. :)
Или вы тут разрабатываете новый серийный защищенный протокол, который будет хакатся и публиковаться глобальными командами и годами? :confused:
-----------------------
По-моему мнению эту задачу лучше решать так.
ESP периодически отсылает данные на сервер по протоколу UDP, как делается и в MQTT, т е без установления соединения.
Cервер принимает данные и если надо отправляет команду на ESP.
Если есть надобность , то протокол обмена можно сделать свой , а не стандартный и еще кодировать 128 битным ключом.
Желающие пусть взламывают и перехватывают ответ сервера.
 

Atom

Member
-----------------------
По-моему мнению эту задачу лучше решать так.
А помоему еще проще и безопасней. апач с веб-бордой представляет из себя отдельный брокер (в моем случае реальный брокер - я пока не планирую использовать москитто). После прохождения авторизации и назначении клиенту сессии, проводит парсинг задания на выполнения. Если задание имеется, то оно отправляется либо броккеру (то есть москитто) [в моем случае прямо на девайс]. в ответ веб-морда посылает статус устройств в текущем сосстоянии. UDP не гарантирует доставку, потому о надежности тоже можно утверждать с такой же вероятности. Ответ подтверждения приходит на другой порт посылающего, посылающий должен как-то склеить запрос и ответ вместе и принять решение, а это сложнее, чем в одной канальной сессии это все делать. TCP как раз и организует канальную сессию: пришел запрос - тут же в контексте ответ.

Upd: Для ВЕБ-морды тоже отказался от всяческих стандартных фишек. Хоть все работает по HTTPS, сделал вожможность работать и по HTTP. веб-клиент посылает первым запрос на получения сессии. В отвев приходит ключь для шифровки. Подготавливается JSON-массив, шифруется и отправляется на сервер. Сервер выполняет описанные выше действия и присылает так же зашифрованный JSON клиенту.
Системой пользуюсь уже чуть более года. У меня стоит рутер с поддержкой телефонной линии. Естественно я через веб-морду могу вытащить список звонков. Но для мобильника проятнее пользоваться специально созданным приложением "Дом" и получать все нажатием одной кнопки. Встроить эту систему обмена в москитто - еще то извращение. Да и надо ли? Окромя этого в домашней системе есть дополнительные функции упpавления домашним сервером - запуск медиаплеера в разных конфугурациях, безопасное подключение-отключение УСБ-накопителей, упдавление камерой наблюдения (которую в данный момент ооочень медленно переделываю).
 

nikolz

Well-known member
А помоему еще проще и безопасней. апач с веб-бордой представляет из себя отдельный брокер (в моем случае реальный брокер - я пока не планирую использовать москитто). После прохождения авторизации и назначении клиенту сессии, проводит парсинг задания на выполнения. Если задание имеется, то оно отправляется либо броккеру (то есть москитто) [в моем случае прямо на девайс]. в ответ веб-морда посылает статус устройств в текущем сосстоянии. UDP не гарантирует доставку, потому о надежности тоже можно утверждать с такой же вероятности. Ответ подтверждения приходит на другой порт посылающего, посылающий должен как-то склеить запрос и ответ вместе и принять решение, а это сложнее, чем в одной канальной сессии это все делать. TCP как раз и организует канальную сессию: пришел запрос - тут же в контексте ответ.

Upd: Для ВЕБ-морды тоже отказался от всяческих стандартных фишек. Хоть все работает по HTTPS, сделал вожможность работать и по HTTP. веб-клиент посылает первым запрос на получения сессии. В отвев приходит ключь для шифровки. Подготавливается JSON-массив, шифруется и отправляется на сервер. Сервер выполняет описанные выше действия и присылает так же зашифрованный JSON клиенту.
Системой пользуюсь уже чуть более года. У меня стоит рутер с поддержкой телефонной линии. Естественно я через веб-морду могу вытащить список звонков. Но для мобильника проятнее пользоваться специально созданным приложением "Дом" и получать все нажатием одной кнопки. Встроить эту систему обмена в москитто - еще то извращение. Да и надо ли? Окромя этого в домашней системе есть дополнительные функции упpавления домашним сервером - запуск медиаплеера в разных конфугурациях, безопасное подключение-отключение УСБ-накопителей, упдавление камерой наблюдения (которую в данный момент ооочень медленно переделываю).
Дело конечно частное.
Но несколько замечаний,
UDP сейчас используется практически во всех системах реального времени.
TCP примерно в 3 раза медленнее UDP.
Разговоры про ненадежность - это из прошлого века.
контроль потери данных решается с UDP реального времени иными методами чем в TCP.
То, что Вы написали - это очень тормозное решение,
но возможно что Вам не требуется скорость обмена.
--------------------------------------------------------------
Без требований к параметрам обмена разговор ни о чем.
 

Atom

Member
Дело конечно частное.
Но несколько замечаний,
UDP сейчас используется практически во всех системах реального времени.
TCP примерно в 3 раза медленнее UDP.
Разговоры про ненадежность - это из прошлого века.
контроль потери данных решается с UDP реального времени иными методами чем в TCP.
То, что Вы написали - это очень тормозное решение,
но возможно что Вам не требуется скорость обмена.
На работе как раз используем UDP, но там промышленные роботы и ресурсов поболее : в один UDP послал запрос, ответ приходит в другой UDP. Нужно делать еще учет того, что ответ может прийти с какой-то задержкой X. а так как сообщения имеют нумерацию, хаоса можно избежать. С микроконтроллерами, где каждый байт на с чету подходы надо использовать другие. У меня ответ по TCP в районе 0.58 сек. Это с учетом того, что запрос идет через телефонного провайдера, через внешний сервер в USA, VPN на домасний сервер и потом к устройству, апотом назад.
 

nikolz

Well-known member
На работе как раз используем UDP, но там промышленные роботы и ресурсов поболее : в один UDP послал запрос, ответ приходит в другой UDP. Нужно делать еще учет того, что ответ может прийти с какой-то задержкой X. а так как сообщения имеют нумерацию, хаоса можно избежать. С микроконтроллерами, где каждый байт на с чету подходы надо использовать другие. У меня ответ по TCP в районе 0.58 сек. Это с учетом того, что запрос идет через телефонного провайдера, через внешний сервер в USA, VPN на домасний сервер и потом к устройству, апотом назад.
Полагаю, Вы противоречите сами себе.
-------------------------------------
Если Вы хотите экономить в микроконтроллере, то это протокол UDP, так как он компактнее и быстрее TCP.
----------------------------------------
Запаздывание пакетов - это в TCP.
в UDP пакетов (в смысле разбивки сообщения на пакеты) нет,
поэтому нет и запаздывания одного относительно другого.
--------------------------------------
Если у Вас на работе UDP ответы путаются, то у вас неправильно настроена сеть.
В правильной сети это исключено.
 

Atom

Member
Полагаю, Вы противоречите сами себе.
-------------------------------------
Если Вы хотите экономить в микроконтроллере, то это протокол UDP, так как он компактнее и быстрее TCP.
----------------------------------------
Запаздывание пакетов - это в TCP.
в UDP пакетов (в смысле разбивки сообщения на пакеты) нет,
поэтому нет и запаздывания одного относительно другого.
--------------------------------------
Если у Вас на работе UDP ответы путаются, то у вас неправильно настроена сеть.
В правильной сети это исключено.
ширина заголовка TCP на несколько байт шире заголовка UDP. Вот и все различие в "противоречии". Сеть то у нас правильно настроена, не стоит беспокоиться. Если хотите больше узнать приколов про UDP - советую попробовать упдавлять например сервисами в Виндовс на удаленном компе. Эта вся басня работает как раз на UDP. Если машина не одна в сети, то очень часто проишодит ситуация, что запрос на остановку службы послан, получено подтверждение, что операция невыполнена, хотя служба была остановлена.
Для микроконтроллера разнице заголовков уж можно допустить - создать единственный буффер хранения заголовка. Тем более этим не стоит заморачиваться, используя ESP.

Очень может быть, что я не правильно умею готовить котят. Если вас не затруднит, пришлите пример того, как делаете это вы: установить соединение, послать буффер запроса, и получить в ответ данные.
 

nikolz

Well-known member
ширина заголовка TCP на несколько байт шире заголовка UDP. Вот и все различие в "противоречии". Сеть то у нас правильно настроена, не стоит беспокоиться. Если хотите больше узнать приколов про UDP - советую попробовать упдавлять например сервисами в Виндовс на удаленном компе. Эта вся басня работает как раз на UDP. Если машина не одна в сети, то очень часто проишодит ситуация, что запрос на остановку службы послан, получено подтверждение, что операция невыполнена, хотя служба была остановлена.
Для микроконтроллера разнице заголовков уж можно допустить - создать единственный буффер хранения заголовка. Тем более этим не стоит заморачиваться, используя ESP.

Очень может быть, что я не правильно умею готовить котят. Если вас не затруднит, пришлите пример того, как делаете это вы: установить соединение, послать буффер запроса, и получить в ответ данные.
---------------------------
Если возможно, объясните, плиз,
что именно в протоколе UDP, по вашему мнению ,
приводит к указанным Вами проблемам.
 

pvvx

Активный участник сообщества
Спор опять ни о чем.

Для пользователя есть главный фактор – мобильность. ESP8266 не позволяет это обеспечить своими средствами. Нет полной поддержки TSL/SSLи т.д.

Для мобильного дома ESPне может служить каким-то входным элементом отделяющим внешнюю глобальную сеть. Забежав в инет-кафе или куда, для простого доступа, имея пароль ничего серьезного и защищенного с ним не сделать.

Как внутреннее устройство домашней сети ESP8266 тоже не канает. Переключать по каналу в мегабиты в секунду WiFi-ем люстру – это моветон. Для умного дома ждите индустрию корпораций – они вам дадут решения автономных исполнительных жучков, но позже. А лепить это на WiFi…

Какая нафиг “домашняя сеть” на сотнях WiFiв окружении тысячи WiFi? До вас ещё не докатилось – к примеру, вечером у меня, танхаузы в Питере, в сети наблюдаются уже наверно тысячи WiFiустройств… :) Скоро уже никто не сможет пользоваться WiFiсвязью дома - всё забито…

За время существования форума видно, что ESP8266 используется как игрушка выходного дня –
“мигаем лампочкой” или “считали температуру по I2Cсо стола в телефон” и далее на помойку.

И по поводу параноя – за год, ESP8266 провисел более нескольких месяцев с открытым в 100Mb/sфиксед IPобщий инет WEBпо 80-му порту и AP, да описанным на стартовой странице паролем и логином. Никаких “посягательств” на покопаться не замечено, кроме автоматических поисковиков и потерянных обрывков чьих-то транзакций…

Я, к примеру, использую ESP8266 как инструмент для мобильного опроса датчиков и прочей отладки, когда неохота тянуть провода, а её скорость позволяет гнать поток мегобиты в секунду, но что не обеспечивают ни какие ардуины и прочие прибамбасы. Например надо поставить, сделать какой замер параметра или что-то переключать от компа... Лепишь к ESP8266 внешнюю микруху или датчик, описываешь программу приема-передачи данных и производишь сиё действо. Потом всё разбираешь и выкидываешь до следующей задачи. Больших применений для ESP8266 увы не вижу. Всё остальное – баловство. :):):)
 

nikolz

Well-known member
Спор опять ни о чем.

Для пользователя есть главный фактор – мобильность. ESP8266 не позволяет это обеспечить своими средствами. Нет полной поддержки TSL/SSLи т.д.

Для мобильного дома ESPне может служить каким-то входным элементом отделяющим внешнюю глобальную сеть. Забежав в инет-кафе или куда, для простого доступа, имея пароль ничего серьезного и защищенного с ним не сделать.

Как внутреннее устройство домашней сети ESP8266 тоже не канает. Переключать по каналу в мегабиты в секунду WiFi-ем люстру – это моветон. Для умного дома ждите индустрию корпораций – они вам дадут решения автономных исполнительных жучков, но позже. А лепить это на WiFi…

Какая нафиг “домашняя сеть” на сотнях WiFiв окружении тысячи WiFi? До вас ещё не докатилось – к примеру, вечером у меня, танхаузы в Питере, в сети наблюдаются уже наверно тысячи WiFiустройств… :) Скоро уже никто не сможет пользоваться WiFiсвязью дома - всё забито…

За время существования форума видно, что ESP8266 используется как игрушка выходного дня –
“мигаем лампочкой” или “считали температуру по I2Cсо стола в телефон” и далее на помойку.

И по поводу параноя – за год, ESP8266 провисел более нескольких месяцев с открытым в 100Mb/sфиксед IPобщий инет WEBпо 80-му порту и AP, да описанным на стартовой странице паролем и логином. Никаких “посягательств” на покопаться не замечено, кроме автоматических поисковиков и потерянных обрывков чьих-то транзакций…

Я, к примеру, использую ESP8266 как инструмент для мобильного опроса датчиков и прочей отладки, когда неохота тянуть провода, а её скорость позволяет гнать поток мегобиты в секунду, но что не обеспечивают ни какие ардуины и прочие прибамбасы. Например надо поставить, сделать какой замер параметра или что-то переключать от компа... Лепишь к ESP8266 внешнюю микруху или датчик, описываешь программу приема-передачи данных и производишь сиё действо. Потом всё разбираешь и выкидываешь до следующей задачи. Больших применений для ESP8266 увы не вижу. Всё остальное – баловство. :):):)
-------------------------
Это не спор и даже не дискуссия, а скорее обмен мнениями.
Я с Вами соглашусь лишь в одном:
Что массовое производство для умных домов сделают корпорации. Добавлю, что подобная ESP и андулино реклама хотелок создает потенциальных покупателей этих изделий.
--------------------------------------
Вы , как и большинство посетителей сайта и пользователей андулино рассматриваю ESP как приемо-передатчик на чстоте 2.4 мгц со встроенным стеком протоколов поддержки беcпроводной сети.
При этом выдвигаете требования к хотелкам на уровне современых систем банковской безопасности.
Типа -" есть пиратский флаг, ищу бесплатный корабль, хочу быть капитаном".
-----------------------------------
Т е все такие хотелки можно представить как БОЛЬШАЯ кнопка на смартфоне,
нажав на которую можно смыть в унитазе. ESP в таких задачах используется на 5% лишь как приемо-передатчик.
--------------------------
Но есть другие задачи, которые скорее всего не будут решаться корпорациями в ближайшее время, либо существующее их решение просто не доступно для тех, кому оно необходимо даже за деньги.
Это умные приборы и умные вещи. В этих задачах не требуется супер защита, так как нет необходимости показывать температуру в унитазе всему миру. Для этих задач ESP просто незаменимо.
При этом , алгоритмы созданные на ESP8266 легко переносятся и на ESP32.
------------------------
В заключение свое эссе, приведу пару примеров
1) сделал на ESP спектрометр для диапазона 200 -800 нм. По-моим оценкам, его цена при мелкой серии 15 т р,
ровно такой же по разрешающей способности спектрометр, но в 2 раза большим по размеру
делают в питере за 150 т р,
в китае за 1.5 т долларов,
в европе за 2.5 т$
2) сделал диммер для управления мощностью потребления нагрузкой, в том числе и индуктивной с ПИД регулировкой.
----------------------
В этих задачах ESP используется на 60%.

-----------------------
 
@Atom, Вы изобретаете велосипед, который изобретён до Вас и за Вас. Я в упор не вижу смысла городить REST для таких задач. Для этого есть MQTT. Смысл конструирования состоит в том, чтобы использовать существующие технологии в максимально целостном сочетании.
 

nikolz

Well-known member
Поясните, пожалуйста, этот фрагмент. Что будет, если у вас сеть с MTU 1500, а UDP-сообщение с размером данных больше, чем 1460 байт.
-------------------------------
Я рад, что Вы знаете про MTU. и ответ на свой вопрос тоже можете найти в учебниках.
---------------------------
Есть разные понятия пакетов.
На уровне протоколов пакетная передача существует в TCP.
В UDP передача осуществляется не пакетами а одним блоком данных не более 64 кбайт.
в протоколе ТСР предусмотрена разбивка на пакеты и сборка их на приемной части на уровне TCP с учетом асинхронного приема.
Есть разбивка на уровне физического канала , там за их сборку отвечает соответствующий уровень.
--------------------------
А что произойдет в ОС на компе, можете почитать в инете.
Я например, на своем компе увеличиваю MTU.
Если Вас интересуют вопросы ускорения обмена то посмотрите еще про алгоритм нагла , но на ESP его тоже нет, а на компе он есть. Я его отключаю.
--------------------------
Народная мудрость гласит - заставь ... богу молится он весь лоб росшибьет.
Применяете все правильно и будет Вам счастье.
 

sarmathus

New member
-------------------------------
Я рад, что Вы знаете про MTU. и ответ на свой вопрос тоже можете найти в учебниках.
---------------------------
Есть разные понятия пакетов.
На уровне протоколов пакетная передача существует в TCP.
В UDP передача осуществляется не пакетами а одним блоком данных не более 64 кбайт.
в протоколе ТСР предусмотрена разбивка на пакеты и сборка их на приемной части на уровне TCP с учетом асинхронного приема.
Есть разбивка на уровне физического канала , там за их сборку отвечает соответствующий уровень.
--------------------------
А что произойдет в ОС на компе, можете почитать в инете.
Я например, на своем компе увеличиваю MTU.
Если Вас интересуют вопросы ускорения обмена то посмотрите еще про алгоритм нагла , но на ESP его тоже нет, а на компе он есть. Я его отключаю.
--------------------------
Народная мудрость гласит - заставь ... богу молится он весь лоб росшибьет.
Применяете все правильно и будет Вам счастье.
Спасибо, учебники я читал, а на мой вопрос вы не ответили. Блок в 64 килобайт не пройдет по Layer1/2.

Вы увеличиваете MTU > 1500? А ваш коммутатор это поддерживает? А ваш маршрутизатор? А Layer1/2 вашего линка с провайдером? А его коммутаторы, маршрутизаторы? А его BGP-пиров? Риторические вопросы. Если вы про Jumbo Frame, то это хорошая штука, чтобы качать файлы с NAS в локальной сети, но за ее пределами MTU = 1500, и это в лучшем случае. Вы в курсе, что если у вас Internet по PPPoE, то MTU уже 1492 байта, а не 1500? И это только один пример.
 
Последнее редактирование:

nikolz

Well-known member
Спасибо, учебники я читал, а на мой вопрос вы не ответили. Блок в 64 килобайт не пройдет по Layer1.

Вы увеличиваете MTU > 1500? А ваш коммутатор это поддерживает? А ваш маршрутизатор? А Layer1 вашего линка с провайдером? А его коммутаторы, маршрутизаторы? А его BGP-пиров? Риторические вопросы. Если вы про Jumbo Frame, то это хорошая штука, чтобы качать файлы с NAS в локальной сети, но за ее пределами MTU = 1500, и это в лучшем случае.
Ну Вы задаете вопросы из учебников. есть соответствующие алгоритмы настройки каналов прочитайте там все это рассматривается подробно.
Но полагаю Вы не поняли основного момента.
На пакеты разбивается на разных уровнях и это не зависит от протокола верхнего уровня.
Т е если например уарт канал попадет в цепочку то он тоже разделит сообщение на пакеты и wifi разделит на свои пакеты и екзернет проводной на свои и TCP на свои а вот uDP не делит.
Т е во всей этой цепочки на уровне протоколов ТСР будет собирать а UDP - нет т е здесь будет ускорение обработки.
Если Вы хотите чтобы нигде не получались осколки пакетов верхнего уровня то вы выбираете длину сообщения кратную длине пакетов соответствующих уровней либо делите сами сове сообщение.
Например, протокол MQTT ориентирован на обмен между устройствами т е сообщения как правило короткие мало живущие частые и быстрые. поэтому и выбран за основу UDP а на него навешан протокол сообщений.
------------------------
Но повторю, не надо праздных вопросов, я не хотел бы заниматься ликбезом.
 

sarmathus

New member
Но повторю, не надо праздных вопросов, я не хотел бы заниматься ликбезом.
Вы, наверно, не поняли, но мне ликбез не нужен, я сам его могу провести. Мне придраться захотелось :).
UDP действительно не занимается фрагментацией. Если данные не влезут, фрагментировать будет IP-уровень. А поскольку гарантии доставки в UDP нет и порядка тоже, то фрагменты могут дойти не все или не в том порядке, и на выходе получится каша. И в этом главный момент: TCP "медленнее" не из-за фрагментации, а из-за гарантированной доставки. Кстати, в надежной сети можно увеличить TCP window и потери на "гарантию" будут минимальны. А в ненадежной сети UDP - это ад кромешный. Попробуйте поговорить по SIP, когда есть потери в сети.
Чтобы в UDP не было фрагментов, приложение само должно следить за размером данных. Кстати, никто не мешает приложению следить за ним и в TCP. Только в UDP приложению надо следить еще и за доставкой, и за порядком. Но иногда - вы правы - UDP уместнее. Всему свой инструмент, и нельзя говорить, что один инструмент однозначно лучше другого.
 

Atom

Member
Поясните, пожалуйста, этот фрагмент. Что будет, если у вас сеть с MTU 1500, а UDP-сообщение с размером данных больше, чем 1460 байт.
По логике ис ходящий пакет будет делиться на фреймы. Но, используя ту же логику, зачем микрокомтроллеру такие длинные сообщения?
 

sarmathus

New member
По логике ис ходящий пакет будет делиться на фреймы. Но, используя ту же логику, зачем микрокомтроллеру такие длинные сообщения?
Делиться будет не на фреймы (L2), а на пакеты (L3). А мы тут просто теоретизируем. Товарищ вон предлагает куски по 64 килобайта через UDP слать, а я объясняю, что на выходе будет винегрет, или придется свой TCP на L7 изобрести с (блекджеком и блудницами) гарантией и упорядочиванием, чтобы нормально собрать это на приеме.
 

Atom

Member
@Atom, Вы изобретаете велосипед, который изобретён до Вас и за Вас. Я в упор не вижу смысла городить REST для таких задач. Для этого есть MQTT. Смысл конструирования состоит в том, чтобы использовать существующие технологии в максимально целостном сочетании.
очень даже может быть... Первыми до сетевого менеджера додумались в ICQ. Потом Майкрософт. Но почему-то изобретатели велосипеда из комманду WhatsApp сейчас на коне.

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

pvvx

Активный участник сообщества
В заключение свое эссе, приведу пару примеров
1) сделал .... при мелкой серии 15 т р,
ровно такой же по разрешающей способности спектрометр, но в 2 раза большим по размеру
делают в питере за 150 т р,
в китае за 1.5 т долларов,
в европе за 2.5 т$
Производство стоит дороже. В понятии производства есть и понятие оплаты школы ваших работников, всякие сертификации и прочие побрякушки. Пока у вас шарашкина контора, то и цена ниже из -за отсутствия социальных гарантий и ...
Можете отдать схему в кружок "детских умелых рук" ;) Прожить или как-то прокормить хотя-бы свою семью на этом не выйдет :p
В MQTT довольно много ограничений, которые я хочу реализовать, но еще не знаю как обойти в рамках протокола. Поэтому я доделаю то, что я хочу, со своим видением этой реализации, казино и девочками, а потом уже буду думать что можно экспортировать в MQTT.
По моему MQTT метво-рожденный протокол, возникший на стыке, как затычка. Пробку то вынут, оборудование переродится, а протокол умрет, как изначально устаревший. Т.е. не протокол - тут наверно ошибка, а стоит воспринимать как концепция временного частичного решения...
В итоге какой Гугле всё равно вам навяжет своё решение с оборудованием. Вы сами такой пример и приводите. :)
 
Последнее редактирование:
Сверху Снизу