Comments 159
off «для создания IOT радиосетей на частотах 2.4Ггц, 915, 868, 433 Мгц» я бы посмотрел решение с радиомодулем на одном чипе с микроконтроллером.
Например habr.com/ru/post/386735
Отладочный комплект от Ti:
image
На него же нет ардуино-скетчей. Там ведь надо программировать.
Мне гугль говорит, что ну хотя бы на nRF52 у ардуинщиков что-то есть.

Минус приёмопередатчик, минус флэшка для обновлений, железо по сложности сводится к среднему блютус-бикону.
Цена как у небольшого космического аппарата?
NRF24 + ATMega238 (а можно и 88/168) < 2$
У отладочных комплектов Ti всегда космическая цена.
По компонентам дешевле. В ценах eu.mouser.com:

TPS61291 Повышающий DC-DC преобразователь напряжения с режимом bypass
1,51 €

TPL5111 Системный таймер
0,786 €

TPS22860 Выключатель нагрузки
0,80 €

HDC1000 Датчик влажности и температуры
7,06 €

CC1310 «Беспроводной контроллер»
5,42 €
Сама суть схемы экономии энергии только в использовании таймера и выключателя нагрузки, остальное можно заменить.

На хабре есть статьи о ESP8266 и питании от батареек. Имхо для дома это удобнее и дешевле т.к. уже есть беспроводная сеть — WiFi.
habr.com/ru/post/130421
habr.com/ru/post/257141
habr.com/ru/post/304936
Что это? Это очень простая и хорошо проработанная и что немаловажно отлично описанная библиотека под Ардуино ИДЕ (и не только) для создания IOT радиосетей на частотах 2.4Ггц, 915, 868, 433 Мгц, а так же проводных сетей на интерфейсе 485, возможно не все упомянул, тк протокол постоянно развивается, все время что то добавляется


За пять минут на mysensors.org никакого вообще описания протокола найти так и не смог.

Дайте ссылку.
Нет, это API шлюза по UART'у.

А что у них там в радио происходит и из чего оно вообще сделано — видимо, в отлично описанной библиотеке надо рыться в исходниках.
А смысл? Вы MQTT тоже побайтно из IP-пакетов парсите?
Все что нужно выдается в UART включенным MY_DEBUG
Если нужно можно еще и отладку конкретного радиомодуля поднять
А смысл?

Например, захотелось подключить что-то свое.
Все что нужно выдается в UART включенным MY_DEBUG

И описание протокола выдается? Или Вы не видите разницу между описанием и отладочной информацией?
Хватило для чего? Вы взяли неподдерживаемый этой библиотекой RF-чип и сделали на нем датчик, работающий в этой экосистеме? Пользуясь только описанием API?
нет, упоси боже, я только обычные ардуино скетчи парой девайнов адаптирую под майсенсорс и фанатею от ардуино модулей. Но у меня это хобби. А вы?
А у меня это и хобби и профессия :) Как хоббисту мне все эти «умные дома» совершенно безразличны, я не вижу в них достаточной пользы, чтобы тратить на это силы. А как профессионалу мне было бы любопытно взглянуть на протокол общения нод с центром, но вызывает недоумение отсутствие описания базовой вещи — этого протокола :)
Как раз вижу. И сниффер на NRF-ке гонял, смотрел все пакеты. Просто не вижу практического смысла в этом. Все через API делается. Что-то свое подключать — нужно транспортный уровень капать в первую очередь. Или вы про новые сенсоры? Так и там избыточно этих сенсоров. Лучше бы по типам данных их разделяли
Ок, вот у меня есть свои приемопередатчики. Или проводная нестандартная линия. Как мне это подключить к шлюзу? В каком виде отправлять ему данные?
Вы собираетесь свою библиотеку писать?
Я бы просто написал поддержку своего транспорта Mysensor/hal/transport/XXX по образу и подобию того же RF24 или RFM69 в стандартной библиотеке Mysensors
Опять же исходя из того что для каждого транспорта нужно свой шлюз, некоторые навороченные модули типа вообще нету смысла к Mysensors стыковать, а лучше использовать свои штатные протоколы и цепляться ими к
тому же MajorDoMo параллельно Mysensors
Вопрос не в том что я собираюсь писать, вопрос в том, что одна из базовых вещей никак не документирована :)
Во-первых, было интересно посмотреть, насколько оно вообще юзабельно за пределами «ну чот вроде работает» — в телеграм-канале мне уже сообщили, что подтверждение доставки сделано через одно место, нумерации пакетов нет вообще, в общем, без доработки напильником неюзабельно.

