Программирование микроконтроллеров
Умный дом
DIY или Сделай сам
Комментарии 74
+1
Меня только гложут небольшие сомнения. А именно, что человек без профильного электротехнического образования собирает на коленке нечто, что работает надежнее фирменных продуктов известных в узких кругах IOT-брендов. Наверное, прогресс свернул куда-то не туда.

Я думаю, что тут дело не в прогрессе. От человека всегда зависит не меньше, чем от образования. Целеустремлённость и мотивированность.
+3
Как раз в прогрессе. В погоне за деньгами всем стало всё равно, что за продукт на выходе.
Кошмар насчёт 10 сервисов чтобы включить лампочку становится явью.
Желаю автору успехов. IoT таким и должен быть.
0
А какие датчики были изначально? У меня стоят Fibaro zWave на открытие дверей и окон. За 5 лет один раз поменял батарейку.
0

Датчики фирмы Vision, модель VIS_ZD2102. Контроллер — Aeon Labs Z-Stick Gen5. Я, когда их покупал, тоже читал про устройства zWave, которые работают хотя бы год от одной батарейки. Но в моем случае это была какая-то катастрофа. Самые дальние датчики переставали работать через 2 или 3 месяца. Остальные — примерно через полгода. Наверное, сильно зависит от конкретного производителя.

0
Vision у меня есть датчик движения/освещенности/температуры. Вот он тоже батарейки жрет как не в себя. Похоже у этого производителя проблемы с ПО или железом, так как датчики движения от других фирм в таком жоре не замечены.
0
Очень странная история. Человек, который может разработать беспроводное устройство для умного дома, не смог прочитать инструкцию к Z-Wave датчику и поменять время пробуждения.
Севшая батарейка в Z-Wave датчике думаю, была лишь предлогом, чтобы разработать свое решение.
Результат несомненно отличный, работа проведена колоссальная. Но лично я все же для охранки выбрал бы проверенные годами датчики, тот же Z-Wave, Jablotron, Ajax, Enocean и др.
0

Судя по опыту Ajax вне конкуренции в системах охранной сигнализации.Как и в плане надежности, так и "прожорливости"

0

Чтение инструкции к Z-Wave датчику не помогло, к сожалению. В доме оказалось 3 места, где сигнал от датчика доходил до контроллера очень условно — даже на абсоютно свежих батарйках могло быть до 25% потерь, что неприемлемо. Устанвка дополнительных zWave повторителей в эти места не помогла. Поэтому подстройку времени пробуждения я даже серьезно и не рассматривал.

0

Если датчик ни с первого раза добивает до контроллера, то он остается в пробужденном состоянии, чтобы сделать 3 попытки отправки. Если контроллер не отправит датчик спать, то тот может быть в эфире и 20 секунд. Z-Wave чип потребляет примерно 25 мА в этом режиме. Батарейка емкостью 750 мАч. 750/25 = 30 часов, 30*3600/20/24= 225 дней может проработать от батарейки.
Частота пробуждения очень сильно влияет на время жизни батареек. Контроллер, который не умеет правильно общаться с датчиками быстро может разрядить батарейку. И возможно проблема не только в датчиках, но и в стике была.

0
Очень странная история.

только по прочтении этого коммента понял, что речь об охранной сигнализации
+1

z-wave просто сделан с заделом на универсальность.
mesh-сеть; достаточно незагруженный диапазон; ограниченная протоколом скважность 1%. Секурность.
Но очень много ограничений, во многом из-за всех этих требований. Поэтому вполне норм, что в конкретном частном случае "велосипед" оказался лучше. Но вот запустите туда хацкера со сниффером 433МГц и глушилкой — и велосипед легко обрастёт ssl-слоем и разными baypass-примочками. Получится в итоге прототип z-wave.


