MockIT создан для целей отладки и демонстрации, поэтому его возможности ограничены обеспечением передачи данных между экземплярами стека на одной машине (детали Вы можете узнать из файла tools/mockit/readme.md). Поэтому в настоящий момент связать между собой две ноды на основе решений в репозитории невозможно. Однако, как было сказано, скоро в репозиторий будет добавлен интерфейсный уровень для работы через LoRa, и с этого момента связь двух нод станет возможна без необходимости дописывать что-то своё.
Если Вас интересует API стека MOAR, то лучше всего обратить внимание на файл moarApi.h (libmoar/inc/moarApi.h), в котором дано описание функций API на английском языке. Для обращения к ним в своём проекте следует использовать в нём этот заголовочный файл и подключить динамическую библиотеку libmoar.so, которая будет находиться в директории lib после сборки проекта.
Русскоязычная описание API появится в ближайшее время.
Есть альфа-версия мок-интерфейса, она уже выложена в репозиторий вместе со стеком. Работает через виртуальную среду передачи данных, MockIT, которая также присутствует в репозитории. Версия интерфейсного уровня для Lora дописывается и скоро будет добавлена в репозиторий. После этого запланировано добавление поддержки WiFi и BLE.
Это статья продолжение. Мы разрабатываем стек протоколов для IoT сетей, о том что нас к этому побудило можно узнать перейдя по ссылке в начале статьи. В данной статье описано решение для linux, компиляция, настройка и запуск сервиса.
При использовании АКБ емкостью 2000 мАч, они должны работать не менее 4 часов. Реальное время зависит от температуры и длительности сеансов обмена данными.
Добрый день
1. Зачем мы выпускаем версию для «полноценного» linux на «полноценной» малине? Достаточно универсальная платформа, много скучающих программистов, гиков.
Мы бы хотели, чтобы в iot появлялось что-нибудь умнее лампочек и камер, а для этого, как нам кажется, нужны программисты, которые обычно не работают непосредственно с устройствами.
2. Что если кто-то сделает на открытой версии хороший продукт? Так это же будет замечательно, let it be, как нам кажется.
3. Мы начали работать с того, что нам не понравились Zigbee и 2g/3g. Оказалось, что потребность в новых решениях значительно больше и не ограничивается заменой плохого ZigBee и дорогого 2g/3g
Как уже было упомянуто (правда, иными словами), мы поставили перед собой задачу несколько более сложную и общую, чем условно-простое обеспечение mesh в рамках одного дома или одной квартиры. А Thread Guard, по их собственному указанию, предназначен исключительно для такого применения.
6LoWPAN также имеет несколько отличающуюся идею в своём основании: эти сети работают исключительно на одном типе интерфейса, тогда как мы стараемся не привязываться к конкретному типу физического интерфейса. В некотором смысле, мы хотим не «победить» другие решения, а подружить их между собой.
Упомянутые устройства на основе Raspberry Pi — в первую очередь тестовые, и в них нам важнее было не оптимизировать цену или какие-то аналогичные факторы, а обеспечить удобство разработки и расширяемость. Кроме того, Raspberry Pi 2B уже были у нас под рукой, тогда как Zero пришлось бы заказывать и ждать.
Насколько мы понимаем, наше решение несколько отличается от Вашего с идейной точки зрения:
1. Вероятно, используемая Вами система рассчитана на домашнее применение, а потому имеет некоторые ограничения, позволяющие её упростить (не нужно связывать ноды, скажем, на расстоянии 500 метров).
2. Мы принципиально отказались от разделения ролей узлов.
3. Мы поддерживаем любой нижележащий интерфейс (как физический, так и нет), и даже несколько разных одновременно. Разумеется, библиотека интерфейса должна отвечать некоторым требованиям, но это лишь один модуль нашего стека, а не весь стек.
4. Указанные нами требования включают в себя, помимо стека, саму ОС, и при этом ещё остаётся достаточно свободных ресурсов для пользовательского приложения или даже нескольких.
Так что Вы правы, и наше, и Ваше решения — IoT, но разного предназначения. Полагаю, история сама «раздаст» подходящие названия для соответствующих категорий.
Речь шла про питание маршрутизаторов. И если маршрутизатор — узел с постоянным питанием, то он перестаёт быть мобильным, а наше решение, как уже упоминалось, рассчитано на полностью динамические сети — то есть такие, где и маршрутизаторы вынуждены (непредсказуемо) менять своё положение.
1. Наша разработка независима от конкретного физического (и не только физического) интерфейса. При наличии соответствующих интерфейсных уровней можем работать и через LoRa, и через WiFi, и через BLE, и через ещё что-нибудь.
2. ZigBee выделяет какую-то из нод в качестве маршрутизатора; нагрузка на эту ноду резко возрастает, поскольку ей необходимо полностью маршрутизировать всю сеть в зоне своей ответственности, из-за чего нода может слишком быстро разрядиться. После её отключения то же самое происходит с другой нодой. И так далее.
3. Ключи шифрования не хранятся на координаторе. Никакого координатора у нас вообще нет.
1. Да, стек заточен под динамические системы.
2. В рамках Open Source DevKit будет возможность реализовывать собственные протоколы маршрутизации. Наше главное отличие это фокус на динамические сети, в которых маршрут постоянно перестраивается, поэтому мы минимизируем размеры таблицы маршрутизации.
3. Представленная нами нода была собрана под нужды тестирования и разработки. Добавить солнечную батарею можно, но пусть это сделают профессионалы.
4. При релизе мы заложим поддержку wi-fi + lora. Для связи нужно будет написать приложение на телефон.
5. Под ESP8266 есть рабочий проект который мы возили на SLUSH. Но там есть сложности в публикации под Open Source. Если интересно ESP на одной банке лития проработала больше 24 часов общаясь и моргая светодиодом. Если интересно могу больше деталей про ESP с фото представить после релиза.
В данной реализации есть не большой плюс над телефоном. Радио чип LoRa в радиусе до 1 км отлично себя показывает. Но в ваших условиях мобильный телефон будет действительно лучше. Есть приложение Firechat, может оно будет полезно.
Версия под андройд (точнее кастомная сборка) в планах есть. Мы сейчас решили сделать первый шаг с Линукс ОС просто потому что Rasbery Pie откопать можно сравнительно быстро и не дорого
Русскоязычная описание API появится в ближайшее время.
1. Зачем мы выпускаем версию для «полноценного» linux на «полноценной» малине? Достаточно универсальная платформа, много скучающих программистов, гиков.
Мы бы хотели, чтобы в iot появлялось что-нибудь умнее лампочек и камер, а для этого, как нам кажется, нужны программисты, которые обычно не работают непосредственно с устройствами.
2. Что если кто-то сделает на открытой версии хороший продукт? Так это же будет замечательно, let it be, как нам кажется.
3. Мы начали работать с того, что нам не понравились Zigbee и 2g/3g. Оказалось, что потребность в новых решениях значительно больше и не ограничивается заменой плохого ZigBee и дорогого 2g/3g
6LoWPAN также имеет несколько отличающуюся идею в своём основании: эти сети работают исключительно на одном типе интерфейса, тогда как мы стараемся не привязываться к конкретному типу физического интерфейса. В некотором смысле, мы хотим не «победить» другие решения, а подружить их между собой.
1. Вероятно, используемая Вами система рассчитана на домашнее применение, а потому имеет некоторые ограничения, позволяющие её упростить (не нужно связывать ноды, скажем, на расстоянии 500 метров).
2. Мы принципиально отказались от разделения ролей узлов.
3. Мы поддерживаем любой нижележащий интерфейс (как физический, так и нет), и даже несколько разных одновременно. Разумеется, библиотека интерфейса должна отвечать некоторым требованиям, но это лишь один модуль нашего стека, а не весь стек.
4. Указанные нами требования включают в себя, помимо стека, саму ОС, и при этом ещё остаётся достаточно свободных ресурсов для пользовательского приложения или даже нескольких.
Так что Вы правы, и наше, и Ваше решения — IoT, но разного предназначения. Полагаю, история сама «раздаст» подходящие названия для соответствующих категорий.
2. ZigBee выделяет какую-то из нод в качестве маршрутизатора; нагрузка на эту ноду резко возрастает, поскольку ей необходимо полностью маршрутизировать всю сеть в зоне своей ответственности, из-за чего нода может слишком быстро разрядиться. После её отключения то же самое происходит с другой нодой. И так далее.
3. Ключи шифрования не хранятся на координаторе. Никакого координатора у нас вообще нет.
2. В рамках Open Source DevKit будет возможность реализовывать собственные протоколы маршрутизации. Наше главное отличие это фокус на динамические сети, в которых маршрут постоянно перестраивается, поэтому мы минимизируем размеры таблицы маршрутизации.
3. Представленная нами нода была собрана под нужды тестирования и разработки. Добавить солнечную батарею можно, но пусть это сделают профессионалы.
4. При релизе мы заложим поддержку wi-fi + lora. Для связи нужно будет написать приложение на телефон.
5. Под ESP8266 есть рабочий проект который мы возили на SLUSH. Но там есть сложности в публикации под Open Source. Если интересно ESP на одной банке лития проработала больше 24 часов общаясь и моргая светодиодом. Если интересно могу больше деталей про ESP с фото представить после релиза.