Большинство статей пишется по принципу «Я/мы это сделал/и, глядите как круто!». Эта же публикация посвящается провальному проекту. Добро пожаловать под кат…

Это продолжение моей публикации Разработка умных устройств на примере контроллера теплого пола на ESP8266


Начнем издалека


Я живу в небольшом доме, который построен по моему проекту. Планировка — евротрешка, коридор, кухня-гостиная на первом этаже, с/у, детская и спальня на втором. Из нестандартного — стены арболит, фундамент УШП, отопление исключительно ТП. При этом перекрытия деревянные, на втором этаже плавающий пол, ТП — в плите ГВЛ. На первом этаже 3 петли труб ТП (фактически одно помещение), на втором — тоже три, но каждая петля отвечает за одно помещение (спальня, с/у, детская), За тепло отвечает настенный газовый котел 14кВт. Управляет котлом китайский программируемый на неделю беспроводной термостат. В каждый день недели у него четыре периода, в каждый период можно задать нужную температуру. Мозги на батарейке, реле спрятано. Работает отлично. Но мне часто нужно больше чем есть. Захотел я покомнатное регулирование температуры. Посмотрел я предлагаемые решения, ничего мне не понравилось. И попалось мне на глаза слово «Ардуино». А по специальности я — программист. И понеслось…


Железо


В железе я не силен. Макетную плату спаять — это верх моих способностей. Но Ардуино — такая простая штука, что я понял — даже с моими познаниями электроники я способен сделать контроллер температуры в доме, который меня устроит.


Датчики температуры


У меня не любовь к проводам в интерьере. Я пытаюсь их исключить или скрыть, если исключить не получается. И несколько извилистым путем я пришел к использованию в качестве датчиков температуры в комнатах использовать беспроводные датчики от китайских метеостанций. Датчики долго работают от батареек и вещают на частоте 433мГц. Вполне симпатичные, можно выбрать разного цвета, с экраном и без экрана. Забегая вперед скажу — каждый производитель метеостанции изобретает свой протокол передачи данных датчиком. В процессе экспериментов я анализировал протоколы 5 типов датчиков — у них у всех разные форматы передачи данных. Я разработал библиотеку, которая принимает данные от 4 типов датчиков. С пятым связываться не стал — его протокол не похож на остальные отсутствием границ пакетов. Основным инструментом анализа данных стал китайский логический анализатор. Без подобного инструмента выполнить анализ протоколов — практически не реально. Стоит совсем немного, пользоваться просто — рекомендую приобрести всем ардуинщикам.

Я реализовал библиотеку на принципе семплирования, частота 10кГц. Этот подход позволил нивелировать шум в эфире и понизить нагрузку на процессор, по сравнению с подходом с прерываниям при изменении уровня на пине приемника. Для отладки использовался логический анализатор:

Сигнал с данными отладки

3...6 каналы — данные для отладки

Приведу примеры датчиков и их особенности.

  • Тип 1: Передача данных каждые 35 секунд. Период не изменяется и это является проблемой при использовании 3х и более датчиков — часы в датчиках идут немного по-разному, сигналы могут иногда накладываться, и один-два датчика выпадают на час-два-три раз в неделю-две. 6 пакетов данных за 0.8сек. ID датчика меняется при каждом включении. Нет данных о состоянии батареи.

    Внешний вид


    Данные

    Сверху — данные приемника, стрелками отмечены помехи
    Снизу — данные передатчика.
  • Тип 2: Период передачи данных — 40...80 секунд, в зависимости от канала. Самый лучший на мой взгляд протокол — 15 пакетов данных за 0.6сек, есть контрольная сумма. ID датчика меняется при включении, есть передача данных состояния батареи. Самый слабый передатчик — когда поместил приемник в коробку, качество приема заметно ухудшилось. Вероятно лечится внешней антеной для приемника.

    Внешний вид


    Данные

    помехи отсутствуют
  • Тип 3: Период передачи данных 50..55 секунд, в зависимости от канала. 7 пакетов за 0.6сек. ID меняется при включении, есть передача данных состояния батареи. Неплохой выбор.

    Внешний вид


    Данные
    Практически идентичны типу 1
  • Тип 4: Период передачи данных 56...76 секунд, в зависимости от канала. Экрана нет. Изменяемый при включении ID не обнаружен. Есть ли отличия в ID у разных экземпляров — не знаю, у меня такой датчик один. Данные о состоянии батареи — есть. Мощный сигнал, пропуска передачи практически не наблюдал.

    Внешний вид


    Данные
    не сохранились
  • Тип 5: Период передачи не замерял, переключателя каналов нет, протокол глубоко не анализировал.

    Внешний вид


    Данные