Во-вторых, у нас в процессе своя реализация, в том числе под умный дом, на nRF52832 с 6LoWPAN (ну, почти, т.к. 52832 не умеет QPSK и, следовательно, IEEE 802.15.4), вдруг бы я захотел не изобретать велосипед, а просто поддержать уже существующий проект?

В-третьих, там же как-то предполагается участие сторонних разработчиков во всём этом, оно же open source не только потому, что создателям нравится, как эти слова звучат? Или реверс-инжиниринг протокола по исходникам — это такой вступительный экзамен?

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

Во-вторых
) поржал, ну так возьмите вашим коллективом в прицел nRF52840…

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

В-четвёртых
В следующий раз напишу ровно так же, потому как так и есть,… это статья именно для тех кто хотел бы попробовать.… вам лучше своё с типа почти 6LoWPAN на nRF52832
а какие именно пакеты вы считаете надо считать в данной реализации??

Ну вообще в целях повышения надежности пакетной коммуникации обычно все пакеты нумеруются. Это гарантирует отсутствие пропуска пакетов, или как минимум обнаружение пропуска или дублирования. Это повышает общую пропускную способность канала.
У меня такое ощущение, что Вы пытаетесь упорно спорить на ту тему, которая Вам совершенно неизвестна :) Вам пишут «внутри все непонятно и, судя по всему, плохо», а Вы отвечаете «нет, все идеально, смотрите какая удобная и красивая обертка» :)
С нумерацией в радио всё ещё веселее — см. reply attack. Мало того, что в нормальных системах пакеты нумеруются, они ещё и криптографически подписываются, чтобы случайно пролетавший мимо дятел, записавший на свой HackRF пакет, отпирающий мой дверной замок, не мог в произвольный момент просто передать его в эфир.
Ну да, и для безопасности тоже, упустил этот момент :)
А тут нет никаких подписей? А вон тот крипточип — он тогда для чего?
Я в канале не общался, поэтому совершенно не в курсе как там и что :)
А в канале никто про это ничего наверняка не знает, там толпа ардуинщиков — хотя с утверждением, что счётчика пакетов нет, никто спорить не стал.

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

www.mysensors.org/about/signing

Прекрасный художественный текст, иллюстрации к нему, полагаю, автор делал сам.

Сделал из него вывод, что шифрования в MySensors нет.

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

Из текста можно сделать вывод, что автор почему-то не любит счётчики сообщений (они предсказуемы — ну и что?), а вместо этого любит генерацию nonce на каждое сообщение, т.е. передача каждого пакета нагрузки по радио у него — это полноценный хендшейк в четыре приёмопередачи, привет батарейке и загрузке эфира.
То есть, получается, для каждого сообщения организуется некая подтвержденная сессия?
Да (точнее, видимо, «наверное», ибо в комментариях отмечают, что текст вообще устарел).

image

(и тут ещё нет подтверждения доставки, это будет четвёртое сообщение в сессии)

По сути, для типовой ноды (которая шлёт пакет на каждое своё просыпание) автор жертвует десятками процентов времени жизни на батарейке, удваивая time-on-air — на который традиционно приходятся основные расходы энергии.
Да, решение какое-то переусложненное и явно не для автономности.
Там у автора два голоса в голове:

1) счётчик кадров плох, потому что предсказуем
2) шифрование — забота пользователя

Оба тезиса неверны, и из них при этом растёт и переусложённость защиты в одном месте, и её полное отсутствие в другом.
Вы сначала посидите и подумайте для чего был сделан MyS. И кто и что на нем в основном поднимает. А потом разберитесь со своей головой, что то явно где то что то пережимает…
Я так понял из ваших объяснений, что для ардуинщиков, которым надо по-быстрому прикрутить либу, а как оно там работает и за сколько батарейку сожрёт, их мало волнует.
Кого-то волнует, коо-то действительно вообще не волнует, ну просто другой интерес…
Там у автора два голоса в голове:

