Фиаско. История одной самоделки IoT15.10.2018 09:19

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

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

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

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

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

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

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

• Тип 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-сокетов я не нашел.

На данном этапе я принял решение использовать плату с 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

Таким образом я на неудавшемся проекте получил большой опыт, который возможно пригодится на других проектах.
Те, кто дочитал до этого места — могут посмотреть, на то что получилось: http://tco.vehs.ru/

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

© Habrahabr.ru