NaN от DHT: почему датчик молчит и как чинить

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

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

Вспомним, как идёт обмен. Контроллер роняет линию данных на 18–20 миллисекунд, сенсор просыпается и отвечает сорока импульсами, где каждый бит закодирован длительностью высокого уровня: около 27 микросекунд для нуля и 70 для единицы. Библиотека отмеряет эти длительности, собирает два байта влажности, два байта температуры и проверяет контрольную сумму. Если сенсор не проснулся, импульсы рассыпались от наводки или сумма не сошлась — честного числа нет. Библиотека не выбрасывает ошибку и не печатает диагностику: она тихо возвращает nan, специальное значение «not a number». Датчик при этом жив; он просто не смог ответить на этот конкретный вопрос. Время всего обмена — 4–5 миллисекунд, и всё это время процессор занят только подсчётом импульсов.

Штатный способ поймать отказ — функция isnan(): принимает float, возвращает true, если внутри nan. Ставится она до использования числа: сорванное чтение печатается отдельной строкой и пропускается, а не едет дальше в логику термостата и не портит ему среднее. Я ставлю isnan во все DHT-скетчи без исключений — по той же причине, по которой пристёгиваюсь в машине: без проверки едешь ровно до первого сбоя. Если в вашем скетче nan уже едет в расчёты, средние за сутки будут испорчены: чинить надо на входе, а не на выходе.

В этом скетче две конструкции тянут на привычку всей жизни. Опрос по millis() вместо delay: loop() крутится свободно, а датчик читается строго раз в две секунды — для метеостанции разница невидима, а для проекта с кнопками и дисплеем это граница между живым и зависшим интерфейсом. Если связка с lastRead выглядит незнакомо, вернитесь к уроку про millis — мы разбирали её по шагам.

Вторая привычка — считать nan отдельной строкой журнала, а не нулём. Если сорванное чтение записать как 0, среднее за ночь просядет, минимум за зиму окажется фальшивым, а график получит яму на ровном месте. Отдельная строка FAIL с меткой времени — уже диагноз в миниатюре: если такие строки кучкуются по ночам, первым подозреваемым будет питание, а не сенсор. Отдельная глава — проводка: тонкая перемычка с плохим контактом в колодке даёт ровно такой эпизодический nan, как в моей истории; как выбирать провода и укладывать их на макетке, разобрано в отдельном уроке.

Проверка диапазона — не замена isnan, а его родственник, и путать их нельзя. В симуляторе она ловит мусорное значение, вышедшее за физические пределы датчика. На настоящем железе всё хитрее: любое сравнение с nan возвращает false, поэтому nan проходит через условие if (t < -40.0 || t > 80.0) как ни в чём не бывало — компилятор не предупредит, а график получит выброс. Поэтому на реальном скетче сначала isnan(), как в листинге выше, и только потом проверки диапазона. Второй рубеж остаётся полезным: он ловит датчик, который ответил числом, но числом невозможным — такое случается с перепутанными линиями и самодельными удлинителями. Правило двух рубежей я формулирую так: нечисловой мусор и невозможное число — разные неисправности, и ловятся по-разному.

Если все шесть строк таблицы проверены, а nan держится — сенсор, скорее всего, мёртв: клоны DHT умирают от конденсата, перегрева и времени. Но есть плановое решение, к которому я прихожу раньше, чем датчик успевает умереть. Самодельный однопроводной протокол DHT с таймингами в микросекунды — устаревшая конструкция: сенсор чувствителен к длине провода, качеству питания и загруженности процессора в момент чтения. I2C-датчики — AHT20, SHT31, BME280 — живут на шине из двух проводов, отвечают стабильно и стоят сопоставимо. Моё правило с границей: DHT11 в комнате на макетке — нормальный выбор на годы; на улице, в теплице или дальше метра от платы я сразу ставлю AHT20, и историй с nan у меня с тех пор ноль. Это не эстетика: на шине I2C не ловятся микросекундные тайминги, и длина провода почти не играет роли. Если шина I2C вам пока незнакома, начните с урока про два провода.

Когда nan побеждён, показания наконец становятся данными, которым можно верить. Дальше маршрут такой: термостат с гистерезисом превращает температуру в реле вентилятора, а журнал на SD-карте копит строки в файл, который потом открывается таблицей. И ставьте isnan сразу — тогда однажды утром в логе будет не столбик nan, а одна строка FAIL с точным временем, после которой останется проверить питание, а не переписывать код. Если журнал копится на карте, эти строки FAIL позже превратятся в статистику: сколько срывов за ночь — готовый график здоровья питания.