При том, что можно было сделать проще и надежнее, включая шифрование по умолчанию.
Не всем даже это нужно, это для продолжающих… Еще раз обращаю ваше внимание на то что такое MyS и его идеология.
Такой подход понятен и простителен для личной поделки в своем доме, но не для продвигания в массы с хвалебными дифирамбами.
Вы наверное не в курсе были, но людей которые занимаются «личными поделками» в своем доме стало сильно больше. И есть куча вещей которые делаются для них, делаются ими, люди собираются в сообщества,… им это итересно. Так что тут вопрос кому простительно а кому бы и призадуматся. Вы глаза вверх экрана приподнимите, гляньте на раздел где вы так «блещите» habr.com/ru/hub/DIY
А потом мы читаем про эти сделанные для них вещи в новостях рубрики «Кибербезопасность», ага.
Шифрование по умолчанию сделать было не можно, а нужно.

Потому как ещё одна типовая атака требует, чтобы одни и те же входящие данные давали каждый раз разные зашифрованные — и это проще всего реализовать через AES-CTR, которому в качестве счётчика просто подсовывается номер пакета. И это не может быть сделано на уровне приложения, ибо уровень приложения номер пакета не знает и знать не может.

В данном случае можно было бы сделать то же самое с nonce, только непонятно, зачем. Знание номера пакета атакующему не даёт никаких преимуществ, если разрядность счётчика достаточно велика, чтобы за разумное время он не обнулился (ну то есть в общем двух байт хватит практически всем).
Потому как ещё одна типовая атака требует, чтобы одни и те же входящие данные давали каждый раз разные зашифрованные

В смысле — противодействие этой атаке требует разного шифрования?
Ну не знаю, в данном случае шифрование, на мой взгляд, опционально, но вот подпись каждого пакета — просто обязана быть, причем на базовом уровне, а не «если хотите, можете включить». Пусть даже примитивная — какой-либо не слишком навороченный по математике HASH, в вычислении которого участвует в том числе и номер пакета. Пользователя нужно только заставить задать свои значения для начальной инициализации функции и для соли. Просто, невысокие энергетические и вычислительные ресурсы и достаточно устойчиво против взлома, на мой взгляд.
В смысле — противодействие этой атаке требует разного шифрования?


Ну да.

Если нам не важно передаваемое значение, а важно его изменение (например, можно ловить показания водосчётчика, если они сутки не меняются — в квартире никого нет, и для понимания этого нам не надо знать, сколько именно литров он показывает), то шифрование с фиксированным ключом не поможет.

На уровне приложения это решается рандомной солью, но соль съедает байты пейлоада. А на уровне MAC можно формировать ключ из nonce или счётчика пакетов, которые гейту известны — соответственно, он сможет сформировать такой же ключ.

Расходы на это незначительные — я занимался оптимизацией AES по памяти как-то, заодно сделал бенчмарки, на инициализацию и один блок (16 байт) уходит 285 мкс на Cortex-M0 и 165 мкс на Cortex-M1 (алгоритм — обычный сишный на Т-таблицах, ничего особенно выдающегося).

Но автор этого чуда почему-то считает, что кому надо — тот пусть и шифрует.
Про шифрование — я имел в виду, что оно в данном применении опционально просто потому, что никаких критически важных данных через эфир не передается. Ну, можно будет узнать из эфира, что датчик №42 передал значение 238, ну и что? :) Даже пусть будет известно, что это датчик температуры и он передал показания температуры 23.8 градуса.
Главное — обеспечить защиту от внешнего проникновения в экосистему, от подмены данных или команд.
А так-то понятно, что шифровать одним ключом одни и те же данные смысла мало.
не слишком навороченный по математике HASH

