Кому интересно, прошу под кат.
Как мне кажется, zWave в моем случае оказался неработоспособным по двум причинам: в доме два этажа с железобетонным межэтажным перекрытием и большая площадь (то есть значительное удаление некоторых датчиков от контроллера). Ну и недоработки в фирменном программном обеспечении, которые не позволяли отключить периодическое пробуждение датчиков, что привело к быстрому разряду батареи. Когда стало понятно, что мне с zWave не по пути, я стал искать другие варианты, которые можно было бы впихнуть в те же корпуса датчиков.
Мой первый прототип датчиков базировался на ESP8266. Контроллер — на базе моей платы, о которой я уже писал на Хабре. В качестве прототипа система даже заработала, но пришлось от нее отказаться по двум причинам. Первая причина та же самая — в доме оказались закутки с очень низким уровнем сигнала WiFi, что привело к очень большому времени активации ESP8266 при пробуждении и, как следствие, к сильному разряду батарейки. Хотя я допускаю, что просто не умею правильно готовить эту самую ESP8266 (статьи вроде этой подтверждают такой тезис). Но вторая причина оказалась более серьезной. Так как я решил оставить не только корпус, но и батарейный отсек, то был ограничен батарейкой CR123A, которая на 3.0 вольта. То есть цена и сложность датчика возрастала за счет повышающего DC/DC преобразователя. Хотя и по этой теме на Хабре есть замечательная статья. Но, так или иначе, эти две причины перевесили и ESP8266 я отбросил.
Второй прототип был проводной. Сделал прототип как датчика, так и USB-контроллера, дописал серверный модуль, чтобы он этот контроллер понимал дополнительно к zWave-Stick. Была идея постепенно тянуть провода и датчик за датчиком менять zWave-плату на проводную. Но ковырять стены в конечном итоге не стал и этот прототип также отбросил.
Потом решил посмотреть в сторону радиомодулей на 433 и 868 MHz и заказал несколько модулей для экспериментов: RFM69HCW, A110LR09A и MRF89XAM8A. По размерам модуля, цене, а также из-за наличия как библиотек, так и хороших примеров остановился на RFM69HCW, который и лег в основу системы.
В системе получилось всего четыре компонента:
- беспроводные датчики (433 MHz, батарейка CR123A 3.0V),
- сетевой контроллер (433 MHz, питание по USB от сервера)
- сервер (о котором я уже писал на Хабре в этой статье) и серверный программный модуль
- мобильный клиент (Андроид-приложение)
Ниже я подробно опишу каждый модуль, а в завершение дам статистику работы системы за последние месяцы работы.
Датчики
В датчиках используется радиомодуль RFM69HCW. Он имеет широкий диапазон рабочего напряжения (1.8V-2.4V 17dBm, 2.4V-3.6V 20dBm) и управляется через SPI. То есть нужен микроконтроллер. Некоторое время назад я познакомился с серией STM32L и заказал для экспериментов STM32L051. В ней меня подкупил как небольшой ток в режиме сна (0.27 ?A), так и рабочее напряжение, практически идентичное напряжению радиомодуля (1.65V-3.6V). Плюс низкая цена.
Получилась такая схема:
Напряжение питания как микроконтроллера, так и радиомодуля таковы, что их можно напрямую запитать от элемента CR123A. STM32L051 имеет внутренний источник опорного напряжения, подключенный к каналу 17 АЦП, а также калибровочное значение этого источника, что позволяет измерять текущее значение напряжения питания VDD. Радиомодуль подключен к питанию через полевик Q1, что позволяет управлять его питанием с микроконтроллера.
Режим сна реализован переводом микроконтроллера в «Standby». В этом режиме у STM32L051 отключено ядро, практически вся периферия и внутренний регулятор напряжения, что обеспечивает потребление на уровне 0.29 ?A (при отключенных часах реального времени). Но в этом режиме есть особенность — микроконтроллер пробуждается только по восходящему фронту сигнала на пине WKUP (А0). Так как используется магнитный переключатель, который двухпозиционный (замкнут или разомкнут), то нужен небольшой блок, который генерирует импульс небольшой длительности как при замыкании, так и при размыкании магнитного контакта. Этот импульс подается на вход А0 микроконтроллера и пробуждает его. Такой преобразователь реализован на микросхеме IC3 «Исключающее ИЛИ» энергоэффективной серии 74AUP (74AUP1G86), которая работает в диапазоне напряжений 0.8V-3.6V и потребляет 0.2 ?A. Таким образом, общее потребление в режиме сна должно быть в районе 0.5 ?A, что подтверждается измерениями на полностью собранном датчике.
Когда микроконтроллер просыпается, он сначала измеряет напряжение питания и, если оно меньше 1.8 вольта, то не судьба — передатчик запустить не получится и микроконтроллер засыпает обратно.
Если же напряжение батарейки больше 1.8 вольта, то микроконтроллер включает и инициализирует радиомодуль, передает состояние на сетевой контроллер и ожидает подтверждения. В пакет данных входят уникальный 32х-битный номер пакета (события), напряжение батарейки, температура, состояние магнитного контакта, контрольный байт (CRC7). В случае успешного подтверждения микроконтроллер засыпает обратно. Если нет, то высылает статус снова, но максимум 10 раз. Такую границу я установил, чтобы датчик не пытался до бесконечности ждать ответа в ситуации, когда сетевой контроллер просто выключен. Последний переданный уникальный номер события хранится во внутренней EEPROM памяти микроконтроллера.
Во время передачи данных микроконтроллер мигает светодиодом (куда же без этого). Светодиод включается при помощи ШИМ, где скважность зависит от текущего значения напряжения, что позволяет иметь практически одинаковую яркость практически во всем диапазоне рабочего напряжения.
Платы спроектированы в EagleCAD, проект плат доступен здесь. Платы двухсторонние: на верхней стороне, обращенной к раме окна, размещен микроконтроллер и его обвязка, а на нижней, обращенной в комнату — радиомодуль и светодиод. Заказывал в Китае, паял сам в обычной кухонной духовке (верхний слой) и феном (нижний слой).
Радиомодулю нужна антенна. Это просто кусочек провода длинной 164 мм.
После монтажа каждый датчик нужно программировать, для чего предусмотрен разъем SWD. Остальные контакты на плате я оставил ради возможных экспериментов в будущем.
Прошивка написана на С++, часть кода вынесена в достаточно универсальные базовые классы, которые инкапсулируют вызовы библиотеки ST HAL. Исходный код лежит здесь. Для разработки использовалась System Workbench for STM32. Размер итогового двоичного файла прошивки 22 kB.
А вот так выглядит датчик в корпусе:
В зависимости от положения датчика, для некоторых датчиков я оставил антенну снаружи (на фоне белой рамы ее, впрочем, не видно), а для некоторых датчиков изогнул провод в рамку и полностью запихал внутрь корпуса.
Ради интереса подсчитал стоимость компонент для одного датчика (по ценам каталога Mouser, цена и итоговая стоимость в евро)
| Элемент | Описание | Значение | Номер MOUSER | Кол-во | Стоимость |
| IC3 | Исключающее ИЛИ | 1G86 | 771-74AUP1G86GW-G | 1 | 0.254 |
| IC1 | Микроконтроллер | STM32L051 | 511-STM32L051K6T6 | 1 | 2.14 |
| SV1 | Разъем | SWD | 68602-406HLF | 1 | 0.157 |
| LED1 | LED 3 мм | 3mm | 630-HLMP-K155 | 1 | 0.351 |
| Q1 | P-MOSFET | BSH205 | 771-BSH205G2R | 1 | 0.276 |
| S1 | Магнитный контакт | ORD211-0810 | 876-ORD211-0810 | 1 | 0.625 |
| IC2 | RFM69HCW радиомодуль | RFM69HCW | 474-COM-13910 | 1 | 5.36 |
| C1, C2, C3, C6 | SMD конденсатор | 0.1uF | 80-C0805C104J5RAC | 4 | 0.1 |
| C5 | SMD конденсатор | 0.4nF | C0805C471K8HACTU | 1 | 0.021 |
| C4 | SMD конденсатор (тантал) | 47uF | 581-TAJR225K016RNJ | 1 | 0.334 |
| R1 | SMD резистор | 10K | 660-RK73H2ATTDD1002F | 1 | 0.01 |
| R10 | SMD резистор | 330 | 660-RK73H2ATTDD3300F | 1 | 0.01 |
| R3, R4, R6, R7, R8, R11 | SMD резистор | 47K | 660-RK73H2ATTDD4702F | 6 | 0.06 |
| R5 | SMD резистор | 56 | 660-RK73H2ATTD56R0F | 1 | 0.013 |
| R9 | SMD резистор | 56M | 603-RC0805JR-0756ML | 1 | 0.037 |
| 9.748 |
Получилось, кстати, ровно в три раза дешевле, чем стоил оригинальный датчик zWave. Хотя это только стоимость деталей без учета корпуса. Но, на мой взгляд, в рознице датчики zWave продаются до неприличия дорого.
Сетевой контроллер
Для контроллера использовался тот же самый радиомодуль и такой же микроконтроллер, как и для датчиков. Это позволило переиспользовать большую часть кода прошивки. Для контроллера я выбрал такой форм-фактор платы, чтобы использовать готовый корпус от Raspberry Pi. По сравнению с датчиком, добавился разъем для внешней антенны и контур USB на базе FT232RL и изолятора SI-8621. Конечно, вместо этого можно было бы взять какой-нибудь STM32 с USB на борту. Но тогда, во первых, пришлось бы разделять код прошивки и, во-вторых, самому заниматься программной реализацией USB. Вариант со внешней FT232RL хоть и дороже, но надежней и быстрее в реализации. В результате получилась такая схема:
А в собранном виде получилось вот так:
Микроконтроллер здесь в сон не уходит, радиомодуль работает на прием, но после успешного приема пакета с любого из датчиков модуль переходит в режим передачи и отправляет подтверждение приема. Кроме этого, любой успешно принятый пакет передается по USB на сервер. Формат пакета — это строка значений, разделенных символом «;»:
GW;3;12;-57;0;146;30;18
где:
- первая позиция — метка пакета (всегда «GW»)
- вторая позиция — тип данных (статус датчика или код ошибки)
- третья позиция — номер датчика
- четвертая позиция — качество сигнала на стороне сетевого контроллера (RFM69HCW сохраняет качество сигнала во время приема и позволяет опросить его, когда прием закончен)
- пятая позиция — состояние окна (0 открыто, 1 закрыто)
- шестая позиция — уникальный номер пакета (события) с датчика. Этот номер позволяет на стороне сервера контролировать, все ли события были получены сервером или одно или несколько событий были утеряны.
- седьмая позиция — актуальное напряжение батарейки (30 соответствует 3.0V)
- последняя, восьмая позиция — температура с внутреннего датчика микроконтроллера. Пока еще не придумал, как это можно использовать
Исходный код прошивки находится там же, что и для датчика. Они имеют общий файл main и общую библиотеку базовых классов. Вариант прошивки (датчик или контроллер) выбирается при помощи директивы define в файле main.cpp.
Стоимость сетевого контроллера получилась выше за счет USB-контура, антенны и дополнительных разъемов. Но этой добавкой можно пренебречь, так как контроллер один. Но даже с учетом этой добавки он также получился в три раза дешевле, чем zWave-Stick, который был перед этим на его месте.
Серверный модуль
Сетевой контроллер подключен к серверу, который работает под управлением CentOS 7. На сервере запущена программа, написанная на Java. И по своей структуре, и по реализации, и по задачам программа достаточно простая:
- При помощи очень древней и, вроде бы, больше не поддерживаемой библиотеки RxTx мониторится указанный в конфигурации USB порт (в моем случае /dev/ttyUSB0). На данный момент это самый плохо оптимизированный участок всей системы, так как библиотека сильно грузит процессор сервера.
- В случае поступления данных с USB-порта, они записываются в лог-файл и сохраняются в классе состояния датчиков. При перезагрузке сервера состояние теряется. Чтобы его восстановить, нужно пройтись по всему дому и вручную открыть и закрыть все окна. Наверное, это самый большой недостаток моей системы, но я вполне сознательно отказался от периодического опроса датчиков ради экономии их батарейки.
- Приложение также является небольшим TCP/IP сервером и слушает TCP/IP порт указанный в конфигурации. По этому порту оно может принимать соединения от мобильного клиента.
- В случае, если мобильный клиент подсоединяется к серверу, он высылает текущее состояние всех датчиков. Также при помощи периодических heartbit-сообщений сервер отслеживает активность соединения.
- Сервер и мобильный клиент обмениваются сообщениями в формате XML. Эти сообщения реализованы в виде небольшой Java-библиотеки, которая совместно используется как на стороне сервера, так и на стороне мобильного Андроид-приложения.
- Хоть большого смысла это пока не имеет, но ради интереса я добавил функцию авторизации мобильного клиента по IMEI, а также AES-шифрование сообщений между сервером и клиентом по ключу, зашитому в исходный код (Java-пакет javax.crypto). Но это так, чисто для эксперимента, так как TCP/IP порт этого серверного модуля доступен только из внутренней сети и снаружи не виден. Хотя, если я захочу открыть этот порт в большой мир, то теперь делать это будет не так страшно.
Кому интересно, исходный код серверного модуля здесь.
Мобильный клиент (Андроид-приложение)
Тут много не напишешь, несмотря на то, что это приложение и есть конечный результат всего проекта. Это стандартное и очень простое Java-приложение с тремя вкладками: состояние окон первого этажа, состояние второго этажа, и небольшая телеметрия сервера (см. исходный код здесь):
В основе графики лежит набор SVG-файлов, которые в виде стека рисуются друг над другом в зависимости от состояния датчиков. Поддерживается долгое нажатие в области каждого окна, по которому отображается подсказка со временем, во сколько это окно было открыто:
В принципе, ничего не мешает добавить в эту подсказку пиктограмму заряда батарейки, но руки пока не дошли.
Опыт эксплуатации
«Каждый чих» записывается в лог-файл на стороне сервера. Анализ этих файлов за последние 5 месяцев позволяет немного подробнее понять, как же эта система себя чувствует.
Анализ очень простой — просто grep в папке лог-файлов на сервере.
Сколько было ошибок передачи данных по радио-каналу? За 5 месяцев зарегистрировано 8 ошибок, когда получено сообщение неправильного размера и 25 ошибок неверного CRC. В обеих случаях нельзя напрямую сказать, с каким датчиком были проблемы, так как пакет данных в этом случае полностью поврежден. Так как сетевой контроллер во всех этих случаях прием данных не подтверждает, то датчик должен высылать данные по новой, что в большинстве случаев эти ошибки исправляет.
А вот сводная таблица по работе датчиков за 5 месяцев.
| Этаж | Датчик | Количество Событий |
Потерянных Событий |
Напряжение Батареи |
Медиана Мощности Сигнала |
| 1 | 10 | 105 | 0 | 3.1 | -66 |
| 1 | 11 | 52 | 0 | 3.3 | -70 |
| 1 | 12 | 122 | 0 | 3.3 | -61 |
| 1 | 13 | 89 | 0 | 3.3 | -74 |
| 1 | 14 | 2573 | 0 | 3.3 | -68 |
| 1 | 15 | 261 | 0 | 3.3 | -60 |
| 1 | 16 | 543 | 2 | 3.3 | -70 |
| 1 | 17 | 156 | 2 | 3.3 | -74 |
| 1 | 18 | 177 | 2 | 3.2 | -68 |
| 1 | 19 | 384 | 3 | 3.3 | -56 |
| 2 | 3 | 368 | 2 | 3.3 | -62 |
| 2 | 4 | 86 | 0 | 3.3 | -71 |
| 2 | 5 | 521 | 2 | 3.3 | -59 |
| 2 | 6 | 115 | 0 | 3.3 | -62 |
| 2 | 7 | 316 | 2 | 3.3 | -63 |
| 2 | 8 | 419 | 1 | 3.3 | -60 |
| 2 | 9 | 89 | 0 | 3.3 | -68 |
Датчик №10 один раз завис. Это, видимо, привело к значительному уменьшению напряжения батарейки. Причина зависания пока не ясна. Зависнет еще раз, придется разбираться.
Датчик №14 установлен на входной двери, именно поэтому у него такое большое количество срабатываний. Но на напряжении батарейки такое большое число срабатываний пока не отразилось.
Потерянное событие — это когда датчик пытался отправить состояние, но сервер его так и не подтвердил. Все потерянные события связаны с тем, что я отключал сервер примерно на полдня для чистки.
В колонке «Медиана мощности сигнала» показано медианное значение RSSI (в dBm), где каждое отдельное значение получено после завершения приема каждого пакета. Датчик с самым лучшим сигналом (№19, -56 dBm) находится на расстоянии 2 метров в прямой видимости от сетевого контроллера, но вот антенна в этом датчике свернута рамкой внутри корпуса. Сам сетевой контроллер находится на первом этаже. Однако сигнал с датчиков второго этажа очень даже неплох. Это связано с тем, что на всех датчиках второго этажа антенна вынесена из корпуса датчика.
Вместо послесловия
С одной стороны я рад, что самостоятельно, в качестве хобби получилось с нуля спроектировать, собрать и запустить систему такого уровня. И еще больше рад, что она работает лучше «фирменной» системы, базирующейся на хайповой технологии zWave. Также есть куда развивать и улучшать эту систему. Меня только гложут небольшие сомнения. А именно, что человек без профильного электротехнического образования собирает на коленке нечто, что работает надежнее фирменных продуктов известных в узких кругах IOT-брендов. Наверное, прогресс свернул куда-то не туда.
Комментарии (58)
MAXXL
04.01.2020 23:27А какие датчики были изначально? У меня стоят Fibaro zWave на открытие дверей и окон. За 5 лет один раз поменял батарейку.
mkulesh Автор
05.01.2020 00:00Датчики фирмы Vision, модель VIS_ZD2102. Контроллер — Aeon Labs Z-Stick Gen5. Я, когда их покупал, тоже читал про устройства zWave, которые работают хотя бы год от одной батарейки. Но в моем случае это была какая-то катастрофа. Самые дальние датчики переставали работать через 2 или 3 месяца. Остальные — примерно через полгода. Наверное, сильно зависит от конкретного производителя.
MAXXL
05.01.2020 00:05Vision у меня есть датчик движения/освещенности/температуры. Вот он тоже батарейки жрет как не в себя. Похоже у этого производителя проблемы с ПО или железом, так как датчики движения от других фирм в таком жоре не замечены.
aivs
05.01.2020 00:19Очень странная история. Человек, который может разработать беспроводное устройство для умного дома, не смог прочитать инструкцию к Z-Wave датчику и поменять время пробуждения.
Севшая батарейка в Z-Wave датчике думаю, была лишь предлогом, чтобы разработать свое решение.
Результат несомненно отличный, работа проведена колоссальная. Но лично я все же для охранки выбрал бы проверенные годами датчики, тот же Z-Wave, Jablotron, Ajax, Enocean и др.
deepform
05.01.2020 00:26Судя по опыту Ajax вне конкуренции в системах охранной сигнализации.Как и в плане надежности, так и "прожорливости"
mkulesh Автор
05.01.2020 11:36Чтение инструкции к Z-Wave датчику не помогло, к сожалению. В доме оказалось 3 места, где сигнал от датчика доходил до контроллера очень условно — даже на абсоютно свежих батарйках могло быть до 25% потерь, что неприемлемо. Устанвка дополнительных zWave повторителей в эти места не помогла. Поэтому подстройку времени пробуждения я даже серьезно и не рассматривал.
aivs
05.01.2020 12:09Если датчик ни с первого раза добивает до контроллера, то он остается в пробужденном состоянии, чтобы сделать 3 попытки отправки. Если контроллер не отправит датчик спать, то тот может быть в эфире и 20 секунд. Z-Wave чип потребляет примерно 25 мА в этом режиме. Батарейка емкостью 750 мАч. 750/25 = 30 часов, 30*3600/20/24= 225 дней может проработать от батарейки.
Частота пробуждения очень сильно влияет на время жизни батареек. Контроллер, который не умеет правильно общаться с датчиками быстро может разрядить батарейку. И возможно проблема не только в датчиках, но и в стике была.
buratino
05.01.2020 12:05Очень странная история.
только по прочтении этого коммента понял, что речь об охранной сигнализации
klirichek
05.01.2020 19:30z-wave просто сделан с заделом на универсальность.
mesh-сеть; достаточно незагруженный диапазон; ограниченная протоколом скважность 1%. Секурность.
Но очень много ограничений, во многом из-за всех этих требований. Поэтому вполне норм, что в конкретном частном случае "велосипед" оказался лучше. Но вот запустите туда хацкера со сниффером 433МГц и глушилкой — и велосипед легко обрастёт ssl-слоем и разными baypass-примочками. Получится в итоге прототип z-wave.
Последний (не прототип, а сам протокол), к слову, зачастую работает ОЧЕНЬ хреново. Он проприетарный, вендоры не особо шевелятся устранять разные проблемы, а открытые решения ( Open-zWave ) работают вообще, порой, погано (с полгода назад я каждую неделю заново строил больше половины сети, добавляя внезапно "отвалившиеся" девайсы). Но всё же в целом какая-то предсказуемость есть. Дверной замок не просто светит в сеть "ручку" открыть/закрыть, а делает это секурно, так что банальным сниффером снаружи перехваченный сигнал расшифровать пока непросто. Разные не сильно важные выключатели тоже, не всегда доставляют свой пакет даже через mesh, но всё же через пень-колоду оно долетает. Но всё это совсем никак не зависит ни от количества wifi-точек в доме, ни от количества припаркованных машин на сигналке во дворе. Хоть какая-то стабильность :)
aivs
05.01.2020 23:25Ни что не совершенно. Даже в проводной сети knx команды могут доходить с задержкой в секунды.
FGV
05.01.2020 07:18общее потребление в режиме сна должно быть в районе 0.5 ?A
А сколько ест в режиме передачи? и какова его длительность?mkulesh Автор
05.01.2020 11:31В режиме передачи я померять не смог, так как сама передача много меньше секунды. Поэтому ориентируюсь на паспортные значения RFM69 — от 16 до 130 mA в зависимости от режима и мощности. Но RFM69 хорошо в этом плане оптимизирован — всю подготовку (буферизациу) передаваемого пакета можно выполнить в Standby моде (1.5 mA), запутить передатчмк по готовности и сразу выключить по окончании передачи. Плюс я сильно оптимизировал потребление микроконтроллера (низкая частота, тактирование только нужной перифирии, подтяжка портов)
EddyEm
05.01.2020 10:59-1За стмку вместо абдурины — однозначный плюс. За кал — однозначный минус!
mkulesh Автор
05.01.2020 11:38А что означает сокращение "КАЛ"?
EddyEm
05.01.2020 11:41hal, понятное дело. На любом форуме по радиоэлектронике можно наткнуться еще на «калокуб» — это вообще дикое извращение: когда код на хале генерируется при помощи «куба». Для использования такое однозначно не годится. Код получается неподдерживаемым, я уж не говорю о том, что в хале огромное количество уже найденных ошибок и неизвестно, сколько еще не обнаруженных.
gudvinr
05.01.2020 21:07+2А какие есть альтернативы, в которых нет ошибок, и при этом они позволяют начать работать без ручной генерации обвязки?
Мне, например, известна только библиотека libopencm3, которая даже адекватной системы версионирования релизов не имеет. Лицензируется под GLP/LGPL, что не слишком удобно для коммерческих проектов. Сооветствует ли MISRA-C? Не известно, а это для компаний, особенно крупных, может быть важно. А для хобби-проектов, в сравнении с инструментами ST, там документации код наплакал.
CubeMX можно скачать с оффсайта, быстро накликать конфигурацию и начать работать. Если ты не супермегаджедай разработки для микроконтроллеров — это простой и адекватный способ сделать хоть что-то. Откуда такая радикальная неприязнь к тому, чем пользуются другие? Не нравится — не пользуйтесь и мимо проходите.
EddyEm
05.01.2020 21:57-2Только код, написанный собственными руками.
Opencm3 я поначалу использовал, но когда в очередной раз поломали апи (да и намучился с тормозами и оверхедом), понял, что нельзя пользоваться всякой сторонней дрянью.
Но вантузоиды-абдуринщики видят мир иначе. Ну и черт с вами.gudvinr
06.01.2020 00:22+2То есть, только хардкор, а если ты не порвал задницу, читая мануалы и собирая свой хал фактически (который не факт что лучше будет), то хоббистской разработкой заниматься нельзя?
Не всем мазохизм доставляет удовольствие, тем более бесплатно.EddyEm
06.01.2020 11:45-3Ну, если хочется оставаться дебилом и не развиваться — пожалуйста! На все ваша воля.
Anidal
05.01.2020 11:10хм. Вижу сразу несколько проблем:
1. Батарейки. Их надо менять, пусть и редко. А заряд батарейки передаётся только если открыть окно. В нашем климате 6 месяцев окна не открывают :)
2. Если перерезать провод — это уже проникновение, то запустить 20Вт глушилку на 433МГц и отключить все датчики от систему контроля — можно и со стоянки у дома. Учитывая что фонового обмена с датчиками нет — то выноси весь дом…klirichek
05.01.2020 19:19а где тут вообще в статье речь про секурность?
Открытый протокол (ну как… security-by-obscurity, но вот статья вышла — и obscurity осталась только в гео-координатах).
- 433 мГц далеко не пуст. Начиная с банальных автомобильных сигналок, и заканчивая каждым первым термометром с Али с выносным датчиком. Не wifi 2.4ГГц, конечно но всё же...
Amor-roma
05.01.2020 11:11Интересный проект, уверен что можно дешевле, проще и миниатюрнее!
Связка, из CC1310 (TI микроконтроллер с интегрированым приемопередатчиком в субгигарцевом диапазоне, 315-866 МГц), датчик температуры-влажности SHT30 или HTU20D, батарея CR-2032 (все прекрасно вмещается на плате размером 30х30мм, толщина платы вместе с батареей 5.5мм, в зависимости от дизайна корпуса габаритные размеры от 34х34х7.5мм)
Отправная точка для разработки, TIDA-00484 (оценочная плата датчика температуры влажности, заявленный срок службы от одной батареи 10 лет)
Оценочная цена 4.5$ в зависимости от жадности поставщиков.
sav1812
05.01.2020 11:33Датчик №10 один раз завис. Это, видимо, привело к значительному уменьшению напряжения батарейки.
А watchdog в контроллерах датчиков не используется?mkulesh Автор
05.01.2020 11:40Пока нет, но по хорошему нужно добавить. Когда я писал, что буду разбираться, если еще раз зависнет, то именно это и имелось ввиду. Проект же чисто хобишный, для себя, поэтому так глубоко в тему надежности пока не стал залазить.
Serge78rus
05.01.2020 13:39Поскольку в дежурном режиме у Вас контроллер находится в состоянии standby, то задействовать watchdog будет не так уж и тривиально.
Кстати, вполне вероятной причиной зависания может быть коммутация питания радиомодуля ключем — при включении питания радиомодуля у Вас разряженный блокировочный конденсатор 0.1 мкФ напрямую подключается к источнику питания, что вызывает как просадку питания, так и иголки на шине земли.
sav1812
06.01.2020 02:49+2Не «по хорошему» — по любому. :)
Контроль питания и собственной работоспособности устройства — это не «глубоко в тему», это фундамент любой подобной «темы».
Watchdog таймер, brownout detection, и т.п — всё это просто обязано быть, особенно в устройствах с автономным питанием. Иначе разряд батареи, окисление контактов и прочие «сопутствующие удобства» сведут работоспособность ваших устройств на нет.
К слову, тут рекомендовали герконы в качестве составной части «средства Макропулоса». Так вот, у герконов было, по крайней мере, такое неприятное свойство: их контакты «залипали» при рабочих токах ниже определённого порога, и «приводить в чувство» такие датчики приходилось методом физического ударного воздействия. А токи, гарантировавшие отсутствие этого эффекта, были порядка единиц-десятков миллиампер. Не для батарейного питания, прямо вам скажу.
И да, присоединюсь к отрицательным мнениям о применении радиоканала. Везде, где есть такая возможность, лучше применять провода. Грамотно спроектированная и проложенная проводная линия связи и питания гораздо меньше подвержена помехам, чем радиоканал. ;) :))
Любой радиоканал с любым, самым «надёжным» протоколом обмена и шифрованием «давится», при наличии «интересантов», просто «на раз» и, в итоге, устройство охраны и сигнализации нередко просто отключается его владельцем за его «глючность», «ненадёжность», и т.а.
Так что — экранированная витая пара в металлической, правильно заземлённой трубе (помним о грозозащите!) — «наше всё!». С резервированием — двукратным, хотя бы… ;)
Да, это дороже. Но разве дом, охраняемый Вашей сигнализацией, не дороже её самой на порядки?..
Kudesnick33
05.01.2020 12:16Смею возразить по поводу меньшей надёжности и трудозатратности перехода на МК с аппаратный USB. HAL тем и хорош, что позволяет портировать код между разными контроллерами. Сделать один проект под несколько СТМок — не проблема. А наличие готовых либ для работы с USB позволяет для организации виртуального COM-порта затратить усилий даже меньше, чем требуется для запуска аппаратного USART. Как только я это осознал — жизнь стала гораздо веселее. А плюсом вы получаете возможность переконфигурировать USB для всяких плюшек, типа эмуляции флехи для обновления прошивки, добавления второго виртуального COM или ещё какой полезной побрякушки. Аппаратный же мост ничем кроме моста стать не сможет.
monah_tuk
05.01.2020 18:30RFM умеер шифровать посылки, вы использовали эту возможность?
mkulesh Автор
05.01.2020 22:37Да, RFM поддерживает AES-128. Если шифрование включено, есть незначительные огранчения на длину пакета, но для меня они были не критичными. Шифрование активируется очень легко, я с ним поигрался, но не стал делать за ненадобностью.
ntfs1984
05.01.2020 19:11Ого. Мсье однозначно знает толк в извращениях.
http://arduino.ua/prod247-radioydlinitel-315mgc-ot-elecrow — приемник-передатчик на 315 МГц, питающийся от 3В-12В. На приемнике выдается логическая единица, когда передатчик включен — 1.3 бакса
http://arduino.ua/prod2988-gerkon-2-kontaktnii — геркон — 0.38 бакса
http://arduino.ua/prod1774-neodimovii-magnit-15x8h2mm-pryamoygolnii — магнит — 0.30 бакса
http://arduino.ua/prod1774-neodimovii-magnit-15x8h2mm-pryamoygolnii — крона — 1.38 бакса
Стоимость датчика составила 3.36 бакса. Схема подключения — до ужаса примитивная. Батарейка подключена к передатчику, в разрыв включен геркон. При открытии окна, геркон смыкается, передатчик включается. На приемнике появляется логическая единица. Все.
На приемной стороне можно использовать что угодно, способное улавливать логическую единицу. Хоть релейный модуль с пароходным гудком.
Ну, можно Ардуинку Mini или Nano, ко входам которой подключены эти миниатюрные приемники. Или Малинку.
Сэр, это же система безопасности. Нельзя ее избыточно наворачивать. Любой нежный чувствительный модуль, вышедший из строя — выводит из строя всю систему. Идеальнее всего использовать вообще провода и механический контакт. Если использовать радио — то никаких 433, 800, 2.4, 5 и прочая, а только НЕСТАНДАРТНЫЕ, которых нет в стандартных глушилках.
EddyEm
05.01.2020 19:45На практике это проверял? Про манчестерский код вообще слышал?
Не будет такое работать.
Вот если к этому радиомодулю добавить STM8L за 20-30 рублей, то уже можно жить.
Кстати, если все железяки брать в количестве штук по 100 на али, то будет намного дешевле.
P.S. Как вариант — на 555-й сделать генератор меандра и пусть это по радиомодулю передается. А в случае размыкания геркона частота меняется. В итоге приемник хотя бы сможет это детектировать.ntfs1984
05.01.2020 23:04Проверял разумеется. Такое вполне себе прекрасно работает с небольшим дополнением.
Там даже если наушник подключить к приемнику — слышна и несущая (белый шум), щелчок, и тишина когда передатчик включается.
Повторюсь, это не теория, это практика.
Впрочем это все для поиграться и не более того. Соглашусь с той частью где радиомодули — зло. К этому приходишь рано или поздно на своем опыте, после первого же сбоя который стоил хоть немного денег. Не надо никаких витых пар, никакого питания, никаких модулей, никаких CAN-шин. Два проводка к геркону с одной стороны, эти же два проводка на любой GPIO с другой стороны. И все. Остальное — избыточно и чревато.
Serge78rus
05.01.2020 23:17Извращением скорее можно назвать попытку противопоставлять нормальному цифровому приемнику простейший сверхрегенаритивный приемник, который используется в предлагаемом Вами «радиоудлиннителе». Уже к концу прошлого века подобные приемники даже у более-менее серьезных моделистов вышли из употребления (правда, до сих пор используются в самых примитивных автосигнализациях, но это, скорее, вопрос к их производителю).
ntfs1984
06.01.2020 00:21Возникает вопрос, зачем двухконтактному датчику вкл\выкл — "нормальный цифровой приемник" ?
Вы серьезно предлагаете подключать один датчик за 30 центов, через навороченное устройство ценой в 9 евро ?)
Ну окей, рядышком стоит NRF24L01 — он еще дешевле, и питается от 3.3В. Суть дела не меняется: оверинжениринг в системах безопасности не нужен, но понимать это начинаешь тогда, когда непосредственно столкнешься с плачевными результатами.
Serge78rus
06.01.2020 00:47Если мы хотим надежности передачи, то в радиоканал придется вкладываться даже несмотря на то, что требуется передаь всего один бит информации. Так что я скорее склонюсь согласиться со второй частью Вашего же комментария чуть выше о нецелесообразности использования радиоканала для подобных целей вообще, если возможна альтернатива в виде проводной связи. Ведь помимо потенциально ненадежного канала передачи, беспроводной датчик вносит и потенциально ненадежный человеческий фактор, который проявляестя в виде своевременной замены источников питания (и что парадоксально — чем больше их срок службы, тем больше вероятность, что эта замена своевременно не будет произведена).
gta2k
07.01.2020 23:01беспроводной датчик вносит и потенциально ненадежный человеческий фактор, который проявляестя в виде своевременной замены источников питания (и что парадоксально — чем больше их срок службы, тем больше вероятность, что эта замена своевременно не будет произведена)
Фактор забывчивости легко решаем. Принимающая сторона знает напряжение батарейки в каждом датчике, и, в случае пороговых значений, может рассылать напоминания через телеграм-бота, простые имейлы или пуш-уведомления в андроид приложении.
Byt
07.01.2020 23:01Мы же умный дом собираем. Цифровой датчик легче модернизировать. Можно шифровать информацию, принимать и ретранслировать удаленные датчики, принимать команды (например, для открытия окна), передавать заряд батареи или температуру воздуха итд…
blind_oracle
05.01.2020 21:43Автору ИМХО просто хотелось помахать паяльником и код пописать.
Давно более или менее стандартны и дешевы Zigbee сенсоры на любой вкус, вроде Xiaomi за 10$.
А в качестве серверного софта есть OpenHAB, который умеет интегрироваться, по моему, вообще с чем угодно. И это де факто опенсурсный стандарт для умного дома.
mkulesh Автор
06.01.2020 15:31Ну почему же только "помахать паяльником и код пописать"? История началась с того, что я установил "более или менее стандартные и дешевые сенсоры", только они случайно назывались zWave, а не Zigbee. Это проприетарное решение не заработало. Уверенности, что заработает другое проприетарное решение, у меня не было. Из комментариев выше я вижу, что есть как качественные, так и не качественные zWave решения. То же самое касается и Zigbee. Чтобы больше не играть в лотерею, я сделал свою открытую платформу, гду полность контроллирую каждый ее аспект (как аппаратный, так и программный). OpenHAB да, хорошее решение. Только слишком избыточное в моем случае.
blind_oracle
06.01.2020 22:48Ну почему же только "помахать паяльником и код пописать"?
Потому что я тоже через это проходил :) Делал всякие считыватели показаний электро- и водо- счетчиков на ESP8266 и прочие компоненты умного дома на коленке. Хотя, как раз в с случае со счетчиками готовых решений особо нет, так что тут думаю колхоз оправдан.
А вот с остальными, стандартными, компонентами как описанные датчики открытия, лампы, розетки и прочее, ИМХО, смысла городить огород нет. Рынок уже хорошо развит и достаточно почитать форумы-отзывы и выбрать себе девайс по душе.
OpenHAB да, хорошее решение. Только слишком избыточное в моем случае.
Ну, для простых действий там ничего городить не надо, по-моему нынче даже можно правила через WebUI рисовать простые, аля If-This-Then-That. Ну и аппетит приходит во время еды, думается просто датчиками открытия окон дело не ограничится...
imdragon
06.01.2020 10:39На продажу планируете?
mkulesh Автор
06.01.2020 10:42Нет, до уровня готового продукта эта система еще не доведена. Да и корпуса я использовал готовые. Но если кто-нибудь захочет довести эту систему до продуктового уровня — милости прошу. Вся документация и исходники открыты, да и сам могу помочь как советом, так и делом.
0lom5zhdovdv
06.01.2020 12:54ESP8266 отлично работает от 3В и сохраняет работоспособность до ~2.4..2.5В
Не берите самые дешевые модули и проблем с уровнем сигнала не будетsav1812
06.01.2020 12:59Автор это уже проходил:
Мой первый прототип датчиков базировался на ESP8266. Контроллер — на базе моей платы, о которой я уже писал на Хабре. В качестве прототипа система даже заработала, но пришлось от нее отказаться по двум причинам. Первая причина та же самая — в доме оказались закутки с очень низким уровнем сигнала WiFi, что привело к очень большому времени активации ESP8266 при пробуждении и, как следствие, к сильному разряду батарейки. Хотя я допускаю, что просто не умею правильно готовить эту самую ESP8266 (статьи вроде этой подтверждают такой тезис). Но вторая причина оказалась более серьезной. Так как я решил оставить не только корпус, но и батарейный отсек, то был ограничен батарейкой CR123A, которая на 3.0 вольта. То есть цена и сложность датчика возрастала за счет повышающего DC/DC преобразователя. Хотя и по этой теме на Хабре есть замечательная статья. Но, так или иначе, эти две причины перевесили и ESP8266 я отбросил.
0lom5zhdovdv
06.01.2020 13:13А вы точно прочли что я написал?
В первой строке — о несостоятельности второй причины, и и во второй строке — о несостоятельности первойsav1812
06.01.2020 14:03Точно. :)
И Ваши доводы не очень убедительны, на мой взгляд.
Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP, да и работоспособность в заданном диапазоне питания тоже не гарантирована в каждом конкретном случае.
Вдобавок, и то, и другое зависит как от характеристик конкретной партии модулей, так и от «характеристик и свойств» разработчика. :)
0lom5zhdovdv
06.01.2020 14:12И Ваши доводы не очень убедительны, на мой взгляд.
Я говорю как разработчик датчика на esp, который питается в трех версиях от трех вольт без степ-апа от элементов АА/ААА/CR123.
Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP
В дешевых версиях находил токопроводящий неотмытый флюс, тогда у esp ток сна с даташитных 20-30мкА доходил до 200мкА и существенно затуплялась ВЧ часть. Мною была найдена корреляция между током сна и дальнобойностью радиочасти. Лучшие модули во сне потребляют 12мкА, видимо сказывается культура производства.
да и работоспособность в заданном диапазоне питания тоже не гарантирована
Operating Voltage 2.5 V ~ 3.6 V из даташита.
В реальности нормальный модуль работает и от 2,4В. Когда CR123 дойдет до 2,4 — это будет уже полный разряд. Степ-ап не нужен, не смотря на убеждения автора.
sav1812
06.01.2020 15:03Я говорю как разработчик датчика на esp, который питается в трех версиях от трех вольт без степ-апа от элементов АА/ААА/CR123.
А я говорю, как человек, легко «убивавший» такие вот, «стабильно работавшие», устройства небольшим изменением внешних условий при испытаниях. :)
В дешевых версиях находил токопроводящий неотмытый флюс, тогда у esp ток сна с даташитных 20-30мкА доходил до 200мкА и существенно затуплялась ВЧ часть. Мною была найдена корреляция между током сна и дальнобойностью радиочасти. Лучшие модули во сне потребляют 12мкА, видимо сказывается культура производства.
Культура производства — это хорошо, даже очень. Я только «за!». :)
Но это никак не опровергает моего тезиса о том, что «Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP», потому как помимо качества элементной базы и сборки модулей, есть и много других факторов, влияющих на уровень сигнала в ближних окрестностях каждого конкретного устройства.
Вы же не знаете местных условий в доме автора, а они могут быть достаточно… гмм… специфическими, скажем так. При чём тут цена и о чём тут, в итоге, спорить? :)
Operating Voltage 2.5 V ~ 3.6 V из даташита.
В реальности нормальный модуль работает и от 2,4В.
В какой именно из бесконечного множества реальностей? ;)
При каком качестве питания — батарей, в том числе? В каком диапазоне температур и влажностей, в какой электромагнитной обстановке?
Степ-ап не нужен, не смотря на убеждения автора.
А это уже решает разработчик.
Правда, у автора, судя по всему, опыта в данной области не особо в достатке, раз уж «собаку не отвязал» (watchdog timer) и датчики «зависают». «Детская» ошибка, в общем-то…
Хотя платы красивые… ;) :))mkulesh Автор
06.01.2020 15:24Тут Вы очень точно подметили, что опыта в данной области у меня нет :) Я по образованию инженер-математик, и работаю в области, очень далекой от электроники. Учусь в том числе и на хабровских статьях. В последние несколько лет вижу, что на Хабре есть небольшая оппозиция ESP8266. Я уже использовал ее в нескольких проектах и этот модуль мне нравится. У меня уже скоро как год работают часы в связке STM32 + ESP8266, и работают стабильно. Но в данном случае ESP8266 не завелся. Было ограничение на размер, так как нужно было втиснутся в имеющийся корпус. Отсюда ограничение на доступные модули. И те, которые я попробовал, в моих условиях работали нестабильно. А вот RFM69 завелся сразу. Может, поэтому и получилось сделать плату красивой, так как проблем с компонентами не было и было больше времи для дизайна.
dalamber_sign
06.01.2020 18:54STM32 + ESP8266
Можно посмотреть в сторону RTL8710AF — два в одном и wi-fi и достаточно продвинутый МК. Пишут, что более энергоэффективный чем продукция ESP.FGV
07.01.2020 02:01Можно посмотреть в сторону RTL8710AF
Хм, а вот это уже интересно :) Ценник на али ~ 230р за модуль, не смертельно, но в два раза дороже чем esp8266.
Глянул даташит… и различий (кроме платформы — у RTL — arm а не L106) особых не увидел, плюсминус примерно одно и тоже, хотя esp8266 все же более нафарширован периферией.dalamber_sign
07.01.2020 11:13esp8266 все же более нафарширован периферией.
Точно речь про ESP8266? В чем состоит её нафаршированность периферией?
плюсминус примерно одно и тоже
RTL меньше ест в режиме пониженного потребления, чем ESP при отключении всего кроме LDO и RTC таймера
esp8266.ru/forum/threads/zamer-potreblenija-rtl00-v1-0.1595/page-2#post-52980FGV
07.01.2020 12:18Точно речь про ESP8266? В чем состоит её нафаршированность периферией?
1. Secure Digital Input/Output Interface (SDIO)
2. Serial Peripheral Interface (SPI/HSPI)
3. I2S Interface
4. ESP8266EX has two UART interfaces UART0 and UART1
5. Pulse-Width Modulation (PWM) — ESP8266EX has four PWM output interfaces
6. ESP8266EX currently supports one infrared remote control interface
7. ESP8266EX is embedded with a 10-bit precision SAR ADC
RTL меньше ест в режиме пониженного потребления, чем ESP при отключении всего кроме LDO и RTC таймера...
Форумы это хорошо, однако больше склонен верить цифрам из даташитов.
EddyEm
07.01.2020 11:44Теоретически, для ESP32 никаких внешних МК не нужно. Однако, к сожалению, часть SDK ESP32 — проприетарные закрытые блобы, поэтому пока их не отреверсят, пользоваться полноценно этими железками нельзя будет.
Вот ESP8266 вроде бы уже полноценно отреверсили, и можно с ними вполне удобно работать.
Alex_ME
07.01.2020 12:30Работал что с ESP, что с RTL на уровне практически "Hello World", но показалось, что у ESP куда более человекоориентированная экосистема разработки
- Наличие доступных и дешевых отладочных плат, вроде тех же NodeMCU или WEMOS
- Портированное Arduino. Хотя, оно есть, вроде, и на RTL, правда, я не являюсь фанатом всего этого, а от Arduino SDK для ESP я плевался
- Очень приятный официальный RTOS SDK для ESP, с Make, CMake, menuconfig. Удобно настроить, можно собирать GNU-тулчейном. Официальный SDK для RTL подразумевает IAR, что сразу большущий минус. Есть всякие поделия для GNU тулчейна, вроде тех, что пилятся на форуме esp8266.ru, но все ж.
Но на RTL я давно не смотрел.
0lom5zhdovdv
06.01.2020 16:38А я говорю, как человек, легко «убивавший» такие вот, «стабильно работавшие», устройства небольшим изменением внешних условий при испытаниях. :)
Не спорю, но в моих условиях — годами работает «без единого разрыва», как у Уральского Антохи.
есть и много других факторов, влияющих на уровень сигнала в ближних окрестностях каждого конкретного устройства.
Вы уводите контекст в сторону. Зачем? Если с сигнал/шумом у человека плохо, это одно. А если с радиочастью esp, то это другое. Мой совет, который я дал не Вам, а ТС-у на основе моего опыта: испытать другие модули вы отвергли и начали отводить в сторону радиообстановки. Зачем? И по каким признакам Вы решили, что виновата радиообстановка, а не ущербные модули?
При чём тут цена
Повторяюсь ещё раз: по моим данным более дешевые модули esp имеют проблемы с радиочастью. Как мне выразиться, чтобы быть услышанным?
и о чём тут, в итоге, спорить?
Вот и мне не понятно? Зачем спорить? Я дал совет ТС-у а не Вам, а спорите Вы…
В какой именно из бесконечного множества реальностей? ;)
Философ?
При каком качестве питания — батарей, в том числе? В каком диапазоне температур и влажностей, в какой электромагнитной обстановке?
Деградировавшие до 0,5Ом внутреннего сопротивления две АА батареи, которые при 70мА просаживались до 2,4В устойчиво питали датчик ещё 3,5 месяца. В домашнем диапазоне температур +35..+21С и влажности от 90% до 25% в жестокой электромагнитной обстановке на 2,4ГГц в условиях деревянного каркасного, многоквартирного дома.
От самого начала и до того, как батарейки потекли прошел 1 год и 3 месяца и 8900 срабатываний. Батарейки всё время были припаяны, а esp курсировала между Deep sleep и активностью без зависаний. Просто в одно утро датчик не вышел на связь и всё…
Goron_Dekar
Я думаю, что тут дело не в прогрессе. От человека всегда зависит не меньше, чем от образования. Целеустремлённость и мотивированность.
mdn-tech
Как раз в прогрессе. В погоне за деньгами всем стало всё равно, что за продукт на выходе.
Кошмар насчёт 10 сервисов чтобы включить лампочку становится явью.
Желаю автору успехов. IoT таким и должен быть.