В итоге блок приемника реализовал на Arduino Pro Mini c отдачей данных по i2c slave.


Arduino Mega


Это первая платформа, на которой я сделал контроллер. Мой контроллер имел командный интерфейс, управлялся посредством вводимых через UART команд. На том этапе, я планировал сделать WEB-интерфейс на ESP8266 и общение ее с Мегой по UART. У меня есть плата Mega от Robotdyn, совмещенная с ESP8266 и вот на этой плате я планировал построить свою разработку. Особое достоинство платы — большое число внешних портов. Но в процессе знакомства с ESP8266 я понял, что этот небольшой чип вполне способен совместить в себе функции контроллера и интерфейса.


ESP8266


Я использовал вариант платы WeMos D1 mini, у нее небольшие размеры и достаточное для меня количество выводов — с учетом использования расширителя портов. Для этой платы есть огромное количество библиотек. Например me-no-dev/ESPAsyncWebServer — отличная библиотека web-сервера с поддержкой web-сокетов. Собрал я контроллер на этой плате. Разработал web-интерфейс. Все красиво работает. Но по непонятной мне причине — аптайм не больше суток. Или я что-то сделал криво, или какая-то из используемых библиотек кривая. К тому же, есть ограничение на 5 одновременных подключений. При превышении — рестарт или даже зависание (не смотря на имеющийся watchdog. с зависаниями я поборолся использованием внешнего watchdog'а). С учетом того что мой web-интерфейс состоит из почти десятка файлов, а браузеры загружают страницы в 5 параллельных потоков — добиться рестарта элементарно. Для себя я решил — эта плата может использоваться только в качестве клиента. Стал искать другие решения.

Скрины интерфейса











ESP32


Это вроде как наследник ESP8266. В ESP32 всего больше — частоты, памяти, ног, … Но вот беда — библиотека me-no-dev/ESPAsyncWebServer на ней не работает в плане web-сокетов. Совсем. Вылетает. Что-то связанное с многопоточностью. Другой библиотеки web-сервера с поддержкой web-сокетов я не нашел.


SOC


На данном этапе я принял решение использовать плату с linux — ничего более подходящего не придумал.


Мои требования к плате. Вроде их не много:



  • Мне не нужен экран.
  • В связи с отсутствием экрана для первоначальной настройки плата должна уметь работать в режиме точки доступа.
  • Мне нужен минимум функционала операционной системы.

Orange Pi i96


Данная плата подходила по всем параметрам — нет видео-выхода, WiFi, встроенная flash память, слот SD карты. Можно поставить Ubuntu или DietPi на встроенную память. Но беда этой платы — ее ПО. Нельзя сделать точку доступа. Ну а самая большая проблема — при рестарте меняется MAC адрес и ничего с этим сделать не получилось. В топку. (На момент написания статьи, на 4pda, в ветке посвященной аналогу этой платы (2g IOT) появилось сообщение о том что возможно победить смену MAC)


Onion Omega 2+


Шикарная документация. С прошивкой из коробки все завелось, экран не нужен, UART не обязателен. SSH по-умолчанию включен. Node.js поставилось (версии 4.х, но мне не принципиально). Поставились (с помощью бубна) библиотеки sqlite и i2c для Node.js.
Кроме i2c, никакие аппаратные интерфейсы мне больше не нужны. По сравнению с вариантом моей разработки на ESP8266 добавился отдельный контроллер Arduino Pro Mini, для анализа данных приемника данных датчиков температуры. Контроллер приемника соединен с Omega как i2c slave. Проводные датчики с интерфейсом 1wire подключены через мост 1wire<->i2c (DS2482-100). Для этого моста есть библиотека для node.js, но у меня она не заработала в части поиска датчиков. Я не стал разбираться, портировал на js ту библиотеку DS2482, что работала на ESP8266.

Но вот беда — WiFi на Omega-2 работает не стабильно, после перезагрузки роутера не переподключается. Эта проблема решается прошивкой версии 2, она не в статусе релиза, но работает. Стало гораздо лучше. Но выяснилась проблема — иногда плата отваливается от роутера Zyxel и снова подключается после перезагрузки роутера или через час-два-три сама без перезагрузки роутера. Или начинает жутко тупить — эта проблема ушла после изменения схемы питания (плата очень любит именно 3.3в или чуть выше) и добавления внешней антенны — омега ей очень обрадовалась. Таким образом платой я в принципе доволен — то что нет иногда доступа меня не сильно волнует — в качестве основного интерфейса я использовал старый смартфон в доке, подключенный к точке доступа Омеги. А сильно нужен будет удаленный доступ — я могу удаленно перезагрузить роутер. Вызывает непонимание — у Omega-2 два пина RST — на один надо подавать +, я так понимаю, это обрабатывается программно. Что подать на второй и как подключить внешний watchdog, который подает -, я пока не знаю.

Интерфейс в интерьере


Логика контроллера

Я уже описывал архитектуру ПО контроллера — она не изменилась (т.е. управление текстовыми командами, передаваемыми по web-сокету). Web-интерфейс перекочевал с ESP8266 c косметическими изменениями. Многие процедуры/функции кода контроллера были просто транслированы с С++ на JS. Другое дело, что наличие linux (OpenWRT) дало мне возможность использовать SQL базу данных — sqlite. Таким образом всю логику я организовал на SQL запросах. Это фактически мой первый опыт работы с sqlite. Особенно мне понравилась возможность использования in-memory базы данных — я все временные и текущие данные расположил в этой базе (например — данные датчиков, данные о текущей требуемой температуре, ...).

Исходники
Я обычно делюсь идеями, а не исходниками. Мне кажется это стимулирует умственную активность, мою и читателей. Хотите получить исходники — пишите в личку.

Сборка

Собрал я все в железе, расположил в коробочке. Далее — ресурсные испытания. После недельного аптайма — я решил что тест пройден. Можно инсталлировать.

Коробочка


Инсталляция


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


Подключил реле котла.


Запуск


Контроллер заработал как планировалось.


Для теста я решил чуть поднять температуру в одной из комнат на втором этаже.


Котел стал перегреваться и отключаться.


И тут пригодились сервисные датчики. Оказалось, что темпе��атура воды на выходе из петли этой комнаты всего на пару десятых долей градуса меньше чем на входе! Вода не остывает! Это значит, что тепло она не отдает. А во всем доме тепло при любой температуре за бортом (цель была чуть понизить температуру на втором этаже). Значит все тепло дает первый этаж, а ТП на втором этаже еле греет пол. Как следствие — покомнатное регулирование отопления в таких условиях не возможно.


Заключение


Таким образом, влияние физики и конструктивных особенностей моего дома поставили крест на моей разработке. Не смотря на то, что сам контроллер работает отлично, в системе отопления моего дома я применить его не могу. Возможно я сделаю ему downgrade, чтобы он управлял климатом в доме аналогично китайскому термостату — по данным одного датчика, но пока не вижу смысла.


Вместе с тем, что проект в целом не удачен, в процессе разработки я познакомился со многими технологиями, с которыми ранее был практически незнаком:

  • Программирование контроллеров
  • Узнал про шины данных 1wire, i2c, uart, ...
  • Обрел некоторые познания в устройстве web-сервера
  • Вроде не плохо разобрался в Web-frontend разработке: html, JavaScript, vue.js
  • Освоил Web-backend разработку: node.js


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

Те, кто дочитал до этого места — могут посмотреть, на то что получилось.
(последние три пункта настроек заблокированы)


P.S. Идеальная плата для DIY


В процессе написания статьи обнаружилась еще одна неприятность с Omega-2 — модуль стал зависать. Жестко, ресет не помогает, только отключение питания. В чем проблема — пока не знаю. Может не нравится повышенное питание — сейчас ему подается 3.8В. Попробую заменить модуль питания. Не смотря на то, что проект не выполняет своих функций, пока что оставлю его в режиме термометра (как говорится, что на Ардуино не делай — получится метеостанция). Но в любом случае, тема мне интересна, я хочу добиться 100% доступности системы 24/7. Если замена блока питания не поможет, попробую систему LinkIt Smart 7688. Она вроде аппаратно идентична Омеге. Может быть будет более стабильна.
Дополнение: после замены линейного стабилизатора 5->3.3в на импульсный проблем с WiFi у Onion Omega 2+ замечено не было — стабильная работа в течении недели. Потом написал это дополнение.

Исходя из этого — я пока не нашел для себя идеальный вариант платы для самоделок :(

Вероятно в качестве мозгов следующего проекта я попробую использовать смартфон на android — датчики к нему подключать придется по wifi, но проблем со стабильностью брендовых телефонов практически нет. А node.js на телефон вроде можно поставить.

Буду признателен если поделитесь своим видением по вопросам выбора платы для DIY.