Будет очень нестоек к взлому. Имея вычислительные ресурсы его можно будет подобрать за разумное время, а значит не стоит на него полагаться для защиты от взлома. Это щеколда на сейфе. Проще добавить счетчик к полезным данным и зашифровать его в рамках одной сессии.
Имея вычислительные ресурсы можно и шифрование взломать :) Вопрос в разумном балансе между стойкостью ко взлому и минимальным энергопотреблением, которое привязано ко времени работы в эфире и требуемой вычислительной мощностью.
Даже упрощенный раза в четыре алгоритм, подобный MD5, с задаваемыми пользователем начальными значениями и солью байт на 8 будет уже достаточно стойким к взлому. Вряд ли кто-то будет тратить сотни или тысячи часов огромных вычислительных ресурсов для того чтобы просто взломать чей-то «умный дом».
Одно дело ломать протокол шифрования, а другое дело уязвимый простенький HASH. Может оказаться что ваш простенький алгоритм хеширования внезапно даст очень высокую частоту коллизий, и от 8 байт стойкости останется только 24 бита…
Конечно же он даст высокую частоту коллизий из-за своей простоты. Но как это поможет правильно подписать поддельное сообщение?
О чём вы спорите, если давно уже придуман AES-CMAC — и нет никаких поводов не подписывать пакет им, кроме жёсточайшей нехватки флэша и процессора?..

Ну или на худой конец HMAC с SHA-256.
а там никто стримить и не собирается, грузить фармвар по воздуху на батарейку это моветон.… Ну раз считаете что считать лучше потому что пакеты легхе, удачи…
Скажите, дорогой мой проектировщик сверхэкономичных метеостанций, вы понимаете, что четыре пакета в радио вместо двух — это год жизни на батарейке вместо двух?..
Спасибо за проектировщика, оценил,… в том смысле что «пукан» у кого то подорвало :)). Понимаю, и если мне нужны будут подписи для передачи например температуры(ответственный узел) я соглашусь с этим и расчитаю решение в железе. В других ситуациях просто зашифрую AESом. Ну а Вы закидайте меня ссылками на что то легкое но со всем этим на что тут у вас обоих vomitus обострился.
Понимаю, и если мне нужны будут подписи для передачи например температуры(ответственный узел) я соглашусь с этим и расчитаю решение в железе. В других ситуациях просто зашифрую AESом


А вы ведь не понимаете, как этот ваш MySensors работает, даже когда вам разжёвывают.
Ок :) Главное что бы Вы понимали, вам еще типа 6LoWPAN разворачивать.
У меня такое же ощущение о Вас. Вы тогда раскажите в каком месте стоит нумеровать пакеты в данной реализации радиообмена
Например, в заголовке. Или еще объяснить что такое заголовок пакета и в каком месте он нужен? :)
Мне объяснять не надо. Например зачем? Вы щас оба занимаетесь «водными процедурами». Совет, подключайтесь к товарищу на аутентичный почти 6LoWPAN на nRF52832 или форкайте MyS и впиливайте нумерацию.
github.com/mysensors/MySensors/wiki/Message.h
Например зачем?

Выше это Вам уже объяснялось, но Вы, похоже, не понимаете в силу отсутствия опыта и знаний. Но зачем-то спорите.
Да нгет же уважаемый, не понимаете как раз Вы, в силу чего?? тут может быть много причин…
Вы понимаете, что злоумышленник может, к примеру, заглушить любой пакет от сенсора, и шлюз об этом никогда не узнает?
Или, что хуже, он может отправить в эфир записанный ранее пакет на открытие замка от имени шлюза (со всеми подписями и шифрованиями) и замок откроется?
Судя по всему — нет, не понимаете.
Я еще раз повторюсь, невтыкаете Вы. Гейт узнает, что и нода в ауте, и отправить левый пакет не получится, неуспеет,… курите доки
Гейт узнает, что и нода в ауте

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

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

Слушаешь эфир, как только оно попросит у сервера nonce — врубаешь глушилку на секунду.

Если есть сосед-радиогубитель, поднявший у себя умный дом — можно свести его с ума.
… простите а какие именно пакеты вы считаете надо считать в данной реализации??


Очевидно, передаваемые в радио. Вы про защиту от атак повтором слышали когда-нибудь?

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


Меня в ней не может что-то устраивать или не устраивать — в силу отсутствия документации я ничего про неё не знаю. Однако в телеграм-канале мне сообщили, что в качестве подтверждения просто возвращается отправленный пакет, причём не всегда.

Соврали? Где прочитать про то, как на самом деле?

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


