Comments 27
А просто mDNS нельзя в локалке использовать?
С андроид смартфонов Captive Portal на локальных адресах типа 192.168.4.1 сам не выскакивает. Но если адрес назначить глобальный, типа 200.200.200.1, то Captive Portal на андроид смартфоне выскочит сам. Исследовал этот вопрос пока писал https://github.com/uqfus/esp32-wifi-provision-care для esp32. С чем связано могу только догадываться, на стэкексчендже такое решение нашел без указания на источник, а конкретных руководящих документов на этот счет не нашел.
Ну и касательно прошивки через подключение устройства через USB, вам не лень подключать, и отключать, приносить, и уносить esp32? Можно добавить обработчик POST запроса и прошивать устройство по сети с использованием curl. Пример тут смотрите https://github.com/uqfus/esp32-wifi-provision-care/tree/main/examples/esp32-firmware-upload-ota-example
По поводу 10.0.0.0/8 и 172.16.0.0/12 не поделитесь наблюдениями?
Такое поведение Captive Portal наблюдается на всех локальных адресах, на указанных вами Captive Portal тоже автоматически не вылезает. Поискал опять, и опять ничего толкового не нашел.
https://github.com/esp8266/Arduino/commit/adf2b14a6a1493b324d8e176a1519af76bd7e5fb
Спасибо!
а вот тут https://stackoverflow.com/a/69006333
пишут что надо перехватывать server.onNotFound(handleRoot);
и тогда работает даже для локальных адресов ...
Такой вариант предусмотрен, в ответ отправляется 302 Temporary Redirect.
Там еще есть предложение использовать в качестве IP адреса 8.8.8.8 ссылаясь на жестко заданный адрес DNS сервера в андроид. Но это получается то же самое, что и любой глобальный адрес. И не понятно что же тут конкретно сработало. А вот как перенаправить пакет с DNS запросом в адрес 8.8.8.8 на локальный DNS сервер на 192.168. на esp32 я чёт с наскока не придумаю.)
На самом деле существует несколько подходов к реализации Captive Portal. :) Ваш подход тоже вполне рабочий, но мы остановились на использовании локального IP 192.168.4.1 и библиотеки DNSServer.
На устройствах Android и iOS, Captive Portal срабатывает благодаря особенностям операционных систем, которые проверяют доступ к интернету, отправляя запросы, например, на connectivitycheck.gstatic.com. DNSServer перехватывает такие запросы и перенаправляет их на локальный сервер 192.168.4.1, обеспечивая корректную работу Captive Portal. Кстати, по аналогичному принципу работает WiFiManager, который является отличным конкурентом вашему продукту. :)
Что касается POST обновлений, я с вами полностью согласен. Однако речь здесь идет о новых пользователях, а не об обновлении существующего кода.
Касательно перехвата запросов, DNS server из примеров esp32 перехватывает вообще все запросы, в логах это видно. Это дело я первым делом проверил. Потом обратил внимание, что если адрес локальный у портала, то в настройках Wi-Fi в смартфоне есть кнопка "требуется настройка" (могу путать, уже подзабыл) и она ведет на портал, но сам портал, при подключении к точке доступа, не выскакивает. Если найдется в будущем решение этой заморочки, то я изменю адрес на локальный.
WiFiManager - отличный проект, он использует фреймворк Arduino, я фреймворк Arduino не использую. Есть еще менеджер Wi-Fi https://github.com/tonyp7/esp32-wifi-manager тоже очень хороший проект, использует парадигму очередей сообщений и базовый фреймворк ESP-IDF. Из-за этого исходники читаются не очевидно и кое где не используются возможности ESP-IDF фреймворка. Там некрасиво (по моему скромному мнению) написан обработчик http запросов. Ещё esp32-wifi-manager всегда запускается в полном объеме, с вебсервером, с очередями. Я решил чуток все это исправить и остановиться уже не смог.) Но за то изучил html с css и JS.
Интересная затея. Я повторял подобный проект, правда на базе ESP32 и подключал к нему ЦАП PCM5102. Работает, классно. Попробовал подключить ЦАП ES9018K2M, но вот здесь к сожалению ничего хорошего не вышло. Либо тишина, либо шумы в одном канале. Почему так - не понял и вернулся к PCM5102.
Может кто работал с таким ЦАП, может подкинуть пример рабочего кода?
Спасибо! Вопрос, а если в сети несколько таких устройств?
Ничего не понял. 90% устройства за NAT сидят и ip роутера тоже локальный внутри провайдера, снаружи недоступен. Что даст сохранение такого ip? Я в своё время делал просто опрос конечными устройствами в определённый период сервера.. Но так себе решение
Вы, вероятно, не совсем внимательно прочитали статью. Проблемы с тем, что устройство находится за NAT, на самом деле нет. IoT-устройство, подключённое к вашей WiFi-сети, может определить свой локальный IP-адрес (например, 192.168.3.2) и отправить его на сервер (onclick.lv) через GET-запрос.
Сервер при этом сохраняет два параметра: локальный IP, который отправило устройство, и глобальный IP, с которого пришёл запрос.
Когда потом вы заходите на сайт (с той же сети), сервер видит ваш глобальный IP-адрес, сравнивает его с сохранёнными данными и проверяет, были ли запросы от IoT-устройства с этим же глобальным IP. Если совпадение есть, сервер может показать вам локальный IP-адрес устройства, который был передан ранее.
Теперь понял - это нужно только для того, чтобы узнать локальный IP и обращаться к нему из локальной же сети. Я действительно не внимательно прочитал.. думал, что решается проблема передачи команд от сервера к устройству в общем случае.
Чего люди не сделают, лишь бы mDNS не использовать :)
К сожалению среди наших клиентов mDNS в среднем работает только у 60% пользователей. Конечно эти цифры могут варьироваться в других случаях, но у нас статистика именно такая. Объяснять оставшимся 40% клиентов, почему технология не работает, особенно когда их количество исчисляется тысячами, превращается в крайне трудоемкую задачу.
Но если за одним NAT провайдера тысячи клиентов, то как различить, какому конкретно клиенту принадлежит конкретный IoT, если вдруг несколько разных IoT разных клиентов посылали GET на Ваш сервер?
Идея неплохая, но если NAT не только на своем роутера, а и у провайдера, то могут быть проблемы. Например, если интернет через LTE модем с МТС SIM картой, то внешний IP даже в двух вкладках браузера может различаться. Даже не знаю, как это у них получается.
Мне кажется, что трехходовочка тут лучше работала бы. После первого шага с поднятием точки доступа и получением SSID и PSK, можно просто подключиться к AP, сохранить IP адрес, полученный от DHCP, а затем снова перейти в режим точки доступа, сообщая этот IP клиенту через редирект. Соответственно после первого же обращения клиента, подключаемся обратно к AP. В подавляющем большинстве случаев IP адрес получим тот же самый.
Если следовать инструкции - включить IoT-устройство и сразу зайти на сервер для настройки - никаких проблем возникнуть не должно.
Что касается вашей идеи с трёхходовкой, она кажется излишне сложной. Проще дать возможность каждому устройству задавать уникальное имя. Когда клиент заходит на сервер, и если сервер обнаруживает несколько устройств с одинаковым IP-адресом, система может запросить имя устройства, а затем сопоставить его с данными.
Мы применяли подобный подход в прошлом году, устанавливая около 15 сенсоров на одном из заводов. Эти сенсоры мониторят оборудование и передают свои локальные IP-адреса на сервер предприятия. На сервере мы настроили удобную панель, где отображается весь список устройств и графики с данными, которые сервер подтягивает по локальным IP адресам. Такой подход отлично зарекомендовал себя. Нужен новый сенсор? Просто включил, подключил к роутеру сети - и он сразу появляется на сервере, готовый к работе.
Забегая вперёд и отвечая хейтерам: сохранять историю данных в техническом задании не было. Нужно отображать только актуальные, свежие данные в режиме реального времени.
Если следовать инструкции - включить IoT-устройство и сразу зайти на сервер для настройки - никаких проблем возникнуть не должно.
И как же Вы свяжете их, если у них окажутся разные внешние IP?
Проще дать возможность каждому устройству задавать уникальное имя
Теоретически оно уже есть в виде MAC-адреса. Но на практике они дублируются. А если имя будет давать пользователь, то в половине случаев для одного типа устройств оно будет совпадать у всех пользователей. Хотя связь вместо внешнего IP по MAC-адресу, скорее всего, уже позволит решить проблему.
она кажется излишне сложной
Зато она не требует выхода в интернет. И если для частных лиц последнее не так уж важно, то для бизнеса это может быть весьма критичным и представлять дополнительные сложности. Например, у моего текущего клиента нет ни одного завода или офиса, где можно выйти в интернет без авторизации в AD FS и не имея такие права. А сам факт необходимости выхода в интернет для какого-то сенсора может привести к запрету его закупки и применения ИБ.
ESP32 поддерживает combined AP-STA mode. Так почему бы этим не воспользоваться?
устанавливая около 15 сенсоров на одном из заводов
Что-то не верится, что у завода выход в интернет через LTE модем. А в остальных случаях маловероятно, чтобы разные TCP соединения производились с разных внешних IP адресов.
Хотя если завод крупный и использует балансер для нескольких соединений, то такое тоже вполне возможно.
Просто включил, подключил к роутеру сети - и он сразу появляется на сервере, готовый к работе.
Если есть локальный сервер, то и проблем никаких нет. Достаточно кроме SSID и PSK указать сервер и токен к нему, заранее привязанный к устройству.
Хмм, а зачем для радио использовать какие то прокладки типа "onclick" ? Нельзя разве напрямую подключаться к необходимым трансляциям - просто настроив адреса станций в еспешке и тянуть трафик. Открытых примеров таких радио в сети полно.
Очередное Интернет-радио на базе ESP*, но с изюминкой