Последний (не прототип, а сам протокол), к слову, зачастую работает ОЧЕНЬ хреново. Он проприетарный, вендоры не особо шевелятся устранять разные проблемы, а открытые решения ( Open-zWave ) работают вообще, порой, погано (с полгода назад я каждую неделю заново строил больше половины сети, добавляя внезапно "отвалившиеся" девайсы). Но всё же в целом какая-то предсказуемость есть. Дверной замок не просто светит в сеть "ручку" открыть/закрыть, а делает это секурно, так что банальным сниффером снаружи перехваченный сигнал расшифровать пока непросто. Разные не сильно важные выключатели тоже, не всегда доставляют свой пакет даже через mesh, но всё же через пень-колоду оно долетает. Но всё это совсем никак не зависит ни от количества wifi-точек в доме, ни от количества припаркованных машин на сигналке во дворе. Хоть какая-то стабильность :)

0

Ни что не совершенно. Даже в проводной сети knx команды могут доходить с задержкой в секунды.

0
общее потребление в режиме сна должно быть в районе 0.5 μA

А сколько ест в режиме передачи? и какова его длительность?
0

В режиме передачи я померять не смог, так как сама передача много меньше секунды. Поэтому ориентируюсь на паспортные значения RFM69 — от 16 до 130 mA в зависимости от режима и мощности. Но RFM69 хорошо в этом плане оптимизирован — всю подготовку (буферизациу) передаваемого пакета можно выполнить в Standby моде (1.5 mA), запутить передатчмк по готовности и сразу выключить по окончании передачи. Плюс я сильно оптимизировал потребление микроконтроллера (низкая частота, тактирование только нужной перифирии, подтяжка портов)

-5
За стмку вместо абдурины — однозначный плюс. За кал — однозначный минус!
-4
hal, понятное дело. На любом форуме по радиоэлектронике можно наткнуться еще на «калокуб» — это вообще дикое извращение: когда код на хале генерируется при помощи «куба». Для использования такое однозначно не годится. Код получается неподдерживаемым, я уж не говорю о том, что в хале огромное количество уже найденных ошибок и неизвестно, сколько еще не обнаруженных.
+2

А какие есть альтернативы, в которых нет ошибок, и при этом они позволяют начать работать без ручной генерации обвязки?


Мне, например, известна только библиотека libopencm3, которая даже адекватной системы версионирования релизов не имеет. Лицензируется под GLP/LGPL, что не слишком удобно для коммерческих проектов. Сооветствует ли MISRA-C? Не известно, а это для компаний, особенно крупных, может быть важно. А для хобби-проектов, в сравнении с инструментами ST, там документации код наплакал.


CubeMX можно скачать с оффсайта, быстро накликать конфигурацию и начать работать. Если ты не супермегаджедай разработки для микроконтроллеров — это простой и адекватный способ сделать хоть что-то. Откуда такая радикальная неприязнь к тому, чем пользуются другие? Не нравится — не пользуйтесь и мимо проходите.

-2
Только код, написанный собственными руками.
Opencm3 я поначалу использовал, но когда в очередной раз поломали апи (да и намучился с тормозами и оверхедом), понял, что нельзя пользоваться всякой сторонней дрянью.
Но вантузоиды-абдуринщики видят мир иначе. Ну и черт с вами.
+3

То есть, только хардкор, а если ты не порвал задницу, читая мануалы и собирая свой хал фактически (который не факт что лучше будет), то хоббистской разработкой заниматься нельзя?
Не всем мазохизм доставляет удовольствие, тем более бесплатно.

-4
Ну, если хочется оставаться дебилом и не развиваться — пожалуйста! На все ваша воля.
0
хм. Вижу сразу несколько проблем:
1. Батарейки. Их надо менять, пусть и редко. А заряд батарейки передаётся только если открыть окно. В нашем климате 6 месяцев окна не открывают :)
2. Если перерезать провод — это уже проникновение, то запустить 20Вт глушилку на 433МГц и отключить все датчики от систему контроля — можно и со стоянки у дома. Учитывая что фонового обмена с датчиками нет — то выноси весь дом…
0

а где тут вообще в статье речь про секурность?
Открытый протокол (ну как… security-by-obscurity, но вот статья вышла — и obscurity осталась только в гео-координатах).


  • 433 мГц далеко не пуст. Начиная с банальных автомобильных сигналок, и заканчивая каждым первым термометром с Али с выносным датчиком. Не wifi 2.4ГГц, конечно но всё же...