Про «ничего сложного» мне пишет человек, который не понимает даже задаваемых мной вопросов.
Мне кажется Вы понимаете только себя. Маякните как допилите свой протокол, было бы любопытно…
Маякните как допилите свой протокол

Запилить свой протокол — дело совершенно нехитрое. При наличии знаний.
Например



Непоспоришь, где нарыли? да вы батенька просто любитель потрещать и померяться...
где нарыли?

Запилил в одном из своих проектов.
А у Вас это что за картинка?
Не совсем понятно… Для передачи 10 байт данных передается пакет размером 88 байт?
ЗЫ: подумал было, что наконец-то раскрыта тайна протокола майсенсора :)))
Не совсем понятно… Для передачи 10 байт данных передается пакет размером 110 байт?
пересчитали? /// Ну вот так :), с нас «ардуинщиков» какой спрос ;)
Ну значит так надо. Вы бы не отвлекались и дальше MyS «раскуривали», может идеи какие посетят…
Ну так и в MyS, очевидно, все как надо и раскуривать кому ни попадя там не положено. Куда мне до его ардуинщиков :)
Вообще тут, конечно, самое прекрасное не то, что документации нет, а у автора какие-то свои голоса в голове — это в 9 опенсорс проектах из 10 так — а то, что люди из «в нашем сообществе ответят на все ваши вопросы» на самом деле не знают не то что ответов на вопросы, но и самих вопросов.

То есть всё их сообщество ответит максимум на вопрос о том, откуда либу скачать.
Разве они не отвечают на все ваши вопросы? «не знаю» — это формально тоже ответ, между прочим. Отвечать отвечают, всё как и заявлено… а вот удовлетворить каждого не обещали.
Ну снизойдите, поймите и научите.


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

Там я вас научу.
Я ознакомился ранее с Вашими статьями, действительно интересно и познавательно, но как учитель вы для меня дескредетированы.… И докладчик != учитель, у Вас явно с этим проблема…
Интересно, чем? Тем, что я рассказал вам, как работает продвигаемый вами же протокол, да ещё и указал на его проблемы (которые вы, пользуясь этим знанием, сможете решить и сделать протокол ещё лучше), но сделал это без должного уважения?
Тем, что я рассказал вам, как работает продвигаемый вами же протокол

Чем-чем а уж этим вы тут точно не занимались
Маякните как допилите свой протокол, было бы любопытно…


Там программировать надо будет. Вам не понравится.
Как уже отметили, это не описание протокола.

Правильно ли я понимаю, что всё, относящееся к радио, попросту не документировано никак?
Вообще говоря, я обо всех имеющихся уровнях по модели OSI.

Но в целом ситуация понятная — оно не документировано.
А зачем документировать? Это же для ардуинщиков, которые подключили скетч — и все работает. Или не работает — тогда писать в канал телеграма чтобы добрые люди сделали так чтобы работало :)
Объясните конкретно что вы хотите понять? Или у Вас просто много свободного времени?
У меня очень мало свободного времени.

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

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

Цикломатическая сложность очень высокая. Количество вложенных if просто огромное.
Выделите отдельные функции.

EFEKTA. В отделе выдумывания названий товаров ИКЕА рвут на себе волосы.
Не советую использовать NRF24L01, по крайне мере сам с ним намучался. 2.4ГГц забит очень. Когда сенсоров/актуаторов набирается с 10, многовато становится NACK-ов.
Открыл для себя RFM69, они в 915/433/итп конфигурации есть. При низком битрейте можно получить сотни метров при желании. Кстати MySensors его поддерживает.

Еще, советую использовать home-assistant (home-assistant.io). Оно умеет serial gateway от mysensors да и через mqtt.

433 тоже прилично бывает забит (различные сигнализации, метеостанции фабричного производства, различные ПДУ к дистанционно управляемым игрушкам и т.п.).
Так что надо смотреть по месту применения и делать протокол, разруливающий коллизии, когда своих устройств становится многовато для частоты.
Кстати, у того же NRF есть возможность выбирать канал (если правильно понял, частоту в некотором диапазоне возле 2.4ГГц), и в большинстве случаев свободный (некритично зашумленный) канал вполне находится.
Можно, конечно, еще давить мощностью (как передатчики на 433, так и NRF есть с неслабыми уровнями на выходе), но для метеодатчика это порождает избыточное потребление и увеличивает габариты за счет большой антенны.

  • на этих мощностях выхлоп и размер антенны никак не связаны
  • частота и размеры антенны (а также самого устройства) связаны очень даже напрямую — на 433 МГц в таких габаритах ничего хорошего не получится
  • больше 20 мВт на 433 МГц в эфир отдавать нельзя
  • больше 10 мВт/МГц на 2400 МГц в эфир отдавать нельзя
