Измеряем температуру, влажность и отслеживаем показания газового счетчика с использованием ThingSpeak. Часть 5. Избавляемся от сенсоров DHT.

В предыдущих частях повествования о проекте по мониторингу температуры и потребления газа, я достаточно подробно описал всю подноготную устройства. Еще в первой версии устройства, построенной непосредственно на платформе Arduino, я отказался от электрохимических датчиков серии MQ и заменил неточные сенсоры DHT11 на своих более точных и обладающих большим диапазоном измерений собратьев DHT22. Но и тут все оказалось не так радужно, как хотелось бы.

После миграции с Arduino Uno на ESP8266 вдруг выяснилось, что помимо очень сложного алгоритма получения сведений температуры и влажности с сенсоров серии DHT, они имеют еще и мерзкую особенность уходить в ступор выдавая вместо реальных показаний -5 как по градусам, так и по влажности. Что меня ни в коей мере не устраивало, тем более что происходило сие в случайные моменты времени и лечилось только перезагрузкой всего устройства.

Заморозка показаний до -5 на одном из сенсоров DHT22

Заморозка показаний до -5 на одном из сенсоров DHT22

При вводе в эксплуатацию подобнее поведение датчиков — недопустимо и назрела насущная проблема по апгрейду всей конструкции.

Трудности при подключении двух одинаковых датчиков к одной системе

Arduino платформа, безусловно, мощная и в меру гибкая. При грамотном подходе тут можно реализовать практически любые хотелки, особенно если понимать те ограничения, которые имеет как сама платформа, включая ее язык, так и используемая периферия. Для экосистемы Arduino существует несколько типов датчиков с разными стандартами подключения. Самые простые версии — полностью аналоговые. Они, как правило, подключаются к аналоговому порту и изменяют свое сопротивление (электрически ток, протекающий через датчик) тем самым сигнализируя о том или ином уровне измеряемого параметра. Перевод сопротивления в падение напряжения, которое способен измерить аналоговый порт, происходит, обычно, путем применения простейшего делителя напряжения. Аналоговые датчики, вернее датчики с аналоговым интерфейсом, конечно хороши, но их точность и широта использования оставляют желать много лучшего. Еще больше усугубляет ситуацию то, что в ESP8266 только один аналоговый порт, поэтому подключение к нему нескольких аналоговых устройств потребует использование какой-то дополнительной схемы коммутации показаний с разных сенсоров.

На ступеньку выше стоят датчики, передающие сигнал импульсами. В некоторых случаях импульсная система коммуникации называется PWM или ШИМ. Суть подобной передачи данных почти идентична азбуке Морзе, только тут, по велению пятки задней ноги производителя, могут использовать не только сигналы низкого или высокого уровня, но и длительность самих сигналов, паузы между импульсами и прочее прочее прочее. Именно к этой категории относятся датчики серии DHT, в том числе и пресловутые DHT22.

Для чего была придумана система передачи данных от датчика к плате импульсами, я достоверно сказать не могу. Видимо какие-то ограничения для разработчиков существовали, а скорее всего, проблема была в неразвитой аппаратной базе или необходимости сопряжения с какими-то не очень смышлеными контроллерами. Тем не менее подобный подход имеет право на существование и наверняка где-то с успехом применяется. Вот только проблем на более современных устройствах, нагруженных высокоскоростными задачами от импульсной кодировки, возникает больше, чем преимуществ от применения таких недорогих датчиков.

Для разбора импульсов требуется нетривиальный код, да с ним справится программист средней руки, но сколько времени он потратит на разработку и тестирование кода или же адаптацию готовых библиотек? Более того, сама суть импульсной передачи данных требует времени. Импульсы размазываются во временном потоке и требуется ждать пока все сообщение полностью доберется до адресата. А в не мультизадачных системах, к которым относится и экосистема Arduino, ожидание сообщения означает блокировку выполнения всех остальных задач. Что есть недопустимая роскошь в некоторых случаях.