0
Ну так датчики для сигнализации должны ж защищать. А основная функция отсутствует. Не понимаю зачем делать систему, которая не работоспособна. Потестить схемотехнику и протокол?! — можно было бы на вентиляции в туалете — даже если кто взломает то ничего не произойдёт.
0
Ну так датчики для сигнализации должны ж защищать.

Защищать должны армия, полиция, Росгвардия и прочие, специально уполномоченные, органы.

А датчики сигнализации, как и прочие-любые датчики, должны только выдавать достоверное значение соответствующей физической величины.
Всё. :)
0
Так не дают же. Глушилка (считайте естественные помехи для датчика сигнализации) не даст, а голова и не поймет что связь с датчиком потеряна.
0
Ну, датчики-то данные выдают. А если канал «задавлен» — не их вина… :)

А чтобы «голова» всё «понимала», протокол обмена нужен соответствующий, с двусторонним обменом.

Герконы с ртутным контактом не залипают.

А такие ещё производятся? И если да, то где можно купить?
+1

Интересный проект, уверен что можно дешевле, проще и миниатюрнее!
Связка, из CC1310 (TI микроконтроллер с интегрированым приемопередатчиком в субгигарцевом диапазоне, 315-866 МГц), датчик температуры-влажности SHT30 или HTU20D, батарея CR-2032 (все прекрасно вмещается на плате размером 30х30мм, толщина платы вместе с батареей 5.5мм, в зависимости от дизайна корпуса габаритные размеры от 34х34х7.5мм)
Отправная точка для разработки, TIDA-00484 (оценочная плата датчика температуры влажности, заявленный срок службы от одной батареи 10 лет)
Оценочная цена 4.5$ в зависимости от жадности поставщиков.

0
Датчик №10 один раз завис. Это, видимо, привело к значительному уменьшению напряжения батарейки.

А watchdog в контроллерах датчиков не используется?
0

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

+1
Поскольку в дежурном режиме у Вас контроллер находится в состоянии standby, то задействовать watchdog будет не так уж и тривиально.

Кстати, вполне вероятной причиной зависания может быть коммутация питания радиомодуля ключем — при включении питания радиомодуля у Вас разряженный блокировочный конденсатор 0.1 мкФ напрямую подключается к источнику питания, что вызывает как просадку питания, так и иголки на шине земли.
+2
Не «по хорошему» — по любому. :)
Контроль питания и собственной работоспособности устройства — это не «глубоко в тему», это фундамент любой подобной «темы».

Watchdog таймер, brownout detection, и т.п — всё это просто обязано быть, особенно в устройствах с автономным питанием. Иначе разряд батареи, окисление контактов и прочие «сопутствующие удобства» сведут работоспособность ваших устройств на нет.

К слову, тут рекомендовали герконы в качестве составной части «средства Макропулоса». Так вот, у герконов было, по крайней мере, такое неприятное свойство: их контакты «залипали» при рабочих токах ниже определённого порога, и «приводить в чувство» такие датчики приходилось методом физического ударного воздействия. А токи, гарантировавшие отсутствие этого эффекта, были порядка единиц-десятков миллиампер. Не для батарейного питания, прямо вам скажу.

И да, присоединюсь к отрицательным мнениям о применении радиоканала. Везде, где есть такая возможность, лучше применять провода. Грамотно спроектированная и проложенная проводная линия связи и питания гораздо меньше подвержена помехам, чем радиоканал. ;) :))
Любой радиоканал с любым, самым «надёжным» протоколом обмена и шифрованием «давится», при наличии «интересантов», просто «на раз» и, в итоге, устройство охраны и сигнализации нередко просто отключается его владельцем за его «глючность», «ненадёжность», и т.а.

Так что — экранированная витая пара в металлической, правильно заземлённой трубе (помним о грозозащите!) — «наше всё!». С резервированием — двукратным, хотя бы… ;)
Да, это дороже. Но разве дом, охраняемый Вашей сигнализацией, не дороже её самой на порядки?..
+2