на этих мощностях выхлоп и размер антенны никак не связаны
частота и размеры антенны (а также самого устройства) связаны очень даже напрямую — на 433 МГц в таких габаритах ничего хорошего не получится

Если рассматривать готовые устройства, то из того, что я видел, физические размеры самих радиомодулей и антенн у мощных версий радиомодулей были примерно одинаковы вне зависимости от частоты (другой вопрос, что там реально внутри пластмассового корпуса антенны накручено).


больше 20 мВт на 433 МГц в эфир отдавать нельзя
больше 10 мВт/МГц на 2400 МГц в эфир отдавать нельзя

Могу ошибаться, но, судя по дистанции уверенного приема, у модулей с антенной, размещенной непосредственно на плате, явно не 10-20 мВт.

размеры самих радиомодулей и антенн у мощных версий радиомодулей были примерно одинаковы вне зависимости от частоты


Зато выхлоп в эфир у них очень сильно отличался.

Откройте даташиты на две похожие по размерам керамические антенны на 433 МГц и 2450 МГц — и сравните усиление и КПД. Физику не обманешь, чем дальше антенна и земля в размерах от четверти длины волны — тем хуже.

Могу ошибаться, но, судя по дистанции уверенного приема, у модулей с антенной, размещенной непосредственно на плате, явно не 10-20 мВт.


Обычно в пределах 5 мВт на 2450 МГц, 25 мВт на 868 МГц, 10 мВт на 433 МГц.
Зато выхлоп в эфир у них очень сильно отличался.

Возможно, что я недостаточно однозначно выразился, но упомянув про "давить мощностью" я имел ввиду изначально не вопрос соотношения мощностей на разных частотах, а возможность "перекричать" мешающих оппонентов на той же частоте.
Если модуль на 433 без внешней антенны дает, например, 10 мВт, то подключив другой, с внешней антенной и дающий 20 мВт, можно получить "конкурентное преимущество".
Конечно, путь ущербный, но вполне применяемый (на тех же WiFi роутерах народ постоянно таким балуется) и иногда даже дающий результат.

NRF24 умеет работать на 2.4 узкими каналами, как и WiFi и Bluetooth. Если поиграться каналами, то вполне можно найти свободный канал. Если сенсор большей частью спит (Passive mode) и выдает изредка короткие пакеты (выключатели, температурные сенсоры, датчики движения, открывания, протечек) — они могут сотнями друг другу не мешать.
1) Wi-Fi не умеет работать никакими узкими каналами, у него фиксированные каналы 20 МГц минимум

2) Мало передать, неплохо бы, чтобы кто-то ещё и принял — а для этого нужен либо приёмник с алгоритмом сканирования всех возможных каналов, либо общий для приёмника и передатчика алгоритм ПСПЧ
Зачем сканирование? задаёшь вручную(например DIP-переключателями) или один раз находишь в автоматическом режиме и запоминаешь до следующей длительной потери сигнала и/или нажатия кнопки пользователем. Кнопка, головная боль для пользователя… оно конечно понятно, но — это один из простых способов решения проблемы, это может быть на уровне инсталляции — этим вопросом(выбор канала) должен заниматься не пользователь а тот кто устанавливает и поддерживает систему. И кнопка сканирования может быть объявлена сервисной функцией.
802.11b досихпор ещё поддерживается, канал там достаточно узок — всего 1Мгц.
Зачем сканирование?

Затем, что найденный сейчас свободный (малошумящий) канал уже при следующей передаче через 5 минут может быть забит помехами или кем-то другим.
Если мы про умный дом, то по сложности инсталляции он не должен превосходить гибрид Wi-Fi-роутера с розеткой.

Соответственно, никакого «должен заниматься не пользователь» в нём нет.