Если продвинуться еще немного вперед, то на сцену выходят устройства передающие показания по цифровым шинам в виде осмысленной информации. В таких устройствах применяется свой прикладной протокол обмена, работающий на какой-то стандартной среде передачи. Например, в качестве транспортной среды используется стандартный последовательный порт, а данные и команды кодируются в шестнадцатеричные последовательности. Разобраться с подобным обменом несоизмеримо легче, чем с импульсным кодированием, да и работает вся связка быстрее и надежнее, поскольку обработка показаний и формирование ответа осуществляется на самом датчике. А задачей Arduino является только запрос сведений и их интерпретация. К числу подобных датчиков можно отнести датчик температуры и влажности SHT1x или же сенсор CO2 MH-Z19.

Еще выше располагаются датчики способные обмениваться информацией по стандартизированным цифровым протоколам, например, SPI или I2C. Переход к стандартизированному протоколу — огромный шаг вперед, который позволяет с легкостью обмениваться данными между десятками, а в некоторых случаях и сотнями устройств по одной шине (читай нескольких проводам). Такое возможно, поскольку у каждого такого устройства имеется свой уникальный адрес, к которому и обращается контроллер если ему нужно отправить команду или получить отклик от сенсора. В моем проекте применяется один такой датчик. Это датчик температуры и барометрического давления BMP180.

И вроде бы казалось, что лучше и разумнее всегда использовать продвинутые датчики. Например, в природе существуют датчики BMP280, сочетающие в себе измерители температуры, давления и влажности. Использование трех таких датчиков покрыло бы, с избытком, все потребности по измерению состояния окружающей среды в проекте. Но не тут-то было. В каждом датчике BMP используется зашитый в него производителем адрес устройства на шине I2C. И адрес этот один и тот же для всех датчиков серии. Соответственно повесив два или более датчиков с одинаковым адресом на одну шину, подключив к одним и тем же пинам, мы рискуем получить неработоспособное устройство, датчики не смогут разобраться, к кому именно идет запрос и отвечать тоже будут хором.

Бороться с подобным можно разными способами. Можно организовать несколько шин I2C на одном контроллере. Но для этого придется заморачиваться с несколькими объектами библиотеки Wire от Arduino и разбираться с библиотеками конкретных датчиков. Можно, при помощи внешней схемы, коммутировать подключение и отключение датчиков в нужный момент. Но это все костыли, которые взлететь хоть и дадут, но насладиться полетом как следует не дадут. Самым правильным способом является изменение адреса на самом датчике или использование дополнительного адреса на самом датчике. Стандарт на коммуникацию в I2C подобное предусматривает, вот только далеко не все производители датчиков позволяют себе такие вольности. И у пользователя нет ни единой возможности для изменения адреса на датчике.

Как выкручиваемся из ситуации

Но недаром русский Илья Муромец подковал татарскую блоху, и из подобного затруднения можно вполне элегантно выбраться. Отступаем на один шаг назад, отходим от стандартизированных шинных протоколов, и переходим к датчикам с уникальными протоколами на стандартных транспортных каналах. Иными словами, возвращаемся все к тем же SHT1x.

Для подключения датчика DHT нужно три провода: VCC, GND и Data. Для подключения датчика SHT1x нужно уже четыре провода: VCC, GND, SCL и Data. Добавился один вход/выход SCL по которому передаются тактующие импульсы, задающие скорость обмена информацией. Но как же быть, если на ESP8266, после отключения двух DHT остается всего два свободных пина? Ведь для подключения вместо DHT новых SHT1x требуется не два, а целых четыре свободных пина.

Напомню читателю, что в системе установлен еще и BMP180 работающий по шине I2C и подключенный тоже четырьмя проводами: VCC, GND, SCL и Data. И вход/выход SCL у него применяется для тех же целей, что и у SHT1x. В своей статье о том, как подключить два датчика SHT1x к одной плате я специально подключил их всего к трем пинам. Контакты Data подключены к отдельным пинам, а SCL у двух датчиков соединены вместе. Но даже если соединить SCL у двух SHT1x, то все равно потребуется три пина для подключения датчиков, а в наличии только два свободных.