Смею возразить по поводу меньшей надёжности и трудозатратности перехода на МК с аппаратный USB. HAL тем и хорош, что позволяет портировать код между разными контроллерами. Сделать один проект под несколько СТМок — не проблема. А наличие готовых либ для работы с USB позволяет для организации виртуального COM-порта затратить усилий даже меньше, чем требуется для запуска аппаратного USART. Как только я это осознал — жизнь стала гораздо веселее. А плюсом вы получаете возможность переконфигурировать USB для всяких плюшек, типа эмуляции флехи для обновления прошивки, добавления второго виртуального COM или ещё какой полезной побрякушки. Аппаратный же мост ничем кроме моста стать не сможет.

0

RFM умеер шифровать посылки, вы использовали эту возможность?

0

Да, RFM поддерживает AES-128. Если шифрование включено, есть незначительные огранчения на длину пакета, но для меня они были не критичными. Шифрование активируется очень легко, я с ним поигрался, но не стал делать за ненадобностью.

-2

Ого. Мсье однозначно знает толк в извращениях.


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 и прочая, а только НЕСТАНДАРТНЫЕ, которых нет в стандартных глушилках.


image

-1
На практике это проверял? Про манчестерский код вообще слышал?
Не будет такое работать.
Вот если к этому радиомодулю добавить STM8L за 20-30 рублей, то уже можно жить.

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

P.S. Как вариант — на 555-й сделать генератор меандра и пусть это по радиомодулю передается. А в случае размыкания геркона частота меняется. В итоге приемник хотя бы сможет это детектировать. Если наоборот сделать — генерировать меандр при размыкании геркона — можно чуть батарейку сэкономить. Но на мой взгляд, в квартире и так достаточно источников энергии. Можно все сделать по-человечески: проложить кабель (витуха из двух пар), по одной паре общаемся по CAN-шине, по второй паре подаем питание. Для такой элементарщины, как датчики на окнах, хватит и стандартной «лапши», как это всегда и делалось.
Радиомодули — зло! И надо искоренять эту любовь к беспроводной связи, засирающую эфир!!!!1111
0

Проверял разумеется. Такое вполне себе прекрасно работает с небольшим дополнением.


Там даже если наушник подключить к приемнику — слышна и несущая (белый шум), щелчок, и тишина когда передатчик включается.


Повторюсь, это не теория, это практика.


Впрочем это все для поиграться и не более того. Соглашусь с той частью где радиомодули — зло. К этому приходишь рано или поздно на своем опыте, после первого же сбоя который стоил хоть немного денег. Не надо никаких витых пар, никакого питания, никаких модулей, никаких CAN-шин. Два проводка к геркону с одной стороны, эти же два проводка на любой GPIO с другой стороны. И все. Остальное — избыточно и чревато.

+1
Извращением скорее можно назвать попытку противопоставлять нормальному цифровому приемнику простейший сверхрегенаритивный приемник, который используется в предлагаемом Вами «радиоудлиннителе». Уже к концу прошлого века подобные приемники даже у более-менее серьезных моделистов вышли из употребления (правда, до сих пор используются в самых примитивных автосигнализациях, но это, скорее, вопрос к их производителю).
0

Возникает вопрос, зачем двухконтактному датчику вкл\выкл — "нормальный цифровой приемник" ?


Вы серьезно предлагаете подключать один датчик за 30 центов, через навороченное устройство ценой в 9 евро ?)


Ну окей, рядышком стоит NRF24L01 — он еще дешевле, и питается от 3.3В. Суть дела не меняется: оверинжениринг в системах безопасности не нужен, но понимать это начинаешь тогда, когда непосредственно столкнешься с плачевными результатами.

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

Фактор забывчивости легко решаем. Принимающая сторона знает напряжение батарейки в каждом датчике, и, в случае пороговых значений, может рассылать напоминания через телеграм-бота, простые имейлы или пуш-уведомления в андроид приложении.
0
Мы же умный дом собираем. Цифровой датчик легче модернизировать. Можно шифровать информацию, принимать и ретранслировать удаленные датчики, принимать команды (например, для открытия окна), передавать заряд батареи или температуру воздуха итд…
0