И да, ничего особенного в сканировании каналов нет, в том же блютусе псевдослучайные скачки по всему спектру — из коробки, 79 каналов, 1600 переключений в секунду.

Вряд-ли лора целесообразна в пределах квартиры и её железо заметно дороже.

Lora не, не для этого она. Но и про 328 я сестно уже забыл как с полгода. Теперь все на nrf5
Я сейчас NRF51 ковыряюсь. В 99% железа хватает. Стоит ли на более дороги NRF52 переходить?
Пожалуй только если нужна работа от батарейки, на 52 можно слушать на 5мА, отправлять на 7мА, с дальнобоем на 9мА, на 51 серии все становится понятно как только в dc-dc mode получаем 12.5мА… многовато
А что сразу квартира, а если частный дом? Ворота/гараж/теплица, подвал?
Стены толстые, расстояния большие. Сяомишный zigbee из подвала вот не очень у меня добивает хорошо.
Ну тут каждому свое, у меня дом больше 200 кв, в основном все на nRF5 (естественнов режиме совместимости с nRF24) Зиг би хорош, щас в процессе изучения. Но опять же я не собираюсь юзать то что дает производитель. Но Lora… и не для дома
да, про нее. из комментариев я понял, что сегодняшняя публикация — некий рассказ о прошлом проекте («328 забыл с полгода как»)

как-то очень куце, точнее вообще никак – про самое интересное: потребление, время работы от батарейки, испытания дальности и влияние числа устройств на срок службы, а еще про головную часть.
Мне кажется это за рамками данной статьи. 328 не совсем батарейный чип, да и nrf24 c его 15-16мА то еще чудо. C nRF52 гораздо ловчее и экономичнее. 5-6мА слушаем, 7-8мА передаем. пара мка сон. Где почитать? Да наверное на форуме Mysensors.ru, на офф сайте mysensors.org, в чате. По дальности все стандартно, как и все другое на 2.4 это метров 20 по бетону. Но варианты есть и низкое потребление и метров 200 по бетону. nrf52832 PA. Думаю на этих выходных спаяю уже собственный модуль с PA
328 и NRF24 вполне себе нормальная комбинация. Мой девайс отсылающий данные каждые 5 минут и при этом не забыв моргнуть светодиодом держится более года от одной копейки CR2032. Главное что-бы NRF24 не совсем палевный был а 328 правильно настроен.
Наверное вертаю слова обратно. про Lora. Если в целом, а не конкретно исходя из моего понимания(батарейная тема, low power), то да, почему бы и нет. Тем более это даже в mysensors есть на rfm95.

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

Радио хорошо если нет возможности проложить провод или как временное решение до прокладки провода. К воротам и гаражу в частном доме не лень должно быть и провод проложить, ведь это надолго и надёжней. С внутренним пространством дома уже сложнее — если ремонт ещё не сделан, имеет смысл стационарные датчики подключить проводом, но такое бывает редко и просто очевидно. Поэтому внутри чаще всего имеет смысл в беспроводных датчиках — ремонт уже сделан, прокладывать провод нет возможности. Хотя есть вариант минимизировать уровни излучения — расположить «точки доступа» для датчиков максимально близко к ним в плинтусах, это снизит требования к мощности передатчика в датчике, а значит повысит автономность и/или помехоустойчивость. Вплоть до того что передавать данные по ИК-каналу.
Зато при том же качестве связи тратится меньше энергии, насколько я понимаю ее принцип.

В теории да. Например, в gsm мощность мобильного терминала подстраивается под текущие условия связи, она минимизируется на лету, что позволяет экономить батарею. Но как это сделать в описанном сценарии? Сначала установить связь с хостом на максимуме мощности, потом померять силу сигнала, получить от хоста потребный уровень мощности и только в конце передать пакет из жалких десятков байт? Так проще сразу пакет передать на максимуме.

Для стационарных устройств нет никакого смысла измерять силу сигнала каждый раз — достаточно это сделать однажды.
Сначала установить связь с хостом на максимуме мощности, потом померять силу сигнала, получить от хоста потребный уровень мощности и только в конце передать пакет из жалких десятков байт? Так проще сразу пакет передать на максимуме.

