Comments 77
Меня только гложут небольшие сомнения. А именно, что человек без профильного электротехнического образования собирает на коленке нечто, что работает надежнее фирменных продуктов известных в узких кругах IOT-брендов. Наверное, прогресс свернул куда-то не туда.
Я думаю, что тут дело не в прогрессе. От человека всегда зависит не меньше, чем от образования. Целеустремлённость и мотивированность.
Датчики фирмы Vision, модель VIS_ZD2102. Контроллер — Aeon Labs Z-Stick Gen5. Я, когда их покупал, тоже читал про устройства zWave, которые работают хотя бы год от одной батарейки. Но в моем случае это была какая-то катастрофа. Самые дальние датчики переставали работать через 2 или 3 месяца. Остальные — примерно через полгода. Наверное, сильно зависит от конкретного производителя.
Севшая батарейка в Z-Wave датчике думаю, была лишь предлогом, чтобы разработать свое решение.
Результат несомненно отличный, работа проведена колоссальная. Но лично я все же для охранки выбрал бы проверенные годами датчики, тот же Z-Wave, Jablotron, Ajax, Enocean и др.
Судя по опыту Ajax вне конкуренции в системах охранной сигнализации.Как и в плане надежности, так и "прожорливости"
Чтение инструкции к Z-Wave датчику не помогло, к сожалению. В доме оказалось 3 места, где сигнал от датчика доходил до контроллера очень условно — даже на абсоютно свежих батарйках могло быть до 25% потерь, что неприемлемо. Устанвка дополнительных zWave повторителей в эти места не помогла. Поэтому подстройку времени пробуждения я даже серьезно и не рассматривал.
Если датчик ни с первого раза добивает до контроллера, то он остается в пробужденном состоянии, чтобы сделать 3 попытки отправки. Если контроллер не отправит датчик спать, то тот может быть в эфире и 20 секунд. Z-Wave чип потребляет примерно 25 мА в этом режиме. Батарейка емкостью 750 мАч. 750/25 = 30 часов, 30*3600/20/24= 225 дней может проработать от батарейки.
Частота пробуждения очень сильно влияет на время жизни батареек. Контроллер, который не умеет правильно общаться с датчиками быстро может разрядить батарейку. И возможно проблема не только в датчиках, но и в стике была.
Очень странная история.
только по прочтении этого коммента понял, что речь об охранной сигнализации
z-wave просто сделан с заделом на универсальность.
mesh-сеть; достаточно незагруженный диапазон; ограниченная протоколом скважность 1%. Секурность.
Но очень много ограничений, во многом из-за всех этих требований. Поэтому вполне норм, что в конкретном частном случае "велосипед" оказался лучше. Но вот запустите туда хацкера со сниффером 433МГц и глушилкой — и велосипед легко обрастёт ssl-слоем и разными baypass-примочками. Получится в итоге прототип z-wave.
Последний (не прототип, а сам протокол), к слову, зачастую работает ОЧЕНЬ хреново. Он проприетарный, вендоры не особо шевелятся устранять разные проблемы, а открытые решения ( Open-zWave ) работают вообще, порой, погано (с полгода назад я каждую неделю заново строил больше половины сети, добавляя внезапно "отвалившиеся" девайсы). Но всё же в целом какая-то предсказуемость есть. Дверной замок не просто светит в сеть "ручку" открыть/закрыть, а делает это секурно, так что банальным сниффером снаружи перехваченный сигнал расшифровать пока непросто. Разные не сильно важные выключатели тоже, не всегда доставляют свой пакет даже через mesh, но всё же через пень-колоду оно долетает. Но всё это совсем никак не зависит ни от количества wifi-точек в доме, ни от количества припаркованных машин на сигналке во дворе. Хоть какая-то стабильность :)
общее потребление в режиме сна должно быть в районе 0.5 μA
А сколько ест в режиме передачи? и какова его длительность?
В режиме передачи я померять не смог, так как сама передача много меньше секунды. Поэтому ориентируюсь на паспортные значения RFM69 — от 16 до 130 mA в зависимости от режима и мощности. Но RFM69 хорошо в этом плане оптимизирован — всю подготовку (буферизациу) передаваемого пакета можно выполнить в Standby моде (1.5 mA), запутить передатчмк по готовности и сразу выключить по окончании передачи. Плюс я сильно оптимизировал потребление микроконтроллера (низкая частота, тактирование только нужной перифирии, подтяжка портов)
А что означает сокращение "КАЛ"?
А какие есть альтернативы, в которых нет ошибок, и при этом они позволяют начать работать без ручной генерации обвязки?
Мне, например, известна только библиотека libopencm3, которая даже адекватной системы версионирования релизов не имеет. Лицензируется под GLP/LGPL, что не слишком удобно для коммерческих проектов. Сооветствует ли MISRA-C? Не известно, а это для компаний, особенно крупных, может быть важно. А для хобби-проектов, в сравнении с инструментами ST, там документации код наплакал.
CubeMX можно скачать с оффсайта, быстро накликать конфигурацию и начать работать. Если ты не супермегаджедай разработки для микроконтроллеров — это простой и адекватный способ сделать хоть что-то. Откуда такая радикальная неприязнь к тому, чем пользуются другие? Не нравится — не пользуйтесь и мимо проходите.
Opencm3 я поначалу использовал, но когда в очередной раз поломали апи (да и намучился с тормозами и оверхедом), понял, что нельзя пользоваться всякой сторонней дрянью.
Но вантузоиды-абдуринщики видят мир иначе. Ну и черт с вами.
1. Батарейки. Их надо менять, пусть и редко. А заряд батарейки передаётся только если открыть окно. В нашем климате 6 месяцев окна не открывают :)
2. Если перерезать провод — это уже проникновение, то запустить 20Вт глушилку на 433МГц и отключить все датчики от систему контроля — можно и со стоянки у дома. Учитывая что фонового обмена с датчиками нет — то выноси весь дом…
а где тут вообще в статье речь про секурность?
Открытый протокол (ну как… security-by-obscurity, но вот статья вышла — и obscurity осталась только в гео-координатах).
- 433 мГц далеко не пуст. Начиная с банальных автомобильных сигналок, и заканчивая каждым первым термометром с Али с выносным датчиком. Не wifi 2.4ГГц, конечно но всё же...
Ну так датчики для сигнализации должны ж защищать.
Защищать должны армия, полиция, Росгвардия и прочие, специально уполномоченные, органы.
А датчики сигнализации, как и прочие-любые датчики, должны только выдавать достоверное значение соответствующей физической величины.
Всё. :)
А чтобы «голова» всё «понимала», протокол обмена нужен соответствующий, с двусторонним обменом.
Герконы с ртутным контактом не залипают.
А такие ещё производятся? И если да, то где можно купить?
www.radioelementy.ru/catalog/prochie-radiodetali/gerkonovye-rele/-45181
Тут, конечно, объелись ухи по цене…
И явно есть импортные аналоги
Интересный проект, уверен что можно дешевле, проще и миниатюрнее!
Связка, из CC1310 (TI микроконтроллер с интегрированым приемопередатчиком в субгигарцевом диапазоне, 315-866 МГц), датчик температуры-влажности SHT30 или HTU20D, батарея CR-2032 (все прекрасно вмещается на плате размером 30х30мм, толщина платы вместе с батареей 5.5мм, в зависимости от дизайна корпуса габаритные размеры от 34х34х7.5мм)
Отправная точка для разработки, TIDA-00484 (оценочная плата датчика температуры влажности, заявленный срок службы от одной батареи 10 лет)
Оценочная цена 4.5$ в зависимости от жадности поставщиков.
Датчик №10 один раз завис. Это, видимо, привело к значительному уменьшению напряжения батарейки.
А watchdog в контроллерах датчиков не используется?
Пока нет, но по хорошему нужно добавить. Когда я писал, что буду разбираться, если еще раз зависнет, то именно это и имелось ввиду. Проект же чисто хобишный, для себя, поэтому так глубоко в тему надежности пока не стал залазить.
Кстати, вполне вероятной причиной зависания может быть коммутация питания радиомодуля ключем — при включении питания радиомодуля у Вас разряженный блокировочный конденсатор 0.1 мкФ напрямую подключается к источнику питания, что вызывает как просадку питания, так и иголки на шине земли.
Контроль питания и собственной работоспособности устройства — это не «глубоко в тему», это фундамент любой подобной «темы».
Watchdog таймер, brownout detection, и т.п — всё это просто обязано быть, особенно в устройствах с автономным питанием. Иначе разряд батареи, окисление контактов и прочие «сопутствующие удобства» сведут работоспособность ваших устройств на нет.
К слову, тут рекомендовали герконы в качестве составной части «средства Макропулоса». Так вот, у герконов было, по крайней мере, такое неприятное свойство: их контакты «залипали» при рабочих токах ниже определённого порога, и «приводить в чувство» такие датчики приходилось методом физического ударного воздействия. А токи, гарантировавшие отсутствие этого эффекта, были порядка единиц-десятков миллиампер. Не для батарейного питания, прямо вам скажу.
И да, присоединюсь к отрицательным мнениям о применении радиоканала. Везде, где есть такая возможность, лучше применять провода. Грамотно спроектированная и проложенная проводная линия связи и питания гораздо меньше подвержена помехам, чем радиоканал. ;) :))
Любой радиоканал с любым, самым «надёжным» протоколом обмена и шифрованием «давится», при наличии «интересантов», просто «на раз» и, в итоге, устройство охраны и сигнализации нередко просто отключается его владельцем за его «глючность», «ненадёжность», и т.а.
Так что — экранированная витая пара в металлической, правильно заземлённой трубе (помним о грозозащите!) — «наше всё!». С резервированием — двукратным, хотя бы… ;)
Да, это дороже. Но разве дом, охраняемый Вашей сигнализацией, не дороже её самой на порядки?..
Смею возразить по поводу меньшей надёжности и трудозатратности перехода на МК с аппаратный USB. HAL тем и хорош, что позволяет портировать код между разными контроллерами. Сделать один проект под несколько СТМок — не проблема. А наличие готовых либ для работы с USB позволяет для организации виртуального COM-порта затратить усилий даже меньше, чем требуется для запуска аппаратного USART. Как только я это осознал — жизнь стала гораздо веселее. А плюсом вы получаете возможность переконфигурировать USB для всяких плюшек, типа эмуляции флехи для обновления прошивки, добавления второго виртуального COM или ещё какой полезной побрякушки. Аппаратный же мост ничем кроме моста стать не сможет.
RFM умеер шифровать посылки, вы использовали эту возможность?
Не будет такое работать.
Вот если к этому радиомодулю добавить STM8L за 20-30 рублей, то уже можно жить.
Кстати, если все железяки брать в количестве штук по 100 на али, то будет намного дешевле.
P.S. Как вариант — на 555-й сделать генератор меандра и пусть это по радиомодулю передается. А в случае размыкания геркона частота меняется. В итоге приемник хотя бы сможет это детектировать. Если наоборот сделать — генерировать меандр при размыкании геркона — можно чуть батарейку сэкономить. Но на мой взгляд, в квартире и так достаточно источников энергии. Можно все сделать по-человечески: проложить кабель (витуха из двух пар), по одной паре общаемся по CAN-шине, по второй паре подаем питание. Для такой элементарщины, как датчики на окнах, хватит и стандартной «лапши», как это всегда и делалось.
Радиомодули — зло! И надо искоренять эту любовь к беспроводной связи, засирающую эфир!!!!1111
беспроводной датчик вносит и потенциально ненадежный человеческий фактор, который проявляестя в виде своевременной замены источников питания (и что парадоксально — чем больше их срок службы, тем больше вероятность, что эта замена своевременно не будет произведена)
Фактор забывчивости легко решаем. Принимающая сторона знает напряжение батарейки в каждом датчике, и, в случае пороговых значений, может рассылать напоминания через телеграм-бота, простые имейлы или пуш-уведомления в андроид приложении.
Автору ИМХО просто хотелось помахать паяльником и код пописать.
Давно более или менее стандартны и дешевы Zigbee сенсоры на любой вкус, вроде Xiaomi за 10$.
А в качестве серверного софта есть OpenHAB, который умеет интегрироваться, по моему, вообще с чем угодно. И это де факто опенсурсный стандарт для умного дома.
Ну почему же только "помахать паяльником и код пописать"? История началась с того, что я установил "более или менее стандартные и дешевые сенсоры", только они случайно назывались zWave, а не Zigbee. Это проприетарное решение не заработало. Уверенности, что заработает другое проприетарное решение, у меня не было. Из комментариев выше я вижу, что есть как качественные, так и не качественные zWave решения. То же самое касается и Zigbee. Чтобы больше не играть в лотерею, я сделал свою открытую платформу, гду полность контроллирую каждый ее аспект (как аппаратный, так и программный). OpenHAB да, хорошее решение. Только слишком избыточное в моем случае.
Ну почему же только "помахать паяльником и код пописать"?
Потому что я тоже через это проходил :) Делал всякие считыватели показаний электро- и водо- счетчиков на ESP8266 и прочие компоненты умного дома на коленке. Хотя, как раз в с случае со счетчиками готовых решений особо нет, так что тут думаю колхоз оправдан.
А вот с остальными, стандартными, компонентами как описанные датчики открытия, лампы, розетки и прочее, ИМХО, смысла городить огород нет. Рынок уже хорошо развит и достаточно почитать форумы-отзывы и выбрать себе девайс по душе.
OpenHAB да, хорошее решение. Только слишком избыточное в моем случае.
Ну, для простых действий там ничего городить не надо, по-моему нынче даже можно правила через WebUI рисовать простые, аля If-This-Then-That. Ну и аппетит приходит во время еды, думается просто датчиками открытия окон дело не ограничится...
Не берите самые дешевые модули и проблем с уровнем сигнала не будет
Мой первый прототип датчиков базировался на ESP8266. Контроллер — на базе моей платы, о которой я уже писал на Хабре. В качестве прототипа система даже заработала, но пришлось от нее отказаться по двум причинам. Первая причина та же самая — в доме оказались закутки с очень низким уровнем сигнала WiFi, что привело к очень большому времени активации ESP8266 при пробуждении и, как следствие, к сильному разряду батарейки. Хотя я допускаю, что просто не умею правильно готовить эту самую ESP8266 (статьи вроде этой подтверждают такой тезис). Но вторая причина оказалась более серьезной. Так как я решил оставить не только корпус, но и батарейный отсек, то был ограничен батарейкой CR123A, которая на 3.0 вольта. То есть цена и сложность датчика возрастала за счет повышающего DC/DC преобразователя. Хотя и по этой теме на Хабре есть замечательная статья. Но, так или иначе, эти две причины перевесили и ESP8266 я отбросил.
В первой строке — о несостоятельности второй причины, и и во второй строке — о несостоятельности первой
И Ваши доводы не очень убедительны, на мой взгляд.
Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP, да и работоспособность в заданном диапазоне питания тоже не гарантирована в каждом конкретном случае.
Вдобавок, и то, и другое зависит как от характеристик конкретной партии модулей, так и от «характеристик и свойств» разработчика. :)
И Ваши доводы не очень убедительны, на мой взгляд.
Я говорю как разработчик датчика на esp, который питается в трех версиях от трех вольт без степ-апа от элементов АА/ААА/CR123.
Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP
В дешевых версиях находил токопроводящий неотмытый флюс, тогда у esp ток сна с даташитных 20-30мкА доходил до 200мкА и существенно затуплялась ВЧ часть. Мною была найдена корреляция между током сна и дальнобойностью радиочасти. Лучшие модули во сне потребляют 12мкА, видимо сказывается культура производства.
да и работоспособность в заданном диапазоне питания тоже не гарантирована
Operating Voltage 2.5 V ~ 3.6 V из даташита.
В реальности нормальный модуль работает и от 2,4В. Когда CR123 дойдет до 2,4 — это будет уже полный разряд. Степ-ап не нужен, не смотря на убеждения автора.
Я говорю как разработчик датчика на esp, который питается в трех версиях от трех вольт без степ-апа от элементов АА/ААА/CR123.
А я говорю, как человек, легко «убивавший» такие вот, «стабильно работавшие», устройства небольшим изменением внешних условий при испытаниях. :)
В дешевых версиях находил токопроводящий неотмытый флюс, тогда у esp ток сна с даташитных 20-30мкА доходил до 200мкА и существенно затуплялась ВЧ часть. Мною была найдена корреляция между током сна и дальнобойностью радиочасти. Лучшие модули во сне потребляют 12мкА, видимо сказывается культура производства.
Культура производства — это хорошо, даже очень. Я только «за!». :)
Но это никак не опровергает моего тезиса о том, что «Нет никакой связи уровня сигнала в данном конкретном месте с ценой приобретения ESP», потому как помимо качества элементной базы и сборки модулей, есть и много других факторов, влияющих на уровень сигнала в ближних окрестностях каждого конкретного устройства.
Вы же не знаете местных условий в доме автора, а они могут быть достаточно… гмм… специфическими, скажем так. При чём тут цена и о чём тут, в итоге, спорить? :)
Operating Voltage 2.5 V ~ 3.6 V из даташита.
В реальности нормальный модуль работает и от 2,4В.
В какой именно из бесконечного множества реальностей? ;)
При каком качестве питания — батарей, в том числе? В каком диапазоне температур и влажностей, в какой электромагнитной обстановке?
Степ-ап не нужен, не смотря на убеждения автора.
А это уже решает разработчик.
Правда, у автора, судя по всему, опыта в данной области не особо в достатке, раз уж «собаку не отвязал» (watchdog timer) и датчики «зависают». «Детская» ошибка, в общем-то…
Хотя платы красивые… ;) :))
Тут Вы очень точно подметили, что опыта в данной области у меня нет :) Я по образованию инженер-математик, и работаю в области, очень далекой от электроники. Учусь в том числе и на хабровских статьях. В последние несколько лет вижу, что на Хабре есть небольшая оппозиция ESP8266. Я уже использовал ее в нескольких проектах и этот модуль мне нравится. У меня уже скоро как год работают часы в связке STM32 + ESP8266, и работают стабильно. Но в данном случае ESP8266 не завелся. Было ограничение на размер, так как нужно было втиснутся в имеющийся корпус. Отсюда ограничение на доступные модули. И те, которые я попробовал, в моих условиях работали нестабильно. А вот RFM69 завелся сразу. Может, поэтому и получилось сделать плату красивой, так как проблем с компонентами не было и было больше времи для дизайна.
STM32 + ESP8266
Можно посмотреть в сторону RTL8710AF — два в одном и wi-fi и достаточно продвинутый МК. Пишут, что более энергоэффективный чем продукция ESP.
Можно посмотреть в сторону RTL8710AF
Хм, а вот это уже интересно :) Ценник на али ~ 230р за модуль, не смертельно, но в два раза дороже чем esp8266.
Глянул даташит… и различий (кроме платформы — у RTL — arm а не L106) особых не увидел, плюсминус примерно одно и тоже, хотя esp8266 все же более нафарширован периферией.
esp8266 все же более нафарширован периферией.
Точно речь про ESP8266? В чем состоит её нафаршированность периферией?
плюсминус примерно одно и тоже
RTL меньше ест в режиме пониженного потребления, чем ESP при отключении всего кроме LDO и RTC таймера
esp8266.ru/forum/threads/zamer-potreblenija-rtl00-v1-0.1595/page-2#post-52980
Точно речь про 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 таймера...
Форумы это хорошо, однако больше склонен верить цифрам из даташитов.
Вот ESP8266 вроде бы уже полноценно отреверсили, и можно с ними вполне удобно работать.
Работал что с 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 я давно не смотрел.
А я говорю, как человек, легко «убивавший» такие вот, «стабильно работавшие», устройства небольшим изменением внешних условий при испытаниях. :)
Не спорю, но в моих условиях — годами работает «без единого разрыва», как у Уральского Антохи.
есть и много других факторов, влияющих на уровень сигнала в ближних окрестностях каждого конкретного устройства.
Вы уводите контекст в сторону. Зачем? Если с сигнал/шумом у человека плохо, это одно. А если с радиочастью esp, то это другое. Мой совет, который я дал не Вам, а ТС-у на основе моего опыта: испытать другие модули вы отвергли и начали отводить в сторону радиообстановки. Зачем? И по каким признакам Вы решили, что виновата радиообстановка, а не ущербные модули?
При чём тут цена
Повторяюсь ещё раз: по моим данным более дешевые модули esp имеют проблемы с радиочастью. Как мне выразиться, чтобы быть услышанным?
и о чём тут, в итоге, спорить?
Вот и мне не понятно? Зачем спорить? Я дал совет ТС-у а не Вам, а спорите Вы…
В какой именно из бесконечного множества реальностей? ;)
Философ?
При каком качестве питания — батарей, в том числе? В каком диапазоне температур и влажностей, в какой электромагнитной обстановке?
Деградировавшие до 0,5Ом внутреннего сопротивления две АА батареи, которые при 70мА просаживались до 2,4В устойчиво питали датчик ещё 3,5 месяца. В домашнем диапазоне температур +35..+21С и влажности от 90% до 25% в жестокой электромагнитной обстановке на 2,4ГГц в условиях деревянного каркасного, многоквартирного дома.
От самого начала и до того, как батарейки потекли прошел 1 год и 3 месяца и 8900 срабатываний. Батарейки всё время были припаяны, а esp курсировала между Deep sleep и активностью без зависаний. Просто в одно утро датчик не вышел на связь и всё…
- замеряла температуру в комнате, примерно каждый час
- отправляла бы показания температуры для обработки
В качестве обработчика хотелось бы использовать raspberry pi, а вот что бы могло быть использовано для замера температуры и передачи (желательно беспроводно) пока не знаю и буду рад за советы.
Все это нужно для того чтобы посмотреть на корреляцию между температурой в доме и количеством использованого газа, а так же для того чтобы иметь какие-то начальные данные температур и сравнить их после утепления пола, чердака и тд.
В самом общем случае, вариантов три, как мне кажется.
- Выше в комментариях о первом варианте упоминали. Готовые стандартные беспроводные датчики (типа Zigbee или zWave) и соответсвующий контроллер, подсоединенный к raspberry pi плюс OpenHUB на нем же. Но придется, наверное, прописать свой сценарий взаимодействия с датчиками для OpenHUB. Но тут я не специалист. С точки зрения железа — тривиально, с точки зрения софта нужно будет под себя настроить OpenHUB. Но может быть дорого.
- Второй вариант — взять тот же ESP8266. Я был уверен, что ESP8266 очень требователен к питанию, но в комментариях выше утверждают, что он будет просто от двух пальчиковых батареек работать. Для него придется писать или свою прошвку, или скрипт для какой-либо существующей прошивки, плюс небольшую программку для raspberry pi, чтобы данные собирать. То есть с точки зрения железа — относительно легко, с точки зрения софта — нужно программировать, но всяко дешевле, чем первый вариант.
- Связка "Микроконтроллер + радиомодуль". Это как у меня. В этом случае Вы можете взять мою плату и слегка подшаманить прошивку. Для вашей задачи нет смысла напаивать магнитный датчик и контур его обслуживания (что уменьшает расход батареи), но придется на микроконтроллере включать часы реального времени, что повышает расход батареи обратно. Также можно взять мою базовую станцию, и как есть подсоединить по USB к raspberry pi. Также взять в качестве шаблона мой серверный модуль и его доработать. Но в целом этот вариант самый сложный как с аппаратной, так и с программной точек зрения.
5. «стандартные» дорогие модули для автоматизации с передачей по чему угодно. Дорого, но как вариант, может оказаться что валяется под столом ненужный
6. Экзотика типа прямого подключения датчика на LPT или COM-порт…
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
он работает на расстоянии 20-50 см от датчика.
Пытался использовать вот этот
вообще никакого сигнала не получаю. Добавление антенны ситуации никак не улучшило.
Мне нужно чтобы сигнал приходил со всех комнат небольшого кирпичного дома. Вопрос соответсвенно какой приемник мне для этого смотреть? Или я возможно что-то не так делаю с теми что у меня уже есть?
Добавление антенны ситуации никак не улучшило
20 см для 433 Мгц это как-то совсем дичь. Антенна точно была под 433 Мгц?
Мне нужно чтобы сигнал приходил со всех комнат небольшого кирпичного дома.
Все зависит от расположения относительно стен и толщины стен. Не знаю есть ли что-то готовое для 433Мгц, в случае допустим Zigbee есть ретрансляторы сигнала
Меня только гложут небольшие сомнения. А именно, что человек без профильного электротехнического образования собирает на коленке нечто, что работает надежнее фирменных продуктов известных в узких кругах IOT-брендов. Наверное, прогресс свернул куда-то не туда.
Ну тут нет ничего необычного. Вот если бы вы разработали такую систему с дипломом ветеринара или журналиста в руках, то я бы удивлялся.
А так, какой-никакой, но вы — инженер. А отклонение от выбранной специализации инженерии вы скомпенсировали своим хобби. Почтение.
PS и «на коленках» — это ЛУТ, макетные платы, навесной монтаж. А тут заказаны платы с белой маской, а это уже в ногу со временем и ноткой шика.
Верно ли я понимаю, что автор сделал и поделился наработками системы, которая может быть универсальной платформой сбора «медленной» телеметрии? (если доработать датчики)
Универсальная платформа — это громко сказано. Скажем так, оптимально и функционально в данный момент времени и для данной задачи. Плюс в том что датчики беспроводные, не надо тянуть провода, а это не всегда целесообразно и можно сделать, и с большим сроком автономности работы.
Есть и моменты, на которые и сам автор акцентирует. Например, на потери пакетов, т.к. нет подтверждений. Если изменить логику транспортного протокола, добавить хоты бы подтверждение, то потери могут свестись к минимуму. А если добавить еще и шифрование, то систему сложно будет «взломать».
Самодельные беспроводные оконные датчики: STM32L051 + RFM69 + Android