Два API в одном loop: опрос по расписанию без блокировок

У дачного табло погоды был один источник — открытый API с городом, — и всё было хорошо, пока жена не попросила добавить на тот же экран состояние теплицы: температура с собственного сервера в сарае. Я вписал второй GET-запрос в loop() рядом с первым и получил сразу две беды. Табло начало обновляться раз в минуту вместо десяти секунд, а мигающий курсор-разделитель замирал на полсекунды, будто плата спотыкается на каждом шагу. Вторая беда вылезла через сутки: кнопки перестали отзываться вовсе, а опросы в Serial шли всё реже и реже — соединения где-то копились, и плата медленно захлёбывалась.

Обе беды выросли из одной привычки: писать сетевой код так, будто запрос мгновенный. Он не мгновенный: http.GET() блокирует loop() на всё время, пока сервер соображает, а по умолчанию в ядре arduino-esp32 клиент ждёт ответа до 5000 мс. Два запроса подряд в одном проходе цикла — до десяти секунд полной глухоты: ни кнопок, ни экрана, ни мигалок. А объект HTTPClient, оставленный без http.end(), держит после себя соединение и буферы — десятки таких забытых клиентов съедают память, и плата ведёт себя как герой детектива: ещё работает, но уже странно.

В этом уроке разведём два опроса по тайм-слотам на millis(): свой сервер — каждые 30 секунд, городской API — раз в минуту. Правило одного запроса за проход loop(), отдельные объекты и end() в той же функции, где begin, — и скетч держит оба источника, не забывая ни про кнопку, ни про экран.

Идея та же, что в millis-мигалке без delay, только будильников два и у каждого своё расписание. На каждый опрос — своя отметка unsigned long: lastA для сервера теплицы, lastB для городского API. В каждом проходе loop() смотрим, истёк ли интервал: millis() - lastA >= 30000 — пора к теплице, millis() - lastB >= 60000 — пора в город. Сравнение через вычитание не прихоть: беззнаковая разность остаётся верной, когда millis() переполнится через 49,7 суток, а лобовое millis() > lastA + 30000 на том же переполнении сломается.

Разнесённые интервалы почти никогда не совпадают, но раз в минуту оба таймера истекают в одном проходе — 60 секунд кратно и тридцати, и шестидесяти. Отсюда мой закон: один проход loop() — один сетевой запрос. Два подряд — это два блокирующих GET друг за другом, до десяти секунд ступора, и все мигалки это почувствуют. Второй опрос просто переезжает на следующий тик: опоздание на миллисекунды никто не заметит, а цикл остаётся живым. Хочется жёстких гарантий между источниками — есть путь суровее: разнести их по задачам FreeRTOS на два ядра, как я показывал в уроке про двойное ядро и уроке про очереди и семафоры. Но в девяти проектах из десяти хватает тайм-слотов, которые видно глазами целиком.

Сколько времени на самом деле занимает один запрос? На домашнем сервере в сарае — 100-300 мс, на внешнем API — от полсекунды до полутора, и такие окна экран и кнопки даже не замечают. Драма начинается, когда сервер молчит: окно растягивается до таймаута, пять секунд на запрос, и вот тут правило одного запроса за проход превращается из стилистики в необходимость. В симуляторе GET отвечает за полсекунды всегда — виртуальные серверы не молчат; на живой плате проверьте свой худший случай: выключите роутер и посмотрите в Serial, сколько реально длится отказ.

Каждый вызов oprosit() живёт по правилу «пришёл — спросил — прибрался»: локальный объект HTTPClient создался, сделал begin/GET/getString и закрылся вызовом http.end(). end() — это client.stop() плюс выгрузка заголовков из памяти; без него каждый запрос оставляет после себя соединение и буферы. Я ставлю end() в той же функции, где begin(): при таком порядке прибираться приходится всегда, что бы ни вернул GET, — и утечка невозможна даже в тех ветках, где тело не читается. Если хочется завести один общий клиент и переиспользовать его — легально, но тогда end() перед каждым begin() обязателен, и следите, чтобы ни одна ветка не выпрыгивала из функции между ними.

Функция oprosit() возвращает код не для красоты: выше по скетчу его можно сосчитать в счётчик отказов, зажечь светодиод или записать строку в журнал — именно так мы поступим в двух следующих уроках. Возвращённое значение — дешёвая страховка на будущее: скетч, где результат запроса уже выведен наружу, расширять на порядок проще, чем тот, где он тонет внутри функции.

Обратите внимание на else if в планировщике: в один проход цикла срабатывает максимум одна ветка. Даже если оба интервала истекли разом — после долгого обрыва, например, — теплица спросится сейчас, город в следующем проходе, через миллисекунду. Честность ради: два независимых if тоже работают и компилируются, но на живой плате я однажды поймал ровно то, от чего страхует else: городской API задумался, тепличный запрос ждал за ним, и экран на десять секунд замер при формально «правильном» скетче. После этого случая правило «один тик — один запрос» висит у меня над столом.

Интервалы 30 и 60 секунд я выбрал не с потолка. Тепличный датчик живёт своей жизнью, его опоздание на полминуты ничего не меняет. А городскому API я читал условия тарифа: бесплатные планы просят не дёргать их чаще раза в минуту, и у одного сервиса в списке лимитов прямо стояла строчка «60 запросов в час». Своим серверам в сарае я задаю хоть секунду; чужим — ставлю интервал с запасом, потому что смена правил на чужой стороне не приходит с уведомлением. Что делать с телом ответа, когда оно пришло, — отдельная история: разбор JSON по HTTP раскладывает его по переменным, здесь же я оставил печать сырой строки.

Движок эмулирует оба этажа, которые нужны этому скетчу: WiFi.begin подключает виртуальную плату за секунду-другую, а HTTPClient честно выполняет begin/GET/getString/end — код 200 и тело приходят настоящими. Одна условность: оба «сервера» отвечают одним демо-телом с Москвой и температурой — демо-сеть у движка одна на все адреса, различить источники по телу не выйдет; на живой плате ответы, само собой, разные. Зато расписание видно идеально: строки [TEPLICA] идут каждые 30 секунд, [GOROD] — раз в минуту, и системная строка HTTP: GET перед каждым запросом показывает, кто именно спросил. Включите скорость ×10 — опросы пойдут каждые три и шесть секунд, и за минуту вы увидите полный цикл расписания, включая момент, когда оба слота совпали. Обратите внимание на порядок строк: системное HTTP: GET — это begin, затем мой вывод с кодом, затем тело и end().

Тайм-слоты отвечают на вопрос «когда спрашивать», но не на вопрос «а жив ли тот, кого я спрашиваю». Оба моих источника однажды отказали в одну неделю: сервер в сарае — после скачка напряжения, городской API — сам по себе, и разбираться, что именно упало, пришлось по косвенным признакам. После этого у табло появился третий, самый частый опрос — проверка роутера раз в десять секунд со светодиодом и журналом отказов: аргумент, с которым в спорах про «у меня всё работает» больше не нужны слова. Собираем этот монитор в следующем уроке; а отправка собственных показаний наружу, если ваш проект растёт в обратную сторону, разобрана в уроке про IoT-датчик. Правило при этом переносится дальше двух источников: третьему и четвёртому достанутся свои отметки и свои интервалы, пока скетч остаётся плоским и читаемым.