Сделали мы шкаф управления для дома вот тут , разработали контроллер и тут.
Свет можно включить/выключить с телефона, в телеграм приходят нотификации об утечке воды, включении полива и бог ещё знает что.
Но вся эта система далеко не умный дом, это лишь продолжение ваших рук и ног, и единственная помощь от неё только лишь в том, что не надо вставать с кровати, чтобы выключить свет.
Эта статья посвящена тому, что может приблизить ваш дом к умному, и вы правильно догадались — это разработка датчиков. Это глаза, уши и еще немного больше для вашего дома. На основе информации с датчиков уже можно написать автоматические сценарии, которые оживят дом, и будут тихо помогать вам и делать вашу жизнь более комфортной.
На рынке сейчас большое разнообразие подобных устройств как от именитых производителей так и непонятного происхождения. И если не сильно заморачиваться то можно использовать и их, но есть одно но, или даже несколько но. Первое, большинство из них используют свои проприетарные протоколы и работают только со своими хабами. И в любой момент API этих хабов может стать закрытым, и контроль будет возможен только через апликейшн производителя (вспоминаем историю с google nest), так что вся ваша автоматизация в один момент рухнет.
Второе, все производители без исключения пытаются хоть как-то получить с этого прибыль, а поскольку явление это пока не массовое то нужно выкручиваться, вот и делают каждый датчик в своём отдельном корпусе со своей батарейкой. А теперь давайте посчитаем, у вас 5 комнат в каждой хотелось бы иметь датчик температуры, движения, освещенности и СО. Не сложные мат. вычисления приводят к 20 коробочкам на потолке. Во-первых, это не красиво, во-вторых, через год-два нужно будет пол дня с лестницей и отверткой менять батарейки в этих датчиках, скорее всего сломав пару креплений и пару раз уронив отвертку на ламинат. Да, и в третьих, когда через пару лет один из датчиков сломается, то вы уже не сможете купить такой же, и скорее всего старые хабы не будут поддерживать новые датчики(прибыль то важна) и вам придётся поменять все датчики и переинтегрировать их в вашу систему. Какой выход — смотреть на что-то из opensource, или делать самому, по крайней мере код всегда будет при вас. Так что в свете описанного, разработка своей коробочки с датчиками становится не такой уж оверкилл задачей.
Так что разрабатывая свой датчик я старался описанные выше 'но' избежать:
Теперь давайте перейдем к тому, как же должен работать подобный девайс.
Есть два возможных варианта, и зависят они от того, в каком окружении использовать устройство, в системе с централизованным контролем, в распределенной системе или вообще как самостоятельное устройство.
Первый вариант проще, т.к. требуется предоставление только сырых данных с сенсоров, а далее уже центральный контроллер, который опрашивает устройство, решает что с ними делать, пример такого устройства — офисный датчик дыма. Например, пришли данные от датчика выше определенного порога, при этом центральный контроллер знает что сейчас включён режим охраны и соответственно надо поднимать тревогу.
Второй вариант предполагает, что устройство само должно знать в каком оно сейчас режиме, уметь конвертировать raw данные с сенсоров, принимать решение об информировании пользователя. Разработка такого устройства конечно же требует больше усилий как с точки зрения написания программы так и с точки зрения проработки юзабилити.
Я изначально планировал делать устройство по второму варианту, и закладывал два канала связи — mqtt и modbus. Mqtt через WIFI так на поиграться и modbus через RS-485 для подключения к домашней системе управления.
Mqtt через WIFI не сложно сделать благодаря lua библиотекам ESP8266 и алгоритм достаточно стандартен:
Однако когда стал вопрос интеграции устройства в домашнюю систему по modbus, мне стало не хватать сырых данных с датчиков, и в конечном итоге я выложил в таблицу modbus ещё и все raw данные. Например, казалось бы не нужное событие с датчика движения, в режиме снятом с охраны, очень даже можно использовать для всяких функций умного дома.
Таблица modbus получилась такой:
N type description
0. -r — state of sensortag (1 — idle mode / 2 — idle to protection / 3 — protection mode)
1. -r — bitfield reason of alarm (bit 1 — gas / 2 — temperature / 3 — motion)
2. -r — motion detection in idle and protection states (0 / 1 — no motion / motion)
3. -r — gas concentration (raw value from adc)
4. -r — temperature in C deg
5. -r — preprocessed light value (night room < 17 / dark room < 50 / twilight < 150 sunny < 250)
6. -r — light value (raw value from adc)
7. -r — number of alarm event in this life cycle
8. -r — number of sensortag restarts
9. -r — not used
10 -wr- alarm activation (0 — switch to idle / 1 — switch to alarm)
11. -wr- motion sensitivity (0 — 100%, means 0 — most sensitive)
12. -wr- gas concentration limit
Далее всё, как всегда, сводится к разработке платы и софта. И в этом случае разработка платы мне далась сложнее, т.к. присутствует аналоговая часть(питание, обвязка сенсоров движения и СО) с чем я дружу не очень, а про софт даже особо и написать нечего, потому что всё там действительно просто. Т.е. не просто, а обыденно, считал показание с АЦП, сконвертировал их, обработал(методом скользящего окна по всем каналам) и сложил в таблицу. Ещё бы не плохо сделать температурную компенсацию сигнала с PIR сенсора т.к. летом, когда температура в комнате выше +30 градусов, у сенсора гораздо слабее отклик. Так что в этой статье хотелось бы описать именно разработку самой платы и немного уделить внимания юзабилити.
Начнем с платы, вот что для этого надо бы сделать:
Выбор микроконтроллера особо труда не составляет, нужно лишь дотянуться до ящика с девбордами и достать одну плату — она и подойдет. А если серьёзно, то я не могу похвастаться знанием многих семейств микроконтроллеров, так что из мне знакомых STM32, ATSAM и AVR. Я выбрал последнюю и только лишь потому что у меня как раз завалялось пару Arduino Leonardo и скучающий по былым временам MK2. Не буду упоминать, что AVR дёргает ногами на частоте кварца, а это мне пригодится, и что у неё широкий набор переферии и довольно быстрый АЦП, мне гораздо важнее что корпус у неё TQFP и могу я её припаять сам, без микроскопа и танцев с бубнами. Если выбор микроконтроллера это дело десяти минут, то выбор датчиков дело не тривиальное. Надо изначально продумать как их подключать, как обрабатывать их сигналы и как они будут влиять друг на друга. Если некоторые датчики можно взять с ардуино набора и стоят они копейки, то с другими, более редкими, можно и повозиться дольше и потратить больше. К тому же на выбор датчиков вносили ограничения и мои дополнительные критерии:
В результате всех изысканий получаем вот такой набор:
И если с первыми тремя позициями, думаю, ни у кого не будет вопросов, то зачем нужен TGS5141 сразу не понятно. Наверно вы скажите — «зачем такая дорогая вещь, ведь есть копеечные СО сенсоры из ардуино набора типа MQ-7». Действительно, я экспериментировал и с ними, и по результату отказался от них по нескольким причинам. Во-первых, это каталитический датчик, и он греется, что сильно влияет на температуру в корпусе устройства и не даёт возможности делать температурную компенсацию для сигнала с PIR сенсора. Во-вторых, чувствительность MQ-7 оставляет желать лучшего, даже в спеке написано 10 to 1000ppmm, а в реальности всё ещё печальнее, плюс нет никакой стабильности от датчика к датчику. Третье, не понятен срок службы самого датчика, я так предполагаю что его характеристики с годами будут сильно меняться именно из-за того что он каталитический. А теперь о плюсах электрохимического TGS5141 — не греется, чувствительность 0 ~ 5000ppm(с линейной характеристикой), гарантированный срок службы 10 лет, малый размер и ещё много плюсов. Думаю выбор очевиден, если вы хотите действительно сделать стоящую вещь, а не наколенную поделку.
Выбрали мы микроконтроллер, датчики, теперь пришло время позаботиться о том, как сообщать пользователю то что мы намеряли. Как я писал ранее у меня есть два канала связи для этого, rs-485 modbus и mqtt через WIFI. Что делает возможным использование моего сенсортега как индивидуальное устройство, и поэтому, немаловажным, является индикация состояния, каким-нибудь образом, на самом устройстве, например светодиодами.
Определившись с концепцией, можно немного внимания уделить остальной элементной базе. Драйвер 485го я использую ADM2587E, микросхема включает не только сам драйвер, но и трансформаторную гальваническую развязку по RX, TX и DE, минус только в цене. Для коммуникации по mqtt через WIFI будем использовать ESP-07, тут, думаю, комментариев не нужно, т.к. только ленивый не сделал что-то на ESP8266. С визуальной индикацией пришлось повозиться больше, для этого я решил использовать RGBW светодиоды sk6812. Как оказалось с AVR управлять ими не очень то и просто, тайминги у них довольно-таки жесткие, так что пришлось дописывать некоторые части кода на асемблере, чего изначально не планировалось. Но результат себя оправдал, получилось информативно и красиво, особенно если светить этими светодиодами в торец кольца из оргстекла. Такую индикацию мне подсказал сотрудник уже съевший на этом собаку(спасибо Саша).
Немного поэкспериментировав с яркостью, стало понятно что один уровень яркости это не моё решение — днём плохо видно, а ночью сильно ярко. Поэтому пришлось сделать изменение яркости свечения этих светодиодов в зависимости от освещения в комнате. Ну вот и всё, с индикацией разобрались, подумали вы, а вот и нет, самым для меня сложным оказалось придумывание патернов свечения и таймингов для них.
Остановился на таком варианте:
С индикацией разобрались, следующий раздел это питание.
Как я уже говорил ранее, у меня по дому протянута слаботочка 24В, поэтому и питание модулей будет именно такое. Забегая вперед, скажу, что после того как я сделал первую плату многое пришлось переделать по питанию. Тут то я и убедился в том что нужно внимательнее читать спеки на step-down конверторы, особенно те места, где описаны нюансы разводки. По результатам изысканий я остановился на step-down converter MCP16311 и он оказался ну очень привередливым, только после того, как я сделал в точности то, что написано в спеке — всё заработало. Но это была не самая большая проблема, как потом выяснилось, изменение яркости светодиодов давало небольшую просадку питания, которой достаточно что бы испортить сигнал с датчика D203S, эту проблему получилось побороть дополнительными конденсаторами как в схему операционника датчика так и в схему step-down конвертора. Всё отладив по mqtt(через ESP8266), я подключил rs-485 и тут опять меня ждал провал, на выходе операционника в канале датчика D203S я опять увидел мусор, и этот мусор чётко соответствовал обмену по rs-485. В общем, побороть это получилось дополнительным LDO конвертором на всю аналоговую часть и тогда наступило счастье.
И если объединить всё вместе то получится вот такая картина:
И если это всё взять и спаять то выглядит оно как-то так:
Плату спаяли, корпус напечатали, всё собрали воедино, повесили на потолок, данные приходят в систему. Так что давайте пофантазируем как можно применять эти данные в системе умного дома, помимо того, конечно, что можно присылать сигналы тревоги в телеграм. Я пока не сделал ничего, кроме первого пункта, но накидал следующие сценарии:
Так что дополняйте, будем делать дом умнее…
Свет можно включить/выключить с телефона, в телеграм приходят нотификации об утечке воды, включении полива и бог ещё знает что.
Но вся эта система далеко не умный дом, это лишь продолжение ваших рук и ног, и единственная помощь от неё только лишь в том, что не надо вставать с кровати, чтобы выключить свет.
Эта статья посвящена тому, что может приблизить ваш дом к умному, и вы правильно догадались — это разработка датчиков. Это глаза, уши и еще немного больше для вашего дома. На основе информации с датчиков уже можно написать автоматические сценарии, которые оживят дом, и будут тихо помогать вам и делать вашу жизнь более комфортной.
На рынке сейчас большое разнообразие подобных устройств как от именитых производителей так и непонятного происхождения. И если не сильно заморачиваться то можно использовать и их, но есть одно но, или даже несколько но. Первое, большинство из них используют свои проприетарные протоколы и работают только со своими хабами. И в любой момент API этих хабов может стать закрытым, и контроль будет возможен только через апликейшн производителя (вспоминаем историю с google nest), так что вся ваша автоматизация в один момент рухнет.
Второе, все производители без исключения пытаются хоть как-то получить с этого прибыль, а поскольку явление это пока не массовое то нужно выкручиваться, вот и делают каждый датчик в своём отдельном корпусе со своей батарейкой. А теперь давайте посчитаем, у вас 5 комнат в каждой хотелось бы иметь датчик температуры, движения, освещенности и СО. Не сложные мат. вычисления приводят к 20 коробочкам на потолке. Во-первых, это не красиво, во-вторых, через год-два нужно будет пол дня с лестницей и отверткой менять батарейки в этих датчиках, скорее всего сломав пару креплений и пару раз уронив отвертку на ламинат. Да, и в третьих, когда через пару лет один из датчиков сломается, то вы уже не сможете купить такой же, и скорее всего старые хабы не будут поддерживать новые датчики(прибыль то важна) и вам придётся поменять все датчики и переинтегрировать их в вашу систему. Какой выход — смотреть на что-то из opensource, или делать самому, по крайней мере код всегда будет при вас. Так что в свете описанного, разработка своей коробочки с датчиками становится не такой уж оверкилл задачей.
Так что разрабатывая свой датчик я старался описанные выше 'но' избежать:
- Агрегируем все датчики в один корпус
- Делаем проводное питание (стройка то с нуля)
- Делаем интерфейсы по стандартным протоколам
Теперь давайте перейдем к тому, как же должен работать подобный девайс.
Есть два возможных варианта, и зависят они от того, в каком окружении использовать устройство, в системе с централизованным контролем, в распределенной системе или вообще как самостоятельное устройство.
Первый вариант проще, т.к. требуется предоставление только сырых данных с сенсоров, а далее уже центральный контроллер, который опрашивает устройство, решает что с ними делать, пример такого устройства — офисный датчик дыма. Например, пришли данные от датчика выше определенного порога, при этом центральный контроллер знает что сейчас включён режим охраны и соответственно надо поднимать тревогу.
Второй вариант предполагает, что устройство само должно знать в каком оно сейчас режиме, уметь конвертировать raw данные с сенсоров, принимать решение об информировании пользователя. Разработка такого устройства конечно же требует больше усилий как с точки зрения написания программы так и с точки зрения проработки юзабилити.
Я изначально планировал делать устройство по второму варианту, и закладывал два канала связи — mqtt и modbus. Mqtt через WIFI так на поиграться и modbus через RS-485 для подключения к домашней системе управления.
Mqtt через WIFI не сложно сделать благодаря lua библиотекам ESP8266 и алгоритм достаточно стандартен:
- при первом старте или если не получается подключиться к WIFI, надо сделать точку доступа из ESP8266
- развернуть на ней маленький вэбсервер с параметрами WIFI и параметрами mqtt сервера(можно сделать бесплатно на амазоне например)
- сохранить всё введенные данные в памяти ESP8266
- после перезагрузки пробовать подключится к mqtt уже через домашний WIFI
Однако когда стал вопрос интеграции устройства в домашнюю систему по modbus, мне стало не хватать сырых данных с датчиков, и в конечном итоге я выложил в таблицу modbus ещё и все raw данные. Например, казалось бы не нужное событие с датчика движения, в режиме снятом с охраны, очень даже можно использовать для всяких функций умного дома.
Таблица modbus получилась такой:
N type description
0. -r — state of sensortag (1 — idle mode / 2 — idle to protection / 3 — protection mode)
1. -r — bitfield reason of alarm (bit 1 — gas / 2 — temperature / 3 — motion)
2. -r — motion detection in idle and protection states (0 / 1 — no motion / motion)
3. -r — gas concentration (raw value from adc)
4. -r — temperature in C deg
5. -r — preprocessed light value (night room < 17 / dark room < 50 / twilight < 150 sunny < 250)
6. -r — light value (raw value from adc)
7. -r — number of alarm event in this life cycle
8. -r — number of sensortag restarts
9. -r — not used
10 -wr- alarm activation (0 — switch to idle / 1 — switch to alarm)
11. -wr- motion sensitivity (0 — 100%, means 0 — most sensitive)
12. -wr- gas concentration limit
Далее всё, как всегда, сводится к разработке платы и софта. И в этом случае разработка платы мне далась сложнее, т.к. присутствует аналоговая часть(питание, обвязка сенсоров движения и СО) с чем я дружу не очень, а про софт даже особо и написать нечего, потому что всё там действительно просто. Т.е. не просто, а обыденно, считал показание с АЦП, сконвертировал их, обработал(методом скользящего окна по всем каналам) и сложил в таблицу. Ещё бы не плохо сделать температурную компенсацию сигнала с PIR сенсора т.к. летом, когда температура в комнате выше +30 градусов, у сенсора гораздо слабее отклик. Так что в этой статье хотелось бы описать именно разработку самой платы и немного уделить внимания юзабилити.
Начнем с платы, вот что для этого надо бы сделать:
- выбрать микроконтроллер и датчики(пир сенсор, освещенности, температуры, СО)
- выбрать rs-485 драйвер для modbus коммуникации
- ESP8266 для mqtt коммуникации(что тут выбирать)
- выбрать RGB светодиод для визуализации состояния устройства
- разработать модули питания
- разработать принципиальную схему, развести и сделать платы
Выбор микроконтроллера особо труда не составляет, нужно лишь дотянуться до ящика с девбордами и достать одну плату — она и подойдет. А если серьёзно, то я не могу похвастаться знанием многих семейств микроконтроллеров, так что из мне знакомых STM32, ATSAM и AVR. Я выбрал последнюю и только лишь потому что у меня как раз завалялось пару Arduino Leonardo и скучающий по былым временам MK2. Не буду упоминать, что AVR дёргает ногами на частоте кварца, а это мне пригодится, и что у неё широкий набор переферии и довольно быстрый АЦП, мне гораздо важнее что корпус у неё TQFP и могу я её припаять сам, без микроскопа и танцев с бубнами. Если выбор микроконтроллера это дело десяти минут, то выбор датчиков дело не тривиальное. Надо изначально продумать как их подключать, как обрабатывать их сигналы и как они будут влиять друг на друга. Если некоторые датчики можно взять с ардуино набора и стоят они копейки, то с другими, более редкими, можно и повозиться дольше и потратить больше. К тому же на выбор датчиков вносили ограничения и мои дополнительные критерии:
- Датчики могут быть подключены как угодно, но только не через I2C. Вот как то не получалось у меня надёжной имплементации I2C на микроконтроллерах, где поддержка этой шины реализована на половину аппаратно, а на половину программно(ну как в AVR). Бывало что работает, работает месяц, а потом встряёт, и никакие рекавери последовательности не помогают, так что решено было использовать как можно больше аналоговых датчиков подключенных к АЦП и только лишь для температуры использовать SPI(с ним кстати дружба крепкая и надёжная).
- Были достаточно надёжными и не меняли своих характеристик во время срока службы(я определил его как 10 лет)
- Были доступными на нашем рынке, что бы не связываться с заказами с маузера и тд.
В результате всех изысканий получаем вот такой набор:
- PIR sensor — D203S
- Light sensor — GL5516
- Temperature sensor — LM95071
- CO sensor — TGS5141
И если с первыми тремя позициями, думаю, ни у кого не будет вопросов, то зачем нужен TGS5141 сразу не понятно. Наверно вы скажите — «зачем такая дорогая вещь, ведь есть копеечные СО сенсоры из ардуино набора типа MQ-7». Действительно, я экспериментировал и с ними, и по результату отказался от них по нескольким причинам. Во-первых, это каталитический датчик, и он греется, что сильно влияет на температуру в корпусе устройства и не даёт возможности делать температурную компенсацию для сигнала с PIR сенсора. Во-вторых, чувствительность MQ-7 оставляет желать лучшего, даже в спеке написано 10 to 1000ppmm, а в реальности всё ещё печальнее, плюс нет никакой стабильности от датчика к датчику. Третье, не понятен срок службы самого датчика, я так предполагаю что его характеристики с годами будут сильно меняться именно из-за того что он каталитический. А теперь о плюсах электрохимического TGS5141 — не греется, чувствительность 0 ~ 5000ppm(с линейной характеристикой), гарантированный срок службы 10 лет, малый размер и ещё много плюсов. Думаю выбор очевиден, если вы хотите действительно сделать стоящую вещь, а не наколенную поделку.
Выбрали мы микроконтроллер, датчики, теперь пришло время позаботиться о том, как сообщать пользователю то что мы намеряли. Как я писал ранее у меня есть два канала связи для этого, rs-485 modbus и mqtt через WIFI. Что делает возможным использование моего сенсортега как индивидуальное устройство, и поэтому, немаловажным, является индикация состояния, каким-нибудь образом, на самом устройстве, например светодиодами.
Определившись с концепцией, можно немного внимания уделить остальной элементной базе. Драйвер 485го я использую ADM2587E, микросхема включает не только сам драйвер, но и трансформаторную гальваническую развязку по RX, TX и DE, минус только в цене. Для коммуникации по mqtt через WIFI будем использовать ESP-07, тут, думаю, комментариев не нужно, т.к. только ленивый не сделал что-то на ESP8266. С визуальной индикацией пришлось повозиться больше, для этого я решил использовать RGBW светодиоды sk6812. Как оказалось с AVR управлять ими не очень то и просто, тайминги у них довольно-таки жесткие, так что пришлось дописывать некоторые части кода на асемблере, чего изначально не планировалось. Но результат себя оправдал, получилось информативно и красиво, особенно если светить этими светодиодами в торец кольца из оргстекла. Такую индикацию мне подсказал сотрудник уже съевший на этом собаку(спасибо Саша).
Немного поэкспериментировав с яркостью, стало понятно что один уровень яркости это не моё решение — днём плохо видно, а ночью сильно ярко. Поэтому пришлось сделать изменение яркости свечения этих светодиодов в зависимости от освещения в комнате. Ну вот и всё, с индикацией разобрались, подумали вы, а вот и нет, самым для меня сложным оказалось придумывание патернов свечения и таймингов для них.
Остановился на таком варианте:
- blue slow — idle, communication over wifi only (modbus missing)
- blue fast — switch from idle to alarm mode, communication over wifi only (modbus missing )
- green slow — idle (modbus communication OK)
- green fast — switch from idle to alarm mode (modbus communication OK)
- red slow — alarm mode
- red fast — motion alarm
- yellow fast — gas alarm
С индикацией разобрались, следующий раздел это питание.
Как я уже говорил ранее, у меня по дому протянута слаботочка 24В, поэтому и питание модулей будет именно такое. Забегая вперед, скажу, что после того как я сделал первую плату многое пришлось переделать по питанию. Тут то я и убедился в том что нужно внимательнее читать спеки на step-down конверторы, особенно те места, где описаны нюансы разводки. По результатам изысканий я остановился на step-down converter MCP16311 и он оказался ну очень привередливым, только после того, как я сделал в точности то, что написано в спеке — всё заработало. Но это была не самая большая проблема, как потом выяснилось, изменение яркости светодиодов давало небольшую просадку питания, которой достаточно что бы испортить сигнал с датчика D203S, эту проблему получилось побороть дополнительными конденсаторами как в схему операционника датчика так и в схему step-down конвертора. Всё отладив по mqtt(через ESP8266), я подключил rs-485 и тут опять меня ждал провал, на выходе операционника в канале датчика D203S я опять увидел мусор, и этот мусор чётко соответствовал обмену по rs-485. В общем, побороть это получилось дополнительным LDO конвертором на всю аналоговую часть и тогда наступило счастье.
И если объединить всё вместе то получится вот такая картина:
И если это всё взять и спаять то выглядит оно как-то так:
Плату спаяли, корпус напечатали, всё собрали воедино, повесили на потолок, данные приходят в систему. Так что давайте пофантазируем как можно применять эти данные в системе умного дома, помимо того, конечно, что можно присылать сигналы тревоги в телеграм. Я пока не сделал ничего, кроме первого пункта, но накидал следующие сценарии:
- включение света на лестнице, если этот свет не включен, если в любой комнате появилось движение, плюс сейчас темно, плюс ночное время
- автоматическое открытие ролет первого этажа, если они закрыты, если уже утро и обнаружено движение в гостиной первый раз за день
- открытие заслонок вентиляции, если концентрация СО превышает какой-либо уровень, и закрытие их если уровень СО упал(актуально в комнате с камином)
- открывать заслонки вентиляции, если температура превысила определённый лимит и соответственно закрывать их в обратном случае
- автоматическое закрытие ролет первого этажа, если ролеты открыты и если ночью на улице сработали датчики движения, а дом стоит на ночной охране.
Так что дополняйте, будем делать дом умнее…