Выход нашелся при соединении SCL от SHT1x к SCL от BMP180. Система будет работать и работать нормально. Сейчас постараюсь объяснить почему. Даже несмотря на то, что у SHT1x и BMP180 используются разные протоколы связи, ножка с SCL применяется и там и там для одной и той же цели — синхронизации передачи данных между устройствами посредством передачи тактовых импульсов. А теперь вспомним, что Arduino это не многозадачная система и опрос датчиков в ней может быть выполнен только и исключительно последовательно. Поэтому соединив SCL сразу у трех датчиков, мы не помешаем их последовательному опросу.

У меня есть две гипотезы относительно того, почему все это работает. Гипотеза «раз» заключается в том, что тактовые импульсы не задаются при инициализации соответствующих библиотек, а возникают только тогда, когда идет непосредственное обращение к датчику. И гипотеза «два» состоит в том, что при использовании единой скорости обмена тактование будет одним и тем же у обоих типов датчиков. Проверить сие достаточно легко, достаточно взять осциллограф и посмотреть есть ли импульсы (всплески напряжения) между SCL и GND после инициализации библиотек, но между поросами датчиков. Если нет, то импульсы появляются только во время обращения к датчику и верна гипотеза «раз», но при этом не отменяется гипотеза «два».

Паяльник в руки и вперед

Подключить новые два датчика не составило особого труда. Ниже я набросал схему для макетной платы, дабы было понятно движение мысли. Прошу обратить внимание, что все три SCL подключены к одному пину.

Измененная схема счетчика с использование SHT1x

Измененная схема счетчика с использование SHT1x

В ходе экспериментов выяснилось, что датчики SHT1x вообще прекрасно работают без подачи на них полноценного питания. Им оказалось достаточно питания с цепей данных. Но все же, не стоит использовать их без нормального, полноценного подключения.

Дополнительно хочу отметить, что применение разработческой платы для Arduino Uno позволило и вовсе обойтись без паяльника. Вся коммутация была произведена внутри корпуса при помощи соединительных проводов, подключенных в нужные пины.

В программный код я внес минимальные изменения, подключение датчиков SHT1x было реализовано в версии 14. Сам исходный код доступен по этой ссылке. Но не стоит им злоупотреблять. Код, по-хорошему, стоит подвергнуть рефакторингу, так как там осталось много вкраплений уже не используемых переменных и осколков ненужных процедур. На скорость выполнения оно не сильно влияет, но лишнее место потребляется.

Собственно, это последняя статья, которая успешно завершает целый цикл статей по теме очумелых ручек в отношении измерения и мониторинга потреблений газа для обогрева жилища вкупе с отслеживанием климатических показаний. Надеюсь, что информация, представленная тут, оказалась полезной для читателя.

Ознакомиться со всем циклом статей можно по следующим ссылкам:
Измеряем температуру, влажность и отслеживаем показания газового счетчика с использованием ThingSpeak. Часть 1. Используем Arduino Uno R3.
Измеряем температуру, влажность и отслеживаем показания газового счетчика с использованием ThingSpeak. Часть 2. Используем ESP8266.
Измеряем температуру, влажность и отслеживаем показания газового счетчика с использованием ThingSpeak. Часть 3. Собираем все вместе.
Измеряем температуру, влажность и отслеживаем показания газового счетчика с использованием ThingSpeak. Часть 4. Обрабатываем значения.
Измеряем температуру, влажность и отслеживаем показания газового счетчика с использованием ThingSpeak. Часть 5. Избавляемся от сенсоров DHT.



Измеряем температуру, влажность и отслеживаем показания газового счетчика с использованием ThingSpeak. Часть 5. Избавляемся от сенсоров DHT.: 2 комментария

  1. Уведомление: Увеличиваем точность определения влажности датчиков SHT-1x, а заодно и всех остальных | Многобукфф

Добавить комментарий