Автору ИМХО просто хотелось помахать паяльником и код пописать.


Давно более или менее стандартны и дешевы Zigbee сенсоры на любой вкус, вроде Xiaomi за 10$.


А в качестве серверного софта есть OpenHAB, который умеет интегрироваться, по моему, вообще с чем угодно. И это де факто опенсурсный стандарт для умного дома.

+1

Ну почему же только "помахать паяльником и код пописать"? История началась с того, что я установил "более или менее стандартные и дешевые сенсоры", только они случайно назывались zWave, а не Zigbee. Это проприетарное решение не заработало. Уверенности, что заработает другое проприетарное решение, у меня не было. Из комментариев выше я вижу, что есть как качественные, так и не качественные zWave решения. То же самое касается и Zigbee. Чтобы больше не играть в лотерею, я сделал свою открытую платформу, гду полность контроллирую каждый ее аспект (как аппаратный, так и программный). OpenHAB да, хорошее решение. Только слишком избыточное в моем случае.

0
Ну почему же только "помахать паяльником и код пописать"?

Потому что я тоже через это проходил :) Делал всякие считыватели показаний электро- и водо- счетчиков на ESP8266 и прочие компоненты умного дома на коленке. Хотя, как раз в с случае со счетчиками готовых решений особо нет, так что тут думаю колхоз оправдан.


А вот с остальными, стандартными, компонентами как описанные датчики открытия, лампы, розетки и прочее, ИМХО, смысла городить огород нет. Рынок уже хорошо развит и достаточно почитать форумы-отзывы и выбрать себе девайс по душе.


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

Ну, для простых действий там ничего городить не надо, по-моему нынче даже можно правила через WebUI рисовать простые, аля If-This-Then-That. Ну и аппетит приходит во время еды, думается просто датчиками открытия окон дело не ограничится...

+1

Нет, до уровня готового продукта эта система еще не доведена. Да и корпуса я использовал готовые. Но если кто-нибудь захочет довести эту систему до продуктового уровня — милости прошу. Вся документация и исходники открыты, да и сам могу помочь как советом, так и делом.

0
ESP8266 отлично работает от 3В и сохраняет работоспособность до ~2.4..2.5В
Не берите самые дешевые модули и проблем с уровнем сигнала не будет
0
Автор это уже проходил:

Мой первый прототип датчиков базировался на ESP8266. Контроллер — на базе моей платы, о которой я уже писал на Хабре. В качестве прототипа система даже заработала, но пришлось от нее отказаться по двум причинам. Первая причина та же самая — в доме оказались закутки с очень низким уровнем сигнала WiFi, что привело к очень большому времени активации ESP8266 при пробуждении и, как следствие, к сильному разряду батарейки. Хотя я допускаю, что просто не умею правильно готовить эту самую ESP8266 (статьи вроде этой подтверждают такой тезис). Но вторая причина оказалась более серьезной. Так как я решил оставить не только корпус, но и батарейный отсек, то был ограничен батарейкой CR123A, которая на 3.0 вольта. То есть цена и сложность датчика возрастала за счет повышающего DC/DC преобразователя. Хотя и по этой теме на Хабре есть замечательная статья. Но, так или иначе, эти две причины перевесили и ESP8266 я отбросил.
0
А вы точно прочли что я написал?
В первой строке — о несостоятельности второй причины, и и во второй строке — о несостоятельности первой
0
Точно. :)
И Ваши доводы не очень убедительны, на мой взгляд.

Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP, да и работоспособность в заданном диапазоне питания тоже не гарантирована в каждом конкретном случае.

Вдобавок, и то, и другое зависит как от характеристик конкретной партии модулей, так и от «характеристик и свойств» разработчика. :)

0
И Ваши доводы не очень убедительны, на мой взгляд.

Я говорю как разработчик датчика на esp, который питается в трех версиях от трех вольт без степ-апа от элементов АА/ААА/CR123.

Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP

В дешевых версиях находил токопроводящий неотмытый флюс, тогда у esp ток сна с даташитных 20-30мкА доходил до 200мкА и существенно затуплялась ВЧ часть. Мною была найдена корреляция между током сна и дальнобойностью радиочасти. Лучшие модули во сне потребляют 12мкА, видимо сказывается культура производства.

