Мини-веб-сервер на ESP32: управляем светодиодом из браузера

Понедельник, десять вечера. Я лежу на диване и соображаю: вставать и идти выключать свет в комнате лень. Светом управляло реле на ESP32, но включалось оно физической кнопкой — как у пещерных людей. Реле-модуль коммутировало лампу через опторазвязку, схема занимала три провода, а вся магия была в софте. Через вечер плата уже слушала 80 порт, а я гасил лампу кнопкой в браузере телефона, не поднимая головы от подушки. Тот момент, когда веб-страница оживает на плате размером со спичечный коробок, — один из самых довольных за весь мой ардуино-стаж.

В этом уроке собираем такой сервер с нуля: как браузер находит плату в локальной сети, как выглядит запрос-строка, которую шлёт браузер, как плата отвечает HTML и по какому слову в запросе решает, включать светодиод или выключать. В симуляторе весь обмен сервера с клиентом будет виден в Serial-логе — вы своими глазами увидите то, что на реальной плате печатается в монитор порта. А в финале ждёт чек-лист на случай, когда страница на живой плате откажется открываться: каждый пункт я собрал на собственных ошибках.

Адрес http://192.168.1.100/ читается по частям: http — протокол, 192.168.1.100 — адрес платы в локальной сети, порт — 80, путь — одинокий слэш. Порт 80 — стандарт для HTTP, поэтому в адресе его никто не пишет; если однажды поднимете второй сервер на 8080, адрес станет http://192.168.1.100:8080/. И условие по сети: адреса вида 192.168.x.x видны только внутри домашней сети — из интернета, с работы или с мобильного трафика страница не откроется, как ни обновляй.

Почему плата доступна по числам, а любимые сайты — по именам? Для имён есть DNS — служба, которая переводит «ya.ru» в IP-адрес. Мини-сервер на плате DNS не поднимает, да и не нужно: в домашней сети проще обращаться к плате по адресу напрямую. Если захочется имени вида esp32.local, плате поможет библиотека ESPmDNS — она объявляет имя в локальной сети, но чтобы имя открывалось, нужен телефон с поддержкой Bonjour, а числа работают всегда. В наших уроках — только числа.

Браузер отправляет плате несколько строк текста, и для нас важна только первая — запрос-строка. Если на странице кнопка ведёт на /on, строка будет такой: GET /on HTTP/1.1 — метод, путь и версия протокола. Вот как выглядит весь запрос целиком, плата получает его обычным текстом:

Ключевые строки. WiFiServer server(80) создаёт сервер, server.begin() запускает его в setup после подключения к WiFi — именно в таком порядке, до сети серверу некуда стучаться. В loop() server.available() возвращает клиента, если кто-то подключился, — и пустой объект, если нет; отсюда if (!client) return;, чтобы loop() не зависал в ожидании.

client.readStringUntil('\n') читает первую строку запроса до перевода строки — она-то и содержит команду. Поиск indexOf("GET /on") надёжнее точного сравнения строк: даже если строка пришла с хвостатым \r от Windows-клиента, поиск по подстроке не сломается. Дальше — digitalWrite по состоянию и сборка HTML ответа построчно.

Ответ плата собирает так же текстово: строка статуса HTTP/1.1 200 OK, заголовок Content-Type: text/html, пустая строка и HTML страницы. Кнопка на ней — обычная ссылка: нажатие заставляет браузер снова постучаться к плате, уже с путём /off. Никакой магии и никакого JavaScript в минимальном варианте — чистый HTTP, как в девяностых, и это прекрасно. Почему ссылка, а не форма? Форма шлёт POST с телом, который надо дочитывать из клиента, — лишние строки там, где хватает одного тега; до форм доберётесь, когда понадобится передавать значения вроде яркости светильника.

Ловушка, о которой молчат примеры: браузер сам запрашивает `/favicon.ico` — иконку сайта — сразу после открытия страницы. Вы увидите два запроса вместо одного, и это не баг. В нашем скетче favicon получает ту же страницу, что безвредно; в больших проектах на favicon отвечают коротким 404 и не грузят плату. Второе число с условием: Connection: close плюс client.stop() закрывают соединение сразу после ответа — без этого браузер держит соединение открытым, и пары клиентов на плате может не хватить.

Отдельно про симулятор ниже: отдельного браузера в нём нет, поэтому приход запроса имитируется — раз в шесть секунд виртуальный клиент присылает запрос-строку, а сервер обрабатывает её той же логикой, что и реальная плата, печатая в Serial-лог запрос, решение и то, что ушло в ответ. Именно так выглядит монитор порта настоящей платы, когда вы жмёте кнопки на странице с телефона. И мнение моё тут такое, с условием: сервер без пароля прекрасен внутри квартиры, а вот пробрасывать 80 порт на роутере в глобальную сеть я не стану, пока не добавлю хотя бы проверку ключа в запросе — голые серверы боты находят за считанные минуты.

Раздел по сети у вас в кармане: плата подключается к WiFi, ходит за данными и сама отвечает браузеру. Логичный следующий шаг — повесить на GPIO датчик DHT22 и собрать табло температуры, которое видно с телефона: сервер из этого урока плюс один analogRead по пути /temp. Схема остаётся той же: датчик опрашивается в loop() по расписанию, значение кладётся в String ответа, страница обновляется кнопкой в браузере. А когда захочется, чтобы данными пользовались несколько устройств и история копилась на сервере — приходите в раздел про MQTT: там плата перестаёт быть единственным сервером в доме. И держите в голове правило из начала урока: локальный сервер — для дома, в глобальную сеть — только с паролем.