Рассматриваемый контроллер представляет собой шестиканальное устройство для подключения датчиков температуры и влажности DHT11 / DHT22 и передачи полученных данных по интерфейсу RS485 на сервер Raspberry Pi.
Кроме функций сбора и передачи показаний температуры и влажности на сервер, контроллер можно использовать как обычный автономный измеритель, в котором показания выводятся на собственный дисплей.
Контролер поддерживает работу с пятью датчиками DHT11 (для измерения температуры и влажности внутри помещений) и с одним датчиком DHT22 (для измерения температуры и влажности на улице).
Принципиальная схема контроллера приведена на рис.1.
Рис.1
Информация о измеряемых параметрах выводится на алфавитно-цифровой дисплей с разрешением 4 строки по 20 знакомест. Особенностью дисплея является то, что он подключается через шину I2C, что позволило уменьшить количество портов управления микроконтроллера с шести до двух и применить простой микроконтроллер 16F628A. Более подробно о дисплеях с адаптером I2C можно почитать по этой ссылке.
Для подключения датчиков используются входы портов А и В микроконтроллера с подтягивающими резисторами. Микросхема МАХ485 является драйвером для приема и передачи данных с UART микроконтроллера по интерфейсу RS485 на сервер Raspberry Pi.
Для удаленного мониторинга температуры и влажности через сервер Raspberry Pi данные выводятся в web-интерфейс (рис.2):
Рис.2
Контроллер собран на печатной плате, алфавитно-цифровой дисплей устанавливается над платой на стойках. Для подключения питания, цифровых датчиков, интерфейса RS485 применяется 20-ти клемный разъем.
Внешний вид контроллера показан на рис. 3
Рис.3
Дополнено: Учитывая, что датчики DHT11 имеют большую погрешность при измерении влажности, разработана еще одна версия прошивки контроллера, позволяющая подключать к нему 6 датчиков DHT22. Вариантов этой прошивки два - первая ch_6_DHT22.HEX, в которой названия точек контроля (улица, балкон, кухня, зал, спальня, кабинет) прописаны непосредственно в программе и вторая ch_6_DHT22_text.HEX в которой пользователь сам может присвоить любому датчику любое название длиной до 8 символов, прописав соответствующие символы в EEPROM в кодировке ASCII (рис.4):
Рис.4
Ниже приведена таблица кодировок знакогенераторов дисплеев типа HD44780. Знакогенераторы с поддержкой кириллицы позволяют выводить на дисплей все символы таблицы, без поддержки - только символы левой части таблицы (рис.5):
Рис.5
В прилагаемом к статье архиве находятся чертежи принципиальной схемы и печатной платы, а также прошивки микроконтроллера. На дисплее в последней строке выводятся названия точек контроля (см. видео):
Так же сегодня посмотрел демо-видео о возможностях веб интерфейса. Так и не понял, есть ли возможность активации и настройки гигростата, по аналогии с термостатом?
Прошить контроллер, собрать и отладить устройство, смогу. А вот с момента " подправить скрипты", для меня тёмный лес начинается. Сможете оказать содействие?
Так же не помешала бы индикация выхода за дозволенные режимы, и сообщения об этом на смартфон. Ну скажем устанавливаешь индикацию при выходе за установленные пределы, и плюс сообщение, если выход за пределы превышает (установлеваемое) время.
Так эти функции нужно реализовывать на стороне сервера! Тем более, что у МК уже фактически не осталось свободных портов. По большому счету - да, это именно индикатор, так все и задумывалось. Но индикатор, который передает данные на сервер. Следовательно, на сервере можно реализовать любые сценарии, исходя из полученных значений температуры и влажности.
Возможно Вы правы. Но не знаю осилю ли я это. Да и железо пока в пути. А идея автономной работы, хорошая идея. И ещё , есть некоторые мысли на этот счёт. Я уже использовал подобные устройства для решения стоящих задач, но все они не универсальны, и не в полной мере удовлетворяют условиям. Например, огромной проблемой, периодически возникающей, является крайне не надёжная и не долговременная работа датчиков влажности. Использовал и дешёвые китайские, и промышленные. И те и те умирают. То есть уже через месяц, два, три, датчики начинают лгать, и климат убегает, что приводит к серьёзным сбоям технологического оборудования, и это не сразу заметишь, из за его инертности (оборудования). Потом, приведя климат в норму, опять приходиться ждать пока из за инертности , все придёт в норму. А это порядка недели простоя. Поэтому, было бы здорово, организовать какой нибудь алгоритм, минимизирующий ошибки, при выходе из строя , или уплывания, старения датчиков. Я это представляю примерно так. Контроллер постоянно опрашивает 4 датчика, и смотрит разницу в показаниях, и принимает за верное, например среднее значение между тремя, с наименьшей разницей показаний. Таким образом, один датчик, дающий наибольший улет, всегда исключается. А при превышении этого улёта на определённую, запрограмированную пользователем величину, система индицирует о неисправности этого датчика. Таким образом, его можно поменять , а система всегда остается на плаву. Возможно это уже где то и реализовано, и возможно это как то по другому делается. Но я не встречал. А мне это крайне необходимо. Поэтому буду благодарен за любую помощь. С Уважением.
Сначала по поводу конкретного девайса, что бы было понимание его назначения. Он разрабатывался как "концентратор" датчиков DHTxx, которые, к сожалению, не имеют возможности работы по шине (в отличие от тех же DS18B20). Поэтому, изначально я вообще не планировал прикручивать к нему дисплей, а только передавать данные на сервер. Но что бы просто посмотреть температуру на улице или в доме, открывать каждый раз браузер не очень удобно, поэтому и появилась "панель оперативного контроля". А так можно организовать мониторинг и без этой "прокладки" и завести датчики DHTxx сразу на GPIO Raspberry Pi.
Если реализовывать Ваш вариант (с возможностью управления нагрузкой по введенным уставкам температуры и влажности), я бы делал девайс немного иначе. Это должен быть модуль, имеющий вход для подключения одного датчика, 1-2 выхода управления нагрузкой, дисплей, кнопки программирования уставок и интерфейс связи с сервером.
Теперь насчет деградации датчиков. На самом деле это очень интересный вопрос, с похожей ситуацией (правда немного в другой плоскости), мне пришлось столкнуться в своей профессиональной деятельности. Поэтому позволю себе небольшое отступление: На работе мы уже давно пытаемся внедрить систему мониторинга высоковольтного оборудования на тяговых подстанциях. Есть много "контор", которые бодро обещают создать подобную систему и рассказывают, какие параметры необходимо снимать с оборудования для создания такого мониторинга. Т.е. поставим вам дополнительные датчики, проложим связь, соберем информацию на сервер…и тут наступает коллапс, когда объясняешь им, что на современных подстанциях мы и так собираем всю эту информацию в АСУ ТП. А дальше-то что с ней делать? Никто не может предложить вменяемую математическую модель (выходную функцию) которая показывала бы тенденцию старения оборудования. Кроме того, здесь очень много зависит от внешних факторов. Например, лежит снег на вводах трансформатора или идет дождь, сопротивление изоляции вводов в этом случае уменьшается. Но это ведь не деградация, следовательно, здесь необходимо учитывать погодные условия, причем только измерением температуры и влажности тут не обойтись. И таких взаимосвязанных факторов огромное количество.
Ваше предложение контролировать деградацию датчиков по уходу показаний одного из датчиков от значения "среднего по больнице", имеет, конечно, право на жизнь. Но нужно учитывать, что датчики должны быть предварительно откалиброваны и должны находиться в абсолютно одинаковых условиях по отношению к внешним факторам. Если обеспечить такие идеальные условия (что в реальных условиях всегда проблематично), то реализация подобного алгоритма вполне возможна.
Конкретно в моем случае, все датчики будут именно в одном месте, а их количество определенно только для вычисления неисправного, с целью его своевременной замены, а не для увеличения точности измерения. Вернее что бы заменить его раньше, чем мы заметим это уже тогда, когда система даст реальный сбой климата. Эталонная точность показаний, не критична. Критична именно стабильность. То есть мы должны создать всегда одинаковую влажность, ибо для себя я пока не представляю, как определить эталон. Сейчас, в системе работает (промышленный) датчик ОВЕН ПВТ100. Его показания принял за эталон, просто потому, что кто то должен им быть. (Хотя производитель отказался сообщить о том, какой сенсор в нём установлен.) Возможно тот же дешевый китай, только со своим интерфейсом. Так же , чисто для информации и наработки статистики, влажность контролируют ещё восемь , различных, скопившихся за время войны с этой проблемой, гигрометров, цифровых, аналоговых стрелочных, и психометрический. И все показывабт по разному. И кому верить...?(((. Но повторюсь, точное соответствие (глобальному эталону) , для меня не важно. Важна стабильность. ОООчень интересные и полезные у Вас разработки. Спасибо ВАм за то что Вы делаете. Я попытаюсь повторить устройства, доработав под свои задачи. Так что иногда буду приставать с вопросами....) С Уважением.
Насколько я понимаю, контроллер влажности , способен работать только как индикатор? Возможно ли реализовать с помощью него , установки порогов срабатывания исполнителей и управление нагрузками, как и в контроллере температуры? Например включение увлажнителя и осушителя, для поддержания влажности в заданных пределах. Думаю что подобный функционал значительно расширил бы границы применения комплекса.
Уважаемый Admin, можно ли попросить немного подправить код и выложить hex на 4-ре DHT22 и остальные DHT11 или все DHT22? (загородная баня и под минусы зимой DHT22 больше подходит)
Зато это есть в куче других статей. Вы когда видите схему девайса с интерфейсом RS485, так что, обязательно "мастер" будет показан? Нет конечно! Просто две линии на RS485.
