Comments 39
а исходниками поделитесь?
Не могу исходниками делиться пока что.
Бинарники по ссылке — играйтесь. :) инструкция черновик там же.
Тогда добавьте хотя бы ds1821 и pwm для управления как раз вентилятором. Давно хотел сделать такую штуку для ванны, но не в визуале, а в виде собственной программы, которая закидывалась бы по WiFi. Датчик движения на 5 ггц (в ванне плохо работают инфракрасные), вентилятор 120мм на 12в (уже стоит) и освещение на 12в ледами. Ну и зимой бывает жарко, еще датчик температуры и освежитель воздуха. Ну и автоматика — зашел, свет включился. Если больше 5 минут торчал — вышел, свет выключился, вентилятор на 10 мин, потом пшикнуть освежителем. Если меньше 5 минут, просто продуть 1-2 мин. Конечно алгоритм еще сложнее, например ночью включать УФ или озонатор для дезинфекции. Но надо RTC.
Термометр Ds1821 попробовать добавить можно. Но какая разница ds1821 или dht11/22?
А вот шим в эту плату не получится. Там три реле на выходе. Схема в доках по ссылке есть.
Если буду развивать аппаратную часть — добавлю шим. Хотя мне не понятно нафига 12вольтовый вентилятор в ванной или туалете, когда есть 220вольтовые.
А вот шим в эту плату не получится. Там три реле на выходе.
При чем тут плата. В софт. Плату я видел. Красиво, но однобоко.
Если буду развивать аппаратную часть — добавлю шим.
Опять же, аппаратная часть меня мало интересует. Все равно я разрабатываю все сам. Главное поддержка. В этой конкретно плате можно и не использовать.
Опять же — исходники не открываете, так можно было переработать что-то. Вместо этого приходится просить что-то добавить. Но идея конечно интересная и здравая. Просто вам нужно было сделать модульную конструкцию. Контроллер с обвязкой отдельно, блоки реле и входные тоже отдельно. Вот и максимальная гибкость. вместо блоков реле можно подцепить например драйвер Шим или шаговика.
Ну в софт попробую:)
Я ж не фирма. Это хобби на свободное время. Поэтому все не быстро.
Так никто и не гонит. А есть возможность распознавать длительные и короткие нажатия на кнопки? Или придется блоками рисовать?
Знаете сколько "пожеланий"?:)
Сейчас пинг сделать пытаюсь.
Длинное и короткое… Не думал об этом. Надо посмотреть что выйдет готовыми узлами.
Вот что придумал на скорую руку. Кнопка с тремя состояниями.
Я стараюсь на узлах все сделать. Не потому, что нельзя отдельный узел придумать а потому что так все тестируется.
Я стараюсь на узлах все сделать. Не потому, что нельзя отдельный узел придумать а потому что так все тестируется.
Надо не так. Просто ввести класс кнопка и все. Ну и 3 состояния — короткое, и длинное. Очень короткое зачем? Заморочки с высчетом времени. Ткнул и пошел. А если надо что-то зафиксировать — длинное. Ну и бипер для подтверждения и подачи всевозможных сигналов. Опять же, как то непонятно сделано например сравнение влажности. То есть значение задается не в узле сравнения, а в самом ADC. Это мне кажется криво. Проще было пользоваться IF-Then-Else. Помните, как на блок схемах в школе. Ромбик. Я понимаю, что битовые значения сравнивать проще. Но проще работать с более стандартизироваными много лет блок схемами.
Просто ввести класс кнопка и все.
Это написать, что «надо просто ввести класс кнопка» просто. А на практике сразу вопросы:
1. Какая длительность «долгого нажатия»? Одному надо секунду, второму 10сек?
2. Как должны работать выходы? Генерировать короткие импульсы по «короткому» и «долгому» нажатию или как в примере — просто устанавливаться в 1 до следующего нажатия?
И ещё кое какие вопросы.
Очень короткое зачем?
Если не нужно — поменяйте в нижнем блоке Pulse число 5 на число 1. Будет только короткое и долгое нажатие.
Опять же, как то непонятно сделано например сравнение влажности. То есть значение задается не в узле сравнения, а в самом ADC. Это мне кажется криво. Проще было пользоваться IF-Then-Else.
Там нет сравнения в узле ADC!
Сравнение производится в компараторе A>B, что и описано довольно подробно.
Узел ADC умеет умножать входное напряжение 0..1В на заданный коэффициент. И прибавлять к полученному значению заданную константу.
То есть в данном случае переменный резистор используется как источник числа от 0 до 100 (порогового уровня влажности). А потом это число сравнивается с показаниями датчика влажности.
Зачем вообще умножать значение входного напряжения и прибавлять константу? Да для пересчета из попугаев в реальное значение.
Например, вы хотите измерять сетевое напряжение. Ставите на вход понижающий трансформатор, делитель, выпрямитель. Так, чтобы напряжению 220В в сети соответствовало, например, 0.5В на входе АЦП. Далее домножаете показание АЦП на 440 — и опа, на выходе узла АЦП не попугаи, а реальное напряжение сети. Точность, конечно, не идеальная, но для оценки того — 220 у вас в сети или 150 — достаточная.
Есть ещё аналоговые датчики 4-20мА, которые тоже можно подключать к АЦП. Да мало ли.
Я понимаю, что битовые значения сравнивать проще. Но проще работать с более стандартизироваными много лет блок схемами.
Там нет сравнения битовых значений.
Вас сильно смущает, что
A>Bэто не ромбик, а квадратик? :)
Блок-схема это совсем другой подход, хотя и тоже визуальный. И в таком контроллере блоксхему я врядли осилю. Только событийный обсчет.
А где посмотреть на цену решения? Было упомянуто, что оно более новое и модное, чем негры с опахалами — а вот вопрос относительной стоимости как-то затерялся.
Не нашел в статье:
- как часто опрашивается АЦП?
- что делать с дребезгом от кнопки?
- Данные от датчиков публикуются в MQTT только по изменению или каждый раз при опросе?
- Ацп опрашивается примерно 10 раз в секунду. Но данные на выход узла ацп поступают при изменении на заданное число процентов.
- Ничего с дребезгом делать не надо. Работает так великолепно.
- Каждый раз публикуются при появлении нового события.
Вдогонку. Если дребезг мешает — есть узел-фильтр (Delay 0/1). Просто включить его после узла-входа и выставить в нем 1-2 (0.1-0.2 сек). Гасит дребезг. Если дребезг супер-дребезжащий (ну, например, датчик уровня воды на герконе и магните) — можно поставить 10сек, например. Или 20сек. Любой дребезг — как рукой снимет:)
В начале есть ссылка на инструкцию. Там подробно про АЦП и прочее.
Хороший тамада и конкурсы интересные. Осталось заказать кабель и датчик и вперед :). Спасибо за плату еще раз.
Чем обусловлен выбор модуля ESP-07 и подойдет ли прошивка для ESP-12?
Да, кстати, как со стабильностью устройства? Ардуино показывает себя с лучшей стороны. А вот на ESP8266 были жалобы на зависания, потерю связи.
И почему так медленно работает устройство — 10 узлов в секунду?
И почему так медленно работает устройство — 10 узлов в секунду?
Да, кстати, как со стабильностью устройства? Ардуино показывает себя с лучшей стороны. А вот на ESP8266 были жалобы на зависания, потерю связи.
Стабильность — это надо тестировать. Долго и нудно. В рабочем режиме проблем не было пока что. Но месяцами оно и не работало без перезагрузок.
А вот при загрузке программ по Upload иногда требуется перезагрузка и устройство после нажатия этой кнопки перезагружается. Но это очень страшно.
Скорее всего ещё что-то вылезет. И немало.
И почему так медленно работает устройство — 10 узлов в секунду?
Это данные с устройства на WEB передаются со скоростью 10 узлов в секунду. В режиме монитора. А устройство быстро работает. Со всей возможной скоростью, так сказать:)
Если я такой поток данных в реал-тайме на веб погоню — захлебнётся всё. Да и не надо обычно. Монитор — это чисто отладка. Поглядеть что в каком узле происходит.
Просто надо акцентировать это. Если допустим в отладке все работает, а в рилтайме какой то сигнал пропускается, это тоже надо учесть. Либо сделать изменяемое время работы узла. Ведь это IoT, тут скорость особо не нужна. Ну тот же насос — можно сделать время работы узла 0.1 сек, например. Как в отладке. Ну а с другой стороны рилтайм как тестировать? Может сделать отладку по tx-rx?
Тут нет понятия «в отладке» и «не в отладке». Скорость работы узлов — всегда одинаковая.
В режиме «монитор» просто опрашивается и передаётся в браузер текущее состояние выходов узлов. По 10 штук за раз. То есть, если вы включили монитор и 5 раз в секунду сработало реле — вы это услышите (щёлкает оно), но все 5 изменений 0-1 вы в браузере не увидите.
Короче, узлы работают всегда с максимальной скоростью, а состояние узлов в браузере отображается неспешно. :)
В режиме «монитор» просто опрашивается и передаётся в браузер текущее состояние выходов узлов. По 10 штук за раз. То есть, если вы включили монитор и 5 раз в секунду сработало реле — вы это услышите (щёлкает оно), но все 5 изменений 0-1 вы в браузере не увидите.
Короче, узлы работают всегда с максимальной скоростью, а состояние узлов в браузере отображается неспешно. :)
Я проанализировал рынок недорогих DIY модулей с реле и Wifi ESPXX. Здесь довольно тесно. Например вот китайская компания предлагает тщательно проработанную линейку контроллеров на 2, 4, 8, 16, 32 канала с Wifi/Ethernet/RS232 c опциональной доп. объвязкой в виде внешних клавиатур, модулей для AI голосовых помощников, с приложениями для мобильных платформ, с открытыми кодами и примерами для различных языков программирования по цене $70-$100 на ebay. А вот еще вариант, и еще, правда это простые реле без возможности программирования. Тем не менее, на мой взгяд, небольшая ниша с емкостью 30-50 штук для вашей системы на ebay есть благодаря визуальному программированию, если в добавок сделать нормальную документацию на хорошем англ. языке. Лучше сразу переделать на ESP32 и разработать линейку устройств и сделать это быстро если вы хотите выйти на рынок с вашей рашей разработкой.
А почему обязательно реле? Реле на выходах — это просто мне так надо было.
Если думать о производстве в смысле на продажу, можно сделать линейку модулей с разной периферией.
Видимо потому что в домашней автоматизации наиболее частая задаяча — включение/выключение силовой нагрузки.
Какую периферию вы еще можете предложить?
Какую периферию вы еще можете предложить?
Входная — можно датчики разные добавить.
Те что по i2c и spi цепляются. Выходная — шим.
Может аудиовыход, но не уверен.
Можно также добавить входную и выходную периферию по протоколам работающим на большие дистанции (RS485), через Ethernet и Wifi. Для i2c и spi расстояния как я понял ограничены несколькими метрами. Нужны будут варианты как с реле на борту так и в виде отдельных модулей реле/SSR.
Можно добавить всё, но про цену не забывайте. :)
То, что сейчас у меня сделано — стоит около 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 бинарных выхода — проще поставить копеечные регистры и формирователи, а не «жирный контроллер» с кучей входов-выходов.
В общем — надо смотреть на задачи.
Краткое резюме. Сделать «универсальную вундервафлю», которая умеет всё, конечно, можно — но:
а) Это дорого. Или очень дорого.
б) Программировать её будет тоже очень сложно.
в) На практике, потенциал этой «вундервали» будет использован очень слабо, то есть большая часть денег, которую она стоит, будет выкинута впустую.
г) таких вундервафель уже много — малинки-апельсинки-микрописи и так далее.
То, что сейчас у меня сделано — стоит около 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 бинарных выхода — проще поставить копеечные регистры и формирователи, а не «жирный контроллер» с кучей входов-выходов.
В общем — надо смотреть на задачи.
Краткое резюме. Сделать «универсальную вундервафлю», которая умеет всё, конечно, можно — но:
а) Это дорого. Или очень дорого.
б) Программировать её будет тоже очень сложно.
в) На практике, потенциал этой «вундервали» будет использован очень слабо, то есть большая часть денег, которую она стоит, будет выкинута впустую.
г) таких вундервафель уже много — малинки-апельсинки-микрописи и так далее.
>Поэтому если делать — то линейку устройств.
С этим я согласен
>По сути ShIoTiny — это оно и есть.
Кроме того что я бы добавил аппаратный watchdog. Он не добавляет особо в цене и сложности.
>Например, зачем вам RS485, если вы можете поставить при каждом датчике свой ESP и всё передавать по WiFi посредством MQTT или UDP multicast?
В случае если мне нужно надежное функционирование внутри замкнутой системы (снять показание датчика, совершить какое-то действие), я бы предпочел непосредственное подключение датчика, нежели иметь в процессе коммуникации 2 ненадежные ESP — я видел и как они зависают, и как они без причины отваливаются от wifi (возможно из-за недостаточной чувствительности антенны). А если датчик нужно поставить в тот угол в котором мертвая зона? Но опять-же, это опционально, модульно. Имееют права быть оба решения-варианта, каждый для своего случая.
>Поэтому модуль сбора данных, который умеет эти интерфейсы покроет практически все доступные датчики.
Проблема в максимальном расстоянии в несколько метров, в наводках, гальваническом смещении земли и т.п. В каки-то случаях это работает, в каких-то нет. Опять-же я не предлагаю все запихнуть в одном устройстве.
>Если надо много входов-выходов — скажем 32 бинарных входа и 32 бинарных выхода — проще поставить копеечные регистры и формирователи, а не «жирный контроллер» с кучей входов-выходов.
Во-первых ESP32 сейчас ненамоного дороже, во-вторых ESP8266 сейчас уже морально устаревает, лучше сразу закладываться на более новую базу.
>Сделать «универсальную вундервафлю», которая умеет всё, конечно, можно — но
Я не предлагал делать универсальную. Я согласен что линейка совместимых устройств это то что нужно.
С этим я согласен
>По сути ShIoTiny — это оно и есть.
Кроме того что я бы добавил аппаратный watchdog. Он не добавляет особо в цене и сложности.
>Например, зачем вам RS485, если вы можете поставить при каждом датчике свой ESP и всё передавать по WiFi посредством MQTT или UDP multicast?
В случае если мне нужно надежное функционирование внутри замкнутой системы (снять показание датчика, совершить какое-то действие), я бы предпочел непосредственное подключение датчика, нежели иметь в процессе коммуникации 2 ненадежные ESP — я видел и как они зависают, и как они без причины отваливаются от wifi (возможно из-за недостаточной чувствительности антенны). А если датчик нужно поставить в тот угол в котором мертвая зона? Но опять-же, это опционально, модульно. Имееют права быть оба решения-варианта, каждый для своего случая.
>Поэтому модуль сбора данных, который умеет эти интерфейсы покроет практически все доступные датчики.
Проблема в максимальном расстоянии в несколько метров, в наводках, гальваническом смещении земли и т.п. В каки-то случаях это работает, в каких-то нет. Опять-же я не предлагаю все запихнуть в одном устройстве.
>Если надо много входов-выходов — скажем 32 бинарных входа и 32 бинарных выхода — проще поставить копеечные регистры и формирователи, а не «жирный контроллер» с кучей входов-выходов.
Во-первых ESP32 сейчас ненамоного дороже, во-вторых ESP8266 сейчас уже морально устаревает, лучше сразу закладываться на более новую базу.
>Сделать «универсальную вундервафлю», которая умеет всё, конечно, можно — но
Я не предлагал делать универсальную. Я согласен что линейка совместимых устройств это то что нужно.
Какую ESP 16 или 32 использовать сильно на цене как раз не скажется.
Вот переделать ПО будет непросто.
Про вачдог я согласен — нужен он. Я думаю, надо его с rtc совместить.
Что касается гальваноразвязок и преобразователей в 485й — лучше это делать отдельными модулями. Как ни верти — стоить это будет не очень дешево, а нужно далеко не всегда.
Вообще есть мысля — а почему оптоволокно не использовать? Стоит оно сейчас недорого. На вход и выход поставить по светодиоду и оптоприемнику. Помехи ему не страшны. Гальваники тоже никакой. Скорости более чем 115200 тоже не особо нужны в нашем случае.
Надо это обдумать.
Sign up to leave a comment.
ShIoTiny: вентиляция влажного помещения (проект-пример)