Основные тезисы или о чем эта статья
Продолжаем цикл статей о ShIoTiny — визуально программируемом контроллере на базе чипа ESP8266.
В этот статье рассказано на примере проекта управления вентиляции в ванной комнате или другом помещении с повышенной влажностью о том, как строится программа для ShIoTiny.
Предыдущие статьи серии.
ShIoTiny: малая автоматизация, интернет вещей или «за полгода до отпуска»
ShIoTiny: узлы, связи и события или особенности рисования программ
Ссылки
Бинарные прошивки, схема контроллера и документация
Инструкция и описание узлов
Настройка MQTT брокера cloudmqtt.com
Панель управления MQTT dashboard для Android
Введение
Понимания вне опыта не бывает. Это истина, проверенная временем и поколениями. Поэтому нет ничего лучше для обучения практическим навыкам, чем попытки сделать что-то самостоятельно. И примеры, которые показывают что можно делать, а что не стоит и пробовать, тут придутся как нельзя кстати. Чужие ошибки, конечно, не смогут предотвратить возникновение ошибок собственных, но могут помочь сократить число последних.
Вопросы и письма читателей предыдущих статей подвигли меня сделать небольшой проект-пример управления вентиляцией для того, чтобы показать как работают узлы ShIoTiny.
Изначальная идея, на основе которой появился контроллер ShIoTiny — насосно-поливальная станция — далеко не всем подойдет и будет интересна. Поэтому я взял всем понятную и многим полезную систему управления вентиляцией в качестве примера.
Скажу, что идея проекта не моя, а почерпнул я ее отсюда и затем адаптировал к ShIoTiny.
Сначала пойми чего ты хочешь
Процесс совершенствования — бесконечен. И именно это свойство погубило множество хороших идей и проектов. Разработчик вместо того, чтобы выпустить пусть и не идеальную, но рабочую вещь — продолжал её совершенствовать. И совершенствовал до тех пор, пока конкуренты не обходили его, выпуская пусть и не идеальное (а часто откровенно убогое), но работающее решение.
Поэтому очень важно знать — где поставить точку в проекте. Или, иными словами, надо определить что мы хотим получить в конце проекта из того, что у нас есть в начале. В русском языке для документа, который составляется как раз с целью описать путь создания чего-либо, есть прекрасное короткое и емкое слово «план», которое умственно отсталые переводчики и дефективные менеджеры в последнее время почему-то начали именовать «дорожная карта». Ну да бог с ними.
Наш план будет таким. Предположим, что имеется помещение, влажность в котором может временами сильно повышаться. Например такое, как ванная комната или кухня. Влажность — вещь неприятная и способ борьбы с ней стар как мир: проветрить помещение. Способов проветривания довольно много. Но мы, пожалуй, откажемся от экзотических и старомодных способов вроде негров с опахалами и остановимся на обычном вентиляторе. Вентиляторы дешевле, да и найти их в наших краях проще.
Одним словом, мы хотим управлять вентилятором: включать его и, соответственно, выключать. Точнее мы хотим, чтобы он сам включался и выключался когда надо.
Осталось определить: при каких условиях вентилятор должен включаться и при каких условиях — выключаться.
Тут все очевидно: если влажность выше какого-то заданного предела — вентилятор включается и вытягивает воздух; влажность пришла в норму — вентилятор отключается.
Внимательный читатель сразу зацепится взглядом за слово «заданной». Кем заданной? Как заданной?
Задавать пороговую влажность можно несколькими способами. Мы рассмотрим два из них: первый — с помощью переменного сопротивления и второй — по сети через протокол MQTT. У каждого из этих способов есть преимущества и недостатки, которые будут рассмотрены в дальнейшем.
Для тех, кто не понял, поясню, что «пороговая влажность» — это такой уровень влажности, при превышении которого требуется включение вентилятора.
Следующий вопрос: давать ли пользователю право включить вентилятор непосредственно? То есть вне зависимости от уровня влажности, по нажатию кнопки? Мы такую возможность предусмотрим. Ведь вентилятор может понадобиться не только при повышенной влажности, но и для удаления из помещения, например, неприятного запаха, именуемого в народе «вонью».
Итак, мы поняли чего хотим и даже немного, как это будет работать. Перечислим кратко все функции нашей системы управления вентиляцией:
- установка порогового уровня влажности (два варианта);
- измерение уровня влажности;
- автоматическое включение вентилятора;
- автоматическое выключение вентилятора;
- ручное включение вентилятора (по нажатию кнопки).
Итак, план понятен. Необходимо реализовать все выше перечисленные функции в нашей программе. На основе этого «плана» и будем действовать. Для начала нарисуем структурную схему устройства.
Структурная схема устройства
Вообще говоря, таких схем у нас будет две. Первая — для варианта, в котором пороговый уровень влажности задается переменным сопротивлением. Вторая схема — для варианта, в котором пороговый уровень влажности задается по сети через протокол MQTT.
Но так как эти схеме будут отличаться всего на один элемент — переменный резистор «установка порогового уровня влажности», то нарисуем лишь одну структурную схему. Конечно, структурная схема согласно ГОСТ выглядит иначе. Но мы ориентируемся не на зубров-инженеров, а на молодое поколение. Поэтому наглядность важнее.
Итак, что ж мы видим на рисунке? Вентилятор подключен к реле Relay1 контроллера ShIoTiny. Обращаю внимание, что вентилятор есть штуковина, обитающая под высоким напряжением. Поэтому, ежели кто будет делать сам такое — проявляйте осторожность. То есть, как минимум, прежде чем совать свои пальцы или измерительные приборы в схему — обесточьте как минимум вентилятор. И второе замечание. Если ваш вентилятор мощнее, чем 250Вт, то подключать его напрямую к ShIoTiny не стоит — только через пускатель.
С вентилятором разобрались. Теперь кнопка «ручное включение» вентилятора. Она подключена ко входу Input1. Тут и пояснять больше нечего.
Датчик температуры и уровня влажности DHT-11 (или DHT-22 или их аналоги). Для его подключения предусмотрен специальный вход на контроллере ShIoTiny. Как видно на рисунке — подключение такого датчика тоже проблем не представляет.
И, наконец, переменное сопротивление, задающее пороговый уровень влажности. Точнее — делитель, состоящий из переменного и постоянного сопротивлений. Проблем с его подключением нет, но поясню, что встроенный АЦП на ESP8266 рассчитан максимум на 1Вольт. Поэтому и нужен делитель напряжения примерно в 5 раз.
И еще раз напомню, что этот делитель не нужен, если пороговый уровень влажности задается по сети посредством протокола MQTT.
Начнем составлять алгоритм работы устройства в редакторе ElDraw ShIoTiny. Как туда попасть, в этот редактор, можно почитать в статьях ранее или в инструкции, ссылка на которую есть в начале статьи.
Вариант первый, простейший
Начнем с простого: включения реле Relay1 по превышению порогового уровня влажности на заданное время.
Как видим, ничего сложного: всего четыре узла, не считая узлов-комментариев. DHT11 — это собственно датчик температуры и влажности (можно поменять на DHT22).
Константа CONST — пороговый уровень влажности, в процентах.
Компаратор — узел сравнивающий два числа и выставляющий на выходе 1, если заданное условие выполняется и 0, если условие не выполняется.
В нашем случае таким условием будет A>B, где A — измеренный датчиком уровень влажности, а B — пороговый уровень всё той же влажности.
Как только измеренный уровень влажности (A) превысит пороговый уровень влажности (B), тут же на выходе компаратора A>B появится 1 и реле включится. И наоборот, как только уровень влажности придет в норму (то есть A<=B), тут же на выходе компаратора A>B появится 0 и реле отключится.
Все понятно? Кому не очень — прочитайте еще раз или загляните в описание работы узлов в инструкции.
Замечу, что данные с датчика DHT11 обновляются примерно один раз в 10сек. Поэтому реле не сможет включаться и отключаться чаще, чем один раз в 10сек.
Все бы ничего, но мы хотели бы задать пороговый уровень влажности с помощью переменного резистора. Нет ничего проще!
Просто заменим узел-константу на узел АЦП. Ведь именно к АЦП мы подключили делитель напряжения с переменным резистором.
Напряжение на входе АЦП изменяется от 0 до 1Вольта. А вот влажность на выходе датчика — изменяется от 0 до 100%. Как же мы их сравниваем? Все просто. Узел АЦП в ShIoTiny не просто измеряет напряжение на входе, но и умеет его масштабировать и сдвигать.
То есть на выходе узла ADC1 (АЦП) будет значение X, рассчитанное по формуле , где — напряжение на входе ADC (от 0 до 1В); k — диапазон (ADC range) и b-смещение (ADC offset). Таким образом, если задать k=100 и b=0, то при изменении в диапазоне от 0 до 1, значение X на выходе узла АЦП будет изменяться в диапазоне от 0 до 100. То есть, численно равное диапазону изменения влажности от 0 до 100%.
Или, по-простому, вращая движок переменного сопротивления, можно задать пороговый уровень влажности от 0 до 100. Единственное неудобство, что нет никаких устройств отображения. Но на практике, если у движка переменного сопротивления сделать 6 делений 0%, 20%, 40%, 60%, 80%, 100%) — то этого достаточно для того, чтобы выставлять пороговый уровень влажности.
Как нам выставить коэффициенты k — диапазон (ADC range) и b-смещение (ADC offset)? Да проще пареной репы! Ткните указателем мыши в узел ADC1 и тут же у вас появится окно настройки. В нем можете выставить все, что вам нужно. Для нашего случая это будет такое окно, как на рисунке.
Итак, простейшее рабочее решение у нас есть. Начнем его усовершенствовать.
Кстати, у простейшего решения есть одно достоинство — ему не нужен интернет. Оно полностью автономно.
Вариант второй, подключаем кнопку
Все работает и все рады. Но вот незадача, мы не можем включить вентиляцию принудительно. Мы уже условились, что ко входу Input1 у нас будет подключена кнопка, которая будет включать и выключать вентилятор принудительно, не обращая внимания на датчик влажности.
Пришло время обработать эту кнопку в нашей схеме-программе.
Блок обработки нажатия кнопки выделен оранжевой линией. Он представляет собой счетчик нажатий кнопки, который сбрасывается в ноль, когда значение на его выходе превысит единицу (зеленая линия, выход узла CT).
Работает все тут так же незамысловато, как и прежде: счетчик CT считает нажатия кнопки, подключенной ко входу Input1. То есть значение на выходе этого счетчика с каждым нажатием кнопки увеличивается на 1.
Как только это значение станет равным двум (то есть больше 1), тут же на выходе компаратора A>B появится 1. И эта 1 сбросит счетчик CT в нуль. Имеется ввиду компаратор, нижний по схеме!
Таким образом, у нашей кнопки два состояния — 0 и 1. Если бы нам надо было больше состояний (3 или 4 или еще больше) — нам было бы достаточно изменить константу CONST с единицы на другое значение.
Итак, у нас есть два условия включения вентилятора: превышение заданного уровня влажности и однократное нажатие кнопки. При выполнении любого из условий вентилятор включится. И будет работать до тех пор пока повторно не нажмут кнопку И уровень влажности не придет в норму.
Можно, конечно, еще больше усложнить алгоритм, но мы этого делать не будем — оставим простор для творчества желающим.
Вариант третий, подключаемся к интернету
Все, что мы описали — вполне работоспособно. А как же понты? Ведь любой прыщавый хипстер-хакер-крекер засмеет того, кто крутит ручку и нажимает кнопку, а не управляет со смартфона! Крутить ручку — это «не модно». А вот елозить пальцем по смартфону, стирая этот палец в кровь — вот он, пик желаний хипстера-хакера-крекера (никогда не мог различить всех их — так что если ошибся, простите).
Но будем снисходительны к указанным личностям. У управления посредством интернета есть и реальные плюсы. Во-первых, это наглядность. Есть масса приложений под все платформы, которые позволяют парой тыков создать вполне пригодную для использования панель управления нашим контроллером-карлсоном. Во-вторых, это возможность дистанционно наблюдать за состоянием влажности в помещении. И, в-третьих, можно видеть не только то, что делает вентилятор — вертится или нет, но и то, какой пороговый уровень влажности задан. И то — включился вентилятор автоматически или вручную. В общем все, что пожелаете.
Конечно, для какого-то вентилятора много чести — столько внимания. Но это лишь пример.
Итак, для подключения к интернету мы будем использовать технологию MQTT и одноименный протокол.
Чтобы воспользоваться этой технологией, нам необходим MQTT-брокер. Это такой специальный сервер, который обслуживает MQTT-клиентов, например ShIoTIny и ваш смартфон.
Суть технологии MQTT состоит в том, что любой из клиентов публикует на MQTT-брокере (сервере) произвольные данные под определенным именем (называемом topic в терминологии MQTT). Другие клиенты могут подписаться на произвольные данные по их имени (topic) и получать вновь опубликованные данные. То есть весь обмен данными идет по принципу клиент-брокер-клиент.
Я не буду заостряться на подробностях. В интернете масса статей и обучалок по тому как работает MQTT и какие есть программы для создания панелей управления. Просто покажу как нам принимать и публиковать данные посредством ShIoTiny.
В качестве брокера я использовал www.cloudmqtt.com, но принцип везде один.
Итак, будем считать, что вы зарегистрировались на MQTT-брокере. В общем случае, брокер выдаст вам (или потребует придумать) имя пользователя и пароль (для авторизации), а так же порт для подключения. Подключить ShIoTiny к MQTT-брокеру можно двумя способами — обычное подключение и по TLS (SSL).
Все эти параметры в ShIoTiny вводятся на вкладке Networking, раздел MQTT Connection to server.
Если ваш MQTT-брокер не требует авторизации — не вводите логин и пароль (оставьте эти поля пустыми).
Параметр MQTT topic prefix требует отдельного пояснения.
Префикс MQTT-параметров — это строка, добавляемая к названию темы (topic) при публикации и подписке на MQTT-брокере. Чтобы установить MQTT-префикс для вашего контроллера, его надо просто ввести в поле ввода «Префикс темы MQTT» («MQTT topic prefix»). Префикс всегда начинается со слеша («/»)! Если вы не введете слэш в поле ввода — он добавится автоматически. В префиксе нельзя использовать символы «#» и «+». Других ограничений нет.
Например, если вы публикуете параметр «status» (или подписываетесь на него), а ваш префикс задан как «/shiotiny/», то на брокере этот параметр будет опубликован под именем «/shiotiny/status». Если у вас задан пустой префикс, то все параметры на брокере будут начинаться со слеша («/»): «status» будет публиковаться как «/status».
Итак, считаем, что вы зарегистрировались на MQTT-брокере и получили логин, пароль и порт. Затем вы прописали эти параметры на вкладке Networking, раздел MQTT Connection to server контроллера ShIoTiny.
Считаем, что префикс установлен в значение «/room/».
Начнем с того, что опубликуем состояние всех ключевых параметров: реле Realay1, состояния ручного включения, состояния автоматического включения и, наконец, пороговый и текущий уровни влажности. Ну и бонусом — температуру в помещении. Как это сделать, смотрите на рисунке.
Как видим, отличие от предыдущего варианта — только узлы «MQTT Publish». С учетом префикса, публикуются следующие параметры:
Как видим, всё состояние системы у нас как на ладони!
Но мы хотим не только видеть, но и управлять. Как быть? Очень просто. Мы откажемся от установки порогового уровня влажности с помощью АЦП и переменного резистора и будем задавать этот самый пороговый уровень влажности по MQTT прямо со смартфона!
Удаляем узел АЦП из схемы и включаем туда три новых узла: FLASH store, FLASH restore и MQTT describe.
Функция узла MQTT describe очевидна: он получает параметр /room/trigHset (пороговый уровень влажности) с MQTT брокера. Но что он делает с данными дальше? Просто отдает их узлу FLASH store, который, в свою очередь, сохраняет эти данные в энергонезависимой памяти под именем trigH. После этого, узел FLASH restore считывает из энергонезависимой памяти данные под именем trigH и что происходит далее мы уже знаем.
Зачем такие сложности? Почему нельзя сразу отдать полученные данные на вход компаратора?
Как говаривал товарищ Ш.Холмс — это элементарно! Никто не гарантирует, что после включения вашего устройства, оно присоединиться к MQTT-брокеру. А влажность измерять надо. И вентилятор надо включать. Но без информации о пороговом уровне влажности это невозможно! Поэтому, наше устройство при включении извлекает ранее запомненный пороговый уровень влажности из энергонезависимой памяти и использует для принятия решений его. А уж когда установится соединение с MQTT-брокером и кто-нибудь опубликует новое значение /room/trigHset, тогда будет использоваться это новое значение.
Дальше вы можете придумывать все что угодно. Например, помимо влажности ввести ещё и учет температуры. Или добавить «умное» управление освещением (у нас ещё остались неиспользованными два реле и два входа). Все в ваших руках!
Заключение
Вот и рассмотрели мы несколько примеров реализации простейшего по сути своей контроллера на базе ShIoTiny. Может быть это будет кому-то полезно.
Как всегда, предложения, пожелания, вопросы, опечатки и прочее — на почту: shiotiny@yandex.ru
Комментарии (38)
sshikov
21.08.2019 13:13А где посмотреть на цену решения? Было упомянуто, что оно более новое и модное, чем негры с опахалами — а вот вопрос относительной стоимости как-то затерялся.
shiotiny Автор
21.08.2019 13:40Себестоимость платы около 1000руб.
Ну плюс вентилятор.
Это ж пример проекта на готовой плате. Можно еще дешевле — модуль ESP-07 около 100 руб стоит.
Прошивка по ссылкам есть.
В общем недорого.
shiotiny Автор
21.08.2019 13:44И про "не модное". Это стеб:)
Просто одно из возможных. Проект-пример.
lingvo
21.08.2019 13:46Не нашел в статье:
- как часто опрашивается АЦП?
- что делать с дребезгом от кнопки?
- Данные от датчиков публикуются в MQTT только по изменению или каждый раз при опросе?
shiotiny Автор
21.08.2019 14:08- Ацп опрашивается примерно 10 раз в секунду. Но данные на выход узла ацп поступают при изменении на заданное число процентов.
- Ничего с дребезгом делать не надо. Работает так великолепно.
- Каждый раз публикуются при появлении нового события.
shiotiny Автор
21.08.2019 18:49Вдогонку. Если дребезг мешает — есть узел-фильтр (Delay 0/1). Просто включить его после узла-входа и выставить в нем 1-2 (0.1-0.2 сек). Гасит дребезг. Если дребезг супер-дребезжащий (ну, например, датчик уровня воды на герконе и магните) — можно поставить 10сек, например. Или 20сек. Любой дребезг — как рукой снимет:)
IliyaPotehin
21.08.2019 16:32Хороший тамада и конкурсы интересные. Осталось заказать кабель и датчик и вперед :). Спасибо за плату еще раз.
apple01
21.08.2019 19:00Чем обусловлен выбор модуля ESP-07 и подойдет ли прошивка для ESP-12?
shiotiny Автор
21.08.2019 19:25Обусловлен выбор модуля ESP-07 тем, что его было достаточно и он был в наличии. По идее прошивка должна идти на любой ESP8266 с 1Мегабайтом ОЗУ. Может и с большей памятью пойдёт. Только надо будет записать последние 20К конфигурационных параметров. Но я не пробовал — не гарантирую.
sterr
21.08.2019 20:23Да, кстати, как со стабильностью устройства? Ардуино показывает себя с лучшей стороны. А вот на ESP8266 были жалобы на зависания, потерю связи.
И почему так медленно работает устройство — 10 узлов в секунду?shiotiny Автор
22.08.2019 05:41Да, кстати, как со стабильностью устройства? Ардуино показывает себя с лучшей стороны. А вот на ESP8266 были жалобы на зависания, потерю связи.
Стабильность — это надо тестировать. Долго и нудно. В рабочем режиме проблем не было пока что. Но месяцами оно и не работало без перезагрузок.
А вот при загрузке программ по Upload иногда требуется перезагрузка и устройство после нажатия этой кнопки перезагружается. Но это очень страшно.
Скорее всего ещё что-то вылезет. И немало.
И почему так медленно работает устройство — 10 узлов в секунду?
Это данные с устройства на WEB передаются со скоростью 10 узлов в секунду. В режиме монитора. А устройство быстро работает. Со всей возможной скоростью, так сказать:)
Если я такой поток данных в реал-тайме на веб погоню — захлебнётся всё. Да и не надо обычно. Монитор — это чисто отладка. Поглядеть что в каком узле происходит.sterr
22.08.2019 18:15Просто надо акцентировать это. Если допустим в отладке все работает, а в рилтайме какой то сигнал пропускается, это тоже надо учесть. Либо сделать изменяемое время работы узла. Ведь это IoT, тут скорость особо не нужна. Ну тот же насос — можно сделать время работы узла 0.1 сек, например. Как в отладке. Ну а с другой стороны рилтайм как тестировать? Может сделать отладку по tx-rx?
shiotiny Автор
23.08.2019 18:31Тут нет понятия «в отладке» и «не в отладке». Скорость работы узлов — всегда одинаковая.
В режиме «монитор» просто опрашивается и передаётся в браузер текущее состояние выходов узлов. По 10 штук за раз. То есть, если вы включили монитор и 5 раз в секунду сработало реле — вы это услышите (щёлкает оно), но все 5 изменений 0-1 вы в браузере не увидите.
Короче, узлы работают всегда с максимальной скоростью, а состояние узлов в браузере отображается неспешно. :)
apple01
22.08.2019 19:26Я проанализировал рынок недорогих DIY модулей с реле и Wifi ESPXX. Здесь довольно тесно. Например вот китайская компания предлагает тщательно проработанную линейку контроллеров на 2, 4, 8, 16, 32 канала с Wifi/Ethernet/RS232 c опциональной доп. объвязкой в виде внешних клавиатур, модулей для AI голосовых помощников, с приложениями для мобильных платформ, с открытыми кодами и примерами для различных языков программирования по цене $70-$100 на ebay. А вот еще вариант, и еще, правда это простые реле без возможности программирования. Тем не менее, на мой взгяд, небольшая ниша с емкостью 30-50 штук для вашей системы на ebay есть благодаря визуальному программированию, если в добавок сделать нормальную документацию на хорошем англ. языке. Лучше сразу переделать на ESP32 и разработать линейку устройств и сделать это быстро если вы хотите выйти на рынок с вашей рашей разработкой.
shiotiny Автор
23.08.2019 05:42А почему обязательно реле? Реле на выходах — это просто мне так надо было.
Если думать о производстве в смысле на продажу, можно сделать линейку модулей с разной периферией.
apple01
23.08.2019 15:03Видимо потому что в домашней автоматизации наиболее частая задаяча — включение/выключение силовой нагрузки.
Какую периферию вы еще можете предложить?shiotiny Автор
23.08.2019 16:32Входная — можно датчики разные добавить.
Те что по i2c и spi цепляются. Выходная — шим.
Может аудиовыход, но не уверен.apple01
23.08.2019 17:25Можно также добавить входную и выходную периферию по протоколам работающим на большие дистанции (RS485), через Ethernet и Wifi. Для i2c и spi расстояния как я понял ограничены несколькими метрами. Нужны будут варианты как с реле на борту так и в виде отдельных модулей реле/SSR.
shiotiny Автор
23.08.2019 18:18Можно добавить всё, но про цену не забывайте. :)
То, что сейчас у меня сделано — стоит около 1000 рублей. Включая плату, элементы и даже наверное сборку, если серийно делать. Причем, как ни странно, дороже всего обошлись реле и плата. Если делать блок без реле — то размеры и стоимость платы существенно сократятся.
Можно наворотить супер-монстра, но с ценой в 5000руб или 10000руб он никому не будет нужен. Да и для себя он вряд ли понадобится.
Лично я сторонник дешевых и простых аппаратных решений. Сколько я видел супермонстрозных устройств с кучей периферии — все они используют её на несколько процентов, а остальная периферия болтается просто так.
Поэтому если делать — то линейку устройств. Скажем — простой и понятных блок управления реле и несколькими дискретными входами и АЦП. По сути ShIoTiny — это оно и есть.
Простой и понятный блок сбора данных с датчиков, умеющий несколько интерфейсов. Простой и понятный, например, WiFi-плеер. И так далее. Главное — единая система программирования и интерфейс обмена данными.
Тогда получатся «кубики» из которых можно построить то, что надо — не больше и не меньше.
Что касается RS485 и Ethernet, то тут тоже есть вопросы и варианты.
Например, зачем вам RS485, если вы можете поставить при каждом датчике свой ESP и всё передавать по WiFi посредством MQTT или UDP multicast? Нет, если расстояния — километр, то придётся что-то придумывать. А для дома обычно достаточно десятков метров.
Ethernet на ESP тоже не очень нужен, если они все подключены к роутеру. Проще взять WiFi роутер с Ethernet и настроить его как надо — например поднять VPN и удалённые на километр части объединить в VPN-сеть. Кстати, при таком подходе 485й тоже не нужен.
Разумеется, можно придумать задачи, где без 485 или какого-то специнтерфейса ну никак вообще. Но много ли таких задач в реальности?
Большинство современных датчиков используют 1-wire (в девичестве MicroLan), I2C, SPI или UART.
Поэтому модуль сбора данных, который умеет эти интерфейсы покроет практически все доступные датчики.
Правда, есть ещё промышленные датчики с аналоговым токовым выходом 4-20мА. Тут АЦП справится. Точность, конечно, под вопросом, но для дома, для семьи — вполне пойдёт. Но опять же — вряд ли дома кто-то будет ставить такие датчики.
Если надо много входов-выходов — скажем 32 бинарных входа и 32 бинарных выхода — проще поставить копеечные регистры и формирователи, а не «жирный контроллер» с кучей входов-выходов.
В общем — надо смотреть на задачи.
Краткое резюме. Сделать «универсальную вундервафлю», которая умеет всё, конечно, можно — но:
а) Это дорого. Или очень дорого.
б) Программировать её будет тоже очень сложно.
в) На практике, потенциал этой «вундервали» будет использован очень слабо, то есть большая часть денег, которую она стоит, будет выкинута впустую.
г) таких вундервафель уже много — малинки-апельсинки-микрописи и так далее.apple01
23.08.2019 19:45>Поэтому если делать — то линейку устройств.
С этим я согласен
>По сути ShIoTiny — это оно и есть.
Кроме того что я бы добавил аппаратный watchdog. Он не добавляет особо в цене и сложности.
>Например, зачем вам RS485, если вы можете поставить при каждом датчике свой ESP и всё передавать по WiFi посредством MQTT или UDP multicast?
В случае если мне нужно надежное функционирование внутри замкнутой системы (снять показание датчика, совершить какое-то действие), я бы предпочел непосредственное подключение датчика, нежели иметь в процессе коммуникации 2 ненадежные ESP — я видел и как они зависают, и как они без причины отваливаются от wifi (возможно из-за недостаточной чувствительности антенны). А если датчик нужно поставить в тот угол в котором мертвая зона? Но опять-же, это опционально, модульно. Имееют права быть оба решения-варианта, каждый для своего случая.
>Поэтому модуль сбора данных, который умеет эти интерфейсы покроет практически все доступные датчики.
Проблема в максимальном расстоянии в несколько метров, в наводках, гальваническом смещении земли и т.п. В каки-то случаях это работает, в каких-то нет. Опять-же я не предлагаю все запихнуть в одном устройстве.
>Если надо много входов-выходов — скажем 32 бинарных входа и 32 бинарных выхода — проще поставить копеечные регистры и формирователи, а не «жирный контроллер» с кучей входов-выходов.
Во-первых ESP32 сейчас ненамоного дороже, во-вторых ESP8266 сейчас уже морально устаревает, лучше сразу закладываться на более новую базу.
>Сделать «универсальную вундервафлю», которая умеет всё, конечно, можно — но
Я не предлагал делать универсальную. Я согласен что линейка совместимых устройств это то что нужно.shiotiny Автор
24.08.2019 05:55Какую ESP 16 или 32 использовать сильно на цене как раз не скажется.
Вот переделать ПО будет непросто.
Про вачдог я согласен — нужен он. Я думаю, надо его с rtc совместить.
Что касается гальваноразвязок и преобразователей в 485й — лучше это делать отдельными модулями. Как ни верти — стоить это будет не очень дешево, а нужно далеко не всегда.
Вообще есть мысля — а почему оптоволокно не использовать? Стоит оно сейчас недорого. На вход и выход поставить по светодиоду и оптоприемнику. Помехи ему не страшны. Гальваники тоже никакой. Скорости более чем 115200 тоже не особо нужны в нашем случае.
Надо это обдумать.
reticular
а исходниками поделитесь?
shiotiny Автор
Не могу исходниками делиться пока что.
Бинарники по ссылке — играйтесь. :) инструкция черновик там же.
sterr
Тогда добавьте хотя бы ds1821 и pwm для управления как раз вентилятором. Давно хотел сделать такую штуку для ванны, но не в визуале, а в виде собственной программы, которая закидывалась бы по WiFi. Датчик движения на 5 ггц (в ванне плохо работают инфракрасные), вентилятор 120мм на 12в (уже стоит) и освещение на 12в ледами. Ну и зимой бывает жарко, еще датчик температуры и освежитель воздуха. Ну и автоматика — зашел, свет включился. Если больше 5 минут торчал — вышел, свет выключился, вентилятор на 10 мин, потом пшикнуть освежителем. Если меньше 5 минут, просто продуть 1-2 мин. Конечно алгоритм еще сложнее, например ночью включать УФ или озонатор для дезинфекции. Но надо RTC.
shiotiny Автор
Термометр Ds1821 попробовать добавить можно. Но какая разница ds1821 или dht11/22?
А вот шим в эту плату не получится. Там три реле на выходе. Схема в доках по ссылке есть.
Если буду развивать аппаратную часть — добавлю шим. Хотя мне не понятно нафига 12вольтовый вентилятор в ванной или туалете, когда есть 220вольтовые.
sterr
При чем тут плата. В софт. Плату я видел. Красиво, но однобоко.
Опять же, аппаратная часть меня мало интересует. Все равно я разрабатываю все сам. Главное поддержка. В этой конкретно плате можно и не использовать.
Опять же — исходники не открываете, так можно было переработать что-то. Вместо этого приходится просить что-то добавить. Но идея конечно интересная и здравая. Просто вам нужно было сделать модульную конструкцию. Контроллер с обвязкой отдельно, блоки реле и входные тоже отдельно. Вот и максимальная гибкость. вместо блоков реле можно подцепить например драйвер Шим или шаговика.
shiotiny Автор
Ну в софт попробую:)
Я ж не фирма. Это хобби на свободное время. Поэтому все не быстро.
sterr
Так никто и не гонит. А есть возможность распознавать длительные и короткие нажатия на кнопки? Или придется блоками рисовать?
shiotiny Автор
Знаете сколько "пожеланий"?:)
Сейчас пинг сделать пытаюсь.
Длинное и короткое… Не думал об этом. Надо посмотреть что выйдет готовыми узлами.
shiotiny Автор
Вот что придумал на скорую руку. Кнопка с тремя состояниями.
Я стараюсь на узлах все сделать. Не потому, что нельзя отдельный узел придумать а потому что так все тестируется.
sterr
Надо не так. Просто ввести класс кнопка и все. Ну и 3 состояния — короткое, и длинное. Очень короткое зачем? Заморочки с высчетом времени. Ткнул и пошел. А если надо что-то зафиксировать — длинное. Ну и бипер для подтверждения и подачи всевозможных сигналов. Опять же, как то непонятно сделано например сравнение влажности. То есть значение задается не в узле сравнения, а в самом ADC. Это мне кажется криво. Проще было пользоваться IF-Then-Else. Помните, как на блок схемах в школе. Ромбик. Я понимаю, что битовые значения сравнивать проще. Но проще работать с более стандартизироваными много лет блок схемами.
shiotiny Автор
Это написать, что «надо просто ввести класс кнопка» просто. А на практике сразу вопросы:
1. Какая длительность «долгого нажатия»? Одному надо секунду, второму 10сек?
2. Как должны работать выходы? Генерировать короткие импульсы по «короткому» и «долгому» нажатию или как в примере — просто устанавливаться в 1 до следующего нажатия?
И ещё кое какие вопросы.
Если не нужно — поменяйте в нижнем блоке Pulse число 5 на число 1. Будет только короткое и долгое нажатие.
Там нет сравнения в узле ADC!
Сравнение производится в компараторе A>B, что и описано довольно подробно.
Узел ADC умеет умножать входное напряжение 0..1В на заданный коэффициент. И прибавлять к полученному значению заданную константу.
То есть в данном случае переменный резистор используется как источник числа от 0 до 100 (порогового уровня влажности). А потом это число сравнивается с показаниями датчика влажности.
Зачем вообще умножать значение входного напряжения и прибавлять константу? Да для пересчета из попугаев в реальное значение.
Например, вы хотите измерять сетевое напряжение. Ставите на вход понижающий трансформатор, делитель, выпрямитель. Так, чтобы напряжению 220В в сети соответствовало, например, 0.5В на входе АЦП. Далее домножаете показание АЦП на 440 — и опа, на выходе узла АЦП не попугаи, а реальное напряжение сети. Точность, конечно, не идеальная, но для оценки того — 220 у вас в сети или 150 — достаточная.
Есть ещё аналоговые датчики 4-20мА, которые тоже можно подключать к АЦП. Да мало ли.
Там нет сравнения битовых значений.
Вас сильно смущает, что это не ромбик, а квадратик? :)
Блок-схема это совсем другой подход, хотя и тоже визуальный. И в таком контроллере блоксхему я врядли осилю. Только событийный обсчет.
sterr
Извиняюсь, недопонял. Просто блок схемы, вроде визуальны, но программисту тяжело с ними. Проще прочитать код. А насчет кнопки… Сделать узел с настраиваемыми задержками и тремя выходами. Самый простой вариант.