да и работоспособность в заданном диапазоне питания тоже не гарантирована

Operating Voltage 2.5 V ~ 3.6 V из даташита.
В реальности нормальный модуль работает и от 2,4В. Когда CR123 дойдет до 2,4 — это будет уже полный разряд. Степ-ап не нужен, не смотря на убеждения автора.

0
Я говорю как разработчик датчика на esp, который питается в трех версиях от трех вольт без степ-апа от элементов АА/ААА/CR123.

А я говорю, как человек, легко «убивавший» такие вот, «стабильно работавшие», устройства небольшим изменением внешних условий при испытаниях. :)

В дешевых версиях находил токопроводящий неотмытый флюс, тогда у esp ток сна с даташитных 20-30мкА доходил до 200мкА и существенно затуплялась ВЧ часть. Мною была найдена корреляция между током сна и дальнобойностью радиочасти. Лучшие модули во сне потребляют 12мкА, видимо сказывается культура производства.

Культура производства — это хорошо, даже очень. Я только «за!». :)
Но это никак не опровергает моего тезиса о том, что «Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP», потому как помимо качества элементной базы и сборки модулей, есть и много других факторов, влияющих на уровень сигнала в ближних окрестностях каждого конкретного устройства.

Вы же не знаете местных условий в доме автора, а они могут быть достаточно… гмм… специфическими, скажем так. При чём тут цена и о чём тут, в итоге, спорить? :)

Operating Voltage 2.5 V ~ 3.6 V из даташита.
В реальности нормальный модуль работает и от 2,4В.

В какой именно из бесконечного множества реальностей? ;)
При каком качестве питания — батарей, в том числе? В каком диапазоне температур и влажностей, в какой электромагнитной обстановке?

Степ-ап не нужен, не смотря на убеждения автора.

А это уже решает разработчик.
Правда, у автора, судя по всему, опыта в данной области не особо в достатке, раз уж «собаку не отвязал» (watchdog timer) и датчики «зависают». «Детская» ошибка, в общем-то…

Хотя платы красивые… ;) :))
0

Тут Вы очень точно подметили, что опыта в данной области у меня нет :) Я по образованию инженер-математик, и работаю в области, очень далекой от электроники. Учусь в том числе и на хабровских статьях. В последние несколько лет вижу, что на Хабре есть небольшая оппозиция ESP8266. Я уже использовал ее в нескольких проектах и этот модуль мне нравится. У меня уже скоро как год работают часы в связке STM32 + ESP8266, и работают стабильно. Но в данном случае ESP8266 не завелся. Было ограничение на размер, так как нужно было втиснутся в имеющийся корпус. Отсюда ограничение на доступные модули. И те, которые я попробовал, в моих условиях работали нестабильно. А вот RFM69 завелся сразу. Может, поэтому и получилось сделать плату красивой, так как проблем с компонентами не было и было больше времи для дизайна.

0
STM32 + ESP8266

Можно посмотреть в сторону RTL8710AF — два в одном и wi-fi и достаточно продвинутый МК. Пишут, что более энергоэффективный чем продукция ESP.
0
Можно посмотреть в сторону RTL8710AF

Хм, а вот это уже интересно :) Ценник на али ~ 230р за модуль, не смертельно, но в два раза дороже чем esp8266.
Глянул даташит… и различий (кроме платформы — у RTL — arm а не L106) особых не увидел, плюсминус примерно одно и тоже, хотя esp8266 все же более нафарширован периферией.
0
esp8266 все же более нафарширован периферией.

Точно речь про ESP8266? В чем состоит её нафаршированность периферией?

плюсминус примерно одно и тоже

RTL меньше ест в режиме пониженного потребления, чем ESP при отключении всего кроме LDO и RTC таймера
esp8266.ru/forum/threads/zamer-potreblenija-rtl00-v1-0.1595/page-2#post-52980
0
Точно речь про 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 таймера...