Думаю, что в пределах квартиры-дома можно сразу передавать на мощности, близкой к минимальной, но в широкой полосе.

Можно. Но сейчас придут желающие поставить датчик в подвал и скажут, что они не согласны. Другие придут и скажут, у нас однушка и нет лишних денег платить за over engineered продукт, дайте дешевле, нам хватит и 30м связи. Третьи скажут, цена роли не играет, но мы не собираемся менять батарейки в десятках датчиков в среднем раз в месяц, дайте работу от батареи 10 лет и т.д. Как обычно, выясняется, что универсального решения нет.

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

Холивар и демагогия. Автор сделал как ему хочется и поделился. Потом кто-то написал слово лора и понеслось. Да, можно и психрометр. Кому надо, тот сделает как хочет.

Запоминать предыдущий уровень мощности и корректировать при необходимости по ответу.
Платы заказывал в Китае на сайте jlcpcb.com, 2 бакса, любой цвет, и через 2 недели вы уже получаете на руки 10 штук «своего творения» :).

А во сколько обошелся shipping? В Украину сейчас 50x50 мм shipping там стоит $6.33.
И да, сейчас любой цвет 2 бакса, но только 5 штук. Если 10 штук — то 5 баксов.
В РФ где-то также доставка. Особенно если 1.0 — 1.2 делать
50x50 можно сделать 4 штуки на одном листе 100x100 и заказать 5 шт
Я еще стараюсь комбинировать несколько плат, отделяя их панелизацией (если много одинаковых) или фрезировкой, если разные. Все это в базовой стоимости
Я так понимаю, что питание от 2032?
Как решаете с просадкой напряжения при передаче (особенно перврй с таким количеством презентаций)?
NRF24 кушает до 20мА при передаче. Mysensors довольно прожорливый протокол и пока идет передача, несвежая батарейка садится проседает ниже 2В, а на таком напряжении мега даже на 8МГц не очень себя ведет.
Пробовал 2450 — пока свежая, нормально работает, стоит немного подсесть батарейки, та же проблема с просадкой напряжения
Хорошо, но дорого. Проще маленький литий-ионный аккумулятор уж воткнуть
Литий-ионный аккумулятор или очень дорог или не держит морозы/повышенную температуру. А посему категорически не пойдёт для наружного датчика. Попробуйте подобрать источник питания который бы держал -40 градусов мороз, хотябы в течении нескольких часов без последствий. В автомобиле летом на стоянке приборная панель прогревается до 100+ градусов в лёгкую. Если там что случайно забыть с литиевым аккумулятором можно получить пожар. Впрочем, 100 градусов и 2032 тоже не очень понравится…
Ну отлично, только с массо-габаритом у такой батареи не очень и соответственно ёмкость не очень большая по сравнению с плотностью энергии в 2032.
Именно что в разы. LiFe в формате 18650 и емкостью 1000ма*ч и таблетка примерно такого же диаметра но толщиной 3мм(существенная часть которой это корпус) емкостью 200ма*ч разница огромна.
Единственный источник, который всю зиму проработал за окном (-30), это литиевые батареи АА. У них и напряжение начальное 1.6В, и просадка от мороза минимальная

С другой стороны, много нужно уличных датчиков в умном доме, да еще и питающихся от батареи? Один, два?
презентации я отключаю. она(презентация по сути делается только раз при регистрации в новой сети, далее при перезагрузке или потере парента я шлю коротку презентацию, одним сообщением с айди парента если он изменился при перестроении маршрута. Майсенсорс вряд ли можно назвать прожерливым, вы наверное не видели дебаг при привязке энд девайса к координатору в зиг би :) Прожерлив радиомодуль nRF24l01, поэтому питание на cr2032 не особо подходит, но тем не менее делают и так, тут главное уже ПО — www.openhardware.io/view/657/Temp_Hum-sensors
2032 изначально не предназначена для токов разряда больше 2мА, проблема импульсного потребления решается за счет буфферного конденсатора, которого должно хватать на передачу одного пакета без повышения тока через батарейку(конденсатор заряжается от батареи через ограничение тока, резистор или ИСТ не принципиально), это накладывает ограничение лишь на частоту передачи пакетов.
Only those users with full accounts are able to leave comments. Log in, please.