Предисловие

Возможно то, про что я хочу рассказать в своей первой статье тут, покажется не новым, уже знакомым велосипедом. Речь пойдет о контроллерах на базе ESP32 и программном обеспечении. Да, современных решений, открытых и бесплатных – много. А сейчас зарождается еще одно (а опенсорса мало не бывает, я считаю).

В статье я упущу и не буду рассказывать ни про свое знакомство с ардуиной, esp, php, python, js ни про то, что пришел сюда давным-давно гуманитарием. И да простят мой, вероятно не корректный, «жаргон» истинные профессионалы в микроэлектронике и программировании - итак, приступим.  

Совсем недавно я отключил RPI4 с HA и наконец «воткнул» в котельную очередную, но «готовую к деплою» версию контроллера (разрешите его далее называть «УМНЫЙ К1», спасибо).

А что по железу?

К1 – контроллер (или любая ESP32, подключенная нужным образом), содержащий набор полезных функций (делал для себя изначально, и делаю по сей день):

·         8 (было 6) реле по 5А
·         6 входов
·         Opentherm совместимый адаптер
·         2 открытых коллектора
·         Вход-детектор 12в
·         2 NTC 10К
·         2 ADC 3 pin (для подключения, например, 5в аналоговых датчиков)
·         Onewire (ds18b20)
·         Слот под самые простые приемники RF433
·         Ethernet W5500
·         Пищалочку (бип-бип)

В открытый доступ схемы еще не выложил, поэтому приложу скрины:

Цифровые входы и выходы сделаны, как я понял классическим методом для похожих контроллеров - PCF8574 в тандеме с 74HC14D

Открытый коллектор через BCX56-16 через биполярный транзистор типа NPN. В К1 их 2 штуки

Для NTC термисторов предусмотрена подтяжка 10к по питанию, токоограничивающий резистор на 1к, плюс защита ESD через PESD3V3L1BA

Аналоговый вход (2 шт) через делитель напряжения, также защищен ESD диодом

Реле (тут 8 штук в контроллере) - решил упростить так, через транзистор.

Адаптер opentherm по схеме, коих можно много найти в достаточном количестве.

USB с неубиваемой розеткой и примитивным, простым CH340C - для мониторинга и заливки прошивки:

По железу закончили, теперь коротко о программных возможностях.

Оффтоп

Вообще, UMNI (знакомьтесь) – это небольшая экосистема свободного, открытого программного обеспечения (изначально отечественного), направленная на решение децентрализованного контроля доступа, видеоанализа, видеонаблюдения, биометрии и управления умным (и не очень) домом.

В своей первой статье я не буду рассказывать про систему, которая немного смахивает на HA на первый взгляд, но решает повседневные проблемы проще и не такая монструозная (не в обиду, я очень уважаю и люблю HA), а сразу перейду только к программному обеспечению контроллера УМНЫЙ К1. Однако, контроллер К1 является частью этой экосистемы и интегрируется с ней.

А что по прошивке?

Программное обеспечение, то бишь прошивка, написана в среде ESP-IDF фреймворка. Страница прошивки - https://github.com/umni-su/umni-uni .

Мне хотелось, чтобы контроллером можно было легко управлять, интегрировать его. Ранее, старые версии использовали классику – MQTT для живого общения. Сейчас я переписал инфраструктуру, выпилив MQTT.

Универсальность ПО – важный аспект. Но это не Tasmota или ESPHome. У меня несколько другой подход – capabilities. По ним можно понять, что есть в контроллере (а они планируются разные), и чем можно управлять.

Отсюда выработалась такая тактика, и я ее придерживался.

1. REST API для управления и запроса состояний https://docs.umni.su/books/prosivka-umni-uni/page/rest-api-v10 . Здесь достаточно методов, которые покрывают практически весь функционал, необходимый мне. Можно даже curl-ом «побибикать пищалкой».

2. SSE – казалось бы, причем тут это. Однако я решил ее использовать в ПО для централизованного управления контроллерами и получения живого статуса изменений состояний.

3. А как же интеграции и получения состояния сенсоров? Тут все просто. Мне очень импонирует стандартный syslog. Поэтому контроллер по умолчанию отправляет UDP пакеты в сеть по настроенному порту. Подключайся Wireshark, скриптом на питоне, да чем угодно, и получай состояния сенсоров и события.

4. 4. Автоматизации – мини простые сценарии из коробки (также доступные через REST API). Датчик температуры > 24 градусов – выключить (реле 1 – 4, котел), иначе включить (типа того). Работает автономно. TODO – сделать гистерезис и отправлять событие в syslog.

5. Вебхуки. Мало мне HTTP – давайте еще один. Можно настроить адрес для вебхуков и контроллер будет туда передавать POST с событиями сенсоров.

6. OTA. Ну тут без комментариев.

Вот так я ушел от зависимости в виде брокера сообщений. Меня устраивает.

А как управлять?

Вторая часть – ПО для централизованного управления такими контроллерами, как К1 – UMNI UNI TOOL (UNI – universal). Выпилив интерфейс SD карты, встал вопрос администрирования контроллера. Фронт был уже написан (Vue). И ранее он открывался с SD карты. Надо было что-то придумать. Вот и наткнулся я на Tauri – фреймворк, который не зависит от фронта и позволяющий превратить его с минимальными доработками в приложение для мобильных и десктопов.

Так родился UMNI UNI TOOL - https://github.com/umni-su/umni-uni-tool . Контроллеры определяются через mDNS в сети, а ПО видит и может подключаться к контроллеру(ам). Выбираем и работаем с ним через REST API. Вот и все.

Финал

Ознакомительная часть закончена. В ней я хотел только познакомиться и ознакомить веб с УМНЫм. Представится и поздороваться. У него есть дока https://docs.umni.su , сайт тоже, но на все не хватает рук.

Хорошо, что в наше время легко найти разработчиков, которые могут помочь в написании проекта. Поэтому осторожно! В коде могут присутствовать следы дипсика и гугл ии, рефакторинг мне в помощь.

Я рад, что могу выложить на бумагу то, что неторопливо пишу не первый год. Если есть энтузиасты – добро пожаловать в клуб. За сим откланяюсь бороздить просторы опенсорса, и занимать тем, что приносит удовольствие – развивать экосистему (а вы что подумали).