Форумы это хорошо, однако больше склонен верить цифрам из даташитов.
0
Теоретически, для ESP32 никаких внешних МК не нужно. Однако, к сожалению, часть SDK ESP32 — проприетарные закрытые блобы, поэтому пока их не отреверсят, пользоваться полноценно этими железками нельзя будет.
Вот ESP8266 вроде бы уже полноценно отреверсили, и можно с ними вполне удобно работать.
0

Работал что с 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 я давно не смотрел.

0
А я говорю, как человек, легко «убивавший» такие вот, «стабильно работавшие», устройства небольшим изменением внешних условий при испытаниях. :)

Не спорю, но в моих условиях — годами работает «без единого разрыва», как у Уральского Антохи.

есть и много других факторов, влияющих на уровень сигнала в ближних окрестностях каждого конкретного устройства.

Вы уводите контекст в сторону. Зачем? Если с сигнал/шумом у человека плохо, это одно. А если с радиочастью esp, то это другое. Мой совет, который я дал не Вам, а ТС-у на основе моего опыта: испытать другие модули вы отвергли и начали отводить в сторону радиообстановки. Зачем? И по каким признакам Вы решили, что виновата радиообстановка, а не ущербные модули?

При чём тут цена

Повторяюсь ещё раз: по моим данным более дешевые модули esp имеют проблемы с радиочастью. Как мне выразиться, чтобы быть услышанным?

и о чём тут, в итоге, спорить?

Вот и мне не понятно? Зачем спорить? Я дал совет ТС-у а не Вам, а спорите Вы…

В какой именно из бесконечного множества реальностей? ;)

Философ?

При каком качестве питания — батарей, в том числе? В каком диапазоне температур и влажностей, в какой электромагнитной обстановке?

Деградировавшие до 0,5Ом внутреннего сопротивления две АА батареи, которые при 70мА просаживались до 2,4В устойчиво питали датчик ещё 3,5 месяца. В домашнем диапазоне температур +35..+21С и влажности от 90% до 25% в жестокой электромагнитной обстановке на 2,4ГГц в условиях деревянного каркасного, многоквартирного дома.

От самого начала и до того, как батарейки потекли прошел 1 год и 3 месяца и 8900 срабатываний. Батарейки всё время были припаяны, а esp курсировала между Deep sleep и активностью без зависаний. Просто в одно утро датчик не вышел на связь и всё…
0
Вопрос немного не в тему, но хотелось бы собрать такую штуку, которая бы:

  • замеряла температуру в комнате, примерно каждый час
  • отправляла бы показания температуры для обработки


В качестве обработчика хотелось бы использовать raspberry pi, а вот что бы могло быть использовано для замера температуры и передачи (желательно беспроводно) пока не знаю и буду рад за советы.
Все это нужно для того чтобы посмотреть на корреляцию между температурой в доме и количеством использованого газа, а так же для того чтобы иметь какие-то начальные данные температур и сравнить их после утепления пола, чердака и тд.
+1

В самом общем случае, вариантов три, как мне кажется.


  1. Выше в комментариях о первом варианте упоминали. Готовые стандартные беспроводные датчики (типа Zigbee или zWave) и соответсвующий контроллер, подсоединенный к raspberry pi плюс OpenHUB на нем же. Но придется, наверное, прописать свой сценарий взаимодействия с датчиками для OpenHUB. Но тут я не специалист. С точки зрения железа — тривиально, с точки зрения софта нужно будет под себя настроить OpenHUB. Но может быть дорого.
  2. Второй вариант — взять тот же ESP8266. Я был уверен, что ESP8266 очень требователен к питанию, но в комментариях выше утверждают, что он будет просто от двух пальчиковых батареек работать. Для него придется писать или свою прошвку, или скрипт для какой-либо существующей прошивки, плюс небольшую программку для raspberry pi, чтобы данные собирать. То есть с точки зрения железа — относительно легко, с точки зрения софта — нужно программировать, но всяко дешевле, чем первый вариант.
  3. Связка "Микроконтроллер + радиомодуль". Это как у меня. В этом случае Вы можете взять мою плату и слегка подшаманить прошивку. Для вашей задачи нет смысла напаивать магнитный датчик и контур его обслуживания (что уменьшает расход батареи), но придется на микроконтроллере включать часы реального времени, что повышает расход батареи обратно. Также можно взять мою базовую станцию, и как есть подсоединить по USB к raspberry pi. Также взять в качестве шаблона мой серверный модуль и его доработать. Но в целом этот вариант самый сложный как с аппаратной, так и с программной точек зрения.
