Период опроса DHT: две секунды и план на случай сбоя

Дачный метеологгер жил на восьми метрах провода вдоль забора и писал CSV на карту. Однажды колодка на линии подсела, и в журнале начались срывы: библиотека возвращала nan, скетч честно пропускал такие строки, и я неделю смотрел на сплошной график, не зная, что под ним дыры. Когда я стал считать средние за сутки, выяснилось, что кривая тихо поплыла — пропущенные чтения сдвинули её без единого предупреждения. Тогда я впервые сформулировал для себя вопрос, который теперь задаю каждому: что ваша автоматика обязана делать, когда датчик замолчал?

Здесь соберём ответ целиком. Период опроса — константа с обоснованием: две секунды для DHT22, секунда для DHT11, и почему не наоборот. Срыв чтения — штатная ситуация, а не катастрофа: nan надо ловить и не пускать в арифметику. И главное — мягкая деградация: последнее честное значение с печатью возраста, счётчик сбоев и аварийная ветка, когда показания устарели окончательно. Почву под это мы готовили в уроке про интервал опроса и уроке про диагностику nan — там разобраны, почему чаще двух секунд нельзя и какие железные причины стоят за каждым срывом. Здесь — поведение автомата, а не поиск виноватых.

Нижняя граница периода задана конструкцией сенсора: DHT11 обновляет показания примерно раз в секунду, DHT22 — раз в две. Опрос чаще этих значений не даёт свежих чисел — вы либо читаете то же самое, либо ловите сенсор на внутреннем пересчёте и получаете nan. Поэтому период живёт в скетче одной константой PERIOD = 2000 и проверяется таймером millis, а не размазанными delay: loop остаётся живым для кнопок, дисплея и реле, как мы привыкли с урока про millis вместо delay.

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

Пара практических привычек к константе периода. Первая: дайте ей имя, говорящее о единицах — PERIOD_MS, а не просто PERIOD, чтобы через полгода не гадать, секунды это или миллисекунды. Вторая: на время отладки период иногда растягивают до двадцати-тридцати секунд, чтобы руками успеть рассмотреть, как автомат живёт на устаревших показаниях, — а потом возвращают обратно. Константа в одном месте делает оба манёвра правкой одной строки вместо охоты за delay по всему скетчу.

У таймера millis есть собственный горизонт, о котором вспоминают раз в полтора месяца: счётчик переполняется через 49,7 суток, и все сравнения с ним проходят через ноль. Конструкция millis() - lastPoll < PERIOD на беззнаковой арифметике переживает переполнение без единой правки: вычитание в unsigned сворачивается корректно при любом моменте перехода. А вот запись вида millis() > lastPoll + PERIOD на границе лжёт — сложение уезжает за максимум, условие срывается, и автомат, проживавший сорок девять дней спокойно, вдруг решает, что время остановилось.

Когда обмен не состоялся, библиотека возвращает nan — «не число». Это вежливый отказ конкретного чтения, а не поломка сенсора. Реакций бывает три, и я прошёл их все. Наивная — пустить nan дальше: любое сравнение с nan даёт ложь, среднее за сутки превращается в nan, реле решает по мусору. Жёсткая — стоп по первому срыву: честно, но один сбой в неделю поднимает будильник среди ночи. Мягкая — держать последнее честное значение и его возраст: пользоваться свежими числами, помечать устаревшие, считать сбои подряд, а когда возраст выйдет за лимит — уходить в безопасный режим.

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

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

Заметьте асимметрию аварийной ветки: нагрев выключается, а не переключается. Без свежих показаний автоматика не имеет права греть: холодный ящик — обратимая беда, перегретый — нет. Безопасное состояние для каждого автомата своё — вентилятор оставить крутиться, реле разомкнуть, зуммер запищать — но оно обязано быть явно прописано, а не «само получится».

Отдельно про самый первый запуск. Пока ни одно честное чтение не прошло, goodStamp равен нулю, и автомат печатает zhdu pervoe chtenie: реле стоит, решения нет. Ветка выглядит скучной, но она ловит реальный сценарий — датчик забыли подключить или перепутали пин. Без неё автомат со старта считает возраст от нуля millis и решает по нулевому значению, а это худший возможный первый шаг термостата.

Аварийная ветка защищает решения автомата, но не сам скетч: если loop завис на delay или упёрся в глухой цикл, тревогу изнутри кода поднять уже некому. На платах AVR за этим следит аппаратный watchdog — таймер с потолком около восьми секунд, который перезагружает плату, если его не гладить вызовом wdt_reset в каждом проходе. Мягкая деградация и watchdog — два этажа одной защиты: первый переживает срывы линии, второй — зависший скетч, и вместе они закрывают худшие сценарии длинного прогона, когда к устройству никто не ходит неделями.

Соберу периоды, к которым я пришёл на живых проектах. Две секунды — отладка и живой монитор, когда хочется видеть дыхание показаний. Пять-десять секунд — комнатная автоматика: окно реле всё равно решает реже, чем датчик успевает устать. Тридцать секунд — теплица и подвал, где всё меняется минутами. Минуты — журнал на SD. Четверть часа плюс сон — батарейная версия, и там период уже диктует не сенсор, а аккумулятор. Все эти цифры — не паспортные требования, а компромиссы между свежестью, шумом и сроком жизни железа.

Период и лимит возраста вместе образуют два контракта со временем: опрос не чаще, чем сенсор умеет, и решения не старше, чем воздух позволяет. Когда оба контракта прописаны в коде именованными константами, автомат становится предсказуемым при любой погоде на линии — собранный целиком такой автомат живёт в итоговом проекте раздела, с реле, LCD и той же аварийной веткой.

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