0
4. вы забыли Ардуину с вагоном и маленькой тележкой датчиков и передатчиков, включая передачу по усб-ту-ком в писи, ESP8266 и т.д.

5. «стандартные» дорогие модули для автоматизации с передачей по чему угодно. Дорого, но как вариант, может оказаться что валяется под столом ненужный

6. Экзотика типа прямого подключения датчика на LPT или COM-порт…
+1
На rpi можно поднять все что угодно.

7. Готовые датчики метеостанций + модуль RF 433Mhz приемник за 1$ с али. Преимущество в том что не надо беспокоиться об энергоэффективном батарейном питании. У меня Ea2 BL999 третий год живет на улице на одном комплекте литиевых батареек, но не суть какой именно датчик.

Почти для всех них есть готовые библиотеки декодирования сигнала. Повесить на распбери какой-нибудь RF 433Mhz приемник и адаптировать библиотеку под распберри или читать через атмегу/stm32/esp посредник.

Наводки по BL999
soltau.ru/index.php/arduino/item/526-chtenie-dannykh-datchika-pogody-bl999-s-pomoshchyu-arduino
github.com/sprilukin/lib_BL999

8. Железо — Xiaomi mijia temperature humidity sensor — 500р, CC2531 USB sniffer, Downloader cable CC2531, CC Debugger / STM32 blue pill — $10 (если без cc debugger'а)
ПО — zigbee2mqtt, NodeRed

habr.com/ru/post/462459
www.zigbee2mqtt.io/getting_started/what_do_i_need.html

У xiaomi датчика тот же плюс — готовое эффективное энергопотребление на одной батарейке CR2032
+1
Меня только гложут небольшие сомнения. А именно, что человек без профильного электротехнического образования собирает на коленке нечто, что работает надежнее фирменных продуктов известных в узких кругах IOT-брендов. Наверное, прогресс свернул куда-то не туда.

Ну тут нет ничего необычного. Вот если бы вы разработали такую систему с дипломом ветеринара или журналиста в руках, то я бы удивлялся.
А так, какой-никакой, но вы — инженер. А отклонение от выбранной специализации инженерии вы скомпенсировали своим хобби. Почтение.

PS и «на коленках» — это ЛУТ, макетные платы, навесной монтаж. А тут заказаны платы с белой маской, а это уже в ногу со временем и ноткой шика.
+2
Можно существенно сэкономить на потреблении, свести потребление к 0 в Standby, немного изменив схему и слегка подправив код в части включения и выключения. Убирается IC3, в R9 и R10 так же нет смысла. Геркон S1 подключается в разрыв питания. Параллельно S1 ставиться P-канальный ключ, bsh205, затвор подтянут высокоомным резистором к GND, а так же затвор подключается к любому порту gpio.Ключ по умолчанию выключен. При замыкании S1 на контроллере будет питание. Контроллер переводит затвор в 1. Да же если S1 разомкнется в параллель установленный P-канальный ключ обеспечит питание схемы. Выключение – подача на затвор 0 и перевод микроконтроллера в Standby.
+1

Спасибо, интересная идея, обязательно поэкспериментирую.

0
Верно ли я понимаю, что автор сделал и поделился наработками системы, которая может быть универсальной платформой сбора «медленной» телеметрии? (если доработать датчики)
+1
Верно ли я понимаю, что автор сделал и поделился наработками системы, которая может быть универсальной платформой сбора «медленной» телеметрии? (если доработать датчики)

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

Есть и моменты, на которые и сам автор акцентирует. Например, на потери пакетов, т.к. нет подтверждений. Если изменить логику транспортного протокола, добавить хоты бы подтверждение, то потери могут свестись к минимуму. А если добавить еще и шифрование, то систему сложно будет «взломать».
Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.